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:
- Join the WHATWG mailing list, and help keep
pictureat the forefront of the discussion. - Join the #WHATWG channel on IRC, since apparently this is where the WHATWG leads’ attention is focused.
- Talk to the WHATWG on Twitter.
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.
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.
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.
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.
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.
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.
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.
I agree that the
picturetag is much better than theimg setattribute, 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
imgtag, when there was discussion about an alternateicontag. Do we want to be stuck with an awkwardly-named tag for such a heavily used element?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.
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.
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!
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.
The
pictureelement 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
setattribute 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.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.
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.
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.
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.
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?
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.
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.
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.
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?
I have nothing to add that hasn’t already been stated, but would add my voice to support the picture element.
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.
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
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.
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.
The picture element is based on the video element – which does exactly what you want already.
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.
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).
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.
Ugh, the
andtags got sucked up by markdown.+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?
Reading up on all the efforts being made towards responsive images thus far, I have to side with the
pictureelement 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 theimgelement andsetattribute, so I’ll just say that I agree with them.+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?
I feel like `picture` is easier to comprehend. Couldn’t additional bandwidth-related attributes be added to the source tags?
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.
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.
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!
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).
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.
The
pictureis the clear winner in my books.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.
I think this should not be a part of HTML at all. Let CSS or JavaScript handle these things.
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.
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*/ }
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.
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
I also feel like
setis a little too unintuitive.picturemakes 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. Therespondelement may or may not be the correct solution, but it definitely goes farther than other proposed solutions.element for sure.Whoops. Guess I formatted my comment incorrectly. Meant to say *picture* element for sure.
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
Could not agree more. There should by only one element for one picture.
Huge fan of the
pictureelement. 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 ofaudioandvideo.The
setattribute isn’t obvious to me. It doesn’t make a lot of sense. You’re also going to end up with a very largesetattribute which is going to be much harder to read than a list ofsourceelements.I’m not a huge fan of how verbose the
syntax is, but thesrc setsyntax takes terseness to an extreme! I’d much rather work withany day than deal with the confusing alternative.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.
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.
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.
I’d vote for the element. The syntax corresponds well to the existing and syntax, and avoids legacy issues with the tag.
I can’t believe that this is even a question. The “set” attribute is so obviously atrocious. +1 for the version.
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!
Definitely the
semantic, as it is more clear, more structured and less hassle than theimgvarietyWhoops, I meant: the
<picture>semanticComment system stripped the angle brackets… I meant +1 for the picture version.
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.
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?
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.
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.
I think the picture is the clear winner. Already more clear to read/write, and more extendable down the road.
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.
+1 for
– obvious advantages is that it has the same syntax asand is easy to read (intuitive).Obviously that should have said:
+1 for
picture– obvious advantages are that is has the same syntax asvideoand is easy to read (intuitive).@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.
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.
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.
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.Ah, that should be support for “picture.” Formatted the comment poorly, sorry.
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.
* correction: At least the picture element follows a logical DOM pattern.
Did we solve this in 1992 with LOWSRC on the img tag?
No. It was intended for a very different job and was never implemented.
@Paul
I feel like `picture` is easier to comprehend. Couldn’t additional bandwidth-related attributes be added to the source tags?
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?
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.
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!
The two proposals solve different problems. The
imgsetis for bandwidth/dpi, andpictureis 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.
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.
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
+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.
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.Rather, the
<picture>tag.Argh!
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.
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.
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.
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.
You all have done a great job summarizing why
pictureis favorable over asetattribute. As far aspicturegoes, though, I do side with Matt on the complexity/verbosity issue.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.
Aye for “picture” http://dl.dropbox.com/u/32750720/YES2.jpg
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.
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:
Looks like the code tag got filtered out.
Here it is:
Damn. Minus the open and close tags
<img src=”mobile.jpg” set=”large.jpg min-width=600px, large-high-res.jpg min-width: 600px and min-device-pixel-ratio: 1.5″ alt=””>
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.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.
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."
What the heck. screw it. I LIKE the picture element and dislike the additions to the img element and HATE this WordPress form.
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
I vote for the
pictureelement. It’s a lot easier to understand, seems more extensible, and provides nice hooks for javascript and css interaction.Go for the element!!!
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.
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.
The
pictureelement is my choice. It’s easily readable and compliments the ideas behind thevideoelement.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.
Why not extend ?
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.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).
Why not <object>?
I think we can agree that the
setattribute 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 ifpictureis the right term that describes this approach best, but I definitely support the markup structure.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?
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.
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!
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.
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.
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.
I’m a fan of the
pictureelement 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
videoandaudioin 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 setproposal 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.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 .
Another vote for
picture. Agree with many of the points already noted — about piggybacking on an existing convention (video), using familiar syntax.picturejust 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
pictureknowing 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.I’d gladly use element. We already know how to use it.
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.
I see I made some slight errors in my examples, but I think you get the idea.
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.
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.
+1 for the picture element!
That looks much better than the img set code because it’s just like the video & audio element.
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.
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.
I prefer the
pictureelement to animgwith asetattribute. I agree thatpictureis a bit on the verbose side, but I’m fine with multiplesrcattributes. 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
pictureelement is the media queries. I know we can already do this withlinkelements, 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
pictureelement.The
imgsetsyntax is not intuitive likepicture, 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.
pictureis 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
pictureas a name candidate, but it’s probably not worth confusing image/img.Picture element all the way
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.
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.
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.
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>
I don’t like
elementbecause it creates a new element to do the same of an existing element. Why don’t use theimgin the same way than theelementproposed ? 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
imgwithout reinventing the wheel with another element. The old browsers understand it without using javascript or other hacks.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.
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.
No,
</img>is out of the question, sorry (vetoed by browser vendors for very good reasons).It’s impossible to change it in a sane backwards-compatible manner.
Ok, I understand 🙂
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
This is a really nice idea, like a much more compact version of http://mattwilcox.net/archive/entry/id/1082/ I dig it!
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="" />
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.
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.
just been discussing this, and i must admit this one seems to be the best idea i have seen so far, +1 from me.
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.
…at least it’s not
.nonetheless, I’m definitely siding with the
element. The reasons have been stated above.[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.Picture element. Please. So clearly superior to the mind-bending “set” syntax.
picture is not perfect, but it is the better choice now. Choose it and let’s make it better.
I really, really dislike the
<picture>tag. It’s gross and way too verbose and is solving the wrong problems. I much prefer thesetattribute. I wrote up my concerns:http://oscargodson.com/posts/picturefill-needs-to-die.html
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/
Just like many smart people on here have already suggested, I would love to definitely stick with
pictureelement as it makes the most sense. It uses already similar approach as when dealing withvideooraudioelements. It’s syntax is cleaner and I find it easier to remember that he one proposed by WHATWG, or Ed O’Connor.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).
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.
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!
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).
Agreed, Denis Leblanc’s idea might be the best thing from this whole post.
Pingback: An alternative proposition to and srcset, with wider scope | Responsive Images Community Group
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.
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.
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.
*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, […]
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.
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.
+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.
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.
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…)
…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)
The
is my preferred solution. It’s syntax parallels that of theandtags. 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 thesetattribute which will require parsing space-delimited strings to add and remove formats.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.
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.
Yep. Completely agree, and in addition to that, see my reply a couple of posts earlier.
+1 on this as well.
Also adding my agreement with this.
Pingback: Use Your ‘Head’ For a Better Way to Serve Images - Gadsit Buzz.com
Having not read all of the comments here (there’s just too many of them). Here are my thoughts:
The
picturetag is way more intuitive thanset. This goes without saying I think.That being said, the main problem with the
picturetag 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…
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.
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″]
[source type=”image/webp” src=”image.webp”][/source]
[source type=”image/png” src=”image.png”][/source]
[source type=”image/jpg” src=”image.jpg”][/source]
[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
Pingback: Proposed responsive images syntax | Michael Gunner
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.
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.
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.
Pingback: Responsive Web Design: Responsive Images: Is this the problem we should be solving? - Quora
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.
I mentioned this quite a while ago on A List Apart
I mentioned this quite a while ago on A List Apart
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:
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?
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.
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.
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?
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.
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.
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 ofpicture( to thevideoandaudiotags ) makes is a clear winner!Pingback: Responsive Design and Mobile First – Look Before You Leap | J. Boye
Pingback: Responsive Images and Web Standards at the Turning Point | AsterHost
Pingback: Responsive images - SmartSell | SmartSell
Pingback: Адаптивные изображения и веб-стандарты на распутье
Pingback: Responsive images: what's the problem, and how do we fix it? | Vutphala.com
Pingback: 3 Types Of Solutions To Work With Responsive Images | Van SEO Design
(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.
Pingback: Internet Blog Business » Blog Archive » How a new HTML element will make the Web faster – Ars Technica – web – Google News
Pingback: How a new HTML element will make the Web faster – Ars Technica – web – Google News | internet technology business
I like neither but I really hate set, it’s a silly solution.
Pingback: Picture 元素的故事 – 陈三