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

[Taken off www-svg since JonF requested that I not send non-SVG-related 
content to the www-svg list. cc'ing www-archive instead. Feel free to 
send this to www-svg if you want.]

On Fri, 5 Nov 2004, Dean Jackson wrote:
> > 
> > The only valid use case I can think of for graphical elements in HTML 
> > is things like dynamic stock graphs, maps, and the like. Dynamic stock 
> > graphs are easiest done with something like Apple's <canvas>
> 
> I'm really confused now. For the last few days you've been suggesting 
> that you wanted more accessible markup, more semantic markup and a 
> better separation of content from presentation. Now, you suggest people 
> use <canvas>!

Not to the exclusion of other markup. Jim asked if I said that it would be 
bad to add more graphical elements to HTML; I was merely explaining the 
only use cases I saw.

<canvas> is much like <object>. You still have to provide alternative 
markup, as in:

   <canvas id="graph">
    <table>
     <tr>
      <th>Item</th> <td>A</td> <td>B</td>
      <th>Mass</th> <td>2g</td> <td>1.2g</td>
     </tr>
    </table>
   </canvas>


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


>   I'm a blind user that wants to find
>   the highest point on the graph, how can I query the <canvas>
>   model to find the object you added?

You can't, just like with SVG. In fact, you're highly unlikely to be able 
to tell that it _is_ a graph.


>   I also want to know
>   what colour it was (because the HTML text around the canvas
>   said "You'll see that the red point on the graph....").

It would be silly to use <canvas> for static images like that.


>   <canvas> is very inaccessible compared to SVG.

<canvas> shouldn't be used in isolation. It's as inaccessible as a bitmap 
image, which is in fact exactly what it is.


> - How are you going to style the graphics in the <canvas>?

You won't. It's a bitmap, just like a PNG, and cannot be styled.


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


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

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.


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


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


>   Compare this to SVG: [...]

Indeed, with SVG you would have a whole DOM and everything.


>   In some ways it could be argued that <canvas> separates content
>   from presentation. The problem is that the <canvas> content is
>   never really part of the document. Canvas is an immediate mode
>   drawing API only.

Exactly.


> SVG and <canvas> are both APIs. They use a very similar graphics model. 
> I see a lot of people saying that <canvas> is easier to implement than 
> SVG, and I agree. In Apple's case they are exposing the existing 
> platform features. However, to implement the equivalent features in SVG 
> wouldn't be much more work, and then you'd get the benefits of 
> accessibility, semantics and a well-known programming model. As an added 
> benefit, you'd probably implement the XML serialisation of SVG at the 
> same time, allowing people to paste SVG graphics into the document.

I can't speak for Apple, but when it comes to Opera, <canvas> and SVG are 
totally separate concerns, and are not pitted against each other any more 
than HTML and XML Events are pitted against each other when it comes to 
deciding what engineering time should be spent on.

Similarly, in the Mozilla world the SVG and <canvas> projects are done by 
totally different teams.

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. 
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. So I wouldn't say that SVG is "not much more work".


> I'm guessing that a lot of people are going to use a drawing tool such 
> as Sodipodi or Illustrator for their graphics. How do they get those 
> into <canvas>?

They don't. That's the kind of thing you would use SVG for.

Note that I have never suggested that SVG and <canvas> are even remotely 
competing. I consider them to be complimentary technologies. I wouldn't 
want to write a game like Doom using SVG; I wouldn't want to draw a 
company logo sing <canvas>.


> Note, I don't have anything against <canvas> per se. I like it and even 
> proposed the feature a few years back for SVG 1.2. I think it has some 
> appropriate uses, such as when the developer doesn't actually have any 
> need to put things into the object model, or has the need to draw 
> millions of objects that would otherwise chew up the memory (in this 
> case the author wouldn't care about reproducibility).

Exactly.


> However, I do have a big problem with you suggesting that people should 
> use <canvas> in a way that potentially damages the Web and goes against 
> all the things you've been telling us you believe in.

I hadn't realised that I had done so.

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

Received on Friday, 5 November 2004 13:16:19 UTC