Re: Use Cases for The <canvas> Element

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