I'd like to propose a new function for the Images module. This function will allow developers to provide, in a compact manner, multiple variants of the same image at differing resolutions. Using @media pushes the two asset references apart from one another, whereas such a function keeps related asset references together. It also helps keep selectors DRY. We've called it image-set(), and it takes one or more image specifiers.
That's their notation. Imagine having to do that for every image ever, when they're all just filename + 2x resolution key + filename extension. Totally asinine. Developers should just be able to pick a single page-wide filename key for all their 2x assets, and the browser will know to look there.
Yep, a solution is still needed for content images.
That's their notation. Imagine having to do that for every image ever, when they're all just filename + 2x resolution key + filename extension. Totally asinine. Developers should just be able to pick a single page-wide filename key for all their 2x assets, and the browser will know to look there.
You assume the developers can guarantee all image assets will be 2x. For quite some time, I doubt that'll be the case. And, given that, if the browser just naively requested 2x assets, there would be some set of wasted http requests that just add overhead and significantly delay page load.
Explicitly declaring the 1x and 2x images' existence is a far better solution, even if it is more verbose. The UA can't be guessing about the existence of resources if it's also to be efficient.
No, the better solution would be to add support for:
<meta img-x2-res="_x2" />
This would alert the browser of the likely presence of 'filename_x2.ext' when it sees img tags, and it would fall back with a second request for 'filename.ext' in case it's not found. This seems relatively easy to implement (especially for web developers), and degrades gracefully on older browsers.
Then, a more fleshed out version accounting for the scenario you describe would be the following:
<meta img-x2-res="_x2" assume-present="false" />
Then for any img tags for which double-res assets are available, you could add a property to the img tag as such:
<img x2-res="true" />
Or, you could leave the 'assume-present' property off, as 'true' is default, and put '<img x2-res="false" />' on any images for which double-res assets are unavailable. This would avoid a second request when the first fails.
Such a solution would be significantly more convenient for developers, as you could choose whether to assume the presence of 2x and flag ones that don't have it, or assume its absence and flag those that do, saving tons of time.
Sorry, that should be '2x', not 'x2'. The img '2x-res' property could also be used to provide an asset-specific 2x-res filename key as such:
<img 2x-res="@2x" />
If we wanted this to affect the image asset requested by the CSS background-image and border-image values as well, then a new CSS property would be required for flagging 2x-res active or not and an asset-specific 2x filename key. But its use would be vastly superior to -webkit-image-set, as you could just do this:
.class {2x-res: "@2x"}
or:
.class {2x-res: "false"}
The only limitation is that these 2x assets must share the same filename with the 1x, except for the addition of a 2x key at the end of the filename. However, that seems to be what people are already doing simply to keep track of their assets, and it's much easier to sell me on this imposition than on having to redo all my CSS in the most redundant and painful way imaginable.
I'd like to propose a new function for the Images module. This function will allow developers to provide, in a compact manner, multiple variants of the same image at differing resolutions. Using @media pushes the two asset references apart from one another, whereas such a function keeps related asset references together. It also helps keep selectors DRY. We've called it image-set(), and it takes one or more image specifiers.