- From: Jonathan Chetwynd <j.chetwynd@btinternet.com>
- Date: Fri, 5 Nov 2004 12:24:03 +0000
- To: Dean Jackson <dean@w3.org>
- Cc: Ian Hickson <ian@hixie.ch>, www-svg@w3.org
Dean, I'm thrilled by your reposte. However doesn't it seem clear that a vocabulary of 'circle' is somewhat limited? I've created an rdf gui schema, at http://www.peepo.co.uk, but it's still not clear to me how this could be used within SVG to respond to queries. in fact it's got that bad that I had a morning nightmare recently, imagining that all that redundant DNA code was RDF the phenotype being SVG demonstrated as if you didn't know. so you can see that my understanding at least is somewhat lacking ~:" do we have any working examples? regards Jonathan Chetwynd http://www.peepo.co.uk "It's easy to use" irc://freenode/accessibility On 5 Nov 2004, at 11:45, Dean Jackson wrote: 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 12:24:36 UTC