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.
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.
> Do you have a mailing list discussion you can link to on this, that might be illuminating?
A better explanation is that it is compatible with the preloader without doing anything complicated. See here: http://trac.webkit.org/changeset/153733
The example you gave confuses rendering performance with the ability to download assets in parallel / pre-load assets. Browsers can request images long before the CSS has even arrived. How does a browser know which image to preload when given multiple options?
Specifying multiple images in a way that in compatible with preloading, is more akin to concatenating javascript/css, putting css at the top, etc. It makes a big difference because it let's you cut the time-to-glass by an entire network round trip.