W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2013

Re: [whatwg] We should not throw DOM Consistency and Infoset compatibility under the bus

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 11 Jan 2013 20:00:07 +0000 (UTC)
To: Henri Sivonen <hsivonen@iki.fi>
Message-ID: <Pine.LNX.4.64.1301111949280.2101@ps20323.dreamhostps.com>
Cc: WHATWG <whatwg@whatwg.org>
On Fri, 11 Jan 2013, Henri Sivonen wrote:
> Hixie wrote in https://www.w3.org/Bugs/Public/show_bug.cgi?id=18669#c31 :
> > I think it's fine for this not to work in XML, or require XML changes, 
> > or use an attribute like xml:component="" in XML. It's not going to be 
> > used in XML much anyway in practice. I've already had browser vendors 
> > ask me how they can just drop XML support; I don't think we can, at 
> > least not currently, but that's the direction things are going in, not 
> > the opposite.
> 
> This attitude bothers me. A lot.
> 
> I understand that supporting XML alongside HTML is mainly a burden for 
> browser vendors and I understand that XML currently doesn't get much 
> love from browser vendors.

Not just browser vendors. Authors rarely if ever use XML for HTML either. 


> Still, I think that as long as browsers to support XHTML, we'd be worse 
> off with the DOM-and-above parts of the HTML and XML implementations 
> diverging.

Sure, but if on the long term, or even medium term, they don't continue to 
support XHTML, this is no longer a problem.


Anyway, I'm not suggesting that they diverge beyond the syntax (which is 
already a lost cause). All I've concretely proposed is syntax for binding 
Web components in text/html; I haven't described how this should be 
represented in the DOM, for instance. If we define <foo/bar> as being a 
text/html syntactic shorthand for <foo xml:component="bar">, or <foo 
xmlcomponent="bar">, in much the same way as we say that <svg> is a 
shorthand for <svg xmlns="http://www.w3.org/2000/svg">, then the DOM 
remains the same for both syntaxes, and (as far as I can tell) we're fine.


> The idea to stick a slash into the local name of an element in order to 
> bind Web Components is much worse.

I don't propose to change the element's local name. <select/map> has 
tagName "select" in my proposal.


> Please, let's not make that mistake.

What do you propose to resolve this problem then?

Some of the constraints are:

 - The binding has to be done at element creation time
 - The binding has to be immutable during element lifetime
 - The syntax must not make authors think the binding is mutable
   (hence why the <select is="map"> proposal was abandoned)
 - The syntax must be as terse as possible
 - The syntax has to convey the element's public semantics (a 
   specified HTML tag name) in the document markup, for legacy UAs
   and future non-supporting UAs like spiders.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 11 January 2013 20:00:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:12 GMT