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

On Tue, Dec 30, 2008 at 4:54 AM, 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?

So, sort of restarting this thread again. Here are the problems that
would be good to solve:

1. When a new version of HTML6 comes out, it should be possible to
write a document that uses elements from HTML6, but that parses to the
same DOM in a browser that both supports HTML6 and HTML5. Ideally such
a document would also validate as valid HTML6 and HTML5. Note that
this doesn't mean that *every* document should parse to the same DOM,
just that it is possible to write one that uses a new element but
still produces the same DOM in both parsers. So for example it's IMHO
ok to require that </p> elements are closed and that no tags are
missnested for the same DOM to be produced.

2. Make it possible to create a generic serializer that takes a DOM
and produces HTML that parses into the same DOM. Independent of which
HTML version (>= 5) is used to parse.

3. Write a generic parser that can be used to parse HTML markup of any
version (>= 5) into a DOM.

1 seems very important to me to allow for adoption of new elements.
I'd hate it if people were forced to use document.write hacks along
with browser detection to be able to use new elements.

2 seems important to allow generic tools, such as XSLT or DOM to
produce HTML. I doubt all tools that produce HTML will be aware of the
semantics of HTML and thus know which elements are empty and which
elements are block-level. Or is that the case today?

3 would be great for the same reasons 2 is, but on the consumption
side rather than on the production side. Unfortunately this one might
be impossible to do if we want to ever introduce block-level elements.

The reason I'm in a couple of places say HTML5 or great is simply that
HTML4 and older is a lost cause.

/ Jonas

Received on Wednesday, 7 January 2009 19:20:47 UTC