9 ms·

WebKit has implemented srcset

138 points by nvk 13y ago

untilHellbanned 13y ago
glad this is happening
joebolte 13y ago
Is srcset really the clearest name they could come up with?
- shousper 13y ago
  Apparently? I'm also not a fan of the value format, let alone the attribute name. Beggers can't be choosers though. Glad we're getting somewhere.
- kalleboo 13y ago
  What bothers me isn't the name, but how the syntax looks like nothing else in HTML. At the time the idea was floated, there were a few alternatives talked about that mimicked the <video> and <audio> tags that made way more sense, and opened up for adding webp alternatives with png/jpeg fallbacks etc. It's a real shame they NIH'ed those.
  - acdha 13y ago
    That part in the article felt strained: Mat was clearly trying extremely hard not to be rude while showing how much cleaner <picture> is. Hopefully this is an opening salvo rather than the end of the discussion…
    - jcampbell1 13y ago
      The problem with picture is that it doesn't poly fill nicely. You can add srcset attributes and it will still work on IE6. I have been using srcset for over a year, and there is is only a minor issue of retina MBPs double downloading. There is no problem with high res tablets.
      - kalleboo 13y ago
        I don't remember any issues polyfilling video, does anything make picture different? This is one of those things one person has to write once and then everyone can reuse it.
        jcampbell1 13y ago
        A polyfill of <picture> much more expensive. First you have to shiv IE to accept it as a DOM node. Then after the DOM is loaded, you have to re-write the DOM to replace the <picture> tags with <img>. Polyfilling "srcset" is trivial as in: if browser is modern and high-res, replace the value of src. else pass Doing a flash video polyfill of a video tag is okay because there is probably only one video on the page. Polyfilling <picture> would produce some seriously janky page rendering, and would be a pain in the ass to maintain.
        acdha 13y ago
        > First you have to shiv IE to accept it as a DOM node 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.
        kalleboo 13y ago
        In the proposal I saw, browsers that supported <picture> would ignore <img> tags inside a <picture>, meaning for anyone who isn't strict about pure semantic HTML, they could just stick an img in there for older browsers.
      - acdha 13y ago
        Polyfilling is an issue, although a manageable one if you're willing to use noscript: <picture> <noscript><img src="old-browser.jpg"></noscript> </picture> (<noscript> should keep browsers from loading the image tag, so you could do things like have JavaScript evaluate your image candidates and generate an img accordingly) 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.
  - chrisoverzero 13y ago
    Experience with the <video> and <audio> tags has shown that their pattern isn't a great pattern to continue using. [0]: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0247.html http://lists.w3.org/Archives/Public/public-whatwg-archive/20... [1]: http://html5doctor.com/interview-with-ian-hickson-html-editor/ http://html5doctor.com/interview-with-ian-hickson-html-edito...
- josho 13y ago
  "There are only two hard things in Computer Science: cache invalidation and naming things." — Phil Karlton http://martinfowler.com/bliki/TwoHardThings.html http://martinfowler.com/bliki/TwoHardThings.html
  - recursive 13y ago
    And off by one errors.
- othermaciej 13y ago
  It matches the CSS equivalent feature, image-set().
malkia 13y ago
Wait.. I thought it was some kind of set of sources of something (actual source code?). Granted, I'm not that versed in html/javascript, so I guess I'm missing the lingo.
- jevinskie 13y ago
  The original attribute for a single image file is 'src'. srcset allows the browser to intelligently select an image (src) from a set of available images.
mzs 13y ago
I wonder... http://www.yoav.ws/2012/05/Responsive-image-format 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.
- othermaciej 13y ago
  When it comes to page load speed, extra network round trips are really bad. Even if you're loading the same total amount of data.
  - mzs 13y ago
    But it can keep the port open so a few round trips are saved, it might be fast enough to make the second request while the first was still coming in so effectively very little overhead, even on (especially on) high latency links where it matters most. It can start drawing even from the first range request, and the idea is to never pull down the entire file (for big files, the case you are optimizing anyway, small ones you don't really need to) and only maybe end-up pulling in the entire hires file with a third request if say the user zooms way in.
josho 13y ago
After adding hidpi support to a small web app I am grateful that we are seeing progress in this area. 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.
- kclay 13y ago
  I had to do the same thing recently and ended up using "Interchange" from the foundation framework. I did have to hack away at the full background slider (supersized) to support this but it worked out nicely. The thing with media queries is that a browser window at 1400 doesn't fit the min-width:1400, in my case I had to use something like 1375 or some odd size. Maybe its some quirk with how matchMedia works ( what the interchange lib uses) who knows, I'll be glad when we don't have to go through these hoops.
subpixel 13y ago
This was posted to HN today, and seems to me a very interesting approach: https://github.com/square/apropos https://github.com/square/apropos
possibilistic 13y ago
I've never commented on an author's English before, but why does this person write somewhat like Yoda? > In our opinion not ideal, this markup pattern. > Not too scary, this markup. Is this an acceptable form of English grammar that I'm unfamiliar with? (I'm a native speaker, and this is an honest question.) Is he just trying to be playful with words?
- maw 13y ago
  It's a Commonwealthism. (I mean the British one, not Massachusetts.)
  - vosper 13y ago
    I'm from New Zealand, and I've lived in London for a while too - I've rarely heard anyone speak this way, and certainly it wouldn't be considered correct to write like that.
- nilliams 13y ago
  Yep I think he literally wrote those 2 sentences in a Yoda-style, intentionally, for playful effect. Rest of article is well written, with above average attention to sentence structure.
- itsameta4 13y ago
  It's called topicalization, and it's more common in some dialects of English than others. It's especially common in urban areas of the US Northeast. I'm from Long Island, and I didn't even notice he'd done it. http://en.wikipedia.org/wiki/Topicalization http://en.wikipedia.org/wiki/Topicalization
  - gojomo 13y ago
    Interesting concept - I didn't know the word for this! 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.)
prodigal_erik 13y ago
I wish they had extended content negotiation to let the browser request an image near an ideal size in pixels using some kind of Accept header. Adding cruft like "med-hd" to the URL path is a design smell, and so is being able to suggest it from HTML but not HTTP.
- hcarvalhoalves 13y ago
  > using some kind of Accept header. 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.
  - bsimpson 13y ago
    The stupid part about that logic re:images is that you get graceful degradation for free in systems that don't implement the additional Accept header.
    - lukeschlather 13y ago
      It's not stupid. From an academic perspective, sure it works either way. From a business perspective, you have to support the full feature set on a given set of browsers, and you're not going to waste time on a solution that only covers 80% of your required browsers when you can write one codebase that covers all of your browsers.
- 1qaz2wsx3edc 13y ago
  Or have a progressive image format. Wherein the smallest/lowest quality image is at the front of the file and is enhanced by loading more data of the same file. It should be up to the browser and the image file format to determine the best option.
  - adamzochowski 13y ago
    JPEG2000 had awesome option of having progressive quality. During compression user could specify number of quality years, with each layer having specific compression ratios. Browser could download a chunk of JPEG2000 and render it, and depending on bandwidth available the browser would keep downloading and improving image quality. Both Jasper support this (ilyrrates) and OpenJpeg (-r and -q) support this functionality.
hcarvalhoalves 13y ago
They are creating their own little DSL inside a tag attribute? This "1x", "2x" stuff in the markup looks awful. I can see from here the compatibility and complexity trainwreck we're going to have down the line.
- 1qaz2wsx3edc 13y ago
  I disagree. It looks like the future of the web. Have you seen Web Components?
- Kequc 13y ago
  Think I agree. I feel like we would expect to see a resolution is either normal or double in dimensions. But currently with media attributes we are able to set the image property in CSS by itself and it gives us much more control. Particularly useful in instances where our images aren't exactly normal or double in dimensions but are resized. Other than 1x and 2x what are we supposed to expect to use here with this? Is there going to be 4x?
  - pornel 13y ago
    Media query syntax has been proposed: <picture><source media="min-resolution: 2ppx"></picture> but mere query doesn't affect intrinsic size of the image, so you'd also need to specify exact dimensions in the markup or something like: <picture> <source media="min-resolution: 2dppx" style="image-resolution: 2dppx"> </picture> which is rather verbose and error-prone compared to srcset. > 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.
    - Kequc 13y ago
      It could assume you are defining image dimensions in the stylesheet the way that normal image tags do. Or it can default to the image scaled down to 2ppx as defined in the media query. Your example looks similar to current audio tags. <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>
recursive 13y ago
The more things change, the more they stay the same. Does anyone else remember lowsrc? Or am I showing my age?
- adamzochowski 13y ago
  lowsrc was awesome. To conserve bandwidth I would often switch to lowsrc. The new solution seem to be geared towards people running retina displays, without doing anything about progressive quality for people with low bandwidth.
  - acdha 13y ago
    Have you started serving progressive JPEG? It's actually surprisingly good for that and supported by just about everything: http://blog.patrickmeenan.com/2013/06/progressive-jpegs-ftw.html http://blog.patrickmeenan.com/2013/06/progressive-jpegs-ftw....
- est 13y ago
  and dynsrc It was fun.
tech-no-logical 13y ago
this is the ugliest use of an attribute value I've ever seen. this needs to follow the way of the dodo, as quickly as possible.
sergiotapia 13y ago
This is terrible and the markup stick out like a sore thumb. The markup definitely needs some tweaking.
derefr 13y ago
> Using CSS to manage content images is broken by default, in terms of keeping our concerns separate. 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> with "bar" (previously the alt text) being the content, and foo.jpg being an alternate representation of the content, for supporting browsers. 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!)
- zalew 13y ago
  like this: <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> ?
  - derefr 13y ago
    Presumably, yes. How would you "show" a blind person your vacation photos?
    - zalew 13y ago
      I wouldn't, because he/she is blind. And I wouldn't describe him the flat picture I took, I would tell a story that includes observations from other senses that they can relate to. 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.
      - derefr 13y ago
        To put it another way--web browsers and web spiders are (currently) blind, and they're the ones who define what "content" is, not users. Users only deal with the web through its presentation layer; it's machines who think on the semantic level, and so it's machines who get to say what is or is not semantically meaningful. 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> Likewise, a UML diagram for an algorithm might be represented thus: <img src="sort_fn.png"> <code> ... pseudocode for sort ... </code> </img> Photography is basically the one special case--where the medium (the shot composition, lighting, etc.) is a large part of the message. Still, unless the photograph was taken completely at random, there is usually a reason it is being included on the page. And that reason can be used as the non-visual text. (And note that, if the entire purpose of the page is to show you the image, then you're not really looking at a hypertext document. You're more looking at HTML+CSS being used as a layout format ala PDF. There is no semantic meaning to such a page, any more than there is to a PDF.) 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.
jschrf 13y ago
Gross. Srcset is definitely not the solution here. Hacky, stupid, doesn't address the real problem. The real problem is that images only map to files in the most simple, rigid way. 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?
canterburry 13y ago
I think we need to ask ourselves whether providing the mechanism, markup or specification for which version of an image to load in order to maintain one and the same INTENT across clients should be the responsibility of front end developers/designers? 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.
culshaw 13y ago
I've wrote a javascript polyfill for this. Currently only supports 1x,2x,3x, same as the implementation in webkit. http://github.com/culshaw/srcset http://github.com/culshaw/srcset
grey-area 13y ago
I find this really disappointing, and it's another example of browser vendors and spec writers creating more problems than they solve. Even the best example here falls short: <source srcset="med.jpg 1x, med-hd.jpg 2x" media="(min-width: 40em)" /> and is fraught with problems. What does 1x and 2x mean in a world where devices range in ppi so dramatically, and single devices allow scaling from a rendered scale of 100ppi to 1000ppi (zooming on an ipad for example)? What actual resolution are these images (as opposed to display intent) and how do we find that out, by loading them all? 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> Something is really broken with the webkit consultation process if changes like this can make it into the browser.

138 points by nvk 13y ago

untilHellbanned 13y ago

glad this is happening

joebolte 13y ago

Is srcset really the clearest name they could come up with?

shousper 13y ago
Apparently? I'm also not a fan of the value format, let alone the attribute name. Beggers can't be choosers though. Glad we're getting somewhere.
kalleboo 13y ago
What bothers me isn't the name, but how the syntax looks like nothing else in HTML. At the time the idea was floated, there were a few alternatives talked about that mimicked the <video> and <audio> tags that made way more sense, and opened up for adding webp alternatives with png/jpeg fallbacks etc. It's a real shame they NIH'ed those.
- acdha 13y ago
  That part in the article felt strained: Mat was clearly trying extremely hard not to be rude while showing how much cleaner <picture> is. Hopefully this is an opening salvo rather than the end of the discussion…
  - jcampbell1 13y ago
    The problem with picture is that it doesn't poly fill nicely. You can add srcset attributes and it will still work on IE6. I have been using srcset for over a year, and there is is only a minor issue of retina MBPs double downloading. There is no problem with high res tablets.
    - kalleboo 13y ago
      I don't remember any issues polyfilling video, does anything make picture different? This is one of those things one person has to write once and then everyone can reuse it.
      - jcampbell1 13y ago
        A polyfill of <picture> much more expensive. First you have to shiv IE to accept it as a DOM node. Then after the DOM is loaded, you have to re-write the DOM to replace the <picture> tags with <img>. Polyfilling "srcset" is trivial as in: if browser is modern and high-res, replace the value of src. else pass Doing a flash video polyfill of a video tag is okay because there is probably only one video on the page. Polyfilling <picture> would produce some seriously janky page rendering, and would be a pain in the ass to maintain.
        acdha 13y ago
        > First you have to shiv IE to accept it as a DOM node 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.
        kalleboo 13y ago
        In the proposal I saw, browsers that supported <picture> would ignore <img> tags inside a <picture>, meaning for anyone who isn't strict about pure semantic HTML, they could just stick an img in there for older browsers.
    - acdha 13y ago
      Polyfilling is an issue, although a manageable one if you're willing to use noscript: <picture> <noscript><img src="old-browser.jpg"></noscript> </picture> (<noscript> should keep browsers from loading the image tag, so you could do things like have JavaScript evaluate your image candidates and generate an img accordingly) 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.
- chrisoverzero 13y ago
  Experience with the <video> and <audio> tags has shown that their pattern isn't a great pattern to continue using. [0]: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0247.html http://lists.w3.org/Archives/Public/public-whatwg-archive/20... [1]: http://html5doctor.com/interview-with-ian-hickson-html-editor/ http://html5doctor.com/interview-with-ian-hickson-html-edito...
josho 13y ago
"There are only two hard things in Computer Science: cache invalidation and naming things." — Phil Karlton http://martinfowler.com/bliki/TwoHardThings.html http://martinfowler.com/bliki/TwoHardThings.html
- recursive 13y ago
  And off by one errors.
othermaciej 13y ago
It matches the CSS equivalent feature, image-set().

malkia 13y ago

Wait.. I thought it was some kind of set of sources of something (actual source code?). Granted, I'm not that versed in html/javascript, so I guess I'm missing the lingo.

jevinskie 13y ago
The original attribute for a single image file is 'src'. srcset allows the browser to intelligently select an image (src) from a set of available images.

mzs 13y ago

I wonder... http://www.yoav.ws/2012/05/Responsive-image-format 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.

othermaciej 13y ago
When it comes to page load speed, extra network round trips are really bad. Even if you're loading the same total amount of data.
- mzs 13y ago
  But it can keep the port open so a few round trips are saved, it might be fast enough to make the second request while the first was still coming in so effectively very little overhead, even on (especially on) high latency links where it matters most. It can start drawing even from the first range request, and the idea is to never pull down the entire file (for big files, the case you are optimizing anyway, small ones you don't really need to) and only maybe end-up pulling in the entire hires file with a third request if say the user zooms way in.

josho 13y ago

After adding hidpi support to a small web app I am grateful that we are seeing progress in this area. 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.

kclay 13y ago
I had to do the same thing recently and ended up using "Interchange" from the foundation framework. I did have to hack away at the full background slider (supersized) to support this but it worked out nicely. The thing with media queries is that a browser window at 1400 doesn't fit the min-width:1400, in my case I had to use something like 1375 or some odd size. Maybe its some quirk with how matchMedia works ( what the interchange lib uses) who knows, I'll be glad when we don't have to go through these hoops.

subpixel 13y ago

This was posted to HN today, and seems to me a very interesting approach: https://github.com/square/apropos https://github.com/square/apropos

possibilistic 13y ago

I've never commented on an author's English before, but why does this person write somewhat like Yoda? > In our opinion not ideal, this markup pattern. > Not too scary, this markup. Is this an acceptable form of English grammar that I'm unfamiliar with? (I'm a native speaker, and this is an honest question.) Is he just trying to be playful with words?

maw 13y ago
It's a Commonwealthism. (I mean the British one, not Massachusetts.)
- vosper 13y ago
  I'm from New Zealand, and I've lived in London for a while too - I've rarely heard anyone speak this way, and certainly it wouldn't be considered correct to write like that.
nilliams 13y ago
Yep I think he literally wrote those 2 sentences in a Yoda-style, intentionally, for playful effect. Rest of article is well written, with above average attention to sentence structure.
itsameta4 13y ago
It's called topicalization, and it's more common in some dialects of English than others. It's especially common in urban areas of the US Northeast. I'm from Long Island, and I didn't even notice he'd done it. http://en.wikipedia.org/wiki/Topicalization http://en.wikipedia.org/wiki/Topicalization
- gojomo 13y ago
  Interesting concept - I didn't know the word for this! 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.)

prodigal_erik 13y ago

I wish they had extended content negotiation to let the browser request an image near an ideal size in pixels using some kind of Accept header. Adding cruft like "med-hd" to the URL path is a design smell, and so is being able to suggest it from HTML but not HTTP.

hcarvalhoalves 13y ago
> using some kind of Accept header. 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.
- bsimpson 13y ago
  The stupid part about that logic re:images is that you get graceful degradation for free in systems that don't implement the additional Accept header.
  - lukeschlather 13y ago
    It's not stupid. From an academic perspective, sure it works either way. From a business perspective, you have to support the full feature set on a given set of browsers, and you're not going to waste time on a solution that only covers 80% of your required browsers when you can write one codebase that covers all of your browsers.
1qaz2wsx3edc 13y ago
Or have a progressive image format. Wherein the smallest/lowest quality image is at the front of the file and is enhanced by loading more data of the same file. It should be up to the browser and the image file format to determine the best option.
- adamzochowski 13y ago
  JPEG2000 had awesome option of having progressive quality. During compression user could specify number of quality years, with each layer having specific compression ratios. Browser could download a chunk of JPEG2000 and render it, and depending on bandwidth available the browser would keep downloading and improving image quality. Both Jasper support this (ilyrrates) and OpenJpeg (-r and -q) support this functionality.

hcarvalhoalves 13y ago

They are creating their own little DSL inside a tag attribute? This "1x", "2x" stuff in the markup looks awful. I can see from here the compatibility and complexity trainwreck we're going to have down the line.

1qaz2wsx3edc 13y ago
I disagree. It looks like the future of the web. Have you seen Web Components?
Kequc 13y ago
Think I agree. I feel like we would expect to see a resolution is either normal or double in dimensions. But currently with media attributes we are able to set the image property in CSS by itself and it gives us much more control. Particularly useful in instances where our images aren't exactly normal or double in dimensions but are resized. Other than 1x and 2x what are we supposed to expect to use here with this? Is there going to be 4x?
- pornel 13y ago
  Media query syntax has been proposed: <picture><source media="min-resolution: 2ppx"></picture> but mere query doesn't affect intrinsic size of the image, so you'd also need to specify exact dimensions in the markup or something like: <picture> <source media="min-resolution: 2dppx" style="image-resolution: 2dppx"> </picture> which is rather verbose and error-prone compared to srcset. > 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.
  - Kequc 13y ago
    It could assume you are defining image dimensions in the stylesheet the way that normal image tags do. Or it can default to the image scaled down to 2ppx as defined in the media query. Your example looks similar to current audio tags. <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>

recursive 13y ago

The more things change, the more they stay the same. Does anyone else remember lowsrc? Or am I showing my age?

adamzochowski 13y ago
lowsrc was awesome. To conserve bandwidth I would often switch to lowsrc. The new solution seem to be geared towards people running retina displays, without doing anything about progressive quality for people with low bandwidth.
- acdha 13y ago
  Have you started serving progressive JPEG? It's actually surprisingly good for that and supported by just about everything: http://blog.patrickmeenan.com/2013/06/progressive-jpegs-ftw.html http://blog.patrickmeenan.com/2013/06/progressive-jpegs-ftw....
est 13y ago
and dynsrc It was fun.

tech-no-logical 13y ago

this is the ugliest use of an attribute value I've ever seen. this needs to follow the way of the dodo, as quickly as possible.

sergiotapia 13y ago

This is terrible and the markup stick out like a sore thumb. The markup definitely needs some tweaking.

derefr 13y ago

> Using CSS to manage content images is broken by default, in terms of keeping our concerns separate. 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> with "bar" (previously the alt text) being the content, and foo.jpg being an alternate representation of the content, for supporting browsers. 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!)

zalew 13y ago
like this: <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> ?
- derefr 13y ago
  Presumably, yes. How would you "show" a blind person your vacation photos?
  - zalew 13y ago
    I wouldn't, because he/she is blind. And I wouldn't describe him the flat picture I took, I would tell a story that includes observations from other senses that they can relate to. 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.
    - derefr 13y ago
      To put it another way--web browsers and web spiders are (currently) blind, and they're the ones who define what "content" is, not users. Users only deal with the web through its presentation layer; it's machines who think on the semantic level, and so it's machines who get to say what is or is not semantically meaningful. 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> Likewise, a UML diagram for an algorithm might be represented thus: <img src="sort_fn.png"> <code> ... pseudocode for sort ... </code> </img> Photography is basically the one special case--where the medium (the shot composition, lighting, etc.) is a large part of the message. Still, unless the photograph was taken completely at random, there is usually a reason it is being included on the page. And that reason can be used as the non-visual text. (And note that, if the entire purpose of the page is to show you the image, then you're not really looking at a hypertext document. You're more looking at HTML+CSS being used as a layout format ala PDF. There is no semantic meaning to such a page, any more than there is to a PDF.) 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.

jschrf 13y ago

Gross. Srcset is definitely not the solution here. Hacky, stupid, doesn't address the real problem. The real problem is that images only map to files in the most simple, rigid way. 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?

canterburry 13y ago

I think we need to ask ourselves whether providing the mechanism, markup or specification for which version of an image to load in order to maintain one and the same INTENT across clients should be the responsibility of front end developers/designers? 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.

culshaw 13y ago

I've wrote a javascript polyfill for this. Currently only supports 1x,2x,3x, same as the implementation in webkit. http://github.com/culshaw/srcset http://github.com/culshaw/srcset

grey-area 13y ago

I find this really disappointing, and it's another example of browser vendors and spec writers creating more problems than they solve. Even the best example here falls short: <source srcset="med.jpg 1x, med-hd.jpg 2x" media="(min-width: 40em)" /> and is fraught with problems. What does 1x and 2x mean in a world where devices range in ppi so dramatically, and single devices allow scaling from a rendered scale of 100ppi to 1000ppi (zooming on an ipad for example)? What actual resolution are these images (as opposed to display intent) and how do we find that out, by loading them all? 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> Something is really broken with the webkit consultation process if changes like this can make it into the browser.