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

Maciej Stachowiak wrote:
> On Dec 1, 2007, at 9:29 AM, Dr. Olaf Hoffmann wrote:
> > Maciej Stachowiak wrote:
> >> I'm not sure any of your remaining suggestions could be seriously
> >> intended, so I'll stop here.
> >>
> >>  - Maciej
> >
> > Well, I'm mainly asking, because I'm not sure, what is a useful
> > and consistent way to specify such a language HTML -
> > HyperTextMarkupLanguage.
> > Obviously there are very different opinions and approaches
> > from different people inside the working group and outside
> > too. And it seems to be different from the HTML4 approach.
> > A markup language for text is in general not much related to
> > audio, video or graphical content at all, but if one starts to add
> > specific elements for other contents, suddenly the choice gets
> > very arbitrary if the list is not complete.
>
> They should be chosen based on:
>
> - Functionality for Web documents and Web applications
> - Expressing document and application semantics
> - Having valid, common use cases

I agree with this, but obviously our conclusions are different.

> - Compatibility with existing practice

This will not be always possible for new features of course.
Looking back in the history, having the idea of controls
for object already in HTML4 or at least implementations of 
the declare attribute, could have maybe avoided such 
constructions of existing practice like the usage of
flash inside HTML or script generated containers for flash 
only to provide controls  playing video and audio, if this is 
accessible for the user, or nothing, if not.

The best method to realise something is to specify first,
then implement it in a useful way and use it. 
If it is the other way round this mainly causes confusion, 
wasted time and a lot of superfluous nonsense in the web ;o)

Obviously even the HTML5 draft does not meet this always, 
for example see the problem with poetry content as 
explained in detail in the wiki too ;o)
Other examples: center or font are still in use by authors,
for whatever reason. Obviously it is useful to restrict
this and the usage of several presentational attributes
from the transitional variant of HTML4, or to note that the 
style attribute is somehow problematic, but they are existing 
practice with many valid, common uses cases 
(unfortunately maybe).
Doing something useful is obviously to get rid of this somehow,
following the concept above clearly says: Leave it as it is,
because it is still in use.

>
> This clearly covers 'video' and rules out ideas like 'smell' (it's
> semantic but would not have a real use case or provide real
> functionality today), 

Because it is a specification for the future too, not only for this 
and maybe the next year and nobody knows what will happen
in the following years after there is a specification for HTML5,
it could be a clever approach to avoid several problems 
providing either an additional generic element or to replace
audio and video with a generic element, lets call it media,
defined to be used typically for media with a simple time line,
typically without internal controls about begin, end (and pause).
Other approaches are maybe even more useful, see below.

Having created about 100 test samples for audio, video and animation 
for SVG tiny 1.2, I think, this simple approach with specific elements 
can be improved - why not to learn from the more common approach
in SMIL?
It is already a nice idea to provide 'controls' in HTML5, even more,
if there is no declarative access to the timing as in SVG or SMIL, but 
this can have a more general applicability with a generic element
for future applications and current common formats can be
used to test and use it already today without any loss.
Modules or basic ideas can be adopted from SMIL to provide 
declarative methods for authors to provide own controls and
having a better access to the timing of such elements too.

> or combining the 'script', 'style' and 'canvas' 
> elements (not compatible with existing practice, muddled semantics, no
> use case relative to separate elemenets). 

Well, this is not really my idea to do this, but related to another
discussion I was told that it is a target too to avoid domain specific
elements. 
And indeed, if 95% of current HTML are faulty or nonsense, this might
indicate, that there is a need to simplify HTML to get a better 
quality, here for example combining elements of the same domain 
'alien stuff' or with the same functionality (containing alien content,
respectively referencing external other formats).
By the way - SMIL 3 introduces timesheets - put it into style or
script? Especially for the HTML variant this is maybe a problem
similar to embedding SVG directly, because I could not convince
them, that is is useful to reference it only with link or for
XML with a processing instruction.

I personally have no problems with more elements, specifying 
the semantical meaning, but then again it is ok to have a list
of elements referencing alien content like
- media or object (generic, main purpose, if nothing else really 
fits to the intended semantical meaning)
- audio (main purpose audible content, optional other resources 
like video in the same container ...)
- video (main purpose timed raster images, optional other resources 
like audio in the same container ...)
- text (provides documents containing mainly text, for example PS
(postscript), PDF (portable document format), SVG with mainly 
text presented (concrete poetry, etc), SMIL with mainly text (this
pseudo-element marquee seems to be quite common today and 
could be replaced with this), flash with mainly text)
- canvas (main purpose graphical content, statical images, scripted images,
graphics with a timeline (SVG, flash with mainly graphics...))
- maybe more (if there are 'fishy' documents in the future, maybe HTML6
has to specify smell too - the technology already exists for this 
(department store sell psychology) and even more for sculptural form 
content, but is not widely used, because the display is expensive ... ;o)

-> outdated: img (because it has the problem to be an empty element with
     very restricted fallback methods), embed (was never defined in previous 
     HTML versions anyway)

Typically such elements will provide the same technical functionality. The
decision, which one has to be choosen is the responsibility of the author.
This is similar as the choice between span, strong, em, code etc - they
all have the same technical functionality as an inline container but have
a different semantical meaning.
Parts of this is just clever naming and psychology too - if the name of an 
element does not fit to the intended semantical meaning or the
technical functionality, authors will have problems, to use such an 
element for it, typically video will not be used to reference a 
document containing mainly text, article will not be used as a container 
for a poem or song texts, small will not be used to emphasise something 
etc. This is no implementation problem at all, it is the difficult task to
find the right name.

Both approaches, having only one element for everything or having a
list of elements with only different semantical meaning, are consistent and
explainable to authors. Having an arbitrary mixture/choice does not
look very promising, this will certainly not improve the usability of the
format or the quality of documents.


> While this is not a line 
> drawn with mathematical precision, surely we both understand that
> language design requires judgment.

Obviously, see above. This should be consistent and following the same 
principle in the complete draft.

>
> Regards,
> Maciej

ditto,
Olaf

Received on Sunday, 2 December 2007 13:01:32 UTC