This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
It appears that the current definition of <object> has several cases where @type (or a type derived from the 'extension' of the URI) would override the server-supplied media type. Consistent with other parts of the spec, this behavior should be optional (== a UA should be allowed to consider the HTTP content type as authoritative). See related discussion, plus pointers to the Mozilla bug database, in http://lists.w3.org/Archives/Public/public-html/2009Dec/0260.html.
What's the point of being vague here? The browsers all use the @type media type, and there are scads of web sites that rely on this behavior. In the email you cite, Jonas says that he wishes it weren't the case but he's not willing to implement the alternate behavior.
(In reply to comment #1) > What's the point of being vague here? The browsers all use the @type media > type, and there are scads of web sites that rely on this behavior. In the > email you cite, Jonas says that he wishes it weren't the case but he's not > willing to implement the alternate behavior. Actually, the alternate behavior already was implemented, and backed out because of *some* sites. AFAIR, Jonas said that it might be possible to revert that change by applying sufficient evangelism. Also, this is not being vague. This is about allowing exactly two behaviors, of which one currently *seems* to be necessary, and the other one would be consistent with HTML4 and the web architecture in general (authoritative metadata). How is this different from the approach in draft-abarth-mime-sniff, which also allows both strategies?
> Actually, the alternate behavior already was implemented, and backed out > because of *some* sites. AFAIR, Jonas said that it might be possible to revert > that change by applying sufficient evangelism. He says he's not willing to do it unless someone shows him compatibility data. Do you have compatibility data? > Also, this is not being vague. This is about allowing exactly two behaviors, of > which one currently *seems* to be necessary, and the other one would be > consistent with HTML4 and the web architecture in general (authoritative > metadata). My understanding is the HTML4 compatibility is irrelevant. You're right that your suggesting something that's vague in that it allows two possibilities: one that matches reality and one that's a pleasant fiction. > How is this different from the approach in draft-abarth-mime-sniff, which also > allows both strategies? HTML5 requires the sniffing part of draft-abarth-mime-sniff. The alternate mode is for non-HTML user agents, like SIP phones. In this case, we're talking about how to interpret an HTML element, which isn't that interesting for SIP phones.
(In reply to comment #3) > HTML5 requires the sniffing part of draft-abarth-mime-sniff. The alternate > mode is for non-HTML user agents, like SIP phones. In this case, we're talking > about how to interpret an HTML element, which isn't that interesting for SIP > phones. That's definitively not what we agreed upon in the Working Group around one year ago. I'll open a separate bug.
(In reply to comment #4) > (In reply to comment #3) > > HTML5 requires the sniffing part of draft-abarth-mime-sniff. The alternate > > mode is for non-HTML user agents, like SIP phones. In this case, we're talking > > about how to interpret an HTML element, which isn't that interesting for SIP > > phones. > > That's definitively not what we agreed upon in the Working Group around one > year ago. I'll open a separate bug. Actually, MINESNIFF has as Step 2 in Section 3: 2. If the user agent is configured to strictly obey Content-Type headers for this resource, then jump to the last step in this set of steps. So yes, using the algorithm is mandatory, but the algorithm explicitly allows not to sniff.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: see diff given below Rationale: I've allowed UAs to skip the sniffing steps, as with MIMESNIFF.
Checked in as WHATWG revision r4556. Check-in comment: Allow skipping sniffing steps. http://html5.org/tools/web-apps-tracker?from=4555&to=4556