Re: SVG 1.2 Comment: Detailed last call comments (all chapters)

On Sat, 6 Nov 2004, Dean Jackson wrote:
> 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.

How do these screen readers read charts? Do you have any URIs for these? I 
couldn't find anything about them.


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

If you removed CSS stylesheet support completely, you wouldn't have the 
cascade any more, and thus you wouldn't have this model, as far as I can 
tell.


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

Neither is vector graphics. The model used on the Web is bitmaps generated 
by servers. I'm sure you'll agree that almost anything is an improvement 
over that.


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

Well, sure, in as much as games will be written in <canvas>. Clocks and 
games, though, are cases where alternate-medium accessibility is not 
really important. The entire point of a graphical clock and a 3D game is 
that they are, well, graphical.

Applications with actual content would use HTML4, and Web Forms and Web 
Apps extensions, to host their UI, not <canvas>.


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

I guess I don't see the problem with that "clash" (or even that it is a 
clash).


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

Like what? Certainly not SVG.


> > >   <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)?

It's definitely possible to abuse <canvas> -- it's possible to abuse HTML. 
It's common, even.

My point is that by design, <canvas> doesn't encourage that kind of abuse. 
For example, it has no text features. It doesn't make it easy to do hover 
effects. And so forth. It's designed (and only really easy to use) for 
generating bitmaps on the fly instead of asking the server to do it.

SVG, on the other hand -- SVG 1.2 in particular -- makes it _easy_ to 
create entire applications purely using the presentation layer.


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

Even if it was _half_ the time, and <canvas> took _twice_ the time, 2 
weeks versus 6 months is rather a big difference. There is simply no way 
that SVG could be considered in the same sort of time frame as <canvas>.


> > 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 :)

I meant SVG 1.1. The spec that the SVG working group has said it has 
tested and found interoperable.


> > 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 do not believe it is possible to profile SVG in such a way as to only 
leave a feature set that exactly matches <canvas>. In any case, if it was 
possible, such a profile would be such a ridiculously small profile of SVG 
that I don't really understand what the point would be.

Unless the SVG group would consider trimming SVG Full down to that level...

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 10 November 2004 13:03:11 UTC