4 ms·

The reason webkit implemented srcset is because of the performance it allows. Consider: <img src="picture.jpg" srcset="picture@2x.jpg 2x" /> When the bro

The reason webkit implemented srcset is because of the performance it allows. Consider: <img src="picture.jpg" srcset="picture@2x.jpg 2x" /> When the browser comes across this markup, it can request the correct image prior to finishing parsing the DOM or the CSSOM being ready. I understand the appeal of <picture>, but the browser cannot choose the correct image until the DOM is parsed, the CSSOM is ready, and the page has been layed out. That all happens much later, which means the page will load slower. I like the idea of <picture> but srcset is ideal if the only features you want are pre-loading and high-res support.

grey-area 13y ago
Do you have a mailing list discussion you can link to on this, that might be illuminating? The reason webkit implemented srcset is because of the performance it allows. I wonder what HTML would look like if browser performance was the primary concern? Is this truly the best argument for srcset, that browsers can parse the page quicker? Probably the fastest HTML to render would be something like this: <img src="foo" border="2px solid red" margin="10px" width="100px" height="100px" align="left"> There are good reasons we've moved away from that, even though it hits performance. It just seems wrong to be tying image resolutions to particular screen resolutions and trying to specify sources in a comma separated list with arbitrary resolution scales included, that's pretty nasty and not at all like other parts of HTML (which generally has been kept surprisingly clean if spartan in terms of features). I'd rather use js to load hires than use this or just serve everyone hires. It reminds me of the horrible multiple resolution handling on iOS, which is probably what inspired it (@2x etc). I think there are now 15 different icon sizes for iOS [1] because of this insistence on tying resolutions to device specs. I can imagine issues with devices lying about resolution or ending up between x1 and x2 and not getting bigger images just because their resolution isn't quite x2 etc. [1] http://mrgan.tumblr.com/post/708404794/ios-app-icon-sizes http://mrgan.tumblr.com/post/708404794/ios-app-icon-sizes I see the concern on loading - if CSS determines the resolution of images, that would have to be parsed before deciding which image option to fetch, but that could be addressed by letting the browser decide which images are appropriate, and if necessary changing them if the CSS overrides that later. However I think the browser has far more pertinent info than the CSS writer (as long as it knows what size images actually are, not the intended device resolution in 2013!) about network, device, images, performance, user prefs etc. - the browser should decide what size of image is appropriate, and should be given the info to do that, and speed of loading should not be the primary concern in designing a document format - that should be a worry for browser makers, not for readers or writers of HTML. The most convincing argument on the article page for me was a short comment pointing out the problem with srcset that it is tied to our expectations today of device specs: If LG releases its Quad HD(?) smartphone screen it still means changing the html if you want to support it. - Niels Matthijs Anyway, rant over, apologies for the long posts, I'll get back to work now, and thank you for taking the time to explain.
- jcampbell1 13y ago
  >> The reason webkit implemented srcset is because of the performance it allows. > Do you have a mailing list discussion you can link to on this, that might be illuminating? A better explanation is that it is compatible with the preloader without doing anything complicated. See here: http://trac.webkit.org/changeset/153733 http://trac.webkit.org/changeset/153733 The example you gave confuses rendering performance with the ability to download assets in parallel / pre-load assets. Browsers can request images long before the CSS has even arrived. How does a browser know which image to preload when given multiple options? Specifying multiple images in a way that in compatible with preloading, is more akin to concatenating javascript/css, putting css at the top, etc. It makes a big difference because it let's you cut the time-to-glass by an entire network round trip.
  - grey-area 13y ago
    Sorry that example was too general, I was just trying to indicate that doc specs shouldn't be based on performance alone, as the most efficient format would be a memory dump like the old word formats or lots of inline style, clearly bad formats that we've moved away from. NB that concatting CSS does not change the doc spec at all, it's not the same kind of change either. In the same way that the browser can choose to load higher res images based on resolution or breakpoint hints (srcset), it could choose to load higher res from a list of images without x2 etc but with image resolutions (picture with sizes). I would argue the browser choice should be based on far more than the HTML writer's ideas about device/display resolution at the time of creation. To let the browser choose, the HTML could specify either original image sizes or some kind of desired resolution threshold for each image (srcset), but HTML should not know about the specific devices it is rendered on or include hints for rendering, I think that's an important distinction which is worth preserving. Not out of some desire for purity, but because separation of concerns stops bleed of concerns from one domain to the other and horrible messes later as the two domains become inextricably bound together. I do think this is a terrible direction go in for that reason, it worries me that browser performance is used as the justification, and it would appear many agree with me, but we'll see by how much usage this gets I guess, I know I wouldn't use it because of the concerns above.

grey-area 13y ago

Do you have a mailing list discussion you can link to on this, that might be illuminating? The reason webkit implemented srcset is because of the performance it allows. I wonder what HTML would look like if browser performance was the primary concern? Is this truly the best argument for srcset, that browsers can parse the page quicker? Probably the fastest HTML to render would be something like this: <img src="foo" border="2px solid red" margin="10px" width="100px" height="100px" align="left"> There are good reasons we've moved away from that, even though it hits performance. It just seems wrong to be tying image resolutions to particular screen resolutions and trying to specify sources in a comma separated list with arbitrary resolution scales included, that's pretty nasty and not at all like other parts of HTML (which generally has been kept surprisingly clean if spartan in terms of features). I'd rather use js to load hires than use this or just serve everyone hires. It reminds me of the horrible multiple resolution handling on iOS, which is probably what inspired it (@2x etc). I think there are now 15 different icon sizes for iOS [1] because of this insistence on tying resolutions to device specs. I can imagine issues with devices lying about resolution or ending up between x1 and x2 and not getting bigger images just because their resolution isn't quite x2 etc. [1] http://mrgan.tumblr.com/post/708404794/ios-app-icon-sizes http://mrgan.tumblr.com/post/708404794/ios-app-icon-sizes I see the concern on loading - if CSS determines the resolution of images, that would have to be parsed before deciding which image option to fetch, but that could be addressed by letting the browser decide which images are appropriate, and if necessary changing them if the CSS overrides that later. However I think the browser has far more pertinent info than the CSS writer (as long as it knows what size images actually are, not the intended device resolution in 2013!) about network, device, images, performance, user prefs etc. - the browser should decide what size of image is appropriate, and should be given the info to do that, and speed of loading should not be the primary concern in designing a document format - that should be a worry for browser makers, not for readers or writers of HTML. The most convincing argument on the article page for me was a short comment pointing out the problem with srcset that it is tied to our expectations today of device specs: If LG releases its Quad HD(?) smartphone screen it still means changing the html if you want to support it. - Niels Matthijs Anyway, rant over, apologies for the long posts, I'll get back to work now, and thank you for taking the time to explain.

jcampbell1 13y ago
>> The reason webkit implemented srcset is because of the performance it allows. > Do you have a mailing list discussion you can link to on this, that might be illuminating? A better explanation is that it is compatible with the preloader without doing anything complicated. See here: http://trac.webkit.org/changeset/153733 http://trac.webkit.org/changeset/153733 The example you gave confuses rendering performance with the ability to download assets in parallel / pre-load assets. Browsers can request images long before the CSS has even arrived. How does a browser know which image to preload when given multiple options? Specifying multiple images in a way that in compatible with preloading, is more akin to concatenating javascript/css, putting css at the top, etc. It makes a big difference because it let's you cut the time-to-glass by an entire network round trip.
- grey-area 13y ago
  Sorry that example was too general, I was just trying to indicate that doc specs shouldn't be based on performance alone, as the most efficient format would be a memory dump like the old word formats or lots of inline style, clearly bad formats that we've moved away from. NB that concatting CSS does not change the doc spec at all, it's not the same kind of change either. In the same way that the browser can choose to load higher res images based on resolution or breakpoint hints (srcset), it could choose to load higher res from a list of images without x2 etc but with image resolutions (picture with sizes). I would argue the browser choice should be based on far more than the HTML writer's ideas about device/display resolution at the time of creation. To let the browser choose, the HTML could specify either original image sizes or some kind of desired resolution threshold for each image (srcset), but HTML should not know about the specific devices it is rendered on or include hints for rendering, I think that's an important distinction which is worth preserving. Not out of some desire for purity, but because separation of concerns stops bleed of concerns from one domain to the other and horrible messes later as the two domains become inextricably bound together. I do think this is a terrible direction go in for that reason, it worries me that browser performance is used as the justification, and it would appear many agree with me, but we'll see by how much usage this gets I guess, I know I wouldn't use it because of the concerns above.