W3C home > Mailing lists > Public > public-html@w3.org > December 2008

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 31 Dec 2008 13:09:24 +0100
Message-ID: <495B60F4.9000809@gmx.de>
To: Jonas Sicking <jonas@sicking.cc>
CC: Ian Hickson <ian@hixie.ch>, public-html@w3.org

Jonas Sicking wrote:
> ...
> 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

Actually, I'm mostly interested in forwards compatible serialization, 
which seems to be just a subset of the parsing problem.

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

And, if that's the case, there's still the option to allow it only on 
certain existing elements *and* future elements.

BR, Julian
Received on Wednesday, 31 December 2008 12:10:06 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:40 UTC