Wednesday 30 May 2012
The Canvas getContext() Mistake
The HTML <canvas> element has a getContext(type) method that takes a string parameter identify a context type (e.g. "2d" or "webgl") and returns a context object of that type. The string parameter was introduced as an extension point to make it easier to add new context types.
This was a mistake. It would have been simpler, and just as extensible, to define a new attribute on the <canvas> element for each new kind of context. E.g. canvasElement.context2d, canvasElement.contextWebGL, and even experimental vendor-specific contexts such as canvasElement.mozContext3d. Less code to write, slightly more efficient, and easier feature detection. (If some contexts need parameters, or we consider getting a context to have more side-effects than is seemly for an attribute getter, we could have used independent methods instead, e.g. canvasElement.getContext2d().)
Of course we're stuck with getContext now for Web compatibility. The reason I mention this is because from time to time I see people trying to use getContext() as a model for extensibility in other Web APIs. Don't do that.
Actually, most of the time when I see someone trying to use getContext() as a model, they're using it because they think it gives them an escape hatch from the world of Web standards. They seem to think that it would be OK to pass in vendor-specific strings, get back vendor-specific objects, and never specify or even document the behavior of those objects. This is incorrect. It's no more acceptable to have permanently non-standard Web APIs accessed through vendor-specific strings than it would be to have them accessible through vendor-specific attributes.
Comments