- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 8 Dec 2009 22:19:31 -0800
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: Julian Reschke <julian.reschke@gmx.de>, "public-html@w3.org" <public-html@w3.org>
On Tue, Dec 8, 2009 at 12:27 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > On 12/8/09 8:32 AM, Julian Reschke wrote: >> >> 4. Otherwise, if the resource type is unknown, and the resource has >> associated Content-Type metadata, then let the resource type be the type >> specified in the resource's Content-Type metadata." > > .... >> >> This suggests that when @type is present, the associated content type >> information (for instance HTTP Content-Type) is ignored > > The "associated Content-Type metadata" bit means the HTTP Content-Type. > > So it's only ignored if @type is a type that is supported via a plug-in. > >> which seems to be both an incompatible change, and violate the >> "authoritative metadata >> principle". > > Sadly required to not break existing content. :( I don't think anyone's > particularly happy about it; if you have a better approach that still > doesn't break existing content I'd love to know what it is. I should add that it's not entirely impossible that this could be made to work, with sufficient evangelism efforts. Bug 1156 [1] (one of few bug numbers I know by heart because it caused so many regressions) changed things to match the HTML4 spec. We were able to stay with that behavior fairly far into the Firefox 3.0 release before we were forced to revert behavior in bug 395110 [2]. It is however possible that with the right combination of logic and the right amount of evangelism effort to get a few high profile sites fixed, it's possible that the http mime type could override the @type mime type. I'm a bit reluctant to take a lead here though given our previous failed attempt. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1156 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=395110 / Jonas
Received on Wednesday, 9 December 2009 06:20:32 UTC