Open AmeliaBR opened 7 years ago
Related: #2994 on preload modifier and #2095 on async modifier. We should probably address them all at the same time to get consistent syntax and implementation guidelines.
The CSS Working Group just discussed URL modifiers for image loading
, and agreed to the following:
RESOLVED: Unknown <url-modifier>s get silently ignored (rather than invalidating the function).
cross-origin, preload and async would certainly be useful for downloaded webfonts, color profiles, etc as well as images. So doing this via <url-modifiers>
is the correct approach and would help with these issues as well:
https://github.com/w3c/csswg-drafts/issues/3659 https://github.com/w3c/csswg-drafts/issues/450 https://github.com/w3c/csswg-drafts/issues/3069 https://github.com/w3c/csswg-drafts/issues/297
The CSS Working Group just discussed Define crossorigin, preload and async URL modifiers
.
Also consider integrity
for SRI, see https://github.com/w3c/webappsec-subresource-integrity/issues/40 and https://github.com/w3c/webappsec/issues/306.
I was just reminded of this proposal when one of our engineers ran into a problem where they need to request background-image
URLs in CORS mode. @tabatkins, @fantasai, or @AmeliaBR (or anyone, really) could we get some draft text for this?
Is this issue stuck? AWS just confirmed this as a blocker in Amplify for both React and Vue... thus rendering these CSS features useless. What is the next step? What kind of support is needed to get this across the finish line?
I'm poking around at @import right now to get it defined on top of Fetch. Once I figure out all those details, I should be able to transfer the knowledge over to general url() usage, such that these parameters can be usefully defined.
I'm poking around at @import right now to get it defined on top of Fetch. Once I figure out all those details, I should be able to transfer the knowledge over to general url() usage, such that these parameters can be usefully defined.
I guess this is done now? :)
I think this is important. I'd be to make an initial PR.
I believe we should be careful with preload
- not sure if we want to make it so that CSS actively loads anything but imported stylesheets, when the DOM might not even have that image. The problem of unused preload is pretty common on the web, and this might make it worse.
Perhaps we can start with standard loading modifiers (crossorigin
and integrity
) and expand it to async
and perhaps preload
later?
Based on url-modifier
, suggesting it would look like:
background-image
: url('...' crossorigin(anonymous
) integrity(sha1-blabla01234) referrerpolicy(same-origin
))`
Lol this slipped thru my fingers.
I guess this is done now? :)
Well, you did it, so I didn't exactly gain the knowledge to transfer over to here. ^_^
Perhaps we can start with standard loading modifiers (crossorigin and integrity) and expand it to async and perhaps preload later?
Sounds reasonable.
Based on url-modifier, suggesting it would look like:
Yes, tho the integrity hash needs to be a string, not an ident. It comes from outside CSS so there's no guarantee it'll always stick to our ident syntax rules. The other two are good tho - technically those values don't come from CSS either, but they're a finite set so we can always give a different "CSS-compatible" keyword if necessary (tho that seems incredibly unlikely).
Lol this slipped thru my fingers.
I guess this is done now? :)
Well, you did it, so I didn't exactly gain the knowledge to transfer over to here. ^_^
Perhaps we can start with standard loading modifiers (crossorigin and integrity) and expand it to async and perhaps preload later?
Sounds reasonable.
Based on url-modifier, suggesting it would look like:
Yes, tho the integrity hash needs to be a string, not an ident. It comes from outside CSS so there's no guarantee it'll always stick to our ident syntax rules. The other two are good tho - technically those values don't come from CSS either, but they're a finite set so we can always give a different "CSS-compatible" keyword if necessary (tho that seems incredibly unlikely).
Sounds good! I started a PR: https://github.com/w3c/csswg-drafts/pull/8222 I can probably use some (a lot of) editorial help there but I've set the functional foundations.
4.5.3. URL Modifiers
[...] This specification does not define any
<url-modifier>
s, but other specs may do so. [...]4.5.5. Request URL Modifiers
The
<request-url-modifier>
s represent<url-modifier>
s that affect the resource’s request. [...]
Do you plan to edit 4.5.3 after handling async/preload or is it an oversight?
4.5.3. URL Modifiers [...] This specification does not define any
<url-modifier>
s, but other specs may do so. [...] 4.5.5. Request URL Modifiers The<request-url-modifier>
s represent<url-modifier>
s that affect the resource’s request. [...]Do you plan to edit 4.5.3 after handling async/preload or is it an oversight?
Oversight!
Agenda+ since we didn't actually get a resolution for adding these, hopefully this should just be a rubber-stamp on the existing work.
The CSS Working Group just discussed [css-values] Define crossorigin, preload and async URL modifiers
, and agreed to the following:
RESOLVED: Leave the values in Level 5
The HTML
img
element (and also preload links and other references to external files) take acrossorigin
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, andshape-outside
images) requirecrossorigin="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:
background-image
that is also used as ashape-outside
image for the same element<mask>
,<filter>
, or<clipPath>
effects for enhancing the final presentation of the element.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:
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 theurl()
function:I don't have opinions on syntax beyond that, except that the keywords should match the ones used in HTML.