W3C home > Mailing lists > Public > public-html@w3.org > January 2009

Re: Making the HTML language self-describing

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 8 Jan 2009 03:45:43 +0000 (UTC)
To: Jonas Sicking <jonas@sicking.cc>
Cc: Martin Atkins <mart@degeneration.co.uk>, Julian Reschke <julian.reschke@gmx.de>, public-html@w3.org
Message-ID: <Pine.LNX.4.62.0901080337510.7181@hixie.dreamhostps.com>

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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:25:26 UTC