W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2004

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

From: Jim Ley <jim.ley@gmail.com>
Date: Sat, 26 Jun 2004 00:23:38 +0100
Message-ID: <851c8d3104062516234e278a99@mail.gmail.com>
On Fri, 25 Jun 2004 23:07:25 +0000 (UTC), Ian Hickson <ian at hixie.ch> 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.)


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

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

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

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

Jim.
Received on Friday, 25 June 2004 16:23:38 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:34 UTC