Re: SURVEY: Accept requirement for immediate mode graphics a la canvas element?

On Nov 30, 2007, at 7:02 AM, Dr. Olaf Hoffmann wrote:

>
> Anne van Kesteren wrote:
>
>> On Fri, 30 Nov 2007 15:15:11 +0100, James Graham <jg307@cam.ac.uk>  
>> wrote:
>>> Richard Schwerdtfeger wrote:
>>>>   One alternative does not fit all even though a fallback may be an
>>>>   improvement for some.
>>>>   I am concerned that we would advocate using canvas over SVG  
>>>> where we
>>>>   would have an opportunity to apply semantics to the base drawing,
>>>
>>> I don't think we would advocate <canvas> where a more appropriate
>>> technology exists, only where it makes sense.
>
>> This is in fact what the _second_ paragraph of the <canvas> section  
>> says:
>> "Authors SHOULD NOT use the canvas element in a document when a more
>> suitable element is available."
>
> I think, this part of the working draft would be more convincing, if  
> there was
> an element like animation (as in SMIL, SVG Tiny 1.2 or vector or  
> however one
> might call it) to reference vector graphics too (optionally with  
> server-sided
> generation to avoid user-sided scripting) - either as an external file
> similar to audio or video or to embed it in a mixed document XHTML+SVG
> as a clear separation...

There are already multiple appropriate ways to embed SVG in HTML or  
XHTML:

1) For an SVG document that is an image or animated image, without  
interaction, embedding in <img> is suitable (this is supported in  
experimental builds of Opera and Safari).

2) For an SVG document that is a purely presentational decuration,  
referencing as a CSS background image is suitable (this is supported  
in experimental builds of Opera and Safari).

3) For an SVG document that supports rich interaction (and has more  
application-like properties) or that requires scripting interaction  
between the containing HTML document and the SVG, either <object> or  
<iframe> is suitable. This works today in the latest shipping versions  
of Safari, Opera and Firefox. <object> even works in IE with a  
suitable plugin installed.

4) In XHTML, the <svg> element in the SVG namespace is a suitable way  
to embed any kind of inline SVG dicrectly in the same document. Many  
are working on a design to let this work in HTML as well.

5) In both Classic and XML serializations of HTML, SVG content can be  
dynamically generated by script and inserted into the DOM at runtime,  
with an svg:svg element as root. This is perhaps closest to the way  
<canvas> operates. This is supported by Safari, Opera and Firefox and  
is used by popular JavaScript libraries, such as the Dojo charting  
toolkit.

So, I think most of the needed technological capabilities are there,  
and some new ones are under development. I'm not sure that adding yet  
another way to embed SVG which does not yet work in any browser and  
doesn't provide any new capabilities over the current options is  
necessary or helpful.

> Alternatively the 'functionality' of canvas could be integrated into  
> the img
> element - seems to be a raster image format too, therefore this fits  
> somehow
> together and does not require yet another element for the same type of
> graphics. Else, without scripting support or without activated  
> scripting,
> canvas seems to be empty or presumably decorative or can be replaced
> with other arbitrary elements like div maybe or span.

This has been considered. However, the fallback behavior of a new  
element that can contain content (like <canvas>) is better than the  
fallback for a new API on an existing element that has rich markup  
fallback. Also, <canvas> is already widely implemented and deployed,  
so the new approach would have to be much better to work effectively.

Regards,
Maciej

Received on Friday, 30 November 2007 20:53:12 UTC