Re: @type attribute on <source> elements

Okay, let's review a few facts:

1. Current web-safe image formats stink. Why?

- We have no lossy format that also has alpha support.
- We're still stuck with a 256-slot color palette, with 1 bit for alpha
when it comes to animations.
- We don't have a good lossless format for photography.

2. The replacements nearly ready, but unless we find a future-friendly
solution, we'll never get past animated gifs. A solution that requires
trial-and-error HTTP requests will not be usable, because the cost/benefit
tradeoff will be too high. We must have a way to hint the mime-type to the
browser.

<picture> is the web's second chance at imaging. Let's not screw it up.

@justinavery - We've been told in no uncertain terms that we can't rely on
HTTP headers. Browsers don't currently specify their accepted image
mime-types, but if they started doing so, that solution still wouldn't work
with most existing CDNs. And CDNs supposedly serve 35-45% of web traffic:
http://www.smartplanet.com/blog/thinking-tech/the-incredible-shrinking-internet/12150

@Andy brings up an important issue.

We're currently trying to support multiple URLs in a single source element.
Since mime-type needs to be per-url, this would further complicate the
srcset syntax, making it triples instead of tuples.

I've noticed we keep encountering issues trying to support 'srcset', and
although it may be too early to suggest this, I'm hoping the following
simplified syntax will be considered:

<source x="1" src="small.jpg" />

<source x="2" src="small-highres.jpg"/>

<source media="(min-width: 18em)" x="1" src="med.jpg" />

<source media="(min-width: 18em)" x="2" src="med-highres.jpg" />

<source media="(min-width: 45em)" x="1" src="large.jpg" />

<source media="(min-width: 45em)" x="2" src="large-highres.jpg" />



I consider this much simpler to script, parse, and generate. While at
first glance it appears much more verbose than the original 'srcset'
syntax, I'd like to remind folks that 'med.jpg' is not a very
representative URL.


CNN, for example, is pretty url-length conscious, but their shortest
image URLs are still 60-70 characters in length:


http://i2.cdn.turner.com/cnn/dam/assets/120911022144-nyc-skyline-c1-main.jpg


Taking that into consideration, we're talking about


<source media="(min-width: 45em)"
srcset="http://i2.cdn.turner.com/cnn/dam/assets/120911022144-nyc-skyline-c1-main.jpg
1x, http://i2.cdn.turner.com/cnn/dam/assets/120911022144-nyc-skyline-c1-main-hires.jpg
2x" />



vs


<source media="(min-width: 45em)" x="1"
src="http://i2.cdn.turner.com/cnn/dam/assets/120911022144-nyc-skyline-c1-main.jpg"
/>

<source media="(min-width: 45em)" x="2"
src="http://i2.cdn.turner.com/cnn/dam/assets/120911022144-nyc-skyline-c1-main-hires.jpg"
/>


That's only 21% longer, in a conservative case.



Cost:

1. Additional duplication of media queries. This increases the need
for media query variables, a problem I think we need to solve
regardless.

2. ~10-25% more markup.


Benefits:


1. Spaces and commas in URLs can be tolerated, as before. Browsers
automatically URL-encode commas and spaces before sending the HTTP
requests, which probably wouldn't be possible with srcset.


2. Simple 1-1 mapping of queries and URLs.

3. Simplified DOM scripting.

4. We can support @type, and perhaps, eventually, escape animated GIFs.



Best regards,

Nathanael Jones



On Mon, Sep 10, 2012 at 5:53 AM, Justin Avery <justincavery@gmail.com>wrote:

> I apologise because I think I must be missing something here.... I'm
> wondering why we're worrying about the type at all.
>
> When HTML5 application cache arrived we didn't need to include anything
> for the browser to understand the file, we did this at the apache level and
> let the browser take care of it in a way that it was design to.  By adding
> these additional attributes it's confusing the situation.
>
>
>
> On Mon, Sep 10, 2012 at 5:48 PM, Andy Davies <dajdavies@gmail.com> wrote:
>
>> On 6 September 2012 22:21, Nathanael D. Jones <nathanael.jones@gmail.com>
>> 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 still wondering how relevant type really is...
>>
>> Yes it make sense when the element has a src but once srcset is used
>> doesn't it open up a can of worms as the images in a srcset may not
>> all be the same mimetype, for example, what should the type be for the
>> following element?
>>
>> <img src="img.png" srcset="srcset="image.jpg 1x, image-x2.webp, #000" />
>>
>> I can think of several possibilities but do any of them make sense?
>>
>> Cheers
>>
>> Andy
>>
>>
>
>
> --
> Justin Avery
>
> *We Build Websites*
> http://justinavery.me
> http://www.twitter.com/justinavery
>
>