- From: Maciej Stachowiak <mjs@apple.com>
- Date: Mon, 30 Jul 2007 12:07:22 -0700
- To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- Cc: Sander Tekelenburg <st@isoc.nl>, public-html@w3.org
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 UTC