[whatwg] Re: Is this introducing incompatibilities with future W3C work
ian at hixie.ch
Fri Jun 25 18:21:59 PDT 2004
On Sat, 26 Jun 2004, Jim Ley wrote:
> > >
> > > 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".
> Sorry, I understood the intention was to take a pretty much complete
> spec to the standards org such that nothing but minor changes were
> necessary for it to be approved - that's my usage of RubberStamped. I
> hope that's the intention, it all seems a much too long process
Naturally one would like our specifications to be so perfect that nobody
could want to change them, which is why we want explicit call-for-comments
periods with wider review.
That's a far cry from expecting a rubber stamp.
> > 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 don't actually agree with this interpretation of the text/html
I urge you to read the RFC. It's pretty clear.
> if I'm wrong (and I probably am) then I would oppose it yes, and would
> suggest application/prs.hixie.html (and a +xml one for the XML version)
> for development and testing yes.
Well that's not going to happen... For one it wouldn't degrade gracefully.
> > By "awful" I presume you mean "standards compliant".
> Yep, but it's an awful standard.
> > > 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?
> Some of it is documented in:
> (where it sniffs text/plain) the previous firefox release also announced
> with relish that now files would be sniffed for media mime-types even if
> the mime-type is text/plain. No idea of the bugzilla references,
> bugzilla is a web-app I've never managed to get the hang of.
Oh you are complaining that when a document sent using one of the three
default Apache Content-Type headers with content that violates those
headers by including illegal bytes, Mozilla (and Opera) attempt to detect
the content to see if it is actually binary data instead of displaying
(what is guarenteed to be) garbage?
That is intentional behaviour to work around an Apache bug that Apache
refuse to fix.
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg