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

Re: @type attribute on <source> elements

From: Aaron Gustafson <aaron@easy-designs.net>
Date: Fri, 7 Sep 2012 07:59:15 -0400
To: "Nathanael D. Jones" <nathanael.jones@gmail.com>
Cc: "public-respimg@w3.org" <public-respimg@w3.org>
Message-ID: <3E3E7D576FB343938BE0A8DCE55D42BF@easy-designs.net>
On Thursday, September 6, 2012 at 5:21 PM, Nathanael D. Jones wrote:
> I'm starting a new thread about the @type attribute, as requested by Adrian Roselli.  
> I believe it is critical that we REQUIRE browsers to SKIP source elements which have an unrecognized (or unsupported) mime-type value in the @type attribute.  
> Otherwise, we will not be able to introduce to formats and simplify <picture> in the future.  
> @type should be an OPTIONAL attribute, not required, but if present, browsers should handle it in a specific way. Widely supported formats like jpeg, png, and gif do not need a type="" attribute, but webp and future formats do.  
> This will allow us to introduce new image formats in a backwards-compatible manner.

I’m inclined to agree with this proposal, but I do think it's probably worth addressing the fact that MIMEs could still be managed server-side as well.

If an explicit MIME is supplied, it is probably safe to assume the author (or script generating the markup) knows what she is doing, but in the absence of one, I would assume a UA should fall back to the server-supplied MIME. It's obviously less efficient because the UA would need to at least obtain the headers for the file, but if we are addressing the use of the type attribute, we should probably provide explicit documentation about the fallback in the match algorithm.


Aaron Gustafson

Aaron takes no responsibility for poor spelling in this message. It was pecked out by fat fingers on a tiny screen.
Received on Friday, 7 September 2012 11:59:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 7 September 2012 11:59:46 GMT