Re: Void elements in HTML (Was: ZIP-based packages and URI references into them ODF proposal)

On Tue, 30 Dec 2008, Julian Reschke wrote:
> > 
> > Producers aren't allowed to produce unknown elements, by definition. 
> > Consumers follow the parsing rules and get interoperable behavior on 
> > all elements, unknown or otherwise.
> 
> That implies that a producer needs to hard-wire the full HTML 
> vocabulary, and that it needs to be updated every time a new element is 
> added.

Yes.


> I think this is a bad idea, because if existing producers can not 
> produce output for new elements, people resort to hacks instead, such as 
> producing HTML by string concatenation -- exactly the programming 
> pattern which is known to cause lots of broken content.

Yes, it's a terrible idea. A design such as CSS (forwards-compatible 
grammar; must-ignore semantics for errors in the parser), or XML 
(self-describing syntax) is much better.

Sadly we're rather stuck with the syntax model we have now.


> The problem can be fixed by stating once and for all the syntax for 
> future elements.

That doesn't work. It would mean never introducing new void elements and 
never introducing new block-level elements. For example, in HTML5, it 
would mean not introducing <command>, <event-source>, <section>, <nav>, 
<aside>, <footer>, <header>, etc.

There are features whose usefulness outweighs the cost of the 
aforementioned pain. So long as the changes happen rarely (less than once 
every decade, at the current rate), and so long as the changes only happen 
when there is at least one very useful new feature involved, then on 
balance it is acceptable to go through the pain.


> > We have to balance this against the benefits of a cleaner language. 
> > For example, the <command> element in HTML5 would be basically 
> > unusable if it had to be writen as <command></command>.
> 
> What if "<command/>" would be allowed as well? Still unusable?

I think that the pain of making the language that inconsistent (the slash 
is allowed for some elements and not others, but has no effect on some 
elements and not others, and the two sets aren't the same) would be far 
worse than the pain introduced by changes to the parsers every decade. 
It's bad enough that we're introducing pseudo-XML syntax for MathML and 
SVG; if we introduce a third syntax as well...


> > The same problem exists with new elements with optional tags (like 
> > <rp> or <rt>), and with new elements that are not phrasing elements, 
> > like <section>. This is the price we pay for HTML not having been 
> > written with forward-compatibility in mind. It's not a huge deal.
> 
> It is a huge deal to me. It would be good if HTML5 would avoid issues 
> like this for future elements.

I don't understand why it is such a huge deal for you.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 30 December 2008 14:15:34 UTC