Re: Begin discussions for pushing Last Call into 2010

Lachlan Hunt wrote:
> Shelley Powers wrote:
>> That may be what Sam is suggesting -- to raise the issue now as a Formal
>> Objection, not in the Issues database.
>>
>> I can do that, but I thought Formal Objections normally came after a
>> publication, and the HTML 5 spec is still only a Working Draft. But I
>> could see how the vote was _a_ decision, and so a FO now would also be
>> appropriate.
>
> Could you please at least clearly and concisely state your technical 
> objections and justification, so that we can discuss the issue 
> properly within the group?  Whether or not you frame it as a formal 
> objection does not concern me, I'm only interested in the technical 
> aspects.
>
The issue of Canvas and accessibility was raised in the WhatWG group 
back in 2005.

This is from an email Dean Jackson posted, when the inclusion of Canvas 
was being discussed for what was then WA1 (Web Applications) [1]:

"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."

This also references the arguments that Doug Schepers provided, that the 
2D API basically describes nothing when it comes to anything specific to 
the page.

However, that nothing does have appeal, and since that nothing has been 
implemented in several browsers, the nothing should be treated as 
_something_ -- just not _something_ within the HTML 5 specification.

That's HTML, not WA, by the way. We're working on a new HTML 
specification. Just a reminder.

Shelley

[1] 
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2005-April/003719.html

Received on Thursday, 13 August 2009 14:59:01 UTC