- From: Doug Schepers <schepers@w3.org>
- Date: Wed, 01 Aug 2007 05:57:44 -0400
- To: "public-html@w3.org" <public-html@w3.org>
Hi- Maciej Stachowiak wrote (on 7/30/2007 3:07 PM): > > 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". I'm very confused by this attitude. Specifications without implementations are useless. I can understand the idea of pressuring vendors to provide more features or better interoperability, but pressuring them to provide fewer interoperable features seems counterintuitive. It gives authors more choice. >> It is unfortunate that Apple went ahead and implemented it without >> much public discussion during its development, but we can't change the >> past. Why is it unfortunate? Apple saw a need for a feature, implemented it, and is (presumably) bringing it to a standards body so it can be implemented royalty-free. That's one way that standards get made, and it's often a very efficient one. Obviously, when there are issue of patent encumbrance, or of competing implementations or approaches that need to be reconciled, that's troublesome, but I see nothing wrong with bringing a proven technology to the table. > 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 think Apple is to be thanked for not trying to lock a technology away in its own proprietary sandbox. > 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. I've only played with 'canvas', not built anything real with it, so could you explain (or point me to a discussion) of the "warts and quirks"? Are they things that could be fixed? Do they severely impact the usability or authorability? >>>> 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. I think that there is a lack of will to integrate SVG into HTML, not a serious technical issue. As Sam Ruby has pointed out, the namespace issue is hardly insurmountable. > 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. I would agree with that. For example, SVG will never be a 3D format, and the DOM underpinnings mean that it can be slow if not implemented carefully; 'canvas' can address both those issues. Interactivity in SVG is more advanced, and it has a richer feature set. In the end, I think that using each of them where it's most appropriate, or even using them together, is the best choice for authors. p.s. I still think that the 'canvas' drawing API belongs in the Graphics Activity, not in HTML itself. Regards- -Doug Schepers W3C Staff Contact, SVG, CDF, and WebAPI
Received on Wednesday, 1 August 2007 09:58:00 UTC