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

On Tue, Dec 30, 2008 at 1:54 PM, Ian Hickson <ian@hixie.ch> wrote:
>
> On Tue, 30 Dec 2008, Julian Reschke wrote:
>>
>> > Furthermore, not ever introducing new void elements is hardly a fix to
>> > the problem of not being able to introduce new void elements!
>>
>> The problem is *not* the inability to introduce them. The problem is the
>> inability of producers and consumers to decide which syntax to use for
>> unknown elements.
>
> 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?

The problem that I see (which may or may not be the same one as Julian
is trying to solve) is one of forwards compatible parsing. I.e. say
that 5 years from now we develop HTML6 which introduces a void
<killswitch> element (which would destroy your enemies using some kind
of evil doomsday device, oh yes). 2 years later Firefox 5 comes out as
the first browser to support this newfangled <killswitch> element,
including parsing it as a void element.

At this point a developer that wants to write a page that uses this
element runs into a problem. Using the proper markup will work fine in
Firefox 5, however any other browser will create a DOM which nests a
pile of elements inside the <killswitch>. This makes it hard to work
with such a page as you have to always take two possible DOMs into
account, for example when walking the DOM tree or when applying CSS.
For example "killswitch { display: none }" would be very bad in any
browser other than Firefox 5.

If we instead allowed the <killswitch/> syntax, all browsers would
produce the same DOM making them easier to work with.

I *think* void elements is the only thing destroying the ability to
have forwards compatible parsing right now. If I understand the
parsing algorithm correctly newly introduced block level elements
would only produce a different DOM for invalid markup. I.e. markup
like

<i><new-block-element>hello</new-block-element></i>

would produce the same DOM in all browsers, but

<i><new-block-element>hello</i>hi</new-block-element>

would produce different DOMs depending on if <new-block-element> is
recognized as a block-level element or not. Please correct me if I'm
wrong.

I actually think it would be great to support the ending-slash syntax
for all elements in HTML5. I have several times ended up writing
things like <div id=foo></div>, and having it consistently supported
in both HTML mode and foreign content mode would actually reduce the
differences between them which I think is a great thing.

I have heard of some real world pages that would break if the empty
element syntax was supported everywhere, however I wonder if it's many
enough that we need to adjust HTML to accommodate them.

/ Jonas