[whatwg] Re: Is this introducing incompatibilities with future W3C work

[Ian Hickson]

On Sat, 26 Jun 2004, Jim Ley wrote:
> > >
> > > I suggested on the WG, not on the mailing list, the same as with the
> > > accessibility expertise.
> >
> > How would that help? The "members" are just an oversight committee, like
> > W3C team is to the W3C. If you want the spec to improve, then we need
> > input on this mailing list, not new "members".
>
> Not really, since the members form a consensus, and then you write
> them into the spec (I'm a little confused where the members are
> forming this consensus as not that many are talking on the list, yet
> changes keep happening to the spec.)

It is the concensus of the members at the moment to use the proposals sent
to this list, in so far as they follow the principles laid out in the
Opera/Mozilla position paper mentioned earlier.


> > > Not really, as the WHATWG obviously subscribes to the view (lots of my
> > > objections would be gone if you weren't stepping on XHTML toes)
> >
> > I've only heard one objection to WHATWG describing extensions to XHTML,
> > yours.
>
> Yes, but there's been very little discussion, it seems a lot of people
> I talk to who might be expected to give input aren't actually
> bothering, there's only a few active people on the list, and most were
> already involved in the spec before the WHATWG formed.

Well I can't easily address non-existant comments.


> > You haven't yet explained how extending the XHTML namespace is
> > worse than extending the text/html namespace or the DOM namespace.
>
> because the "text/html namespace" is not something that can be polluted,
> there's no such thing existing, you can simply publish your own dtd and
> it's up to browsers if they support it - just like the ISO have done
> with their version of HTML, or others have with various attributes.
> The DOM also is not IMO being polluted, there's nothing in DOM that
> prevents you exposing other methods on the objects. (Just like
> ECMAScript doesn't outlaw adding features)  XML Namespaces though are
> different, they rely on the names having a specific owner or things
> start falling apart, and we can't combine XML documents.  I realise this
> isn't something you want to do, and I've always fully agreed that
> everything is wrong in the XHTML world, but we don't fix it by
> externally defining new elements.

Exactly how are namespaces in XML different than namespaces in the MIME
type hierarchy or in the DOM?

You seem to consider XML namespaces to be somehow more holy than other
name spaces. I really don't understand the difference.


> > > Mozilla certainly does lots of awful things with application/xhtml+xml
> > > content that it doesn't do with HTML content.
> >
> > Do you have any bug numbers? I'm not familiar with any awful bugs in this
> > area in Mozilla.
>
> I didn't mention any awful bugs, just awful things - it decides not to
> render something in response to non-WF XHTML for example!  it's awful.

Eh? Could you give an example URI?


> > I don't understand how "there is only one codebase to implement both" can
> > possibly be an argument for "the spec should extend only one". Could you
> > explain this in more detail?
>
> Users only need to use a new HTML version to use the new features,
> therefore there's no point trampling on the XHTML namespace since it
> adds nothing new to users, and takes away from future work in XHTML (not
> XHTML 2.0, but other work).  You say IE6 is the important client, and I
> agree, this doesn't support XHTML, so why bother changing it?

I've already explained. It's not a matter of bothering to change it. If
Opera, Mozilla, or Safari add support for a feature in HTML, then
automatically that feature will be supported in XHTML. They would have to
go well out of their way to _prevent_ the new feature from working in
XHTML. Given that there is no benefit (beyond some theoretical "well W3C
might change their plans and add something to XHTML1") and there is some
loss (authors who do want to use XML would be unable to use these new
features), it is highly unclear why these vendors would want to add the
extra bloat to do this.

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