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

[Vipul S. Chawathe]

>From: Ian Hickson [mailto:ian at hixie.ch] 
>To: Henri Sivonen
>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.

It's okay for authors who leave deploying content to publisher to stop with
looking at html appearance from browser to users. Xhtml's fewer publishers
maybe bonded abit over-tightly with it if their quantity is lesser
considering how helpful transforms are. Repetitive content over-counted is
more likelier for html than transformable xml serializations. The publisher
may favour plug-ins for flash, jvm, Silverlight and whichever else. However,
small publishers who are impacted by semantic significance of content
grasped by search engine, oft deliver same data using link tag with
rel="alternate" attribute than difficult to index proprietary plug-in based
formats. The alternate representation might be atom, rdf, ... using grddl
xslt or some such html sibling spec, so xhtml may not be well-supported but
vanilla support is another matter. For my personal interest, I'm looking
forward to seamless iframes, though styled iframe does hide the frame
appearance for javascript that breaks on main xhtml page, and place it in
another page that's plain html. My point is, if the spec can be precise w.
r. t. DOM to avoid usability breakage in xhtml, then the spec hopefully will
be precise,  leaving aside when xhtml should be considered dead to
user-supporters at present.