... other formats in HTML ...

Maciej Stachowiak wrote in
'Re: SURVEY: Accept requirement for immediate mode graphics a la canvas 
element?'

>
> 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

Well what currently works for HTML 4 or XHTML is maybe no argument
against a better structure of elements names in a new version like
HTML 5. Currently it seems that even the discussion did not finish to
publish the current draft as an official working draft or not to get
more audience to discuss this. This looks like a starting point for
implementation, not the end point - and it should be not much work
either to move the functionality from the current canvas to another element
or to add more functionality to the canvas element to establish this
for example as a generic element for any graphical content, either
referenced  from an external document, embedded directly or
generated dynamically with a specific graphical script language
developed for this purpose.

There were opinions about avoiding too much 'domain specific' element
names too and therefore this could be a good chance to clean up and
reduce elements with very similar functionality to one or two elements,
alternatively it could be another approach too to complete the set
of 'domain specific' element names for more semantical relevance.
Currently there is the following set of elements to embed somehow 
'alien' content into HTML 5 (sorry if I forgot some):

style
script

object
embed (more a command as a propper element name?) 
iframe
img
video (+source)
audio (+source)
canvas

From the point of semantical completeness the list should be
completed, for example with 'text', 'animation', maybe some
more. Several of them will have almost the same 
functionality (as in SMIL for example), but the author can
choose a name fitting well to the intended purpose.
A general problem in 10 or 20 years might be, that there
are formats too for other senses as vision and hearing,
maybe smelling, feeling, degustation and this list has
to be updated anyway to cover the specific requirements
of such formats (offtopic: video - I see; audio - I hear,
currently video includes optionally audio too, maybe 
audio should not exclude video? And both should not
exclude other senses to avoid such future problems
and to improve the accessibility potential for multimedia 
applications?)

From the point of redundance, the list could be reduced to 
the essentials too, for example having only
'style' (including script and maybe canvas) and 'object' 
(the others and maybe canvas) and forgetting everything 
else, because the functionality can be covered with this two 
elements completely. 
This is easier to explain to authors, what the
difference between the elements is and what the
basic purpose or functionality.

Having an arbitrary selection is not explainable at all
and authors have no chance to understand why they
have a choice between different names for the same
functionality in one domain and no element with 
a specific name for another domain at all.
This is similar to the problem for list elements -
there are a lot of different element names for
the same functionality, but the list is incomplete
to cover several other interesting functionalities.
There are some more inconsistencies, as having
or defining elements specific for the domain 'prose' 
in HTML5 but none for 'poetry' as already discussed 
and added to the wiki.
With a closer look maybe there will be some more
of those unbalanced domain specific selections.


Such inconsistencies in the design of the language HTML5
need to be solved, else readers of the draft will have
the impression, that it is jammed together to a funny collection
of may useful existing tools or just the draft authors
subjective choice, what is available or not. Well, maybe
the impression is correct or intended, but then maybe
the name of the game should be changed (maybe HFC1,
HyperFunCollection 1, just joking ;o) or related to the prose
problem HPML1 - HyperProseMarkupLanguage 1, no joke
at all after a closer look into the current draft.

Received on Saturday, 1 December 2007 14:04:46 UTC