Re: ... other formats in HTML ...

On Dec 1, 2007, at 5:54 AM, Dr. Olaf Hoffmann wrote:

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

Our Design Principles require compatibiity with existing content, so  
we can't remove existing functionality. At best we could add  
additional ways of doing the same thing.

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

It's easy to say something "should be not much work" for someone else  
(such as the multiple vendors who have already implemented and shipped  
<canvas>). I don't see a strong benefit to renaming the <canvas>  
element. Adding functionality is reasonable if the functionality is of  
practical use. Inventing a new scripting language is, of course, a  
huge amount of specification and implementation work, and the  
practical benefit is not clear. Is that really intended as a serious  
suggestion?


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

Elements that are overloaded with a lot of different functionality in  
different cases tend to end up with buggy and non-interoperable  
implementations. To understand why, see <http://en.wikipedia.org/wiki/Cyclomatic_complexity 
 > and consider that past a certain point of complexity (as measured  
by independent linear paths through the code) a software component is  
effectively untestable.

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

I'd prefer if we stick to elements that only have a valid use case,  
and not ones based on hypothetical needs.

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

These seem useful and needed.

> From the point of semantical completeness the list should be
> completed, for example with 'text', 'animation', maybe some
> more.

I don't think 'text' is needed since text is not by any means foreign  
to HTML. With 'animation' it's less clear; what exactly is an  
"animation" and how does it differ from an animated image ('img'), a  
video ('video'), or arbitrary possibly-interactive content ('object'  
or 'iframe')?

SVG draws the line between 'image' and 'animation' at bitmap formats  
vs. vector formats. But that's not a semantic distinction, nor does it  
match the names of the respective elements. It appears to leave no  
place for a PDF (static vector image) or an animated GIF (animated  
bitmap image). HTML doesn't try to draw distinctions between image  
formats. (Arguably animated image formats could also be held in a  
'video' element which would then provide time control through the API).

> 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

'object' is the generic embedding element for content types that are  
not handled in a more specific way. I don't think you are seriously  
suggesting that there should be a 'smell' element.

I'm not sure any of your remaining suggestions could be seriously  
intended, so I'll stop here.

  - Maciej

> (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:48:43 UTC