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

Thomas Broyer wrote:

>2007/11/30, Dr. Olaf Hoffmann:
>
> 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.

>When scripting is disabled (or when there is no scripting support at
>all), <canvas> should "fallback" to its content (because the whole
>point of <canvas> is to be scripted).

Then - from my point of view (typically for several reasons I have
scripting switched off by default) - the 'fallback' is the intended content
of the canvas and not the result from scripting, because the scripting
is not directly related to the element, it is not declarative and somehow
optional. Then this becomes an argument against the canvas, it
remains no specific functionality anymore related to a markup
language and can therefore pretty good represented by div or span.

>If you integrate the canvas API to <img>, you don't have such a
>fallback mechanism (except the image referenced by the src attribute;
>or eventually the alt text if you're also in the case where images are
>disabled / there's no support for images at all).

Then the img element could be replaced by canvas in general to have
such a mechanism too. Typically raster image do not have much
accessible content apart from alt and longdesc. And if canvas provides
a better fallback mechanism this would be an argument to replace
img by canvas (and adding something like src either to reference
a static raster image or a dynamic script, server or user sided to
cover more functionality).

>(note: the same kind of rationale also applies to the video and audio
>elements: I could disable audio and thus be given the "fallback"
>content, without at the same time disabling video, and without having
>the browser resort to some heuristics –e.g. on the content type, but
>that might not always be feasible– as would be the case with using the
>more general <object>)
>

About video and audio:
The controls attribute looks like a nice feature to me, else I miss a
declarative way for authors for timing and interactivity as available in 
SMIL or SVG tiny 1.2. Authors may not want to leave all controls to
the user agent.
The source element seems to be an interesting approach too; in 
SMIL and SVG there is a switch element for a more general
approach for conditional processing. I think, currently for source
it is not clearly described, which source is choosen - but maybe I
did not see it yet.

Thierry Michel referred already a nice comparsion to SMIL to this
list. Interestingly no one commented it yet...
Maybe if authors have the requirement to have access to timing 
controls, it looks like a good idea to reference a SMIL or SVG tiny 1.2
document instead of using the video or audio elements.
I think, currently several use already flash for this purpose.


>-- 
>Thomas Broyer

Received on Friday, 30 November 2007 16:52:13 UTC