W3C home > Mailing lists > Public > public-html@w3.org > January 2009

Re: Write-up about semantics in HTML5 from A List Apart

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 07 Jan 2009 17:58:13 +0100
Message-ID: <4964DF25.4060300@gmx.de>
To: Thomas Broyer <t.broyer@ltgt.net>
CC: public-html <public-html@w3.org>

Thomas Broyer wrote:
>> All true.
>> But in XML based languages you can extend the vocabulary,
> Only when the vocabulary has been defined to be extensible, otherwise
> your document won't validate (DTDs do not allow plugging in attributes
> other than defined ones and only allow "foreign" child elements when
> the content model is ANY; it's almost the same with XML Schema except
> you can opt-in for foreign attributes --eventually constrained by
> namespace-- and allow foreign child elements while still
> validating/constraining other child elements; again almost the same
> with RelaxNG, with added expressiveness re. deterministic vs.
> ambiguous content models).


So yes, in XML either the language needs to have the right attitude wrt 
extensibility, or you need to ignore validity. Still better than the 
situation with HTML.

> ...
> I don't know SGML much but it seems no more different than optional
> tags being defined in the DTD: if HTML5 were still SGML-based, when
> you'd add a new element (particularly a new "void element": EMPTY
> content model with optional end tag), you'd have to update the DTD,
> and because no one would download DTDs but use their local catalogs,
> you'd have the same deployment problem.
> ...

Right, and that IMHO was the key innovation: the parser is frozen, 
out-of-band metadata (DTD) is not needed, but the vocabularies can evolve.

 > ...> As already mentionned, one thing we could do is prohibiting
> introduction of void elements, but a) as Ian said it would make things
> harder to read (<command></command>) and b) it would not address all
> use cases, as you would also need to prohibit introduction of new
> scoping/formatting/phrasing elements, and that's probably not desired
> (we want <section> to auto-close any opened <p>, but for compatibility
> with non-HTML5 UAs, authors still have to explicitly close their <p>
> before opening a new <section>).
 > ...

I think if auto-closing <p> would be the one thing that kept us from 
reaching a sane parsing model, the winner should be clear...

 > ...

BR, Julian
Received on Wednesday, 7 January 2009 16:58:58 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:41 UTC