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

Ian Hickson wrote:
> On Tue, 30 Dec 2008, Julian Reschke wrote:
>> Ian Hickson wrote:
>>> ...
>>> I don't understand. Producers know which syntax to use because the spec very
>>> precisely defines the exact syntax to use in the "Writing HTML documents"
>>> section, and consumers know how to process this syntax because of the very
>>> precise rules in the "Parsing HTML documents" section.
>>>
>>> What's the problem?
>> For unknown elements?
> 
> I don't understand the question. 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.

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.

>>> Why not? Void elements are great, and other than a little pain every 
>>> few years when new ones are introduced, they don't cause any long-term 
>>> problems. After all, the pain caused by new void elements is minute 
>>> compared to the pain of actually implementing those new elements.
>> The pain is substantial if it means that serializers and parsers need to 
>> be updated for no other reason than that change.
> 
> I agree that if we were defining the language from scratch, we would be 
> better off with a syntax that was self-describing. Sadly, that boat sailed 
> about 18 years ago.

The problem can be fixed by stating once and for all the syntax for 
future elements. Yes, there will be special cases for *existing* 
elements, but that doesn't mean that this mess needs to be carried over 
for *new* elements.

>> Even worse, people may not realize that they *need* to upgrade their 
>> libraries, because consumers silently correct the errors. So this will 
>> *cause* broken content to appear in the wild.
> 
> Yup, for a few years each time a new void element is introduced, there is 
> 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?

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

BR, Julian

Received on Tuesday, 30 December 2008 14:06:48 UTC