1
edit
Changes
no edit summary
=SIGGRAPH 2010=
==Browser Unification==
One thing the web is known for is innovation. This is the case for Processing.js and many of the browsers on which the library is used. With innovation, there comes differences in implementation. Each browser handles key strokes and other web events differently. This is due to a somewhat lenient standardization that mostly just ensures that certain events exist. It is not preventative for browser vendors to customize and create their own unique events, which would stifle innovation.
Developers need to make sure that their creation handles the necessary differences for all browsers. We ensured that this was done for Processing.js so that the functionality of the Processing language be easily accessible for the open web. Processing.js does not only handle events, but it takes those events and standardizes it to copy (or at the very least imitate) a proper Processing compilation. One of the biggest pieces of code in Processing.js that we worked on to unify the browsers involve key events.
Handling key events was a difficult task because not only were there different browsers but the functionality of those browsers varied with different operating systems. We found glitches wherein Google Chrome was doing something entirely different on an Apple OSX system compared to Google Chrome on a Linux Ubuntu system. We opted for feature detection to handle specific bugs such as the aforementioned. It was the appropriate move compared to browser detection, which would have left it less manageable and more complicated. Browser detection involves obtaining a specific string or phrase that we can extract from browsers. However, this method is dangerous due to the fact that we can never really predict what the string we extract will say. One version may say something but the next update from the browser vendor may change the string entirely. If relied upon, it would break whole sections of code. Feature detection may still break if the feature is removed within the next update. The great idea behind feature detection is that it would only break that specific feature within the code and can be easily pinpointed.
Key event feature detection turned out to be a daunting task. Generally, this wouldn't be such a tough task. It would involve just returning or modifying the key given by the stroke and browser. With Processing, it involves the use of user written functions when pressing, holding or releasing a key. So, we had to adapt the browser key strokes to run those functions when needed. This adaptation involved making sure that the keys were fired and re-fired properly. It involved a lot of testing and manipulating using a Processing IDE.
(figure/image of w3c keycode/charcode app comparing chrome and firefox, using the same key (a) - http://www.w3.org/2002/09/tests/keys.html)
As seen above (in Figure …), keyCode under the keypress column on Firefox fires a 0. Whereas the same row and column on Chrome, gives a 97 like the charCode. Re-firing of keys also differ. Chrome likes to re-fire both the keydown and keypress events; Firefox only re-fires the keypress. Manually adjusting and testing this was definitely a task. In the end, we managed to replicate the key strokes of Processing while using different browsers and maintaining browser accessibility for artists and developers.
Keys are not the only code we've worked with to ensuring browser accessibility. Another example is the newly implemented typed arrays for Javascript.
// Typed Arrays: fallback to WebGL arrays or Native JS arrays if unavailable
function setupTypedArray(name, fallback) {
// check if TypedArray exists
// typeof on Minefield and Chrome return function, typeof on Webkit returns object.
if (typeof this[name] !== "function" && typeof this[name] !== "object") {
// nope.. check if WebGLArray exists
if (typeof this[fallback] === "function") {
this[name] = this[fallback];
} else {
// nope.. set as Native JS array
this[name] = function(obj) {
if (obj instanceof Array) {
return obj;
} else if (typeof obj === "number") {
return new Array(obj);
}
};
}
}
}
The code above shows feature detection for typed arrays. As seen from the commenting, Minefield/Firefox and Chrome return functions for the typeof the object and webkit returns an object. In new technologies like this and WebGL, as another example, standardization is very new and limited so browsers have lots of wiggle room to customize. We, as developers of Processing.js, code it so when other developers use our library they do not have to worry about the differences and quirks of different browsers.
Resources:
http://www.w3.org/2002/09/tests/keys.html
http://www.quirksmode.org/
==community and collaboration==
Society has a vital interest in encouraging and rewarding innovation. Presently, there are two major models characterizing how this may be done. The first, the “private investment” model and the second, the “collective action” model (von Hippel and von Krogh 2003). Von Hippel and von Krogh go on to say that the private investment model assumes private returns to the innovator resulting from private goods and efficient rule of intellectual property protection. Whereas the collective action model assumes collaboration from multiple innovators resulting in a public good that can be accessed by anyone.