W3C home > Mailing lists > Public > public-html@w3.org > July 2007

Re: Use Cases for The <canvas> Element

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 30 Jul 2007 12:07:22 -0700
Cc: Sander Tekelenburg <st@isoc.nl>, public-html@w3.org
Message-Id: <EA12CE7B-BB65-4908-ADA1-2A89FF935DAD@apple.com>
To: Lachlan Hunt <lachlan.hunt@lachy.id.au>


On Jul 29, 2007, at 7:29 PM, Lachlan Hunt wrote:

>
> Sander Tekelenburg wrote:
>>
>> As hard as I try, I don't see how to interpret that as anything  
>> else then "UA
>> vendors will do what they want, the rest of you will just have to  
>> play by
>> some rules we set for you".
>
> It is unfortunate that Apple went ahead and implemented it without  
> much public discussion during its development, but we can't change  
> the past.

For the record, Apple's implementation long predates the existence of  
this working group, and at the time there was no active web standards  
process for enhancing HTML.

I do think <canvas> as it currently stands has some unfortunate warts  
and quirks in its API, but none that are so bad they'd make you want  
to throw the whole thing out and replace it with something else.

>>> Plus, as my examples showed, it's already being widely used.
>> If that's an argument, then clearly the need for native SVG is  
>> stronger than
>> that for <canvas>, as Karl listed more examples.
>
> Yes, SVG in HTML has been discussed as a possibility in the past on  
> the whatwg mailing list.  It's just not particularly easy  
> considering issues like parsing requirements, namespaces, etc.

The browsers that do have native SVG implementations let you insert  
SVG elements dynamically in the DOM at least, even in HTML documents.  
However, SVG and <canvas> have different cost-benefit tradeoffs and  
I'd argue that both are useful.

Regards,
Maciej
Received on Monday, 30 July 2007 19:07:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:02 GMT