11 ms·

How a new HTML element will make the Web faster

311 points by wfjackson 12y ago

TheAceOfHearts 12y ago
tl;dr: <picture> tag. It contains an <img> tag inside for backwards compatibility, and allows you to define multiple <source> tags for different sizes.
- est 12y ago
  Which is kinda lame IMHO. Why can't we use progressive JPEG, with offsets? The first rough scan for small size image, a second scan for normal image, a third scan for retina sized image? One file, one URL, different offset for different dimensions, done.
  - cbhl 12y ago
    You may want to show a different icon with different viewport sizes. For example, compare the different sizes of the Google Calendar icon here: http://setup.googleapps.com/Home/user-resources/google-icons-and-logos http://setup.googleapps.com/Home/user-resources/google-icons... You'll note the 16px icon uses square corners, while the other sizes have rounded corners. There are other considerations as well, such as causing unintentional Moiré effects, and scaling DPIs in not-quite-powers-of-two (basically all of Android).
  - Groxx 12y ago
    Still doesn't solve the design-problem of showing e.g. a differently-cropped (or entirely different) image to different viewports.
  - rrouse 12y ago
    Doesn't that mean I would be downloading all of the image data and only using part of it?
    - Sanddancer 12y ago
      No. Part of the http spec is the ability to download only a specific range of bytes in a file.
bambax 12y ago
There are many browsers out there, not just Chrome and Firefox, esp. on mobile. Android Chrome is fairly out of sync with desktop Chrome. Kindle devices use their own browser and won't let you install another one, etc. Plus, mobile users update their apps or their OS rarely, if ever. Shouldn't the solution come from the server side? You can serve different image sizes to different devices, whereas if you need the browser to do the work you'll wait forever. There is even a simpler solution, which is to use just one image of average-to-small size, and size it in the page dynamically. If the image is of good quality in the first place (noise free), most users won't notice.
- nathancahill 12y ago
  Noise has nothing to do with good quality in this case. Pixels are the enemy, and they show up all too quickly when you scale a small image to a large size.
  - RussianCow 12y ago
    And conversely, you don't want to load a huge high-res image on mobile devices with bad connections that won't even use them.
- dkyc 12y ago
  The article mentioned the problem with this approach: Your browser loads the HTML, CSS, JS simultaneously with the images on the start of the page load - so when you find out what size you need at runtime (via JS), and then put in the right img-src, it will be slower than loading a higher-res version right from the start. Another option would be to "guess" the right size to serve based on the User Agent String (maybe you meant this and I misunderstood?). This could work, although the server may very well guess wrong.
  - bambax 12y ago
    Yes, I meant "guessing" the right size based on the user-agent string as the best approach (since it doesn't rely on the browser doing the work, it will work with any browser, including old ones). But I also maintain that a single image of relatively small size can be used for all form factors if its quality is good enough (resized by the browser based on CSS instructions); you can at least double the size of a "good" image before you begin to see problems.
Illniyar 12y ago
This is a bit of a linkbait. There are maybe two lines on how the new "picture" element makes the web faster. The rest is the story of how the "picture" element came to be, which is a very interesting story but has nothing to do with how it'll make the web faster.
- bambax 12y ago
  And, ironically, ArsTechnica isn't responsive and uses stock images that contribute nothing to the article (blurry hands on a laptop keyboard!)
  - Tepix 12y ago
    Agreed. Quite annoying. The top rated comment post here was just 5 lines or so and told me more than 4 pages of that click bait article.
    - Natsu 12y ago
      I used to love Ars, but they've started this kind of nonsense and I no longer bother to read them :/
      - glitchdout 12y ago
        What do you read nowadays?
        Natsu 12y ago
        HN. Even when it publishes stuff from Ars or wherever, I often skip the article and just read the comments here because they're much more insightful and if there's anything good, the commentators here know better. The demand at news sites that they keep churning out news no matter what is what lowers their quality. Sometimes there just isn't anything worthwhile to read at the moment about a topic.
  - manojlds 12y ago
hrjet 12y ago
Why stop at images only? A more general solution using CSS-like media queries would be much preferable; with a general solution it would be possible to serve all sorts of assets (CSS, JS, Images, Video, etc) tailored to the display device and network connection.
- eurleif 12y ago
  <picture> is responsive; when you change the viewport's width, the browser can load a differently-sized version of the image. How would JS be made responsive like that? Once one version of a script is loaded, you can't magically replace it with a difference version. Of course, you could limit the media queries that could be used with JavaScript, but then your general solution isn't really so general anymore. And there's already a way to dynamically load scripts, so we don't really need another way to do that: <script> if (blah) { document.write('<script src="a.js">'); } else { document.write('<script src="b.js">'); } </script> And there's also already a way dynamically load CSS (using media queries, even): <style> @import url(a.css) (max-width: 800px); @import url(b.css) (min-width: 801px); </style>
  - hrjet 12y ago
    Good point about JS. But there are potentially more types of media (audio, video, html via frames, etc). Even if a general solution isn't applicable to JS, it can have lots of other uses.
    - tg3 12y ago
      the <picture> tag is set up very similarly to the audio and video tags, so I think that even if this specific solution isn't general, the pattern can be applied generally to other types of media.
    - eurleif 12y ago
      >html via frames That has the same problem as JS, especially when you realize that framed pages on the same domain can interact with the parent's DOM.
latch 12y ago
Recently, a HN job post brought me to a career page. It served up a 1MB css file, a 650K [mostly red] png image, and a 300K black and white png. I don't know whether it's incompetence or indifference, but for most sites, slow loads is a developer, not a tool or design, issue.
- iamben 12y ago
  I agree to a point - I think it's maybe thought about a bit more by those who were building sites when a 1mb page meant a 5 minute download. For those that grew up taking high speed Internet for granted it's thought about a lot less. That said, when the only way to get the design to work is using alpha transparency, and you know you need a massive 24bit PNG you're caught between a rock and a hard place. Especially when you then have to think about creating the same image at double size to serve to retina displays (because the client asks "why is it fuzzy on my ipad/mac/phone?") - page sizes start to get out of control.
  - rangibaby 12y ago
    Your point is valid, but using imagealpha allows you to have alpha channel in 8bit pngs. www.pngmini.com
    - iamben 12y ago
      That's fantastic, thank you. I've been using TinyPNG.com - will give this a go :-)
- rattray 12y ago
  If you want people to do more of something, make it easier for them to do. Making it easier to optimize web resources with a `<picture>` tag may help some developers take the steps to actually optimize where they didn't before (even with existing tools).
- userbinator 12y ago
  I'd say it is a bit of a design issue too - I remember when the majority of images on sites were actually "contentful" (for lack of a better term), and not just something like a gradient or glittering button. The practice of providing a thumbnail/preview that links to the full-sized version was common, so you wouldn't be unnecessarily loading images you didn't want to see at full resolution. In some ways, this almost feels like spacer.gif all over again.
ardemue 12y ago
For the technical side, instead of the historical one: http://responsiveimages.org/ http://responsiveimages.org/ An example from the homepage: <picture> <source media="(min-width: 40em)" srcset="big.jpg 1x, big-hd.jpg 2x"> <source srcset="small.jpg 1x, small-hd.jpg 2x"> <img src="fallback.jpg" alt=""> </picture>
- hliyan 12y ago
  I understand from the article that the img srcset was somehow horrible, but the following (presumably the WHATWG proposal) looks more intuitive to me: <img src="small.jpg" srcset="large.jpg 1024w, medium.jpg 640w"> Can someone explain the drawbacks?
  - est 12y ago
    file names can have spaces and JPEG can end with "640w" in URL. It's really weird to see a tiny DSL invented in a DOM attribute.
    - TheCoreh 12y ago
      Spaces can be escaped as %20 in URLs. I do agree that the domain specific language is weird though, and would even require new DOM APIs to manipulate it directly (like the style attribute does).
      - bshimmin 12y ago
        Surely the way one would represent this in XML, rather than `srcset="foo 1x, bar 2x"`, which strikes me as odd, would be: <picture> <srcset media="(min-width: 40em)"> <source size="1x" src="big.jpg" /> <source size="2x" src="big-hd.jpg" /> </srcset> ...another srcset... <img src="fallback.jpg" /> </picture> Fractionally more verbose, but really a lot less fiddly.
        kolektiv 12y ago
swehner 12y ago
If mobile browsers struggle to download images, change the mobile browsers. Let the browser wait for some javascript to manipulate the src's ...
ihsanyounes90 12y ago
I knew about this tag 2 months ago, when I was Implementing a responsive website. I came accross the picture element but Unfortunatlly, most of modern browser is not supporting it yet. So I decided to do it via javascript. So I don't see the "news" here, I thought the article was about a compression algoritm or somthing, but nothing special.
aianus 12y ago
This doesn't seem too useful in the first world anymore now that we have 4G connections and higher resolution screens on our phones than our desktops.
- dannyr 12y ago
  The first world would still benefit because web pages would download faster on mobile. Also, the first world is just a subset of internet users.
- joosters 12y ago
  I don't agree with your 4G comment, as its coverage is poor, performance is patchy and smaller files will still download quicker regardless of your max speed. But your point about high res screens is definitely true. Hell, we first had 'retina' hacks and bigger images specifically for our phones! Why is a site going to want to serve up smaller files for screens with more pixels?
- Renaud 12y ago
  I would presume that the higher resolutions of mobile devices over laptops and desktops is just a transient thing. Laptops and desktop monitors are slowly catching up. We're just living in this part of history where it was easier to manufacture small high-DPI screens than large ones. It's not going to last. Heck, I'm typing this on a 13" Yoga Pro laptop with a near 4K resolution. So the sizes needed for larger displays will bump up over the next few years and we're still going to have the same issue of having to serve massively larger images to large screens than small ones.
sixQuarks 12y ago
I think the current mobile browser is long overdue for disruption. In 10 years, I can see us looking back and chuckling at the fact that we had such tiny spaces for all the information we interact with. Virtual reality should bring inexpensive, full-peripheral "monitors" that we can interact with naturally, anywhere. No more having to bend over backwards to fit all our info on mobile devices.
- coldtea 12y ago
  >Virtual reality should bring inexpensive, full-peripheral "monitors" that we can interact with naturally, anywhere. Yeah, I don't see that happening any time soon, because ergonomics.
  - sixQuarks 12y ago
    I can see it evolve into a normal pair of glasses in 10 to 15 years. We need another Steve Jobs-type character to speed things up a bit, but I think we can get there.
xenomachina 12y ago
This element reminds me of the ill-fated FIG element (https://www.cmrr.umn.edu/~strupp/elements.html#FIG https://www.cmrr.umn.edu/~strupp/elements.html#FIG) which was proposed in HTML 3.x, but never made it in. (I think it was replaced by EMBED which then transmogrified into OBJECT). FIG was intended to be an alternative to IMG, and unlike IMG it wasn't self-closing. It could have children, and the way it was supposed to work was that the outermost one the browser thought was "good enough" would get rendered. One possible usage at the time was to have a png in your outer FIG, a gif on the next one in (png was new at the time, so not well supported), then an IMG for browsers that didn't understand FIG. Once FIG was well supported then you'd leave out the IMG, and instead just have the "alt" text -- except it could have real markup instead of just the plain text of the alt attribute.
c23gooey 12y ago
http://caniuse.com/#feat=picture http://caniuse.com/#feat=picture This probably wont be used on any major sites for the time being, considering the devices that the element has been designed for dont support it.
- thomasfoster96 12y ago
  There's always a polyfill: https://github.com/scottjehl/picturefill https://github.com/scottjehl/picturefill Considering many HTML5 features and related JavaScript APIs can easily be made to work in older browsers using polyfills, many relatively larger sites have been doing this for lots of things (HTML5 block elements in IE<9, for example).
blencdr 12y ago
I don't understand why so much question as this problem should be easily solved with wavelet type images (jpeg2000 for instance). the low resolution devices could load the first bytes of the image and the high resolution one the full image.
NicoJuicy 12y ago
To resize images, i create a cookie with javascript that gives the browsers current width and height. (mostly for full image front pages -> the function for choosing the image width is based on bootstrap) When i read the title, i thought media-queries would get the functionality to load external stylesheets, which seems like a better option to me (especially if css could fill the img src, then stylesheets reduce in size, but also images. Only this option uses to much back-and-fort communication. Perhaps a default naming would be appropriate (eg. img-1024.jpg => for browsers with a max-width of 1024 px, same could be used with stylesheets). Even a syntax like <img src="small.jpg" srcset="large.jpg 1024w, medium.jpg 640w"> could be used. PS. If you downvote me, at least do it with the decency of giving arguments...
- idlewords 12y ago
  It's also horrible for anyone trying to archive your page.
  - NicoJuicy 12y ago
    Then the archiving functionality saves all additional stylesheets and images, so it can be appropriately used later on. But not much people "save" a page as html, they bookmark/favorite it, if it's interesting or print it to pdf (or your favorite document type)- eg. on a checkout Then again, what's your preference?
- acdha 12y ago
  0. This requires a full server round trip before it can send the right size images. 1. This breaks caching, which is a big deal for most sites. 2. This also has the problem of needing a separate fallback to handle window resizing. 3. This requires a separate approach to handle format detection, although you could set a cookie for that as well.
thomasfoster96 12y ago
I think <picture> will (hopefully) ultimately win out because it quite nicely makes all the main three forms of embedded media (pictures, video and audio) work pretty much the same way. Plus, if only use of <figure> and <figcaption> was a bit more widespread... Either way, the article makes it pretty clear that the current method for drafting and implementing standards for the web is not working brilliantly (having both W3C and WHATWG around exemplifies this).
jbb555 12y ago
Ah, it might make the web faster on mobile. Not very interesting.
- jpatte 12y ago
  As the border between mobile/portable devices and dektops/workstations keeps getting blurrier, this "on mobile" concept will probably just lose any sense in the near future.
- tomelders 12y ago
  Probably not. In my experience I've found that images are usually higher res (and bigger file sizes) that on mobile devices.
- joezydeco 12y ago
  Mobile is getting worse, IMO. Maybe it's because I have an older iOS device running 6.1, but the insane size of some of these sites combined with all the side-loaded javascript and CSS rendering (and re-rendering) is just making sites completely unusable. How come I can load Metafilter in 3 seconds, but Wired takes over a minute, if it works at all? And Medium? Even worse.
  - Pxtl 12y ago
    OMG this. It's insanely frustrating that 90% of the time we're just reading text and it's so painful on older mobile devices that still should run circles around computers that happily consumed internet content ~10 years ago.
    - nfoz 12y ago
      The web used to provide text, and allow the user-agent to render it as appropriate for that display/user. Now the web is a (bad) application platform, where the content designers demand full control of interactivity. As a user you are not well-served by the modern web. It's not the devices per se it's also the content that is different than ~10 years ago.
ethana 12y ago
I think this should just be a server side issue. Querying for images with size information and the server spit out lower res images on the fly. This way, the web design guys have less to do when creating graphics assets for a site.
ptbello 12y ago
I found this article on the subject to be more informative and useful: http://ericportis.com/posts/2014/srcset-sizes/ http://ericportis.com/posts/2014/srcset-sizes/
superzamp 12y ago
For people interested in on the fly image processing, there's a nice article here http://abhishek-tiwari.com/post/responsive-image-as-service-rias http://abhishek-tiwari.com/post/responsive-image-as-service-...
- hisyam 12y ago
  Some more alternatives: http://www.imgix.com/ http://www.imgix.com/ http://www.thumbr.io/ http://www.thumbr.io/
- bergie 12y ago
  Then there is the self-hosted https://github.com/jonnor/imgflo-server https://github.com/jonnor/imgflo-server based on GEGL
igl 12y ago
Someone from the HTML standard body is going to make the web better? Riiiiiiight...
ndreckshage 12y ago
This article is pretty naive. 1. m dot sites are not a thing of the past. Many sites benefit from a pure mobile experience. 2. The Boston Globe (while impressive) does not show that 'that responsive design worked for more than developer portfolios and blogs'. The globe is largely text / image based, and that does not translate to a site like Amazon / Facebook.
ollysb 12y ago
A simpler solution might be <img src="image.jpg" sizes="640,800,1024"/> Then then the browser can choose the most appropriate size based on the screen size. The filenames would simply follow the convention, image-640.jpg, image-800.jpg etc. older browsers would simply use the original src.
- ollysb 12y ago
  Another option would be to allow the source to be specified in css (stylesheets are loaded before images anyway). Then you could do <img id="cats" src="fallback_for_old_browser.png" /> @media (max-width: 600px) { #cats { src: url('http://cats.com/cats-600.png'); } }
  - kaoD 12y ago
    No please. CSS is meant for presentation, not content.
    - swift 12y ago
      We'll need a solution in CSS for properties like background-image and border-image. (Indeed, there have been multiple proposed solutions already.) It would be nice to use the same mechanism for both CSS and content images instead of introducing yet another case in the web platform where we have multiple slightly-incompatible mechanisms that do the same thing.
- Steuard 12y ago
  To my eye, it's a little odd to read an article about multiple groups of experts who spent months or years hashing out a difficult problem, and then to see a comment like this one that proposes its own much simpler solution. Is your thought here that not one of the dozens of people involved considered this sort of syntax during those months or years or work? (That seems unlikely.) Or do you think their reasons for rejecting it were unsound? (You don't seem to have said why.) I'm just not understanding what you're aiming for here.
NoMoreNicksLeft 12y ago
Seriously, I thought this was what request headers were for. Have the goddamned browser request the most appropriate size, don't hardcode it into the markup.
- wtetzner 12y ago
  The problem is if you want different images for different screen sizes, not just different sizes of the same image.
Thiz 12y ago
Polluting the HTML with extraneous information not intended as markup is never a solution. As someone already said, use headers, css, etc.
dredmorbius 12y ago
TL;DR: <picture> element. arstechnica: you can do better than linkbait titles.
Pxtl 12y ago
Or we could finally stop futzing around with scaling raster graphics and find a way to make vector formats not terrible. Serioulsy, fast vector graphics were a solved problem back in the late '90s. How is this still a problem today on the Web?
- steveax 12y ago
  Not that I'm against improving vector graphics, but The majority of images on the web today are not suited for vector formats (photos).
  - Pxtl 12y ago
    I would disagree that the majority of images on the web are photos. Yes, there are many photos on the web, but I'd wager the vast majority of images (or at least the vast majority of image requests) are tiny bits of connective tissue of web layout - little rounded corners, gradient backgrounds, icons, etc.
    - steveax 12y ago
      Rounded corners and gradients can both be handled without images these days, but even if you use images for things like that, that bandwidth (certainly) and number (probably) of photos dwarfs them.
- nawitus 12y ago
  What's terrible about svg?
  - Pxtl 12y ago
    Performance.
- egypturnash 12y ago
  Vector formats can replace simple images, sure. They can't replace photos. And vector art complicated enough to be interesting can be a huge CPU load to draw... and can often be a LARGER file than a bitmap made at a resolution appropriate for the screen. It's not a more efficient representation for complex images until you start getting to 300+ dpi images that fill a whole printed page. Source: I'm an artist who works primarily in Illustrator and checks to see how horrible the svg performance on her more complicated images is every few years.
asher_ 12y ago
I was neck deep in this very issue for most of today. It is surprising that there is no usable solution to this issue without resorting to what seem like pretty awful methods. If I am wrong about this please do let me know. Based on what I found today, there are a couple of ways to handle the problem of variable sized images. If anyone knows others please do tell. 1. Use picture and srcset with a polyfill (Picturefill). With this you end up with verbose markup as well as needing stuff like "" to make it work. It also results in requests to multiple images for browsers that support srcset but not picture, meaning twice as many images are downloaded. Many browsers are in this group with the current or next versions. 2. Use javascript. This is the method employed by various saas solutions that I looked at, and there are of course libraries that you can use yourself. Waiting for javascript to execute before the images can start being pulled down has obvious problems. 3. User agent sniffing. This method requires server side logic to implement, and relies on data that in many cases will not result in an appropriately sized image being rendered. Is there another way? Has anyone got a workable solution to this and could give a recommendation?
mccr8 12y ago
The work to get the picture element implemented in Firefox is going on in the bugs in the "Depends on" field in this bug, if people are interested: https://bugzilla.mozilla.org/show_bug.cgi?id=1017875 https://bugzilla.mozilla.org/show_bug.cgi?id=1017875
laurisvan 12y ago
While the <picture> and <img srcset="..."> are a step towards responsive images, but I personally see them as too complicated for developers that just want to get things done fast. The complexity of the new standards will slow down their adoption even more than the browser support. For an example, we solve the adaptive images server-side problem with our SaaS image compression service http://www.slender.io/ http://www.slender.io/ with smart recompression & a few content negotiation tricks. Some of our customers would like to use <picture> and related polyfills for their sites, but their designers struggle defining the target image sizes relative to viewport dimensions, not the size that the image is/would be layouted. As a result, adoption on both smart browser and server-side solutions are slowed down. The article mentioned element queries, that will hopefully solve this problem, but make the browser implementation much more complex. While the browser could resolve the normal media queries already when preparsing (e.g. it knows the viewport dimensions all the time), I understood it would know the element queries only after layout, partially defeating the whole purpose of preparsers. It seems web standards are making things as simple as layouting insanely complex. While I am sad about all that artificial complexity, I am happy that no WYSIWYG editor will automate my job any time soon. :)
adad95 12y ago
HTTP Client Hints - New draft imp. of Client Hints for <img> and <picture> for Ruby. https://github.com/igrigorik/http-client-hints https://github.com/igrigorik/http-client-hints
exo_duz 12y ago
I love this idea of the <picture> element which hopefully most browsers will adopt soon but how will this support on the older iPhones that cannot upgrade to iOS7 (iOS8 soon). Especially with Apple not supporting these devices anymore.

311 points by wfjackson 12y ago

tl;dr: <picture> tag. It contains an <img> tag inside for backwards compatibility, and allows you to define multiple <source> tags for different sizes.

est 12y ago
Which is kinda lame IMHO. Why can't we use progressive JPEG, with offsets? The first rough scan for small size image, a second scan for normal image, a third scan for retina sized image? One file, one URL, different offset for different dimensions, done.
- cbhl 12y ago
  You may want to show a different icon with different viewport sizes. For example, compare the different sizes of the Google Calendar icon here: http://setup.googleapps.com/Home/user-resources/google-icons-and-logos http://setup.googleapps.com/Home/user-resources/google-icons... You'll note the 16px icon uses square corners, while the other sizes have rounded corners. There are other considerations as well, such as causing unintentional Moiré effects, and scaling DPIs in not-quite-powers-of-two (basically all of Android).
- Groxx 12y ago
  Still doesn't solve the design-problem of showing e.g. a differently-cropped (or entirely different) image to different viewports.
- rrouse 12y ago
  Doesn't that mean I would be downloading all of the image data and only using part of it?
  - Sanddancer 12y ago
    No. Part of the http spec is the ability to download only a specific range of bytes in a file.

bambax 12y ago

There are many browsers out there, not just Chrome and Firefox, esp. on mobile. Android Chrome is fairly out of sync with desktop Chrome. Kindle devices use their own browser and won't let you install another one, etc. Plus, mobile users update their apps or their OS rarely, if ever. Shouldn't the solution come from the server side? You can serve different image sizes to different devices, whereas if you need the browser to do the work you'll wait forever. There is even a simpler solution, which is to use just one image of average-to-small size, and size it in the page dynamically. If the image is of good quality in the first place (noise free), most users won't notice.

nathancahill 12y ago
Noise has nothing to do with good quality in this case. Pixels are the enemy, and they show up all too quickly when you scale a small image to a large size.
- RussianCow 12y ago
  And conversely, you don't want to load a huge high-res image on mobile devices with bad connections that won't even use them.
dkyc 12y ago
The article mentioned the problem with this approach: Your browser loads the HTML, CSS, JS simultaneously with the images on the start of the page load - so when you find out what size you need at runtime (via JS), and then put in the right img-src, it will be slower than loading a higher-res version right from the start. Another option would be to "guess" the right size to serve based on the User Agent String (maybe you meant this and I misunderstood?). This could work, although the server may very well guess wrong.
- bambax 12y ago
  Yes, I meant "guessing" the right size based on the user-agent string as the best approach (since it doesn't rely on the browser doing the work, it will work with any browser, including old ones). But I also maintain that a single image of relatively small size can be used for all form factors if its quality is good enough (resized by the browser based on CSS instructions); you can at least double the size of a "good" image before you begin to see problems.

Illniyar 12y ago

This is a bit of a linkbait. There are maybe two lines on how the new "picture" element makes the web faster. The rest is the story of how the "picture" element came to be, which is a very interesting story but has nothing to do with how it'll make the web faster.

bambax 12y ago
And, ironically, ArsTechnica isn't responsive and uses stock images that contribute nothing to the article (blurry hands on a laptop keyboard!)
- Tepix 12y ago
  Agreed. Quite annoying. The top rated comment post here was just 5 lines or so and told me more than 4 pages of that click bait article.
  - Natsu 12y ago
    I used to love Ars, but they've started this kind of nonsense and I no longer bother to read them :/
    - glitchdout 12y ago
      What do you read nowadays?
      - Natsu 12y ago
        HN. Even when it publishes stuff from Ars or wherever, I often skip the article and just read the comments here because they're much more insightful and if there's anything good, the commentators here know better. The demand at news sites that they keep churning out news no matter what is what lowers their quality. Sometimes there just isn't anything worthwhile to read at the moment about a topic.
- manojlds 12y ago

hrjet 12y ago

Why stop at images only? A more general solution using CSS-like media queries would be much preferable; with a general solution it would be possible to serve all sorts of assets (CSS, JS, Images, Video, etc) tailored to the display device and network connection.

eurleif 12y ago
<picture> is responsive; when you change the viewport's width, the browser can load a differently-sized version of the image. How would JS be made responsive like that? Once one version of a script is loaded, you can't magically replace it with a difference version. Of course, you could limit the media queries that could be used with JavaScript, but then your general solution isn't really so general anymore. And there's already a way to dynamically load scripts, so we don't really need another way to do that: <script> if (blah) { document.write('<script src="a.js">'); } else { document.write('<script src="b.js">'); } </script> And there's also already a way dynamically load CSS (using media queries, even): <style> @import url(a.css) (max-width: 800px); @import url(b.css) (min-width: 801px); </style>
- hrjet 12y ago
  Good point about JS. But there are potentially more types of media (audio, video, html via frames, etc). Even if a general solution isn't applicable to JS, it can have lots of other uses.
  - tg3 12y ago
    the <picture> tag is set up very similarly to the audio and video tags, so I think that even if this specific solution isn't general, the pattern can be applied generally to other types of media.
  - eurleif 12y ago
    >html via frames That has the same problem as JS, especially when you realize that framed pages on the same domain can interact with the parent's DOM.

latch 12y ago

Recently, a HN job post brought me to a career page. It served up a 1MB css file, a 650K [mostly red] png image, and a 300K black and white png. I don't know whether it's incompetence or indifference, but for most sites, slow loads is a developer, not a tool or design, issue.

iamben 12y ago
I agree to a point - I think it's maybe thought about a bit more by those who were building sites when a 1mb page meant a 5 minute download. For those that grew up taking high speed Internet for granted it's thought about a lot less. That said, when the only way to get the design to work is using alpha transparency, and you know you need a massive 24bit PNG you're caught between a rock and a hard place. Especially when you then have to think about creating the same image at double size to serve to retina displays (because the client asks "why is it fuzzy on my ipad/mac/phone?") - page sizes start to get out of control.
- rangibaby 12y ago
  Your point is valid, but using imagealpha allows you to have alpha channel in 8bit pngs. www.pngmini.com
  - iamben 12y ago
    That's fantastic, thank you. I've been using TinyPNG.com - will give this a go :-)
rattray 12y ago
If you want people to do more of something, make it easier for them to do. Making it easier to optimize web resources with a `<picture>` tag may help some developers take the steps to actually optimize where they didn't before (even with existing tools).
userbinator 12y ago
I'd say it is a bit of a design issue too - I remember when the majority of images on sites were actually "contentful" (for lack of a better term), and not just something like a gradient or glittering button. The practice of providing a thumbnail/preview that links to the full-sized version was common, so you wouldn't be unnecessarily loading images you didn't want to see at full resolution. In some ways, this almost feels like spacer.gif all over again.

ardemue 12y ago

For the technical side, instead of the historical one: http://responsiveimages.org/ http://responsiveimages.org/ An example from the homepage: <picture> <source media="(min-width: 40em)" srcset="big.jpg 1x, big-hd.jpg 2x"> <source srcset="small.jpg 1x, small-hd.jpg 2x"> <img src="fallback.jpg" alt=""> </picture>

hliyan 12y ago
I understand from the article that the img srcset was somehow horrible, but the following (presumably the WHATWG proposal) looks more intuitive to me: <img src="small.jpg" srcset="large.jpg 1024w, medium.jpg 640w"> Can someone explain the drawbacks?
- est 12y ago
  file names can have spaces and JPEG can end with "640w" in URL. It's really weird to see a tiny DSL invented in a DOM attribute.
  - TheCoreh 12y ago
    Spaces can be escaped as %20 in URLs. I do agree that the domain specific language is weird though, and would even require new DOM APIs to manipulate it directly (like the style attribute does).
    - bshimmin 12y ago
      Surely the way one would represent this in XML, rather than `srcset="foo 1x, bar 2x"`, which strikes me as odd, would be: <picture> <srcset media="(min-width: 40em)"> <source size="1x" src="big.jpg" /> <source size="2x" src="big-hd.jpg" /> </srcset> ...another srcset... <img src="fallback.jpg" /> </picture> Fractionally more verbose, but really a lot less fiddly.
      - kolektiv 12y ago

swehner 12y ago

If mobile browsers struggle to download images, change the mobile browsers. Let the browser wait for some javascript to manipulate the src's ...

ihsanyounes90 12y ago

I knew about this tag 2 months ago, when I was Implementing a responsive website. I came accross the picture element but Unfortunatlly, most of modern browser is not supporting it yet. So I decided to do it via javascript. So I don't see the "news" here, I thought the article was about a compression algoritm or somthing, but nothing special.

aianus 12y ago

This doesn't seem too useful in the first world anymore now that we have 4G connections and higher resolution screens on our phones than our desktops.

dannyr 12y ago
The first world would still benefit because web pages would download faster on mobile. Also, the first world is just a subset of internet users.
joosters 12y ago
I don't agree with your 4G comment, as its coverage is poor, performance is patchy and smaller files will still download quicker regardless of your max speed. But your point about high res screens is definitely true. Hell, we first had 'retina' hacks and bigger images specifically for our phones! Why is a site going to want to serve up smaller files for screens with more pixels?
Renaud 12y ago
I would presume that the higher resolutions of mobile devices over laptops and desktops is just a transient thing. Laptops and desktop monitors are slowly catching up. We're just living in this part of history where it was easier to manufacture small high-DPI screens than large ones. It's not going to last. Heck, I'm typing this on a 13" Yoga Pro laptop with a near 4K resolution. So the sizes needed for larger displays will bump up over the next few years and we're still going to have the same issue of having to serve massively larger images to large screens than small ones.

sixQuarks 12y ago

I think the current mobile browser is long overdue for disruption. In 10 years, I can see us looking back and chuckling at the fact that we had such tiny spaces for all the information we interact with. Virtual reality should bring inexpensive, full-peripheral "monitors" that we can interact with naturally, anywhere. No more having to bend over backwards to fit all our info on mobile devices.

coldtea 12y ago
>Virtual reality should bring inexpensive, full-peripheral "monitors" that we can interact with naturally, anywhere. Yeah, I don't see that happening any time soon, because ergonomics.
- sixQuarks 12y ago
  I can see it evolve into a normal pair of glasses in 10 to 15 years. We need another Steve Jobs-type character to speed things up a bit, but I think we can get there.

xenomachina 12y ago

This element reminds me of the ill-fated FIG element (https://www.cmrr.umn.edu/~strupp/elements.html#FIG https://www.cmrr.umn.edu/~strupp/elements.html#FIG) which was proposed in HTML 3.x, but never made it in. (I think it was replaced by EMBED which then transmogrified into OBJECT). FIG was intended to be an alternative to IMG, and unlike IMG it wasn't self-closing. It could have children, and the way it was supposed to work was that the outermost one the browser thought was "good enough" would get rendered. One possible usage at the time was to have a png in your outer FIG, a gif on the next one in (png was new at the time, so not well supported), then an IMG for browsers that didn't understand FIG. Once FIG was well supported then you'd leave out the IMG, and instead just have the "alt" text -- except it could have real markup instead of just the plain text of the alt attribute.

c23gooey 12y ago

http://caniuse.com/#feat=picture http://caniuse.com/#feat=picture This probably wont be used on any major sites for the time being, considering the devices that the element has been designed for dont support it.

thomasfoster96 12y ago
There's always a polyfill: https://github.com/scottjehl/picturefill https://github.com/scottjehl/picturefill Considering many HTML5 features and related JavaScript APIs can easily be made to work in older browsers using polyfills, many relatively larger sites have been doing this for lots of things (HTML5 block elements in IE<9, for example).

blencdr 12y ago

I don't understand why so much question as this problem should be easily solved with wavelet type images (jpeg2000 for instance). the low resolution devices could load the first bytes of the image and the high resolution one the full image.

NicoJuicy 12y ago

To resize images, i create a cookie with javascript that gives the browsers current width and height. (mostly for full image front pages -> the function for choosing the image width is based on bootstrap) When i read the title, i thought media-queries would get the functionality to load external stylesheets, which seems like a better option to me (especially if css could fill the img src, then stylesheets reduce in size, but also images. Only this option uses to much back-and-fort communication. Perhaps a default naming would be appropriate (eg. img-1024.jpg => for browsers with a max-width of 1024 px, same could be used with stylesheets). Even a syntax like <img src="small.jpg" srcset="large.jpg 1024w, medium.jpg 640w"> could be used. PS. If you downvote me, at least do it with the decency of giving arguments...

idlewords 12y ago
It's also horrible for anyone trying to archive your page.
- NicoJuicy 12y ago
  Then the archiving functionality saves all additional stylesheets and images, so it can be appropriately used later on. But not much people "save" a page as html, they bookmark/favorite it, if it's interesting or print it to pdf (or your favorite document type)- eg. on a checkout Then again, what's your preference?
acdha 12y ago
0. This requires a full server round trip before it can send the right size images. 1. This breaks caching, which is a big deal for most sites. 2. This also has the problem of needing a separate fallback to handle window resizing. 3. This requires a separate approach to handle format detection, although you could set a cookie for that as well.

thomasfoster96 12y ago

I think <picture> will (hopefully) ultimately win out because it quite nicely makes all the main three forms of embedded media (pictures, video and audio) work pretty much the same way. Plus, if only use of <figure> and <figcaption> was a bit more widespread... Either way, the article makes it pretty clear that the current method for drafting and implementing standards for the web is not working brilliantly (having both W3C and WHATWG around exemplifies this).

jbb555 12y ago

Ah, it might make the web faster on mobile. Not very interesting.

jpatte 12y ago
As the border between mobile/portable devices and dektops/workstations keeps getting blurrier, this "on mobile" concept will probably just lose any sense in the near future.
tomelders 12y ago
Probably not. In my experience I've found that images are usually higher res (and bigger file sizes) that on mobile devices.
joezydeco 12y ago
Mobile is getting worse, IMO. Maybe it's because I have an older iOS device running 6.1, but the insane size of some of these sites combined with all the side-loaded javascript and CSS rendering (and re-rendering) is just making sites completely unusable. How come I can load Metafilter in 3 seconds, but Wired takes over a minute, if it works at all? And Medium? Even worse.
- Pxtl 12y ago
  OMG this. It's insanely frustrating that 90% of the time we're just reading text and it's so painful on older mobile devices that still should run circles around computers that happily consumed internet content ~10 years ago.
  - nfoz 12y ago
    The web used to provide text, and allow the user-agent to render it as appropriate for that display/user. Now the web is a (bad) application platform, where the content designers demand full control of interactivity. As a user you are not well-served by the modern web. It's not the devices per se it's also the content that is different than ~10 years ago.

ethana 12y ago

I think this should just be a server side issue. Querying for images with size information and the server spit out lower res images on the fly. This way, the web design guys have less to do when creating graphics assets for a site.

ptbello 12y ago

I found this article on the subject to be more informative and useful: http://ericportis.com/posts/2014/srcset-sizes/ http://ericportis.com/posts/2014/srcset-sizes/

superzamp 12y ago

For people interested in on the fly image processing, there's a nice article here http://abhishek-tiwari.com/post/responsive-image-as-service-rias http://abhishek-tiwari.com/post/responsive-image-as-service-...

hisyam 12y ago
Some more alternatives: http://www.imgix.com/ http://www.imgix.com/ http://www.thumbr.io/ http://www.thumbr.io/
bergie 12y ago
Then there is the self-hosted https://github.com/jonnor/imgflo-server https://github.com/jonnor/imgflo-server based on GEGL

igl 12y ago

Someone from the HTML standard body is going to make the web better? Riiiiiiight...

ndreckshage 12y ago

This article is pretty naive. 1. m dot sites are not a thing of the past. Many sites benefit from a pure mobile experience. 2. The Boston Globe (while impressive) does not show that 'that responsive design worked for more than developer portfolios and blogs'. The globe is largely text / image based, and that does not translate to a site like Amazon / Facebook.

ollysb 12y ago

A simpler solution might be <img src="image.jpg" sizes="640,800,1024"/> Then then the browser can choose the most appropriate size based on the screen size. The filenames would simply follow the convention, image-640.jpg, image-800.jpg etc. older browsers would simply use the original src.

ollysb 12y ago
Another option would be to allow the source to be specified in css (stylesheets are loaded before images anyway). Then you could do <img id="cats" src="fallback_for_old_browser.png" /> @media (max-width: 600px) { #cats { src: url('http://cats.com/cats-600.png'); } }
- kaoD 12y ago
  No please. CSS is meant for presentation, not content.
  - swift 12y ago
    We'll need a solution in CSS for properties like background-image and border-image. (Indeed, there have been multiple proposed solutions already.) It would be nice to use the same mechanism for both CSS and content images instead of introducing yet another case in the web platform where we have multiple slightly-incompatible mechanisms that do the same thing.
Steuard 12y ago
To my eye, it's a little odd to read an article about multiple groups of experts who spent months or years hashing out a difficult problem, and then to see a comment like this one that proposes its own much simpler solution. Is your thought here that not one of the dozens of people involved considered this sort of syntax during those months or years or work? (That seems unlikely.) Or do you think their reasons for rejecting it were unsound? (You don't seem to have said why.) I'm just not understanding what you're aiming for here.

NoMoreNicksLeft 12y ago

Seriously, I thought this was what request headers were for. Have the goddamned browser request the most appropriate size, don't hardcode it into the markup.

wtetzner 12y ago
The problem is if you want different images for different screen sizes, not just different sizes of the same image.

Thiz 12y ago

Polluting the HTML with extraneous information not intended as markup is never a solution. As someone already said, use headers, css, etc.

dredmorbius 12y ago

TL;DR: <picture> element. arstechnica: you can do better than linkbait titles.

Pxtl 12y ago

Or we could finally stop futzing around with scaling raster graphics and find a way to make vector formats not terrible. Serioulsy, fast vector graphics were a solved problem back in the late '90s. How is this still a problem today on the Web?

steveax 12y ago
Not that I'm against improving vector graphics, but The majority of images on the web today are not suited for vector formats (photos).
- Pxtl 12y ago
  I would disagree that the majority of images on the web are photos. Yes, there are many photos on the web, but I'd wager the vast majority of images (or at least the vast majority of image requests) are tiny bits of connective tissue of web layout - little rounded corners, gradient backgrounds, icons, etc.
  - steveax 12y ago
    Rounded corners and gradients can both be handled without images these days, but even if you use images for things like that, that bandwidth (certainly) and number (probably) of photos dwarfs them.
nawitus 12y ago
What's terrible about svg?
- Pxtl 12y ago
  Performance.
egypturnash 12y ago
Vector formats can replace simple images, sure. They can't replace photos. And vector art complicated enough to be interesting can be a huge CPU load to draw... and can often be a LARGER file than a bitmap made at a resolution appropriate for the screen. It's not a more efficient representation for complex images until you start getting to 300+ dpi images that fill a whole printed page. Source: I'm an artist who works primarily in Illustrator and checks to see how horrible the svg performance on her more complicated images is every few years.

asher_ 12y ago

I was neck deep in this very issue for most of today. It is surprising that there is no usable solution to this issue without resorting to what seem like pretty awful methods. If I am wrong about this please do let me know. Based on what I found today, there are a couple of ways to handle the problem of variable sized images. If anyone knows others please do tell. 1. Use picture and srcset with a polyfill (Picturefill). With this you end up with verbose markup as well as needing stuff like "" to make it work. It also results in requests to multiple images for browsers that support srcset but not picture, meaning twice as many images are downloaded. Many browsers are in this group with the current or next versions. 2. Use javascript. This is the method employed by various saas solutions that I looked at, and there are of course libraries that you can use yourself. Waiting for javascript to execute before the images can start being pulled down has obvious problems. 3. User agent sniffing. This method requires server side logic to implement, and relies on data that in many cases will not result in an appropriately sized image being rendered. Is there another way? Has anyone got a workable solution to this and could give a recommendation?

mccr8 12y ago

The work to get the picture element implemented in Firefox is going on in the bugs in the "Depends on" field in this bug, if people are interested: https://bugzilla.mozilla.org/show_bug.cgi?id=1017875 https://bugzilla.mozilla.org/show_bug.cgi?id=1017875

laurisvan 12y ago

While the <picture> and <img srcset="..."> are a step towards responsive images, but I personally see them as too complicated for developers that just want to get things done fast. The complexity of the new standards will slow down their adoption even more than the browser support. For an example, we solve the adaptive images server-side problem with our SaaS image compression service http://www.slender.io/ http://www.slender.io/ with smart recompression & a few content negotiation tricks. Some of our customers would like to use <picture> and related polyfills for their sites, but their designers struggle defining the target image sizes relative to viewport dimensions, not the size that the image is/would be layouted. As a result, adoption on both smart browser and server-side solutions are slowed down. The article mentioned element queries, that will hopefully solve this problem, but make the browser implementation much more complex. While the browser could resolve the normal media queries already when preparsing (e.g. it knows the viewport dimensions all the time), I understood it would know the element queries only after layout, partially defeating the whole purpose of preparsers. It seems web standards are making things as simple as layouting insanely complex. While I am sad about all that artificial complexity, I am happy that no WYSIWYG editor will automate my job any time soon. :)

adad95 12y ago

HTTP Client Hints - New draft imp. of Client Hints for <img> and <picture> for Ruby. https://github.com/igrigorik/http-client-hints https://github.com/igrigorik/http-client-hints

exo_duz 12y ago

I love this idea of the <picture> element which hopefully most browsers will adopt soon but how will this support on the older iPhones that cannot upgrade to iOS7 (iOS8 soon). Especially with Apple not supporting these devices anymore.