W3C home > Mailing lists > Public > public-respimg@w3.org > September 2012

Re: @type attribute on <source> elements

From: Mathew Marquis <mat@matmarquis.com>
Date: Fri, 7 Sep 2012 18:25:18 -0400
Cc: David Clements <huperekchuno@googlemail.com>, "Nathanael D. Jones" <nathanael.jones@gmail.com>, "public-respimg@w3.org" <public-respimg@w3.org>
Message-Id: <5E767BD4-082D-47A6-8CA3-2D6E15657CCC@matmarquis.com>
To: Aaron Gustafson <aaron@easy-designs.net>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 7 September 2012 22:25:43 GMT