Skip to content

Instantly share code, notes, and snippets.

@andrerom
Created May 15, 2012 23:22
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save andrerom/2705938 to your computer and use it in GitHub Desktop.
Save andrerom/2705938 to your computer and use it in GitHub Desktop.
Responsive image html support proposal
<p>The proposed (but human unreadable) WHATWG syntax:<p>
<pre>
<img src="face-600-200@1.jpg" alt=""
set="face-600-200@1.jpg 600w 200h 1x,
face-600-200@2.jpg 600w 200h 2x,
face-icon.png 200w 200h">
</pre>
<p>The propposed RICG syntax (that WHATWG rejects):</p>
<pre>
<picture alt="">
<source src="mobile.jpg" />
<source src="large.jpg" media="min-width: 600px" />
<source src="large_1.5x-res.jpg" media="min-width: 600px, min-device-pixel-ratio: 1.5" />
<img src="mobile.jpg" />
</picture>
</pre>
<p>Assuming that part of WHATWG's reasoning is introduction of new tag for something that already exist, here is slicker "merged" proposal:</p>
<pre>
<img alt="" src="mobile.jpg">
<source src="large.jpg" media="min-width: 600px" />
<source src="large_1.5x-res.jpg" media="min-width: 600px, min-device-pixel-ratio: 1.5" />
</img>
</pre>
@Wilto
Copy link

Wilto commented May 16, 2012

Hey @andrerom!

Psyched to see more devs helping hashing these things out. @Crossdiver was working on your suggested syntax early on (item #1) — and we got as far as testing this approach — but we couldn’t go very far with it. Short answer is: we wouldn’t be able to change the way img is parsed enough that it would know to “look ahead” for sources inside it. img kind of considers itself closed as soon as the a line ends, after an src has been found. I do kinda dig this syntax, but whenever we bring it up to someone on the browser side they shut it down right away. C’est la vie.

@andrerom
Copy link
Author

Hey,

it makes total sense that browsers start loading the image as soon as end of tag is reached, but I assumed they where already doing read ahead on certain others tags so this wouldn't be to large of an effort to accomplish.

Given the benefit of KISS approach and how much easier it is to adapt for an approach around img tag, it is kind of a shame that they turn down the approach we are used to from video and audio, and also the approach we are used to in regards to media attribute.
It's almost on a level where I would rather prefer a http solution with Accept-Size and then using Vary: Accept-Size, involving having to dynamically select the fitting image size server side :P

Anyway, thanks a lot for the feedback on this and especially the links :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment