Re: Making the HTML language self-describing

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


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


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


> 3. The site could deploy a custom plugin or extension and use that to 
> implement the element.

Such custom plugins or extensions could fix the markup at the same time.


> For the case where neither of these are true then the site has no choice 
> but to not use the element at all until all browsers with significant 
> market share has deployed support for the element.

This is true regardless of whether the element can be parsed by down-level 
clients or not.


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



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.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 8 January 2009 03:46:18 UTC