- From: Dean Jackson <dean@w3.org>
- Date: Sat, 6 Nov 2004 01:23:53 +1100
- To: Ian Hickson <ian@hixie.ch>
- Cc: www-archive@w3.org
On 6 Nov 2004, at 00:16, Ian Hickson wrote:
- Suppose you use <canvas> for a dynamic stock graph. How is
>> a screen reader going to "display" the content of the
>> graph to the user?
>
> Same as with SVG; it'll fall back to the alternative content.
Sorry, I wasn't clear. I meant that it is possible to
write a screen reader that understands SVG (and there are
a few), but not for canvas.
>> (I guess you could manually ask for all the style
>> properties that can be computed on the <canvas> element in the
>> javascript, but you'd end up writing a good amount of a CSS
>> engine this way, it's extremely limited and every use of <canvas> in
>> the entire web would have to add this code into their scripts).
>> Using SVG you could assign class="points" class="label" class="note"
>> and so on.
>
> (...assuming that SVG doesn't drop CSS support, which is looking to be
> an
> increasingly popular idea in the SVG working group as I understand it.)
It's true that we've found a lot of CSS not very useful in SVG
and all the implementers complain about how hard CSS is to implement
compared to SVG (and hence why it isn't in SVG Tiny). However, even
if we removed CSS stylesheet support completely, we'll still have the
model, and we wouldn't consider anything that reduced accessibility.
>> - The standard way to program Web content is by manipulating a
>> document (adding elements, changing attributes, etc). The data
>> structure
>> of the program is the document. Unfortunately <canvas> throws this
>> completely out the window and forces people to learn a new paradigm
>> (and often people will need to use both the well-known programming
>> model
>> alongside the new model).
>
> A bitmap canvas is a pretty old paradigm, to be fair. Games have been
> using it since the dawn of the video card.
Oh yes, of course. As I said, it's what a graphics textbook would
call an immediate mode drawing API. It's by far the most common
way to draw graphics. However, it isn't the model used on the Web
(for good reasons).
> Also, the way you describe it makes it sound like applications would be
> built out of <canvas>. That is highly unlikely. <canvas> is just a
> part of
> a wider language (HTML) -- heck, <canvas> doesn't even support basic
> text
> output, for instance.
I don't get you. Obviously you'll embed <canvas> in HTML (or SVG if
you wanted). But it is this embedding that causes the clash - document
model vs immediate mode.
And I think you're wrong. People *will* build applications out of
<canvas>.
Look at the Dashboard analogue clock example - obviously it uses
HTML/CSS to put the numbers on the clock face, but that doesn't
add anything to the application. Take the numbers away and you have
the same application built out of <canvas>.
>
>
>> You posted this code to www-archive:
>>
>> var canvas = document.getElementById('photo').getContext('2d');
>> function addCircle(x, y) {
>> canvas.lineWidth = 2;
>> canvas.moveTo(x - 10, y);
>> canvas.arc(x, y, 10, 0, Math.PI * 2, true);
>> canvas.stroke();
>> }
>>
>> After this has run, there isn't any circle in the document. There
>> isn't
>> any way a programmer can actually find out what has been added to
>> the
>> <canvas> (same for a screen reader).
>
> Yup. Just like with any other bitmap, which is what <canvas> is -- an
> API
> for JavaScript to generate bitmaps that are displayed on the fly.
But the problem is that it is generating bitmaps using an API where
there
are much more accessible and semantically rich ways to do exactly the
same thing.
>> <canvas> forces a radically different programming model
>> on Web authors - they have to be responsible for their own data
>> storage mechanisms, and the semantic concepts are never added to the
>> document.
>
> Correct.
Isn't that exactly what you've been saying is a Bad Thing (tm)?
>> Compare this to SVG: [...]
>
> Indeed, with SVG you would have a whole DOM and everything.
... which is both a well-known programming model and the fundamental
interface to accessibility engines.
> However, I can say that we have internal estimates that SVG 1.1 Tiny
> would
> take at least a year to implement, and that <canvas> would take a week.
My estimate for SVG 1.1 Tiny would be less (but I'm not going to argue
because it depends on your existing platform, toolsuite, experience
and about a zillion other things).
> Similarly, it would take me around a decade to write a solid test suite
> for SVG 1.1, whereas I could write a solid <canvas> test suite in a
> month
> or so.
I never meant to imply that people need all of SVG 1.1 for <canvas>.
If you meant to say SVG 1.1 Tiny, then I think you're overstating
(although you're most welcome to spend the next 10 years proving me
wrong :)
> So I wouldn't say that SVG is "not much more work".
In that case I'll ask another question: if there was a profile
of SVG that exactly matched the graphical capabilities of
canvas, how much extra would it take to implement?
I'd expect that you could do it using <canvas> pretty quickly.
Dean
Received on Friday, 5 November 2004 14:24:03 UTC