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

HI Ian,

On Dec 30, 2008, at 8:14 AM, Ian Hickson wrote:

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

I would agree with Juilian on this issue. These excuses raised  
repeatedly sound more and more pathetic each time. XML syntax is  
widely understood. in HTML5 (and beyond) the slash would always mean a  
void element for unknown elements (and for newly introduced elements).  
For document conformity authors could be told to always use the slash  
for void elements and never use the slash for non-void elements. So in  
terms of document conformance and authoring, the consistency for HTML5  
making use of a slash is quite strong (maybe stronger than for XML  
where the slash encountered by a processor does not necessarily mean a  
void element).

I do disagree with Julian that we should never introduce new block  
level elements. As I've said in the past the parsing algorithm  
(currently severely broken) should be improved to better support block  
and inline level elements (for example within the head element). The  
use of the slash would compliment that by also making forward  
compatibility for void elements stronger.

Take care,
Rob

Received on Tuesday, 30 December 2008 21:43:15 UTC