[css-values] Define crossorigin, preload and async URL modifiers #1603
Description
The HTML img element (and also preload links and other references to external files) take a crossorigin attribute. It's purpose is to upgrade a request for an asset that normally doesn't need CORS permissions, so that the same asset can later be re-used in a context that does need CORS permissions.
CSS does not currently have this option. URLs in some properties (filters, clipping paths, masks that reference <mask> elements, and shape-outside images) require crossorigin="anonymous" mode. But URLs in older properties (background-image, border-image) don't request CORS permissions.
This causes caching headaches if you use the same asset file in multiple properties: even if the server is set up to use the correct caching headers, the same file would be download twice (once with CORS headers, and once without). If the server is not set up correctly, the CORS-request often fails because the cached version of the file does not have the correct headers.
Some examples of cases where you'd want the same asset file with different CORS requirements:
- A
background-imagethat is also used as ashape-outsideimage for the same element - An SVG file that is used as an image (e.g., background image, border image), but also includes
<mask>,<filter>, or<clipPath>effects for enhancing the final presentation of the element. - Any CSS image that will also be used in a canvas animation (e.g., a logo image that gets turned into a fancy animated loader graphic)
Currently, the only solution is to add a preload link to the markup to force the browser to fetch the assets with CORS permissions before the CSS can trigger its own fetch.
Related issues:
- Ambiguities in handling url() [css-images][css-masking][paint] Ambiguities in handling url() #383
- Consider ways to make the CORS limitation in CSS Shapes easier for authors [css-shapes] Consider ways to make the CORS limitation in CSS Shapes easier for authors #1481
But I couldn't find an issue or proposal specifically about allowing CORS upgrades to CSS asset fetches.
The is, in my opinion, a logical use of the url-modifier token that CSS Values 3 introduced into the url() function:
The url() function supports specifying additional s, which change the meaning or the interpretation of the URL somehow. A is either an or a functional notation.
This specification does not define any s, but other specs may do so.
I don't have opinions on syntax beyond that, except that the keywords should match the ones used in HTML.