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

On 5 Nov 2004, at 05:49, Ian Hickson wrote:

>
> On Thu, 4 Nov 2004, Jim Ley wrote:
>>
>> Are you saying it would be a bad idea to add more graphical elements 
>> to
>> HTML?
>
> 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>!

- 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? 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? 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....").
   <canvas> is very inaccessible compared to SVG.

- How are you going to style the graphics in the <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.

- 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). 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). There isn't any way they can 
update
   the lineWidth to 4 (without redrawing it). Even worse, the highest 
level
   of semantic meaning you can extract from this is that you drew an
   arc - there isn't any concept of a "circle" here. And you can only
   extract that meaning by listening to all the individual method calls 
- what
   a nightmare!!  <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.

   Compare this to SVG:
   var photo = document.getElementById('photo');
   function addCircle(x, y) {
     var c = document.createElementNS(svgns, "circle");
     c.setAttribute("cx", x);
     c.setAttribute("cy", y);
     c.setAttribute("r", 5);
     c.setAttribute("style", "fill:none;stroke-width:2;stroke:black;");
     photo.appendChild(c);
   }

   Now the document *really* does have a circle in it. Screen readers
   can find it. I can change the style. I can give it an id and move
   it anywhere, transform it, remove it from the "photo" group and add
   it into the "banana" group. This is the normal way HTML and the
   Web works.

   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.

- You mentioned the word "dynamic". This could either mean that the
   graph changes (eg. displays new data) or is animated somehow (maybe
   due to an update, or maybe to provide a visual highlight).
   SVG provides a declarative animation model, which can be exposed
   to accessibility tools (and avoids the need for Javascript, which
   is sometimes disabled). There isn't a similar declarative interface
   to <canvas>, so animation would be a Javascript loop (much less 
efficient
   and much less accessible).

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

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

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.

If anyone's interested, Antoine and I drafted a document that goes
into a little more detail, and describes a potential fast-track to
implementing the features of <canvas> using SVG.

Dean

Received on Friday, 5 November 2004 11:45:27 UTC