[whatwg] Canvas element

[Dean Jackson]

On 21 Apr 2005, at 01:20, Olav Junker Kjær wrote:

> I don't completely understand the rationale for the canvas-element in 
> WA1.
>
> 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
the document, you just call javascript methods.

Obviously this has pretty significant accessibility problems. There is 
no
content in <canvas> - it's just script. With document-based graphics
solutions, such as SVG and even Flash, there is real content in the 
document.
Accessibility tools can access that content and provide alternate 
renderings
(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, 
radius,
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.
Well, that isn't really true. You could, in your javascript code that is
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:

circle {
   fill: red;
}

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
have to implement code in Javascript to do the graphics management 
(redrawing
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 
typically
involves a designer drawing the artwork in an illustration tool. How 
would
you get that illustration into canvas? It would be pretty difficult, not
to mention extremely verbose and unmaintainable, to convert the 
illustration
into Javascript commands. Compare this to a document model such as SVG
where you simply export the illustration. You can reuse that 
illustration
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 
which
are better suited in the vast majority of cases, have a higher level
of semantics, more in line with the accepted Web architecture and 
developer
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.

Dean