[whatwg] Canvas element
dean at w3.org
Wed Apr 20 10:21:10 PDT 2005
On 21 Apr 2005, at 01:20, Olav Junker Kjær wrote:
> I don't completely understand the rationale for the canvas-element in
> It seems to overlap a lot with the use case for SVG. Of course WF2
> competes directly with XForms also, but WF2 has the critical advantage
> that it is backwards compatible, implementable in script (which allows
> an IE implementation), and leverages existing knowledge.
> Canvas does none of this, its completely new and has to be implemented
> by the browser vendors. This rules out that it will ever be supported
> by IE, which in turn means that it will not be used on the world wide
> web in the foreseeable future (and most likely never). I understand
> that it was invented by Apple for use in platform specific
> applications. This makes sense, and it also makes sense that other
> vendors might want to support it in non-www contexts. Mozilla could
> use it in XUL, for example.
Furthermore, it's a completely different model to the one that Web
developers are used to. Why would you go against accepted practise?
In HTML, you use script to modify the content of the document using the
DOM. Your model is the document. If you want to change the view, then
you update the model via the DOM and the view is changed accordingly.
With <canvas> your document doesn't have the content. You don't update
Obviously this has pretty significant accessibility problems. There is
content in <canvas> - it's just script. With document-based graphics
solutions, such as SVG and even Flash, there is real content in the
Accessibility tools can access that content and provide alternate
(such as voice).
For example, when you draw a circle in SVG you add a <circle> element
into the document. That element has attributes, such as position,
fill colour, a textual description, etc. All these attributes are
part of the DOM and available to accessibility tools. There *really*
is a circle in the document.
Using canvas there isn't a circle. There isn't anything. All that
has happened is that some pixels on the screen have been coloured
in. Those pixels don't have any meaning.
Imagine if you had to call document.write to generate your *entire* HTML
document everytime you wanted to change anything? Actually even
that is better than canvas. Imagine if you had to draw all the pixels
of all the text, rather than put the text in the document?
How do you style a canvas? You can't, because there are no elements.
doing all the drawing everytime you want an update, decide to query
the CSS OM and work out, in script, whether or not any styling rules
should apply. But it isn't as easy as doing:
The canvas model is what we call immediate mode drawing in the graphics
community. It's popular, but suited to drawing millions and millions
of objects where it is impractical to keep the content in memory. There
are performance tradeoffs on the graphics side as well. Developers will
everything all the time is usually a bad idea). I won't look forward
to coding this again and again. Using a document model solution the
implementation doesn't need to redraw everything. It knows what parts
need updating. It can cache renderings of elements that have not
changed for increased performance, The developer doesn't need to worry.
Canvas exists to draw graphics. The workflow of such applications
involves a designer drawing the artwork in an illustration tool. How
you get that illustration into canvas? It would be pretty difficult, not
to mention extremely verbose and unmaintainable, to convert the
where you simply export the illustration. You can reuse that
in multiple places, in multiple documents.
I'm not against the idea completely as it has a certain set of limited
areas where it is applicable. But I think there are other solutions
are better suited in the vast majority of cases, have a higher level
of semantics, more in line with the accepted Web architecture and
experience and much more accessible.
I've seen the Dashboard widgets that use canvas (there isn't many of
them). In every case it would be just as easy to use SVG, and much
more suitable (and probably with better performance). My feeling is
that canvas provides a worse alternative to a problem that is already
solved by SVG (and implemented in Opera and Firefox). Or even Flash....
and believe me it hurts to say that.
More information about the whatwg