Responsive image element proposed by the WHATWG

After months of discussing possible solutions for responsive images on the WHATWG mailing list, I discovered yesterday that another, different syntax was proposed on the WHATWG IRC channel. Additionally, when I joined the discussion, it became apparent that the majority of the WHATWG leads present in IRC weren’t aware of the proposed picture element—or, in fact, this Community Group. Thankfully, after being informed about our efforts, I was assured they would attempt to incorporate our input.

The majority of the people involved in the IRC discussion had not heard of our Community Group, and —though none of us were contacted for input when the time came to propose solutions.

So we’re all in the loop here, the currently proposed solution is a new set attribute on the img element. If that link’s not working for you, the proposed syntax is:

<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">

To recap, the markup pattern proposed by this community group is as follows:

<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>

I noted a number of concerns with the new, WHATWG-proposed img syntax in IRC, namely that it seems far less developer-friendly than the proposed picture markup structure.

But now? Now we need to hear from you.

The WHATWG, having now realized there’s been significant work being done in this group, wants to hear what you think. I’ve been asked to provide citations of developer opinion on the topic, so I’d like to ask you to sound off in the comments:

Does picture seem like something you’d like to write, or does the img set attribute seem more accessible to the average developer?

Additionally, if you have more thoughts on the topic you’d like to share with the WHATWG, here’s how to continue the discussion:

If you have a clear argument for or against the proposed syntax here, for or against the picture element, or a decided preference between the two: it seems like now is our opportunity to have our voices heard.

If you care about responsive images, I’d love for you to join in.

219 Responses to Responsive image element proposed by the WHATWG

  1. So when I asked Hixie – some time last year – about proposals that hijacked the existing `img` element, and was told that efforts using `img` were doomed (due to existing / legacy parsing rules)…that was wrong? Because the WHATWG proposal seems to do exactly that.

  2. The picture element is the clear winner for me. While adding an additional attribute to the img element could be nice for backward compatibility, the proposed syntax looks terrible.

  3. Matt Wilcox says:

    Wow, really? I have no idea how this has happened. OK, getting over my incredulity…

    set is awful.

    1) The syntax is not at all clear or familiar to anything else in CSS or HTML.

    2) It addresses only image dimensions and pixel density multipliers. That’s not even close to good enough, we care about other aspects such as bandwidth just as much if not more. image size is merely a proxy we’re using because we can’t detect bandwidth at the moment. With MQ you will be able to.

    3) There is no way to template set cleanly. At least with the proposed picture there is a clear way to template ( http://mattwilcox.net/archive/entry/id/1082/ )

    4) Set is assuming pixel units in an era where pixels are dying. Picture does not have that limitation and will happily conform to fluid units – which are actually what people use.

    Don’t get me wrong; picture as it stands is not something I’d use either. Far too much repetition and baking display sensing into the semantics layer (HTML). I’d use picture if it was extended to work as proposed here http://mattwilcox.net/archive/entry/id/1082/

    But the chances of me using set are even more remote. I simply wouldn’t.

    • Shepazu says:

      Merit aside, because of parser complexity in adding new elements in the , your / proposal is unlikely to be accepted. There may be other ways of doing that in the , but new elements are basically a non-starter.

      • Shepazu says:

        Sigh… stupid comment parser… my comment should read:

        Merit aside, because of parser complexity in adding new elements in the ‘head’, your ‘respond’ / ‘breakpoint’ proposal is unlikely to be accepted. There may be other ways of doing that in the ‘body’, but new ‘head’ elements are basically a non-starter.

  4. Sean says:

    The img syntax seems over complicated and is hard to understand, even with the linked explanation.

    The picture markup is not only straight forward, but it mirrors the existing video markup, and uses attributes that already exist and are understood by the development community. It also has the added benefit of being backwards compatible.

    My only minor quibble with the picture syntax is its use of the word “picture” as the tag name. Changing from “picture” to “image” not only makes more sense, but creates a strong tie back to the original “img” tag.

    • Cory Hughart says:

      I agree that the picture tag is much better than the img set attribute, and I also agree that the word “picture” is kind of terrible. Using “image” would make a lot more sense semantically. Is this an issue because “image” and “img” might be confused?

      This reminds me of the history of the img tag, when there was discussion about an alternate icon tag. Do we want to be stuck with an awkwardly-named tag for such a heavily used element?

  5. Levi says:

    Set makes absolutely no sense to me (seconding everything Matt Wilcox said about it) and I can’t imagine using it. Picture makes far more sense and is far easier to implement on a templated site.

  6. Chris Coyier says:

    I’m in favor of the <picture> element. It is comfortably similar to the syntax of video and audio elements which we already use. It also allows for the use of media queries, another already-comfortable syntax for us.

    This new proposed syntax feels weird to me. “w” and “h”? I’m sure that means “width” and “height”, but it’s used like a unit not a property. So then the value is pixels only? Surely that’s not as useful or extensible as a media query.

    • Rémy Bach says:

      Ditto! The element is way friendlier than the proposed syntax!

      We use timthumb to make sure images show up in the ratio we want (so the end user can upload an image and it shows up the way we want it to), and with the ‘set’ attribute, the markup would be an absolute nightmare!

    • Michael says:

      Chris, I prefer the picture tag too. But I just don’t like this double “source” thing going on. It reads “source source”, that’s confusing too.

  7. Chris C says:

    The picture element seems far more developer-friendly. I could probably implement it right now from memory, since the syntax is consistent with video and audio.

    I know for a fact I’ll have to use the set attribute dozens, perhaps hundreds of times before I know it well enough to write it from memory. That might slow down adoption rates with the average developer, to boot.

  8. Jason Gross says:

    As a matter of the format I would choose to use in my development process I find it very hard to argue a case for the proposed set attribute. It strikes me as some sort of weird Frankenstein of HTML and CSS attributes. It doesn’t strike me as a clear cut approach.

    The picture element on the other hand extends the capability of the tag and falls in line with what has already been proposed and agreed upon for the and elements. The latter point is a very crucial one for me. Standards based design and development should place a huge emphasis on consistency. There is much more benefit to having a picture element that is similar in its syntax to audio and video.

  9. John Porter says:

    set syntax is god awful. I much prefer picture as it follows suit with video and audio elements. img could still be used for simple images, like design related ones, but picture speaks so much more for what it is and does.

  10. Shane Hudson says:

    I am also in favour of the (or ) element. That said, it still does not feel fairly cluttered. But it would be easy enough to create a JavaScript script that creates ds sources to the picture element based on name.

    It still feels rather hacky, but unless something can be implemented at browser level for responsive images (including responsive in terms of bandwidth) then is probably our best bet.

    That said, I do see how adding set as an attribute to would make people feel more comfortable, but their proposal seems extremely confusing.

  11. bruce says:

    I’m not sure that this was proposed “by” the WHATWG, or not the inner circle, anyway. It was proposed by Edward O’Connor of Apple – he proposed a similar syntax for background images in CSS which is already being integrated into webkit: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-May/035746.html

    I dislike the syntax and imagine that designers will prefer to control which images are shown rather than rely on browser heuristics.

  12. This is the first I’ve heard of img set, and at first glance, it is completely unintuitive. Picture makes so much more sense, especially given the structure is very much like the already used video tag.

    The use of media queries is already something we all use. Why make up something totally foreign and less useful?

  13. There is definitely some weird syntax in the set attribute (e.g., w / h used in place of unit), but I think it makes perfect sense to expand on img rather than replace it.

  14. Between the two I much prefer the picture syntax for the reasons that Chris Coyier pointed out in comment #6 above.

    Picture could probably be improved upon but set feels like a step back. If we have to move forward with something and these are our only two choices then let’s please move forward with picture.

  15. Brannon says:

    I much prefer the picture element to the proposed set attribute. It’s much cleaner looking and easier to understand at a glance. I think that it will scale better over time if more and more sources and cases need to be included, while still being readable. Also, it’s consistant with the way different sources are handled in the video tag, and with the way we create fallbacks in many cases where differing support is needed.

    As a professional web developer, I would much rather use the picture element.

  16. Philip Ingrey says:

    Syntactically I prefer <picture>, also would ‘set’ have to request the header of the src image to get at the image dimensions even if it ends up using one of the other images?

  17. Mark Reeves says:

    I have nothing to add that hasn’t already been stated, but would add my voice to support the picture element.

  18. I would far prefer to write picture than add set attributes. Picture is a beautiful element (comparatively), it is nearly identical to the video element that many of us have come to love, and is simple to implement.

  19. maxw3st says:

    I currently handle image sizing by simply not defining a height and width. If you put an image of any size into a CSS container box it will fill the box according to the original aspect ration of the image.

    In other words as you scale down the size of the browser window the image scales down to match. As an example here is a template for a slideshow I am going to be making once classes allow me some free time:
    Click here

    Please note that no code specifies dimensions for the size of this image and it displays just fine for me in any size browser window. Not sure how it’ll look on an iPhone, but that would be a complete misuse of the fundamental purpose of this slide show. It’s primary purpose is to provide high def images of nebula without the usual clutter of site related content creating a distraction. It should look pretty good on an iris tablet though.

    just a thought

    • Matt Wilcox says:

      You are missing the point. This is all about sending images of different file-sizes, to avoid slow devices on slow networks dealing with huge downloads.

  20. Brannon says:

    I would also like to note that images aren’t the only things that will need to be able to be resized like this. Videos also need to be responsive to device widths and bandwidth considerations. Using the picture element to handle responsive images will allow the same syntax to be more intuitively ported to the video element.

  21. Ian Moffitt says:

    I love picture but I agree with Matt Wilcox in keeping media queries outside of markup.

    Maybe a companion css attribute, like

    @media (min-width: 800px) {

    picture {
    use: source1;
    }

    }

    or something like that. I’m trying to think more along the lines of ease of CMS use of the tag, since all the WYSIWYGs nowadays use just plain IMG tags and it’d be nice if they eventually supported more HTML5 stuff.

  22. Francesco says:

    Being member of neither the Community Group nor the IRC Channel I can say that I’ve heard a lot about the picture element these last few months, while this is the first time I hear about the img’s proposed set attribute.

    Personally I think that the picture element sound a lot better, being immediately backward compatible and also very easy and natural for the developer (following the very similar video element logic).

  23. I agree with the previous commenters that the element is superior in that it conforms to existing syntax styles. I for one would find the element much easier to read and write than the proposed modifications. I also think the element leaves a lot more wiggle-room for future expansion as use-cases become more complex.

    I also agree with Mat that modifying the tag could have unpredictable and disastrous effects in older browsers. I think that’s the whole reason Mat proposed instead of just revamping .

    And, since I’m feeling agreeable, I also agree with Sean that using the word “picture” seems limiting somehow. Although I can’t propose a better alternative, I have an ominous feeling that a use case will appear down the road where other types of non-picture media will benefit from this syntax. But perhaps that’s a bridge to be crossed when gotten-to.

  24. Paul Irish says:

    +1 on bruce’s link to the original proposal from Ed. More detail in there.

    Can someone write up the two approaches for the same semantic meaning? (Meaning: same filenames, etc)

    I really like the terseness of the srcset solution and do think currently <picture>/code> is too verbose, but..

    AFAICT, srcset is a solution primarily around display resolutions. We need a solution that conditionally picks image assets based on viewport dimensions and bandwidth constraints. Maybe the srcset syntax could be extended to that?

  25. Patrick Haney says:

    Reading up on all the efforts being made towards responsive images thus far, I have to side with the picture element as well. A lot of smart people have already chimed in here in the comments and have said more than I could’ve to argue against the WHATWG proposal for the img element and set attribute, so I’ll just say that I agree with them.

  26. Paul Irish says:

    +1 on bruce’s link to the original proposal from Ed. More detail in there.

    Can someone write up the two approaches for the same semantic meaning? (Meaning: same filenames, etc)

    I really like the terseness of the srcset solution and do think currently <picture> is too verbose, but..

    AFAICT, srcset is a solution primarily around display resolutions. We need a solution that conditionally picks image assets based on viewport dimensions and bandwidth constraints. Maybe the srcset syntax could be extended to that?

    • Ian Moffitt says:

      I feel like `picture` is easier to comprehend. Couldn’t additional bandwidth-related attributes be added to the source tags?

    • Chris Bank says:

      The syntax needs to be Media Queries. If I want a really responsive image, it may need to go from a landscape on desktop to a square on mobile. A change like that will affect the rest of the layout and I need to coordinate the rest of my styles. If there is the new syntax I need to do a bunch of recalculations and hope the browser is picking the correct pairing of image and styling.

      It doesn’t matter if it’s the tag or a generated content like solution @media{ img{ src:url(); } } }, the syntax needs to be the same so you can get the exact same results everywhere.

  27. The picture element seems like a better fit as the syntax is the same featured in audio and video (as Chris mentioned).

    Using media queries, which we’re already familiar with, seems a lot easier than using “600w 200h 1x”. It’s completely different than everything else in we’ve been using in HTML5.

    I think the goal should be consistency. This makes it easier for people just learning HTML. You could easily teach video, audio, and images together and it would make sense instantly. With the set proposal, you would have to separate them and that just doesn’t make a lot of sense.

  28. Rohit Mehta says:

    Well. This is great. makes total sense to me. The Set attribute is surely not developer friendly. Picture element being on the lines of the audio and video tag doesn’t have a high learning curve. This wins for me. I hope this is taken up. Great Job!

  29. Mo says:

    Massively in favour of , here, particularly given the use of media queries to specifically control matching of image resources to device capabilities.

    (The fact that there’s an existing polyfill to support it helps a little, but in practice doesn’t mean much, as that’d end up being the case whatever was codified).

  30. Michael says:

    I also prefer , especially as it seems way more expandable and is easier to read than the proposed img elment with a set attribute.

    Furthermore I hope that with the element we will finally be able to define images according to the bandwith. And by detecting bandwith I don’t mean something like navigator.connection, but some kind of detection to get the “real” speed. This way we could for example easily surf high-res images to devices, but only if the user sits on a fast internet connection.

  31. Tim Visher says:

    The picture is the clear winner in my books.

  32. Kyle Gach says:

    I think the syntax of the Picture element, primarily because it matches that of Video and Audio, makes much more sense than that of Img + Set attribute. The benefit of using media queries for the conditions is also huge, both for the already-known syntax and, more importantly, the flexibility of supporting further media queries (such as network connection speed) once they are developed.

  33. Kelvin says:

    I think this should not be a part of HTML at all. Let CSS or JavaScript handle these things.

  34. Zeldman says:

    I’m saddened that the WHAT WG has chosen to ignore the work of the community here, and puzzled that its editor would put forward an inferior solution to what has been proposed here.

  35. Kelvin says:

    I think this should not be a part of HTML at all. Let CSS handle these things. Or maybe even server-side!

    For example, and now im just thinking out loud, how about a “calculatedWidth” property usable in img.im-responsive[calculatedWidth>300] { /*style rules here, assuming a 100% set width*/ }

    • Matt Wilcox says:

      Don’t think no-one has tried. It is simply not possible for JS alone to solve this issue without having some broken HTML. Seriously, it’s been looked into by a lot of very smart people. It’s a no-go.

  36. While I can appreciate the higher organization of code that comes with , I’m in agreement with Paul Irish that it’s overly verbose.

    There’s only one image appearing on the page at any given time. I think there should only be one corresponding element for it with multiple attributes defining the different size images.
    Additionally, manipulating the DOM and performing operations on your code is easier if it’s all self contained in one element.

    -Bill

  37. Dave says:

    I also feel like set is a little too unintuitive. picture makes much more sense, but Matt brings up a good point that even that is not going to be totally useful looking forward. Having media queries is pretty nice (which set doesn't seem to address), but it also creates a burden of repetition which will need to be used on each and every image. The respond element may or may not be the correct solution, but it definitely goes farther than other proposed solutions.

  38. While I can appreciate the higher organization of code that comes with picture, I’m in agreement with Paul Irish that it’s overly verbose.

    There’s only one image appearing on the page at any given time. I think there should only be one corresponding element for it with multiple attributes defining the different size images.
    Additionally, manipulating the DOM and performing operations on your code is easier if it’s all self contained in one element.

    -Bill

  39. Adam Singer says:

    Huge fan of the picture element. It’s far more flexible. It can handle more than just media query type situations (what if a browser implements a new image format?). Plus, it follows the convention of audio and video.

    The set attribute isn’t obvious to me. It doesn’t make a lot of sense. You’re also going to end up with a very large set attribute which is going to be much harder to read than a list of source elements.

  40. Chris says:

    I’m not a huge fan of how verbose the syntax is, but the src set syntax takes terseness to an extreme! I’d much rather work with any day than deal with the confusing alternative.

  41. Not even close. The picture BY FAR.

    The img one looks like embedding flash files through the OBJECT element. WAY too much information and it’s cluttered.

    Elements need to be easy to understand and most of all INTUITIVE. The img solution you propose just isn’t.

  42. Not even close. The picture BY FAR.

    The img one looks like embedding flash files through the OBJECT element. WAY too much information and it’s cluttered.

    Elements need to be easy to understand and most of all INTUITIVE. The img solution you propose just isn’t.

  43. Derek says:

    Big fan of the picture element syntax. It is similar enough to the video syntax and the set attribute feels like an abuse of attributes.

  44. Tracy Rotton says:

    I’d vote for the element. The syntax corresponds well to the existing and syntax, and avoids legacy issues with the tag.

  45. Nate says:

    I can’t believe that this is even a question. The “set” attribute is so obviously atrocious. +1 for the version.

  46. Kumo says:

    Looks good to me! :-)
    The element seems like the perfect solution, even more with the fallback.

    I’m not a JS guy, so this kind of solutions really appeals me. Using media queries we can target the device precisely!

  47. Jelmer says:

    Definitely the semantic, as it is more clear, more structured and less hassle than the img variety

  48. Nate says:

    Comment system stripped the angle brackets… I meant +1 for the picture version.

  49. dave says:

    I really like the idea of the picture element, but I don’t love the idea of having the media queries right in the markup like they are. I don’t have a solution, but that’s the only thing I don’t love about it.

    Set, on the other hand, looks terrible. I actually had a hard time understanding what was happening before I read it 3-4 times. Not to diminish the work of whoever came up with this, but I really don’t think it’s a good solution at all.

    Sorry, not a lot of substance to this reply, but wanted to make sure the WG sees my position.

  50. Max says:

    It has to be the picture element of those two options, especially, as others mention, it follows the syntax of video and audio elements. Also agree with the comments about media queries making their way into markup – is that the direction that responsive code is heading?

  51. Dan Denney says:

    The people posting before me have said everything more eloquently than I can, but I want to go on record stating that the element is definitely more developer friendly.

    It is not perfect, but the use of media queries and the similarity to the and elements make it a big win for teaching and implementing.

  52. Brian says:

    My first thought with the proposed set attribute is that it would be hell to try and parse with JavaScript. At least the set follows a logical DOM pattern.

  53. Scott Block says:

    I think the picture is the clear winner. Already more clear to read/write, and more extendable down the road.

  54. Chris Grant says:

    The element is a nice approach, especially over the new img attribute.

    The syntax is a bit confusing, or perhaps I need a clearer example.

  55. kimblim says:

    +1 for – obvious advantages is that it has the same syntax as and is easy to read (intuitive).

    • kimblim says:

      Obviously that should have said:

      +1 for picture – obvious advantages are that is has the same syntax as video and is easy to read (intuitive).

  56. Ian Moffitt says:

    @Kelvin

    Markup is usually touched before CSS or JavaScript is loaded and subsequently fired. It’s better to figure out which image to download as soon as possible, and I don’t feel like any current JavaScript method does this sufficiently.

  57. Sharbel says:

    Picture is cleaner and easier to understand but it’s still not the place for these media based transformations to happen. Let the mark-up *mark-up* that an image should be there and let the stylesheet decide what is the best image/style-rules to apply to the image based on the device requesting.

  58. Owen says:

    I dislike the img/set syntax because it’s cryptic and does not build on existing knowledge/technology.

    The picture syntax seems better, but can already be done with a div, several internal img elements, and some CSS media queries.

    An ideal solution would allow a single img tag to render the correct src based on media queries. The syntax shown for set is simply too cryptic to be useful, and not (at least to my eye) extendable via CSS.

  59. Cole Peters says:

    Here’s another bit of support for the element. As a designer and front-end developer, I find the “set” attribute far more (needlessly) complex than ‘s natural-feeling syntax. The “set” attribute’s syntax style just seems dated.

  60. Christian Neuberger says:

    I’m in favor of the picture tag. This seems much closer to the way we currently handle video and objects and is much cleaner than the “set” proposal on the img tag.

    It also has a nod toward media queries which helps tie this together with other similar concepts.

  61. Brian says:

    * correction: At least the picture element follows a logical DOM pattern.

  62. Did we solve this in 1992 with LOWSRC on the img tag?

  63. Ian Moffitt says:

    @Paul

    I feel like `picture` is easier to comprehend. Couldn’t additional bandwidth-related attributes be added to the source tags?

  64. Michel Marrache says:

    When I saw the approach in an article a couple weeks back, the first thing I thought was how brilliant it was.

    It is very works very similar to the current HTMK5 tag so when I saw the proposal, I thought and still believe it’s completely backwards.

    It’s not intuitive and seems like it doesn’t give developers as much control. For example, what are 1x and 2x exactly?

  65. Eileen says:

    Consider me a representative of that large group of people who uses HTML but does not live & breathe it — on the 2nd RWD site I built I already could see a need for different images at different screen sizes.

    I read the picture syntax and understand it immediately. I have read through the set syntax 4 times now and I still don’t get it. It will fail if 2 entries have the same descriptors? W is optional, or H is optional, but if any have it all need to have it? We have to specify W or H or density because otherwise the comma will cause a syntax error?! Recipe for disaster.

    I have a bit of a soft spot for the idea of expanding img but this syntax is seriously confusing. We can do better.

  66. Matthew Trow says:

    Vote for the picture element here.
    The proposals above for the img element are … messy.

    Some people have commented along the lines of “why either?”
    I’d have to give a lot more thought to that, I’m on the fence here. Having gone through the pain barrier of creating responsive websites, I’m more inclined to suggest a hybrid approach – websites which utilise media queries AND server side methods to deliver content to different devices.

    If that’s the case, the trusty old IMG element as it stands now is quite simply good enough.

    KISS – keep it simple! – lets not litter HTML with yet more markup options!

  67. Kornel Lesinski says:

    The two proposals solve different problems. The imgset is for bandwidth/dpi, and picture is for layout/screen size.

    So they’re not really even competing! Those are orthogonal issues.

    I like terseness of the imgset.

    I don’t think developers will usually bother to prepare more than low & high res versions of images, and just specifying filenames and @1x @2x works very well for that basic case

    *lt; 20% effort > 80% functionality.

    • Matt Wilcox says:

      Wrong, picture can address those issues too because it uses media queries – which can detect DPI and are set to soon detect bandwidth. imgset does not detect bandwidth either.

      • Kornel Lesinski says:

        No, it has been explained many times (more than there are letters in min-device-pixel-ratio) that media queries are a poor fit for selecting image resolution, and there will be no bandwidth media queries.

        http://www.xanthir.com/blog/b4Hv0

        Bringing up rejected min-device-pixel-ratio is not going to move the picture proposal forward.

        It’s more productive to admit that MQs are not suitable for all cases and extend picture with something that is:

        http://lists.w3.org/Archives/Public/public-respimg/2012May/0003.html

  68. Andre Jay Meissner says:

    +1 for picture, all good arguments above.

    Thumbs down for JS/CSS handling on a long term view. What we need is a streaming image format, no fragmented workarounds.

  69. Jory Graham says:

    The tag seems to leave more control in the hands of the developer to decide what assets should be served when, and has the benefit of not requiring Yet Another Microsyntax, since it can just leverage media queries.

  70. Ryan Chapel says:

    The currently proposed syntax is beyond horrible. It’s confusing, not memorable, and isn’t consistent with any other existing html.

    If these are the only two options, let’s go with the element. At least it matches the element syntax.

    While i’m here I might as well ask: what’s up with all the horrible proposals lately from web standards bodies? The CSS variables proposal from the W3C was just about as confusing as it could’ve been (can’t just copy what Sass has?), and now these img attributes which are just a long messy string of unhappiness.

  71. Jason says:

    The picture syntax is definitely more pleasing, but at the same time I don’t see an issue with the img set attribute.

    If I was to get behind one solution, it would probably be the picture element as it’s more consistent with the video and audio tag syntax.

  72. The set attribute and the syntax is confusing to read. I’ve always liked the picture element from it’s conception but feel the same as paul irish towards the verbosenesss of the picture element -especially for large imagery sites like a Flickr. I’ve said that before and I’ll say it again.

    We need it to be simple, future friendly and powerful all at once. The devil is in the details and the details are how to list all the sources in a manner that is pragmatic, consistent, easy to maintain, bandwidth/resolution friendly and sensible.

  73. Larry Garfield says:

    Skimming the picture tag, I can see immediately exactly how it works and how to use it.

    Glancing at the set attribute, my eyes glaze over. space-delimited list of magic numbers? What? And is the @ in the file names significant, or is that just an artifact of the proposal coming from an Apple developer? That’s unclear.

    I agree that I’m a bit uneasy about putting that much “style” information into the markup, but the set attribute puts the same amount in. It just does it in a less comprehensible syntax.

    And really, it’s not style markup. It’s resource definition. The picture is the meta-resource, and the sources inside it are the variants to use under “some circumstance”. Strictly speaking, I could very easily see overriding the default browser logic from Javascript to put in a different set of logic for choosing which source to use. (And that same statement applies to audio and video, too.)

    In fact, looking at the picture element I can easily envision how one might write a JS API to make it easier to manipulate and provide additional client-side extensions, and that same model would work for audio and video, too. Looking at the set attribute, I cannot fathom how one would write a *good* JS API to manipulate it. And yes, we will want this data manipulatable just as you can programmatically mess with the height, width, and src attributes of img now.

    This is a no-brainer for me. A new well-designed element is the way to go. Let’s focus on refining that.

  74. You all have done a great job summarizing why picture is favorable over a set attribute. As far as picture goes, though, I do side with Matt on the complexity/verbosity issue.

  75. Anahkiasen says:

    Pretty much the same than everyone here. The set syntax is horrible, unintuitive and unflexible. While the picture element mirrors comfortably the video tag and uses the preexisting flexibility of media queries.
    Please let us be heard, adopt the picture element.

  76. jklm313 says:

    Aye for “picture” http://dl.dropbox.com/u/32750720/YES2.jpg

  77. John Holt Ripley says:

    I’m at the risk of repeating what’s been said here already, but I wanted to add weight to the developer opinion requested. I think ‘picture’ is the way to go – it has much more flexibility and using the MQ style approach enables more features to be tested against as they become available.
    That said, I do think the current proposal for ‘picture’ is quite lengthy and hopefully that could be improved to make it more maintainable (especially if a lot of images will share breakpoints and conditions) – maybe part of this could be moved to css or some sort of meta attribute in the head that sets a default scheme.
    I don’t know to be honest, we haven’t quite got the answer yet, but I don’t think we’ll go wrong choosing picture over srcset.

  78. I’m in favor of neither! The picture proposal is way to verbose, I can’t imagine have to use that for a dynamic site.

    The img with set proposal seems a little easier to implement but the syntax is awful.

    I’d like to see something more along the lines of:

  79. Matt Bainton says:

    I’d strongly agree with Chris Coyier’s response: The “000w 000h” seems maddeningly restrictive and confusing. It doesn’t even follow the CSS convention of x then y axis in things like background shorthand.

    seems much more flexible and friendly with the parallel syntax of other new media elements, and especially user-friendly with the media-query-like attribute.

    I’ll be disappointed if I have to write the new tag instead.

  80. PJ McCormick says:

    Between the two in their current forms, is the clear winner. It looks far easier to write, read, and understand. The “set” attribute syntax–and hell, even the term “set” itself–just seems unintuitive and unwieldy.

  81. Matt Bainton says:

    The preview of my previous comment stripped my blocks. Should read:

    " seems much more flexible ..."
    "... disappointed if I have to write the new tag instead."

  82. The picture element easily looks like the best solution here. The mark up is clear and will be easy understand for those familiar with the video and audio tags.

    One bonus the picture element would have over the img srcset is that the picture element could support new image formats while having a fallback for browsers that don’t support image format X.

    Here is an example of what that markup might look like: https://gist.github.com/2509735

    The only issue I have with the picture element is how verbose the markup can get when you start to support multiple devices with various screen sizes/resolutions. I’ve posted a thread about this issue here: http://www.w3.org/community/respimg/2012/04/26/syntax-issue-with-displaying-high-resolution-images-in-the-picture-element-how-a-mole-hill-could-turn-into-a-mountain/

    I would like to see a solution developers could use as an alternative to multiple source tags in the picture element where developers could alter the image loaded in the picture element through CSS, using syntax like image-set() and URI templates. This would help keep the picture element short and simple as well as help with maintainability and keep the overall codebase DRY.

    Here is an example of this concept.
    https://gist.github.com/2572749

  83. Chris says:

    I vote for the picture element. It’s a lot easier to understand, seems more extensible, and provides nice hooks for javascript and css interaction.

  84. ienakiko says:

    Go for the element!!!

  85. Jeff Coburn says:

    Between the two, the ‘picture’ markup seems more developer friendly. Because of it’s similarity to the video tag, it seems closer to the paving the cowpaths concept that HTML has embraced recently.

  86. Erik Runyon says:

    I agree that “picture” is easier to read and easier to understand at first glance. I also like the terseness of imgset. The “winner” between the two is the one that can adequately handle screen resolution and bandwidth concerns. Anything less than that is pretty much pointless.

  87. Jonathan Tegg says:

    The picture element is my choice. It’s easily readable and compliments the ideas behind the video element.

  88. To those who question whether or not this should be handled in HTML at all: images/pictures are a part of the content, and as such should be handled with HTML, the code that is designed to markup content. Handling this through CSS or Javascript encroaches on the divisions between content, presentation, and FX.

    Besides, we’ve already crossed this bridge with the HTML5 video element, which determines what codec should be delivered for what browser. Considering that, it is a very small leap to apply that syntax to the picture element as well.

  89. Bjartur Thorlacius says:

    Why not extend ?

  90. Chip Cullen says:

    I’ll ad my voice to the chorus – I think the element is the better option. It’s just flat-out more intuitive, and as has been pointed out, simliar in nature to other established media elements.

    I *do* think it is important to have a markup language that is easy to comprehend, and if the element’s cost for intuitiveness is a little extra verboseness, so be it. I’m thinking here of future HTML authors and what they would find more easy to grasp when learning the language. I think that answer is clear.

  91. Shane Hudson says:

    Just for the record, I like the idea of Matt Wilcox’s derivative of . Breakpoints would work well for this, as well as future proofing by allowing any type of query that may exist (I especially like the idea of using it for bandwidth).

  92. Bjartur Thorlacius says:

    Why not <object>?

  93. juicypx says:

    I think we can agree that the set attribute is counter intuitive for developers. However I also think that the current proposal needs a solution for setting default breakpoints to reduce code repetition – for example an element in the head as suggested by Matt that lists all breakpoints and that is available for HTML as well as CSS and JS. I don’t know if picture is the right term that describes this approach best, but I definitely support the markup structure.

  94. is for me the only sensible option. It fits nicely with and and it’s human friendly.

    Easy to use, easy to remember, sensible semantic markup. What’s not to love?

    • Seth Warburton says:

      ahh. That’ll be stripped then.

      Of course, I clearly favour ‘picture’ as it already has close brethren of ‘audio’ and ‘video’ and is 100% developer (and indeed non-developer) friendly.

  95. Brannon says:

    How many developers are going to need to say “I can’t tell what set is doing, give me intuitive syntax” before the proposal is at least revisited? “Set” is obviously a bad idea, the way it is proposed now. I will grant that maybe something better than “picture” can be done, but I am already grinding my teeth imagining using “set” in the future. Please, working group, listen to your end users!

  96. At first glance I hate set. Reading through the comments I think the general idea of it has merit but the actual syntax looks confusing, especially the w and h. I do however like the version that Denis Leblanc suggests. Particularly if it could include min-bandwidth (or something similar).

    If it was a choice between the suggested set or picture. I think I would find picture much better to use.

  97. awesomerobot says:

    The currently proposed solution is rubbish, pure and simple. I’d rather eat a bucket of deep-fried vendor prefixes.

    I think the key to moving forward with HTML as a markup language is to keep it readable by humans. Making things as terse as possible sounds pretty awesome if you’re looking to cut every possible bit, but in practice you’re talking about creating markup that’s often just utterly frustrating to work with.

    I mean seriously, this? This already looks cryptic and it isn’t even markup in the wild, it’s an example. Take things one step into reality and things get awesome, I can’t wait to see something akin to:
    <img src="face-600-200@catphoto1-600x200.jpg" alt=""
    set="face-600-200@catphoto1-600x200.jpg 600w 200h 1x,
    face-600-200@catphotoHD-600x200.jpg 600w 200h 2x,
    catface-icon-200x200.png 200w 200h"

    As others have said, the picture solution is a context that all of us are already familiar with. If you came out of a coma from 2010 you’d likely understand what the picture tag does just by reading it. New HTML elements should be readable by all two-year coma patients.

  98. Jérôme Coupé says:

    I add my vote to the picture element (or some variant thereof). Makes a lot more sense to me that using an img tag with a set attribute.

    Second what has been said above (understandable, builds on known patterns like and , extensibility). Might not be perfect (DRY) but in the right direction IMHO.

  99. Ashley Nolan says:

    I’m a fan of the picture element myself, but agree with Matt Wilcox in that it would be better to separate out media queries from being put on the source elements somehow.

    I like the fact that the picture element follows video and audio in structure, but feel that having the media queries in each source element could make code very verbose in future when media queries start dealing more regularly with variables such as bandwidth.

    The img set proposal isn’t particularly friendly syntax, especially when compared to current HTML – it could provide a bigger barrier of use than the picture element because of this. I also don’t like the use of w and h for width and height – it just isn’t consistent compared with what has preceded it in HTML and looks slightly out of place to me.

  100. Liam Jay says:

    Personally, the picture element is the clear winner for me. I can understand the logic behind adding an additional attribute to the img element so that it has the benefit of backward compatibility, but the proposed syntax looks very confusing and seems to be more in line with other elements like .

  101. Jen Matson says:

    Another vote for picture. Agree with many of the points already noted — about piggybacking on an existing convention (video), using familiar syntax. picture just makes intuitive sense to me, and I say that with both my front-end dev *and* UX hats on.

    I also feel very comfortable backing picture knowing the time and effort Matt and others have put into not just hashing out this kind of approach, but also on large-scale, complicated projects that have helped inform and refine their views, and their efforts in evangelizing these ideas to the larger design and development community. Which is why I feel compelled to comment today.

  102. I’d gladly use element. We already know how to use it.

  103. Brannon says:

    After thinking on the “set” attribute a little, I’ve realized that in addition to other problems mentioned, it’s also not a very intuitive name for the attribute. What the “set” attribute basically is is a conditional src tag. It sets image source, and it sets conditions for image source. The same thing could basically be done more intuitively like this:

    <img src=”face-600-200@1.jpg” alt=”” src-when[max-width: 600px and max-height: 200px]=”face-600-200@1.jpg1x” src-when[max-width: 600px and max-height: 200px and min-resolution: 2]=”face-600-200@2.jpg” src-when[max-height 200px and max-width: 200px;]=”face-icon.png”>

    or:

    <img src=”face-600-200@1.jpg” alt=”” src-while[max-width: 600px and max-height: 200px]=”face-600-200@1.jpg1x” src-while[max-width: 600px and max-height: 200px and min-resolution: 2]=”face-600-200@2.jpg” src-while[max-height 200px and max-width: 200px;]=”face-icon.png”>

    or maybe even

    <img src=”face-600-200@1.jpg” alt=”” src-if[max-width: 600px and max-height: 200px]=”face-600-200@1.jpg1x” src-if[max-width: 600px and max-height: 200px and min-resolution: 2]=”face-600-200@2.jpg” src-if[max-height 200px and max-width: 200px;]=”face-icon.png”>

    There are several advantages to this. First, the attribute name explains what the value is, and what the attribute does. The image source is used when/while/if something is happening. Secondly, the syntax can match media query syntax for more a more intuitive switch between css and html. Third, the syntax can expand just like media query syntax, but without so much confusion. Fourth, this will be a lot easier for JavaScript to parse. Finally, because the src and conditions for the src to be loaded are each separate, it would probably be easier to pollyfill this soultion. Like the data attribute, older browsers will see these attributes and do nothing with them; they’ll load in the DOM, but they just won’t do anything. JavaScript could go in in older browsers, and just parse each attribute for its conditionals, and it’s src.

    Just to be clear, I’m not presenting this as an alternative to the picture tag, but as an alternative to the set attribute. For people who want to use attributes, this does the same thing as set, but it self documents, matches existing syntax, and is more JavaScript/human readable.

  104. Kevin Suttle says:

    Well, I’m sticking to my guns. Read my initial, from-the-hip thoughts and some follow-up thoughts here

    1. I’ve never been a huge fan of the name ‘picture’, but I guess there really aren’t any better terms. (I’ve looked).

    2. The W3C needs to decide if img is able to be modified or not. Either way, my next point may negate the outcome.

    3. I’m a little stunned either one is being considered when media query syntax is being used in the markup. (Yes, Matt Wilcox, I saw your comment :) )
    To me, the content is a markup problem (the subject of the image), but the size of the image is a CSS style problem. If the site we run our solutions on can handle media queries, then it can handle CSS3, including multiple backgrounds. Why hasn’t a similar syntax been proposed? In order to keep presentation separate from content, I think we need to steer the conversation in this direction.

    3. If we are forced to do handle this in HTML, why not pave the cowpaths like the Microformats community did? See this example from the Filament Group from 2010. While I don’t want to rely on JS or .htaccess as a solution, I think the notion of custom data attributes is far too powerful to be overlooked. We can get creative and combine this with attribute selectors in CSS, combining the syntax of multiple backgrounds, or even better CSS pseudo selectors + media queries + generated content to place the appropriately-sized images.

    I worry that in our haste to standardize a working solution, we may have started looking for answers inside the box. There is more to be discovered for sure.

  105. Andrew Frank says:

    Hi all.

    My name is Andrew and I am just graduating from college with a BFA in communication design. While I’m not a developer I do a lot of front end HTML and CSS. I don’t understand why everyone is focusing specifically on responsive images here. It seems as though a system should be in place to swap any content via HTML and media. A universal solution is more future proof, am I right? I understand that would be very full proof and a quickish fix, but we are bound to encounter the same issue with other media that cannot be reassigned via CSS or JavaScript easily/effectively. My two cents.

  106. Ischa Gast says:

    +1 for the picture element!
    That looks much better than the img set code because it’s just like the video & audio element.

  107. Zachary Forrest says:

    For the sake of cuddly bunny rabbits and my little ponies, can we please not use the set attribute?

    The picture element, in my opinion, makes sense in light of patterns that are established for video and audio.

    If there are other options out there, let’s look for them. But I think we should start from the picture proposal rather than destroying the squeezable cute face of the img element with an attribute hammer.

  108. Picture is a clear winner when comparing to set. But it has its issues too (as many people already said… like mixing media queries with markup, and the ugly ‘picture’ name itself).

    But the final solution needs to be based on media queries. People already know this and trying to replicate it with new syntax (like ‘set’ did), is very bad.

  109. Brandon Carroll says:

    I prefer the picture element to an img with a set attribute. I agree that picture is a bit on the verbose side, but I’m fine with multiple src attributes. The proposed WHATWG implementation is much less straightforward than the picture element. One of the beautiful things about HTML is its approachability, and that set attribute just doesn’t jog with the rest of the language, in my opinion.

    Where I become concerned with the picture element is the media queries. I know we can already do this with link elements, but I feel it blurs the lines between content and presentation too much here. I like the idea of having a way to tie each version of the image into CSS, as Ian Moffitt mentioned above, but maybe not that implementation exactly.

    I definitely do think the media query bit should be happening in CSS, not HTML… But either way, my vote goes toward the picture element.

  110. The imgset syntax is not intuitive like picture, which I’ve watched evolve and prefer. It more easily allows extension for alternative media queries and mirrors similar media elements (audio/video).

    Eventually, non-developers will have to confront what’s decided here without a WYSIWYG editor. picture is much more digestable for somebody with a cursory knowledge of HTML.

    I don’t like the idea of putting media queries directly in markup/content though. This is a maintainability train wreck. Abstracting the values to meta tags (or some other global data attribute) would allow the media attribute to behave more like a CSS class with external definition. Smartly named “classes” could exist for a long time.

    Here’s an example:

    <meta name="picture-source" media="large" content="min-width: 600px" />
    <meta name="picture-source" media="large-hires" content="min-width: 600px, min-device-pixel-ratio: 1.5" />

    <picture alt="">
    <source src="mobile.jpg" />
    <source src="large.jpg" media="large" />
    <source src="large_1.5x-res.jpg" media="large-hires" />
    <img src="mobile.jpg" />
    </picture>

    I’m also not too pleased with picture as a name candidate, but it’s probably not worth confusing image/img.

  111. Picture element all the way

  112. Billee D. says:

    I’m still on the side of the new picture implementation over the new set attribute. Picture seems more future-friendly and syntactically sound; cleaner, if you will. As a few others have stated already I don’t like the set syntax at all. Matt’s proposal makes much more sense and is clearly a more flexible solution.

  113. Shepazu says:

    I personally prefer the ‘picture’ element syntax, with one caveat:

    Instead of an alt=”” attribute, there should be a child element (like the SVG ‘title’ or ‘desc’ elements) that contains the fallback text. This is more accessible and internationalizable, and it would also provide fallback text even in older browsers that don’t support ‘picture’.

    You could even style the fallback-text element to display the text content as a caption, either statically or as a mouseover.

    For legacy browsers, have you made a ‘picture’ polyfill? If not, you might consider doing so.

  114. Oscar Otero says:

    I don’t like element because it creates a new element to do the same of an existing element. Why don’t use the in the same way than the proposed ? For example:

    With this syntax you can continue using img without reinventing the wheel with another element. The old browsers understand it without using javascript or other hacks.

  115. Oscar Otero says:

    Oops, sorry. The html code I’ve written in the previous comment has been deleted. Here is it:


    <img src="http://lorempixum.com/200/200">
    <source src="http://lorempixum.com/600/600" media="min-width: 600px" />
    </img>

  116. Oscar Otero says:

    I don’t like element because it creates a new element to do the same of an existing element. Why don’t use the img in the same way than the element proposed ? For example:

    <img src="http://lorempixum.com/200/200">
    <source src="http://lorempixum.com/600/600" media="min-width: 600px" />
    </img>

    With this syntax you can continue using img without reinventing the wheel with another element. The old browsers understand it without using javascript or other hacks.

    • Jason Grigsby says:

      Current browsers treat img as a self closing element. If you include child elements inside an img tag, they will be moved by the browser into sibling elements.

      This is simple to verify. Create an html document with the syntax you suggest. Use web inspector in Chrome to look at the DOM. What you will find is that your code has changed to:

      <img src=”http://lorempixum.com/200/200″>
      <source src=”http://lorempixum.com/600/600″ media=”min-width: 600px”>

      No closing tag. Source is now a sibling to img, not a child.

      • Oscar Otero says:

        You are right, but I don’t thing this is a problem. The future browsers that understand the sources inside the img will load the image file according to the media attribute and the old browsers load the img element and ignore the source element.

  117. Would something like this be possible?

    <meta name=”media” data=”large” media=”min-width: 600px” />
    <meta name=”media” data=”large-hr” media=”min-width: 600px and min-device-pixel-ratio: 1.5″ />

    <img src=”file-name[media].jpg” alt=””>

    Files could be named as such: file-name.jpg, file-name-large.jpg, and file-name-large-hr.jpg

    • Matt Wilcox says:

      This is a really nice idea, like a much more compact version of http://mattwilcox.net/archive/entry/id/1082/ I dig it!

    • Matt Wilcox says:

      It’s even backward compatible, and will work for altered paths. So for example you could just as easily use it like:

      <meta name=”media” data=”/small” media=”min-width:350px” />
      <meta name=”media” data=”/large” media=”min-width:1000px” />

      <img src=”/content/images[media]/photo.jpg alt=”” />

      And, as long as you have a folder called images[media] with photo’s in it too, it’s backward compatible. Heck you wouldn’t even need the folder, just alias it in the server config.

    • I like this solution a lot. For true backward compatibility the img element could have a new attribute to handle the responsive src:

      • Edit:

        <img src="fallback.jpg" rsrc="file-name-[media].jpg" alt="" />

        • Martijn Megens says:

          Or include a “point-of-entry” variable,
          in the meta-data, or as a seperate meta:
          1) :first (represents first directory)
          2) :last (represents last directory)
          2) :name (pad name left)
          2) :ext (pad name right/just before extension)



          or one-for-all


          becomes:


          or

          This way NOTHING changes for older browsers.

          • Martijn Megens says:

            Or include a “point-of-entry” variable,
            in the meta-data, or as a seperate meta:
            1) :first (represents first directory)
            2) :last (represents last directory)
            2) :name (pad name left)
            2) :ext (pad name right/just before extension)

            meta name=”media” data=”/small:first” media=”min-width:350px”
            meta name=”media” data=”-large:ext” media=”min-width:1000px”
            or one-for-all
            meta name=”poe” data=”large-:name”

            img src=”/content/images/photo.jpg alt=””
            becomes:
            img src=”/small/content/images/photo.jpg alt=””
            img src=”/content/images/photo-large.jpg alt=””
            or
            img src=”/content/images/large-photo.jpg alt=””

            This way NOTHING changes for older browsers.

    • This is really similar to what I proposed a few comments earlier: http://www.w3.org/community/respimg/2012/05/11/respimg-proposal/#comment-699

      The failing is that is requires a specific server architecture or configuration-level access. This can’t always be guaranteed. It’s much easier to have a markup-dependent pattern than a file system-dependent pattern.

      Using a data-attribute to store the media type is as simple and bypasses the need for server-side constraints.

    • I like this idea a lot. It keeps things simple. So it sets a variable from the active media meta tag, and in essence, uses a URI template to fill the image src attribute. It would be nice to see the media meta tags being extended for use as a variables in CSS and JS files. I think this is an idea that is worth exploring more.

    • Daniel Newns says:

      just been discussing this, and i must admit this one seems to be the best idea i have seen so far, +1 from me.

    • Jacob Mather says:

      It’s a great idea in theory, but the issue is backwards compatibility. Every browser currently on the market now would download file-name[media].jpg. And with the long-tail of browser adoption, that means a bunch of extra files hanging around for a long long time.

  118. Adrian says:

    …at least it’s not .

    nonetheless, I’m definitely siding with the element. The reasons have been stated above.

    • Adrian says:

      [correction to my post above]

      …at least it’s not <imggroup>.

      nonetheless, I’m definitely siding with the <picture> element. The reasons have been stated above.

  119. Erik Kraft says:

    Picture element. Please. So clearly superior to the mind-bending “set” syntax.

  120. David DeMello says:

    picture is not perfect, but it is the better choice now. Choose it and let’s make it better.

  121. Oscar Godson says:

    I really, really dislike the <picture> tag. It’s gross and way too verbose and is solving the wrong problems. I much prefer the set attribute. I wrote up my concerns:

    http://oscargodson.com/posts/picturefill-needs-to-die.html

    • Jason Grigsby says:

      Your description of the problem and proposed solution focuses entirely on network connection. That isn’t the full scope of the issues:
      http://blog.cloudfour.com/a-framework-for-discussing-responsive-images-solutions/

  122. Just like many smart people on here have already suggested, I would love to definitely stick with picture element as it makes the most sense. It uses already similar approach as when dealing with video or audio elements. It’s syntax is cleaner and I find it easier to remember that he one proposed by WHATWG, or Ed O’Connor.

  123. Andrew says:

    Oy vey…just looking at the ‘set’ code makes me wince. Picture needs a lot of work (name, length of the code, and so on), but it comes a whole lot closer to solving the problem than this mess. +1 vote for the picture element, taking into account the caveats that have already been brought up by more knowleadgable voices (above).

  124. As a newcomer to these different proposals the picture element seems far more logical code and closer to video and audio.

    However, it’s a hell of a lot of code to write. Set is far more succinct, but is obtuse and I’d find it difficult to learn. As it currently stands I’d prefer the picture tag, but it would be nice to see more examples of how each approach would work for common use cases.

    On the set attribute, would this even work? There seems to be comments elsewhere that browser manufacturers claim rewriting the img tag to conditionally load images is near impossible.

  125. Anselm Hannemann says:

    I am very sad that the WHATWG seems to not recognized our group. This is something I cannot understand. I posted several times in the WHATWG-mailing list my img-proposal (https://gist.github.com/1158855), then the picture-element and many more things. But nevertheless I want to say something about the WHATWG-proposal:

    The syntax is a no-go. We never had such syntax in HTML and it is similar to the non-standardized Apple-way to solve responsive images. This CSS way by Apple is also not handy and we won’t use this as a standardized version.

    If we really should do it the tag way, we should use my initial proposal from months ago: https://gist.github.com/1158855
    This is a syntax which makes it clear how to use it, what way to handle it and it is somehow a proof of concept. This is the only way (and we discussed this many times before) to do it within the original img-tag.

    Otherwise we thought about many solutions and came to the picture-element which is the best way to do responsive images in HTML.
    We discussed this for months now and I think it is proven that this is the best way to handle responsive images. But we also know that the proposed element and sytax specification is not finished yet. Matt (Wilcox) stated in the comments about a templating way to make it easier for developers. This for example is something we need to address but first it seems we need to proof that this is the right way to go.

    Please, WHATWG members, trust us that the picture-element is the best way. If you don’t like it, use my proposed solution which uses a more common syntax for developers and is easier to write and maintain. Thank you, I’d really appreciate this!

  126. Joel Birch says:

    I love the idea proposed by Denis Leblanc, around 8 comments prior to this one. Before seeing it my preference was for the picture element, although embedding the media query with each tag feels so wrong.

    So I vote for scrapping imgset and picture and starting over with the meta-tag-media-variables-with-plain-old-img-tag idea. (Needs a better name, maybe).

  127. Pingback: An alternative proposition to and srcset, with wider scope | Responsive Images Community Group

  128. The picture element is definitely the way to go. It’s far more readable than the alternative and uses patterns that we’re already used to writing.

  129. Jacob Mather says:

    I’m just going to be blunt. I’ve tried to be nicer about this stuff but the text just ends up far too long.

    The thought of the set format becoming the standard makes me physically anxious.

    The variable strategy is elegant, until you account for every browser currently out there now, and have to name a directory images[media]. That is terrible. I’ve heard others say that modifications to will be hard to accomplish? Does this play into that?

    The only solution that really makes sense thus far is a two pronged approach:

    1) The html based picture element. Yes, it’s verbose. That’s kind of the point. It’s for your content. It NEEDS to be flexible.

    2) The css based image set (image-set? img-set?). Yes, it’s more awkward to use for content — but it’s not MENT for content. It’s for your layout, so you don’t have all of the excess code needed for the picture element in the rest of the layout.

    The bottom line is this: The point is to provide us all with the right tools for the job. Giving both an HTML and a CSS based way to cope with responsive images makes a way for everyone to do what they want to do, and you and decide where it is you want to optimize and organize.

    I don’t mean to step on anyone’s feelings, I’m just trying to make sure my point is clear.

  130. Xavier says:

    I am not really sure whether this belongs in HTML at all.

    The way I see it, having read through the proposals and a lot of (but not all) comments, there are two very different problems being mixed up: 1) viewport size and 2) available bandwidth. Both problems should be tackled with different solutions.

    In my opinion, the bandwidth problem is not something that belongs in a markup language. It should be handled by the client/image format itself. Progressive JPG files actually already kind of solve that problem in a very good manner—although we could benefit from better implementation. A browser (or whatever client you use to fetch data) is much more fit to decide whether it should download the high-res (complete) version of an image, or stop downloading the image after n passes/amount of data has been transmitted. That has absolutely nothing to do with viewport size. And seriously, who wants to save low-medium- and high-res versions of every picture they have on their server? Imagine what a clusterfuck of images and filenames that becomes when you also cater to viewport size . . .

    Concerning the viewport size, metadata is much more fit to tackle the problem. It could, for instance, make a lot of sense to use a different crop of the same image on a small screen and use the full crop on a big screen. But again, I am not sure whether that kind of descriptive info really belongs in HTML.

    Essentially, what you’d want is a separate meta-file (xml, maybe?) that describes the different crop points of the image, much like SVG describes beziers–but unlike SVG in that it doesn’t describe itself. That way, image editing software can be used to define the crop points and generate and maintain that file, separate from the HTML document. And also that way, you can do some awesome backwards-compatible stuff like:

    And your image.xml being something like

    image.jpg

    image.jpg

    Of course, we’d have to think a bit harder about the syntax and possible use cases, but I just really, strongly believe that this does not belong in HTML itself.

    • Xavier says:

      *sigh* HTML stripping, never really works the way you’d expect. Another try:

      [...] And also that way, you can do some awesome backwards-compatible stuff like:

      Example Code

      Of course, [...]

  131. Scott Jehl says:

    Thanks, Mat! Nice recap. This is unfortunate.

    The largest issue I see with this new attribute proposal is that it doesn’t solve the problem entirely: any browser that exists today will immediately begin downloading the image referenced in the src attribute, and no JavaScript polyfill can prevent that request from occurring (it happens long before the DOM is available for scripting).

    A JavaScript polyfill could easily add support for the SET attribute and replace images with the intended size, but at that point, the damage is already done. Additional overhead is a serious problem here – it’s the reason we’re discussing a new element in the first place!

    A serious proposal should offer something that we can use in browsers that exist today. This issue is more about building fast-loading experiences than it is about developer conveniences, but as it is, PICTURE offers a great answer for both, and it’s already polyfilled to work great in browsers that exist today.

    I’ll add a +1 to disliking the syntax as well, but frankly, I just want something that addresses all of our needs, and PICTURE does that in ways SET cannot.

    I sincerely hope the whatwg considers the discussions and code that this community group has produced. At this point, loads of developers are ready to use PICTURE and are just waiting for a browser to implement it and validate its use.

  132. Regarding the two proposed variants I go with the picture element, too. Definitely easier to read and remember. I like also like the meta-idea by Denis Leblanc.

    The advantage of the picture over the meta-idea is that you can handle this for each image individually. Downside is extra markup in comparison to meta. The meta-idea would be great to apply it to all images on a site, but it’s harder to achieve exceptions to some of the images.

  133. Tom Maslen says:

    +1 for the picture element as it is obvious how to use it.

    I agree it is very verbose, wouldn’t be a problem if a page has a few images on it but it becomes an issue if you have many images on the page.

    If 20 images have the same media query rules using regular-expression-able file names, then it should be shortcutable to an element higher up in the doc or describable in JavaScript.

    I see this tag as a way of defining the first image that is loaded into the page. On orientation change / window resize it would be nice to state whether you want a different image to appear or not. So maybe an attribute like live=true/false?

    Picture isn’t the best tag name either, someone suggested object which I think I prefer.

  134. David Hund says:

    I am surprised (and a little worried) that the (majority of the) WHATWG was not aware of the discussions in this Community group… I hope they’ll take a good look at what has been discussed in this community group and not disregard all the thinking and effort that has been done on this topic.

    As for the proposed `@set` attribute: I agree with most dev’s here and strongly favour the proposed `picture` element for most of the reasons given in previous comments. The `picture` element follows a familiar (video/audio) pattern for alternative sources, solves many (though not all) of the problems and (very important) is simple enough to learn (as opposed to `@set`).

    However, I also think that Denis Leblanc’s idea re: ‘meta variables with Media Queries’ looks very promising.

  135. Thomas says:

    I prefer the pictire-syntax, but the set attribute has a few important benefits over media queries:
    * the given widths and heights are tested against the available width for the img, not the viewport-size as media queries do
    * with the set attribute, the browser can choose which version to use, media-queries are strict rules, so the last matching source will be used, even if this is not the best choice, as the “power” of the media queries totally depend on the skills and foresight of the developer (and could fail if he ignores bandwidth or whatever…)

    • Thomas says:

      …I think the a the best solution is a combination of both techniques, using the picture element with an img-fallback and multiple source elements, but instead of defining “strict rules” with media queries, we should provide some information of the used images and let the browser decide, which is the best to use (considering current connection speed, available width of the column containing the image, display resolution and so on:

      eg:
      (picture alt=”alt”)
      (source src=”lores.jpg” width=”400″ height=”200″ filesize=”234kb”)
      (source src=”medres.jpg” width=”600″ height=”300″ filesize=”540kb”)
      (source src=”hires.jpg” width=”800″ height=”400″ filesize=”1.23mb”)
      (img src=”fallback.jpg” width=”400″ height=”200″ alt=”alt”)
      (/picture)

      when the column containing the picture is only 150px width, the browser can choose the lores version, regardles of the viewport width, if the column is wider and the device has a retina display, or the user has zoomed in the website, the browser can choose the source depending of the connection speed (or allow the user to always use the lowest or highest version with a browser setting)

      this is more user friendly, more powerful and easier than media queries (considering screensize, retina display and bandwidth, media queries will become very complex)

  136. The is my preferred solution. It’s syntax parallels that of the and tags. For folks new to HTML, this normalizes the syntax of the media tags; for folks new to HTML5, this will normalize the syntax of the media tags.

    As so many folks have mentioned, templating the tag will be more straightforward than the set attribute which will require parsing space-delimited strings to add and remove formats.

  137. Not that there is anything new to be added to the discussion at this point.. but hey it’s the Internet and it’s built on opinions… and funny cat photos.

    My thoughts… the picture source model blows away the img set one. The syntax for img set while more condensed isn’t nearly as clear to skim and understand compared to picture source. If all of that contextual information is needed then it should at least be quick and easy to interpret.

    I’m sure there are some attribute naming conventions that could be mulled over a little, but overall structure of the picture source model is definitely the most intuitive based on existing conventions of video and audio.

  138. Kevin Suttle says:

    As developers, I think we’re used to starting our solutions to problems with a more complicated approach than is necessary (no offense intended). Looking at Jeremy Keith’s Conditional CSS post it just seems focused on solving the wrong problem.

    If you think about it, how are multiple images and multiple styles that much different from making enitre other sites? Thinking a bit holistically, is it really that much worse to serve high-to-medium res graphics than to assume the user’s browsing context and create/serve multiple versions of graphics/sites? Why are we not looking at better image formats seriously or standardizing higher compression settings?

    The more I think about this, the more I think that this isn’t our problem to solve. It’s really a browser and server problem. Let’s take a look at current media implementations.

    Looking at the current video tag solutions, look at all the markup required, which we’re now trying to mimic for images. The only reason that much markup is required is because of codecs, not resolution. To further make my point, look at YouTube. Using this video as an example, notice how many quality settings there are. The user can choose one, and even set a default in their account settings, even though, only one video file is uploaded. However, does a non-tech savvy user know the difference between 240p and 360p? Imagine not working on the web and reading this “help” post. Vimeo has a more elegant model, in my opinion, having one HD toggle setting, usually defaulting to ‘off’, something a user can easily grasp and decide on. None of this really requires much from the developer, especially not uploading and specifying multiple files to serve. Remember back in the day when we had to provide tons of compression options for users to choose on their own based on bandwidth? Let’s not do that again. The user shouldn’t have to make that many decisions. Hick’s law and all that.

    Audio is a mess as well, as far as codecs go, but for some reason, you rarely see compression or quality options when it’s being delivered to users.

    I don’t think bandwidth APIs solve anything, either. Think about the last time you tried to use your laptop at a hotel. Does poor bandwidth automatically mean it’s a mobile device? Not at all.

    I just am leaning less and less towards the idea that this is a front-end developer’s problem. I mean, why are we focusing specifically on images? What’s the reasoning behind that? It just seems like we’re focusing on this micro-problem when we should be looking at the big picture.

    Indeed, these are very difficult problems to solve with this many moving parts, but I think looking at the landscape as a whole and trying to be a bit more pragmatic rather than trying to fix problems we really shouldn’t have to will be better time spent.

    Update: this presentation by Yiibu hits the nail on the head. Feature detection at the server-level is our most reliable solution. It’s not hard science, and it’s not straight-forward, but we shouldn’t use that as an excuse to ignore the server.

  139. Pingback: Use Your ‘Head’ For a Better Way to Serve Images - Gadsit Buzz.com

  140. Having not read all of the comments here (there’s just too many of them). Here are my thoughts:

    The picture tag is way more intuitive than set. This goes without saying I think.

    That being said, the main problem with the picture tag is the sheer length of it. Each image on the page will take up a good few lines of code and that just seems like overkill to me. Could we not make these changes in the CSS spec instead of HTML?

    Also the name ‘picture’ is too simplistic I think, but that’s a minor issue really.

    Other than that – plenty of far more knowledgable people than me have given their opinions above…

    • Scott Jehl says:

      A couple of thoughts on this:

      – PICTURE is not a replacement for IMG, but rather an alternative for specific situations; it would not necessarily need to be used for every – or even more than one – IMG in a document. Many images smaller than a certain dimension may be fine to deliver as one size via a regular img element to all resolutions; the largest filesize is sometimes already small-screen-friendly. It could be used for anything, but I think PICTURE is more useful for images that have dramatically different sizes depending on the screen size on which they’re viewed.

      – I see a lot of suggestions that PICTURE img sources should be specified via CSS, but I think the layout breakpoints in CSS are often a separate, more fine-grained concern, and not the domain of content images. Content image sizes don’t necessarily need to correspond to design breakpoints, especially in a fluid layout with fluid images. Content image sources might be appropriately divided up based on reasonable jumps in filesize rather than tying them to anything layout-related. At least, that’s how things played out in past use cases for projects I’d worked on.

  141. Not bad.
    But I think image’s quality may be selected with JavaScript or something.
    HTML should defines the type only.

    If element does not exist in the element, alt attribute of element is should be written.

    Now, you may use element as above.

    • Excuse me. This is rewriting with tag samples.

      Not bad.
      But I think image’s quality may be selected with JavaScript or something.
      HTML should defines the type only.

      [picture width="800" height="600"]

      [img src="fallback.jpg" alt=""]
      [/picture]

      If [img] element does not exist in the [picture] element, alt attribute of [picture] element is should be written.

      Now, you may use [object] element as above.

      • OMG. How can I write as I think?

        picture width=”800″ height=”600″
        source type=”image/webp” src=”picture.webp”
        source type=”image/svg” src=”picture.svg”
        source type=”image/png” src=”picture.png”
        img src=”fallback.jpg” alt=””
        /picture

  142. Pingback: Proposed responsive images syntax | Michael Gunner

  143. Kornel Lesinski says:

    The problem with use of media is that it defines when to use the image rather than what is available for UA to use.

    This puts all responsibility on the developer, and does not allow UA to excel and innovate without making mess of MQ.

    For example the code in proposal did not include “print” media query. Does it mean that images have to be printed in low resolution?

    Declaring what is available allows UAs to automatically print in best resolution, to download image for appropriate zoom level, to have setting to always use low-res (save bandwidth), etc.

    • Dave Joyce says:

      That’s my impression too. One solution puts the responsibility on the browser makers. The other solution puts the responsibility on the developer.

      The picture tag needs a solution that is low in specificity where the browser makers can make the big decisions, but that still allows advanced specifications for more advanced use cases.

      We need the best of both worlds.

  144. I definitely come down on the side of picture element. Everyone’s already said it, but I’ll restate: continuing the pattern of other multiple source elements (video, audio), JavaScript and CSS interaction will be easy, and more extensible for future situations that we haven’t thought of yet.

    As for name, I know there must be a reason that no one’s suggested opting up the image tag to source tags, so if we can’t do that picture sounds fine.

    Come on, picture ftw.

  145. Pingback: Responsive Web Design: Responsive Images: Is this the problem we should be solving? - Quora

  146. Marc Brooks says:

    If only there was a standard way that the browser could communicate what it would like to display (after IT makes decisions based on image display size (resolution, zoom,etc.) and estimated bandwidth, and available memory) and have IT communicate that information in a standard way… I think something as simple as when requesting the image from the ONE canonical URI, it could send along some CSS-selector based request headers. The would then let the server do whatever best-match it would like to offer up… to the level of even being able to shape its OWN bandwidth restrictions.

    This is far more sensible than making a web designer try to handle the near-infinite possible clients.

  147. Marc Brooks says:

    I mentioned this quite a while ago on A List Apart

  148. Xmak says:

    Just one addition…

    The tag supports having a src attribute so that you can specify the video source withou having to add additional subelements. So why not implement this in the tag also, for the sake of simplicity so that we can use it like this also:

  149. Isaac Fischer says:

    All in favor of the “picture” solution, so long as the actual tag is called something else, like . The image in question could be a graph or an illustration. Also, this mechanism should insist on allowing vector to supportive clients, and any emerging formats. MIME type as an attribute in src, perhaps?

  150. Dave Joyce says:

    Aren’t there two philosophies going on here with the two proposals? Why can’t we have both?

    The WHATWG seems to have answered our basic need, which is the ability to set multiple images of varying resolutions. The browser makers can then decide what images in the set best suit the resolution/bandwidth concerns of its users. The iPad 2 browser will behave differently then the iPhone browser.

    The picture pattern adds more control for developers via the media tag, which can be good, but it seems overly semantically complex for something as basic as an image. If I just want to add a higher density image for the iPad2 and nothing more, than the WHATWG seems cleaner and simpler to me. And I’m not even clear how to do this with the picture pattern.

    And then if I want something more complex, such as feeding a high res photo to a desktop and a lower res version to a mobile phone, I can use the picture tag instead.

  151. Adam Hobson says:

    The “picture” tag syntax is certainly more intuitive and follows the example of the “audio” and “video” tags, which is nice. However, my biggest issue is introducing another tag that has the exact same semantic meaning of the “img” tag. Differentiating the use by function rather than meaning seems odd. I understand the difficulties in forcing the “img” tag to use the same syntax as the proposed “picture” tag, so that’s a non-starter.

    So if the “picture” tag syntax is implemented, I feel that the “img” tag should be deprecated at the same time, so the semantic meaning of image remains in only a single tag. For brevity, perhaps it would be possible to allow the “picture” tag to also utilize the current “img” syntax as well. And if the “img” tag is deprecated, lets just call the new tag the “image” tag, rather than “picture” as well. It’s not like the “video” or “audio” tags are abbreviated.

  152. Oscar Otero says:

    Responsiveness always has been in css, not in html. Html defines data structure, not how this data is displayed depending of the device resolution. If an image is displayed at 300x400px, it is independent of what is the original dimmensions of the image (it can be larger and resized using css). So using media queries in both html and css can be confusing and more complicated. But changing the src of an img using css is not a good idea because we are changing the content, not how the content is displayed.

    I think this is a problem that has to be solved in the server side, not in the client side, because this problem affect to the performance and bandwidth, not to content or style. A good idea to solve this problem is using the http protocol. When a browser loads an image, it can send a header with the width and height in which the image will be displayed. For example, if an image is displayed in 100% of the window size, if my window width is 800px the server knows that I need an image of 800px. This method would work also in images loaded by css (background-images, etc).

    A similar method is used to load ajax content, you can know if the request is ajax with the header HTTP_X_REQUESTED_WITH. Why not create a header such HTTP_X_RESOURCE_WIDTH, HTTP_X_RESOURCE_HEIGHT?

  153. It’s about more than just the same image at different sizes / resolutions. The image may require alternate crops and dimensions or be totally different for different sized screens. If I have a photo with text over it I might want the text larger on the mobile version as the screen is much smaller.

    We need the control of pixel density and height / width like picture offers.

    I could have a large screen with a high pixel density and a large screen with a low density. Both of these would want the desktop style site. But a mobile will with high or low density will need the mobile variant of the image. src-set is broken, and as other have mentioned the syntax is awful.

  154. Can each source of a picture set have it’s own ID/ class for styling hooks? That would be very valuable.

    Touch devices have no hover so you want to offer different rules.

  155. Suhi says:

    As much as I dislike having a new tag instead of a tag that has been around from the early days of html, namely img, the simplicity, extensibility and familiarity of picture ( to the video and audio tags ) makes is a clear winner!

  156. Pingback: Responsive Design and Mobile First – Look Before You Leap | J. Boye

  157. Pingback: Responsive Images and Web Standards at the Turning Point | AsterHost

  158. Pingback: Responsive images - SmartSell | SmartSell

  159. Pingback: Адаптивные изображения и веб-стандарты на распутье

  160. Pingback: Responsive images: what's the problem, and how do we fix it? | Vutphala.com

  161. Pingback: 3 Types Of Solutions To Work With Responsive Images | Van SEO Design

  162. (Sorry, the first comment had the two tags in question as actual tags, but they got stripped. Re-posting to clarify)

    For what it’s worth, I’m the co-founder, CEO & Chief Geek at SmugMug, one of the largest photo sharing sites on the net with billions of photos and many tens of millions of visitors every month.

    We’re massively in favor of ‘picture’ over ‘img srcset’. The syntax is easier to use, more flexible, and much more future proof. So much so that I’m surprised there’s a debate.

    Feel free to email, Twitter (@DonMacAskill), etc if we can help in any way.

  163. Pingback: Internet Blog Business » Blog Archive » How a new HTML element will make the Web faster – Ars Technica – web – Google News

  164. Pingback: How a new HTML element will make the Web faster – Ars Technica – web – Google News | internet technology business

  165. Nick says:

    I like neither but I really hate set, it’s a silly solution.

  166. Pingback: Picture 元素的故事 – 陈三

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Before you comment here, note that this forum is moderated and your IP address is sent to Akismet, the plugin we use to mitigate spam comments.