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

[Ian Hickson]

On Sat, 26 Jun 2004, Jim Ley wrote:
> >
> > 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.
>
> Right, I don't really see that, as you seem to be filtering the
> suggestions sent to the list, not taking them straight...

I am taking all the input sent to this list, including my own, and
incorporating into the spec what I believe to be the solutions having the
most support and most closely adhering to the group's principles.


> > Well I can't easily address non-existant comments.
>
> Of course not, which is why you need to be more proactive in soliciting
> them IMO, otherwise we're not going to get a rubber-stampable spec, and
> we're wasting our time here, we should just wait until it goes to the
> standards org.

I don't believe anyone (apart form you) has suggested we try to get this
work "rubberstamped".

We will, however, be soliciting further comments from a wider audience
once we publish a call-for-comments snapshot this weekend, as described
in our charter.


>> Exactly how are namespaces in XML different than namespaces in the MIME
>> type hierarchy or in the DOM?
>
> There are no namespaces in the DOM.  it's an application environment,
> there's nothing in the DOM that states how it should (or should not)
> be extended.

There isn't anything in the Namespaces in XML specification that states
how it should (or should not) be extended either.


> The MIME heirachy indeed it's just as holy as in XML, but you're not
> suggesting changing any of that, so I've nothing to complain about.

WHATWG's proposed specifications are co-opting the meaning of the
"text/html" MIME type just as they are co-opting the meaning of the
"http://www.w3.org/1999/xhtml" namespace.  There really is no difference.


> > > 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?
>
> Take any WF XHTML document and leave off the final </html> you get
> awful behaviour in Mozilla, at least you did last time I looked, maybe

By "awful" I presume you mean "standards compliant". The parsing change is
the one change I explicitly mentioned was different between XHTML and HTML
processing. It's amusing to note that this is the part of my e-mail that
you decided to ignore in your reply, especially in light of your
accusations that I was ignoring your feedback.

In any case, the difference in processing HTML and XHTML that you
highlight above is, as I previously mentioned, one of the few differences
in the codepaths for processing HTML and XHTML that Opera, Safari and
Mozilla have. It is not an argument for introducing _more_ differences in
the processing.


> they fixed this along with their mime-type sniffing spec violations.

Do you have any bug numbers for the "mime-type sniffing spec violations",
or, failing that, any URIs demonstrating them?


> > 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.
>
> Really, but mozilla already go out of the way to prevent rendering of
> non-WF docs in XHTML that they don't in the HTML code-paths, Mozilla
> provides different DOM behaviour in XHTML to HTML, and that's just the
> changes I know about, I don't use XHTML with Mozilla, simply because
> XHTML has such ridiculous conformance requirements, but it definately
> reacts differently to HTML for me.

Yes, I already explained this:

   http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2004-June/000584.html

The parser has nothing to do with the majority of the body of code that
implements HTML and XHTML, and the DOM differences are inconsequential.

My point still stands.

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