[whatwg] Re: Is this introducing incompatibilities with future W3C work
ian at hixie.ch
Fri Jun 25 17:46:54 PDT 2004
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
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
> 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:
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg