On Sep 7, 2012, at 9:09 AM, Aaron Gustafson wrote: > On Fri, Sep 7, 2012 at 8:21 AM, David Clements > <huperekchuno@googlemail.com> wrote: > >> I've been pondering this as a background process for the past hour or so... >> >> I think I'm seeing the point - by having browser skip an unsupported MIME on >> a type attribute it avoids unnecessary HTTP requests and possibly even >> broken images whilst allowing developers to specify modern MIME types with >> JPG/PNG/GIF fallbacks? > > Yeah, that’s the gist of it. > I don’t claim to be an expert in this arena, but according to “4.2. Image Media Type” on http://www.ietf.org/rfc/rfc2046.txt : Unrecognized subtypes of "image" should at a miniumum be treated as "application/octet-stream". Implementations may optionally elect to pass subtypes of "image" that they do not specifically recognize to a secure and robust general-purpose image viewing application, if such an application is available. We’re including `type` in the proposal, following `video`’s lead ( http://dev.w3.org/html5/spec/single-page.html#attr-source-type ). It looks as though unrecognized `type`s are omitted in the case of `video` sources, but according to the above: image types are to be included in some form even if they’re unrecognized. I’m not sure where that leaves us, or how best to codify that unrecognized images should be skipped. Would someone more familiar like to take point on researching this, while I merge the resolutions from the a11y discussion into the proposal? If not, I’m happy to continue researching! No rest for the wicked, after all. -M
Received on Friday, 7 September 2012 22:25:42 UTC