Re: Making the HTML language self-describing

On Wed, Jan 7, 2009 at 7:45 PM, Ian Hickson <ian@hixie.ch> wrote:
> On Wed, 7 Jan 2009, Jonas Sicking wrote:
>> >
>> > However, DOM differences would be the least of your problems if the UA
>> > doesn't support the void elements. With flow elements like <section>
>> > or <meter>, you might be able to use the elements even though the UA
>> > doesn't support them because you can style them. But with void
>> > elements, the elements are useless if the UA doesn't support them.
>>
>> That's not true, both <br> and <hr> are void elements but could be
>> decently implemented using styling in a UA that doesn't support them.
>> Possibly <spacer> and <wbr> can too.
>
> I don't think we would be introducing elements like <br>, <hr>, <spacer>,
> or <wbr>, though. They're all legacy (and indeed two of them have never
> been, and are still not, compliant -- they're examples of what happens
> when unilateral extension of the vocabulary is possible!).

Why not? We're introducing several non-void elements add semantics and
in a browser can be implemented using only CSS. Why couldn't we
introduce an empty semantic element in a future version of HTML?

>> > In other words, it basically *doesn't matter* if the DOM is different
>> > if you're using void elements the UA doesn't support.
>>
>> There are several occations where this is not true:
>>
>> 1. In cases where you can use CSS and/or JS to emulate the element. In
>> addition to <br>, <hr>, <spacer>, and <wbr>, this is true for
>> <eventsource> (can be emulated using XHR and JS), <embed> (can be
>> emulated using <object>), possibly <command> can be emulated using JS
>> (don't know enough about it), <bgsound> (can be emulated using <audio>
>> or flash).
>
> If you can emulate the element using another feature, just use that
> feature until the parsers are updated.

This means that there is very little incentive for UAs to implement
the new element, or for users to use it. There's already a lot of
inertia due to chicken-and-egg problems when it comes to deploying new
web features, we should do our best to revert that.

>> 2. The site is ok with having different levels of functionality for
>> different browsers.
>
> But then it doesn't matter if the DOM is different.

Why? The DOM isn't different just for the new element in question, but
for all content that comes after it.

>> > In fact, as far as I can tell, the only problem would be with
>> > round-tripping, which is a serialisation issue:
>>
>> There's also the issue with receiving a DOM that is significantly
>> different due to the parser not knowing that an element is a void
>> element. And I don't really see how you could solve round-tripping by
>> changing the serializer since the DOM you receive is "wrong", could you
>> elaborate?
>
> I meant round-tripping from a DOM to a DOM, going through a serialiser
> that doesn't support the feature, but with a parser that supports the
> feature. So the DOM is not "wrong" at the serialising end.

I'm not sure how this is relevant to the problem at hand?

> In short, I don't really see that there's anything practical we can do
> here to truly solve the problem being described, and as far as I can tell,
> even if we solved the problem somehow, we would not in fact remove enough
> roadblocks to help in any practical sense with real problems that authors
> run into.

A few possible ideas:

1. Allow a trailing '/' to indicate an empty element, a'la XML, on
some set of tags (unfortunately it seems like honoring them everywhere
breaks the web)
2. Allow a trailing '/' to indicate an empty element on all unknown elements.
3. Make it conforming to write void elements as <foo></foo>. I.e.
<eventsource></eventsource> would be conforming and equivalent to
<eventsource>. <br> would have to be an exception since </br> has to
mean something else.
4. Don't ever introduce more void elements (I'm personally not a fan
of this idea)

/ Jonas

Received on Friday, 9 January 2009 19:25:51 UTC