WebKit has implemented srcset
mobile.smashingmagazine.com
mobile.smashingmagazine.com
I can see from here the compatibility and complexity trainwreck we're going to have down the line.
Other than 1x and 2x what are we supposed to expect to use here with this? Is there going to be 4x?
You can see they are basically getting this very vendor-specific hack they already had and calling it a standard. That's heresy.
They've done the same thing with resolution independence on iOS - instead of some sensible system of scaling and caching, we've ended up with a situation where images and icons are saved in several different versions by the developer just to cope with all the different possible resolutions/ratios using this sort of @2x naming scheme, and all based off arbitrary resolutions of screens which are going to change. It's a mess.
I think they'd be better with something like this:
<picture>
<source src="myjpg.jpg" width=100 height=100>
<source src="myjpglrg.jpg" width=1000 height=1000>
<img src="myjpg.jpg" alt="fallback img tag or text">
</picture>
The above proposal already displays perfectly fine in older browsers if you use an img tag within the <picture> tags for backwards compatibility, and could easily be dealt with in older IE with workarounds if necessary, though I think the img tag would display fine.
CSS can then be used to control the intended display size.
Yes, that's true, though generally pixel size does relate quite well to file size for different versions of a given image on the web, and a picture element could just have sources in order of preference of use (regardless of size), so basically quality order - I think that's what the video element does (though for formats, not sizes)? The browser could choose different images depending on quality/bandwidth/resolution concerns, so it wouldn't always have to use the first. If not a quality attribute or something similar would be easy enough to add. I think the basic idea of the audio and video/source elements is fine, and should be extended to images as it could cover lots of use cases - don't really mind about the details as I'm sure they could be worked out.
The best way to get good retina images I've found so far is simply to oversize and compress heavily, which gives surprisingly good results and small files even for large images - I'd love to use something like the new picture element for multiple resolutions so that I could also provide a smaller version for lower bandwidth uses, but frustratingly webkit authors seem to see the picture element as somehow superseded by srcset, even though it doesn't do what a picture element would do, and introduces yet more headaches. I wouldn't consider using srcset for the reasons given above and because I've already experienced this solution in iOS dev, and it was equally broken there.
> From the available options, the user agent then picks the most appropriate image.
So if you are zoomed in, the UA can decide that a higher-res image is the most appropriate one.
[0]: http://www.whatwg.org/specs/web-apps/current-work/multipage/...
On top of that the syntax is awful and appears to have been chosen to make browser vendors' lives slightly easier - I went and had a look at the links you gave to hixie's reasoning, and it's all based on minor difficulties browsers had parsing audio/video, but they've already done that work, why introduce yet another sub format within an attribute?
If I have an image meant to be displayed in a 250x250 area of layout, a 500x500 "retina-ready" image will not fit. The browser must be told that the image is meant to be displayed "@2x" (as Apple puts it). This is what the "2x" is for. The browser is allowed to use any or none of that information in its decision making.
The syntax of srcset="" was chosen to match CSS's image-set syntax. The <audio>/<video> pattern wasn't great for anyone.
[0]: http://www.whatwg.org/specs/web-apps/current-work/multipage/...
No, that's HTML5.
is complexity that simply can't happen with srcset. Similarly one needs to consider the behaviour of preloaders in extant UAs; if existing browsers will start to download all the images that will create a much worse user experience in the short term.
I don't remember what all the considerations were here, but this is a much harder problem than many people give credit for, and certainly isn't a case where a single vendor controlled the whole process.
Is the picture element containing source elements (like video and audio) still under consideration, or is srcset supposed to replace it somehow?
<picture><source media="min-resolution: 2ppx"></picture>
<picture>
<source media="min-resolution: 2dppx" style="image-resolution: 2dppx">
</picture>
> Other than 1x and 2x what are we supposed to expect to use here with this? Is there going to be 4x?
I don't think so (meaning of "1x" gradually changed from 72dpi to 100-130dpi, so I expect "2x" similarly gradually increase) and I proposed that new image embedding methods default to @2x, but that idea hasn't gained support from CSS/HTML WGs.
<audio controls>
<source src="horse.ogg" type="audio/ogg">
<source src="horse.mp3" type="audio/mpeg">
Your browser does not support the audio element.
</audio>> Note that at the moment WebKit only supports the resolution modifiers (e.g. 1x, 2x, 3x).
The official [draft] specification: http://www.w3.org/html/wg/drafts/srcset/w3c-srcset/
The dimensions in the srcset attribute are the maximum (viewport) dimensions that an image is intended for. e.g.:
<img src="pear-mobile.jpeg" srcset="pear-mobile.jpeg 720w, pear-tablet.jpeg 1280w, pear-desktop.jpeg 1x" alt="The pear is juicy.">That would be way saner, the problem is that it seems no one wants wants to touch HTTP. Browser vendors work under the assumption that whatever feature they implement, it only has a chance of being adopted if it can be hacked in other browsers with javascript shims.
It should be up to the browser and the image file format to determine the best option.
Both Jasper support this (ilyrrates) and OpenJpeg (-r and -q) support this functionality.
<picture>
<source srcset="foo.jp2 100w 100h range=1-<first layer>">
<source srcset="foo.jp2 500w 500h range=1-<middle>">
<source srcset="foo.jp2 1000w 1000h">
</picture>
That's largely opinion: are byte ranges really better than having to maintain clusters of related images? Any serious site already has to deal with things like cache invalidation when a source file changes and by the scale of things which sites do for performance this is certainly no worse than, say, JavaScript/CSS minification or UA sniffing.
It would be way more flexible and even easier to implement, since you don't have to revisit all your markup.
Yes, unfortunately we have to rely on a small client side javascript to detect your client's properties but the solution allows you to both upload and reference one and the same image and URL regardless of client and we'll scale, re-sample and even crop on the fly and cache the formatted image for future requests. We are trying to provide an experience as seamless as HTTP content negotiation.
Also, this solution can be built into a Javascript shim for older browsers, something header-based would be much harder to do as a shim.
Why? There's no difference on the server side, you would have multiple versions of the same file anyway. You're just exchanging the responsibility of getting the right file from the markup to responding with the right file on the server (which is way easier to keep consistent, IMO).
In an ideal world, it would be server side. But it would easily mean twice as much work to get there.
I'm not sure I agree with this, in that I'm not sure there is such a thing as a "content image." Images on the web are presentational, full stop.
--well, okay, that's a bold statement. Let me put it another way: the "alt" attribute of the <img> tag is not only badly-named, it really shouldn't be an attribute at all. Ideally, this is what <img> tags should look like:
<img src="foo.jpg">bar</img>
Seen in that light, picking one visual representation out of several is exactly the job of CSS. (Though CSS is admittedly lousy for local rules right now. This would pretty much be the perfect use-case for scoped stylesheets!)
<object data="https://news.ycombinator.com/y18.gif">No image</object><img src="vacation.jpg">me standing in front of the Pisa Tower leaning towards one side with my hands like I'm keeping it from falling with a crowd of people around me doing the exact same thing</img>
?
Your case is a picture is not content. It's exactly what it is in many contexts (photography, illustration, charts). When a picture is only website decoration, then you're right.
Illustrations and charts are frequently cases of "I just explained this in prose or as tabular data; now I'll give you an alternate visual representation of the same idea as well, to enhance your understanding". A chart would work perfectly well like this:
<img src="chart.png">
<table>
...
</table>
</img>
<img src="sort_fn.png">
<code>
... pseudocode for sort ...
</code>
</img>
Here's how I think of it--you should compose every page presuming the user is blind (and deaf, etc.) first--make your page work perfectly well standing alone like that--and then perform the same process of gradual enhancement that is recommended for javascript features, when you detect that the user can deal with image/audio/video/etc. content.
In my opinion, the only work the designer should have to do it to declare a particular image should be displayed. It should be the client<->server's responsibility to do its best in fulfilling that intent for each and every visitor.
To me, this is clearly a content negotiation issue and should not be solved in the form of verbose markup. Just because as designers we CAN always add markup, doesn't mean we should...not to mention the additional work of preparing multiple versions of the same image.
> In our opinion not ideal, this markup pattern.
> Not too scary, this markup.
Though, the examples atop the Topicalization article still have all the words necessary for a more traditional grammar, just out of order. As highlighted in this article, the author has also dropped the implied "is".
I find this more common in spoken language, used by the speaker to inject a bit of variety and emphasis. I didn't realize it was a US-northeasternism, but I'm also not surprised to find in writing that's attempting an informal, spoken-word-like tone. It tends to set the observation off to the side, as if delivered in a different voice (stepping aside from the podium for a moment), or (as in some textbooks) like a comment printed in the side margin.
To answer the GP's question, it seems acceptable to me in an informal 'chatty' context, but you probably wouldn't find it in an academic/historical/neutral-journalistic composition. (I didn't read it as a specific attempt to invoke Yoda-style-speech.)
I find this one acceptable.
> In our opinion not ideal, this markup pattern.
This is very clumsy, perhaps even ungrammatical. The addition of "in our opinion" ruins it.
However, please note that I am not a native anglophone.
(I mean the British one, not Massachusetts.)
The new solution seem to be geared towards people running retina displays, without doing anything about progressive quality for people with low bandwidth.
http://blog.patrickmeenan.com/2013/06/progressive-jpegs-ftw....
It was fun.
The solution is to decouple images from URLs and to provide some client-side mechanism to resolve them based on an ID or name of sorts.
Instead of using static URIs, we should be providing resource names and allowing clients to resolve them based on their needs.
Instead of <img src="rock.png" />, we should be doing something more like <img name="rock" /> and allowing clients to decide how to resolve that. It may be a URI string, a data URI, a Blob, a canvas, etc.
The problem isn't low-res or hi-res. It's about how to serve particular images. There are a multitude of factors involved, and a multitude of ways to satisfy an image request.
It's not just about DPI, it's about bandwidth, request count, spritesheets, network conditions, and responsive HTML templates.
srcset is an ugly hack. A tiny DSL within an attribute value that only attempts to address DPI.
Everything else in HTML is more-or-less responsive - why aren't images?
http://www.yoav.ws/2012/05/Responsive-image-format
Yup I'm not the only person to come-up with this. I think heuristically guessing how much to request from the content-length with two range requests would work just fine.
if browser is modern and high-res,
replace the value of src.
else
pass
I find this an increasingly weak argument as it's applying to <10% of the market and falling fairly rapidly ahead of the 2014 Windows XP end of life and is true of everything else in the HTML5 spec.
> Then after the DOM is loaded, you have to re-write the DOM to replace the <picture> tags with <img>.
This is a reasonable complaint - I'm not sure I'd consider it a big deal since the work of manipulating the DOM is a lot faster than doing anything like downloading an image or rendering it but for anyone trying to do a wall of images it'd be worth benchmarking at the very least.
<picture>
<noscript><img src="old-browser.jpg"></noscript>
</picture>
I'd prefer an extra tag during the migration stage to make the long-term goal more readable, particularly if we start wanting to extend it to do things like offer different image formats rather than just resolutions.
[0]: http://lists.w3.org/Archives/Public/public-whatwg-archive/20...
[1]: http://html5doctor.com/interview-with-ian-hickson-html-edito...
<source srcset="med.jpg 1x, med-hd.jpg 2x" media="(min-width: 40em)" />
Including srcset in the picture element just makes things worse, not better, it's a confusion of a very good idea (allowing pictures to have multiple optional sources specified in the markup), and doesn't add any useful information, just gives hints as to rendering intent.
Here's how the concerns break down, from my point of view:
The HTML should provide a list of images to be displayed, in different formats and resolutions. It should not care about the device it is being rendered on, but it should provide as much info as possible on the source elements.
The CSS should specify the intent of the designer as to size and style (possibly suggesting different display sizes for different devices).
The User Agent (and thus the user) should be deciding which images to load and display based on the zoom level, the screen resolution, network, user preferences, and the image sizes available (as specified in html), designer intents, and future requirements we can't anticipate now. HTML works best when the markup doesn't try to second guess how it will be displayed and leaves that to UA.
srcset is a solution to a problem we didn't have, which will introduce all sorts of other problems in future (what is 2x resolution? how do we introduce new image formats?), and tries to stuff rendering intent into HTML where it doesn't belong. We'd be much better off looking at the picture element and improving it to include information on the actual image sizes (already possible), and letting the User Agent decide how to load and use those images.
Just as one example of unanticipated usage, a gallery plugin might read the source images available in some picture elements, and automatically construct a gallery from the thumbnails and hires images for each image. That's not possible with srcset and 1x 2x etc, but it is if picture elements have multiple sources at different specified sizes. e.g.:
<picture>
<source src="myjpg.jpg" width=100 height=100>
<source src="myjpglrg.jpg" width=1000 height=1000>
<img src="myjpg.jpg" alt="fallback img tag or text">
</picture>
<img src="picture.jpg" srcset="picture@2x.jpg 2x" />
I understand the appeal of <picture>, but the browser cannot choose the correct image until the DOM is parsed, the CSSOM is ready, and the page has been layed out. That all happens much later, which means the page will load slower.
I like the idea of <picture> but srcset is ideal if the only features you want are pre-loading and high-res support.
The reason webkit implemented srcset is because of the performance it allows.
I wonder what HTML would look like if browser performance was the primary concern? Is this truly the best argument for srcset, that browsers can parse the page quicker?
Probably the fastest HTML to render would be something like this:
<img src="foo" border="2px solid red" margin="10px" width="100px" height="100px" align="left">
It reminds me of the horrible multiple resolution handling on iOS, which is probably what inspired it (@2x etc). I think there are now 15 different icon sizes for iOS [1] because of this insistence on tying resolutions to device specs. I can imagine issues with devices lying about resolution or ending up between x1 and x2 and not getting bigger images just because their resolution isn't quite x2 etc.
[1] http://mrgan.tumblr.com/post/708404794/ios-app-icon-sizes
I see the concern on loading - if CSS determines the resolution of images, that would have to be parsed before deciding which image option to fetch, but that could be addressed by letting the browser decide which images are appropriate, and if necessary changing them if the CSS overrides that later. However I think the browser has far more pertinent info than the CSS writer (as long as it knows what size images actually are, not the intended device resolution in 2013!) about network, device, images, performance, user prefs etc. - the browser should decide what size of image is appropriate, and should be given the info to do that, and speed of loading should not be the primary concern in designing a document format - that should be a worry for browser makers, not for readers or writers of HTML.
The most convincing argument on the article page for me was a short comment pointing out the problem with srcset that it is tied to our expectations today of device specs:
If LG releases its Quad HD(?) smartphone screen it still means changing the html if you want to support it. - Niels Matthijs
Anyway, rant over, apologies for the long posts, I'll get back to work now, and thank you for taking the time to explain.
> Do you have a mailing list discussion you can link to on this, that might be illuminating?
A better explanation is that it is compatible with the preloader without doing anything complicated. See here: http://trac.webkit.org/changeset/153733
The example you gave confuses rendering performance with the ability to download assets in parallel / pre-load assets. Browsers can request images long before the CSS has even arrived. How does a browser know which image to preload when given multiple options?
Specifying multiple images in a way that in compatible with preloading, is more akin to concatenating javascript/css, putting css at the top, etc. It makes a big difference because it let's you cut the time-to-glass by an entire network round trip.
In the same way that the browser can choose to load higher res images based on resolution or breakpoint hints (srcset), it could choose to load higher res from a list of images without x2 etc but with image resolutions (picture with sizes). I would argue the browser choice should be based on far more than the HTML writer's ideas about device/display resolution at the time of creation.
To let the browser choose, the HTML could specify either original image sizes or some kind of desired resolution threshold for each image (srcset), but HTML should not know about the specific devices it is rendered on or include hints for rendering, I think that's an important distinction which is worth preserving. Not out of some desire for purity, but because separation of concerns stops bleed of concerns from one domain to the other and horrible messes later as the two domains become inextricably bound together.
I do think this is a terrible direction go in for that reason, it worries me that browser performance is used as the justification, and it would appear many agree with me, but we'll see by how much usage this gets I guess, I know I wouldn't use it because of the concerns above.
Concentrating on device resolution ignores many of the other bits of information a browser has when deciding which images to load. What happens when the device pixel ration is < 2, but the device is zoomed on the web page? What about slow connections on retina devices, or users who prefer to load things faster by getting lores images (something specifically called out in the spec)? Or some new browser which gets incredible first page render speeds by loading thumbnails of all images, and only loading hires images for those displayed? Or scripts which want to enumerate images and choose a certain resolution, independent of the intended display size?
This proposal is just making life easier for browser makers who want to cater for 2 resolutions in a hurry (ipad Retina, iPad), not for the people reading pages or creating them, and it puts the decision as to which image to render in the wrong place anyway IMHO. That should be a browser decision, based on data in the HTML.
My solution was to use CSS media queries to selectively load different images. Using media queries this way felt like a kludge, and I knew there must be a better way. The new srcset attribute is definitely a step in the right direction.
Assuming Rails and other frameworks will add support for this I can see that at build time, or page generation time, our web frameworks will look for '@2x' version of images and automatically populate the srcset tag.