W3C home > Mailing lists > Public > public-css-archive@w3.org > February 2019

Re: [csswg-drafts] [css-values] Define a crossorigin URL modifier (#1603)

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Mon, 25 Feb 2019 23:05:55 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-467221081-1551135954-sysbot+gh@w3.org>
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).`

<details><summary>The full IRC log of that discussion</summary>
&lt;presenter_> Topic: URL modifiers for image loading<br>
&lt;astearns> github: https://github.com/w3c/csswg-drafts/issues/1603<br>
&lt;presenter_> ScribeNick: presenter_<br>
&lt;presenter_> AmeliaBR: So there are several modifiers that exist in HTML image loading.<br>
&lt;presenter_> #1603 is crossorigin.<br>
&lt;presenter_> AmeliaBR: background-images don't need crossorigin info, so if it's the first thing it sees, browser fetches it without crossorigin.<br>
&lt;presenter_> AmeliaBR: If you then use it for something else that *does* care about CORS, browser has to fetch a second time.<br>
&lt;presenter_> AmeliaBR: Or it just gets reused and errors.<br>
&lt;presenter_> AmeliaBR: Both are suboptimal.<br>
&lt;presenter_> AmeliaBR: Can get around it today by adding a &lt;link rel=preload>, but then need to alter markup to adjust CSS.<br>
&lt;presenter_> AmeliaBR: So having a way to indicate in CSS that something should be requested with crossorigin permissions for later would be useful.<br>
&lt;fantasai> tantek: I agree completely with the use case and with the more gneral use case, that eveyrthing you can tweak about image loading in HTML shoudl be tweakable from CSS as well<br>
&lt;fremy> ScribeNick: presenter_<br>
&lt;fantasai> hober: I agree that CSS and HTML should match here.<br>
&lt;fantasai> hober: But both should be sitting on top of Fetch. Fetch should hav esome keywords, and we use those keywords<br>
&lt;presenter_> hober: I agree that CSS should match here, but both should be in Fetch and these should be based on this.<br>
&lt;presenter_> AmeliaBR: good point<br>
&lt;presenter_> AmeliaBR: I think all of these should be addressed together with a common syntax.<br>
&lt;hober> s/CSS should match/CSS should match HTML/<br>
&lt;presenter_> AmeliaBR: I don't know what's the nicest or more author-friendly syntax, but good to consider them all together, not piecewise.<br>
&lt;astearns> https://github.com/w3c/csswg-drafts/issues/2994<br>
&lt;astearns> https://github.com/w3c/csswg-drafts/issues/2095<br>
&lt;astearns> https://github.com/w3c/csswg-drafts/issues/3659<br>
&lt;presenter_> AmeliaBR: Other ones open are #2994 on preloading something, #2095 for async decoding, and #3650 for lazy loading<br>
&lt;presenter_> AmeliaBR: issues for async and lazyload is that browser defaults for CSS images are different from HTML content images.<br>
&lt;xfq> s/#3650/#3659/<br>
&lt;presenter_> AmeliaBR: Maybe can't copy html, need to think about what makes sense for CSS specifically<br>
&lt;presenter_> jensimmons: Yes, we need this. Proposal is to put the burden on authors to set this up correctly?<br>
&lt;presenter_> jensimmons: Authors already have a hard time on CORS compat.<br>
&lt;presenter_> jensimmons: Can we put the burden on the browser instead?<br>
&lt;presenter_> TabAtkins: I suspect not. These are all behavior changes, so changing defaults could break changes.<br>
&lt;presenter_> AmeliaBR: Also if browser has to consider all possible cases for how it'll request an image before it can send the request, it can get messy/slow, especially with dynamic loading<br>
&lt;presenter_> astearns: Yeah, browser might not know that a *future* load will need CORS, so there's no way for it to tell without a hint.<br>
&lt;presenter_> astearns: So on the align-with-fetch issue, does Fetch have keywords for all these topics we can follow?<br>
&lt;presenter_> emilio: Firefox already does async decoding on all images.<br>
&lt;presenter_> myles_: Really? We did that but had to roll it out.<br>
&lt;presenter_> emilio: We do it unless it's something our image library can tell is fast.<br>
&lt;presenter_> TabAtkins: Is ther an attribute for async decoding on &lt;img>? Not sure we should do anything img doesn't.<br>
&lt;bkardell_> proposed* I think<br>
&lt;presenter_> AmeliaBR: Yeah, there's a `decoding="auto|sync|async"` attribute proposal.<br>
&lt;chris> :)<br>
&lt;presenter_> emilio: What's the story with unknown url modifiers? Would be sad if you have to rewrite the url several times for different combos of browser support.<br>
&lt;presenter_> TabAtkins: Not defined right now. We should decide how we want to do error handling<br>
&lt;presenter_> myles_: We solved this for src() with forgiving handling, split on top-level commas and ignore unknown stuff.<br>
&lt;presenter_> astearns: Yeah, good to match.<br>
&lt;AmeliaBR> URL modifiers https://drafts.csswg.org/CSS-values/#url-modifiers<br>
&lt;presenter_> AmeliaBR: Reading the definition of url-modifier, it looks like they can't be used on unquoted urls or just-string urls. That means it needs to have a quoted string inside?<br>
&lt;presenter_> TabAtkins: Yes.<br>
&lt;presenter_> fremy: Edge currently ships with the quoted-url-as-function-token behavior.<br>
&lt;presenter_> emilio: Also Firefox.<br>
&lt;presenter_> astearns: So any objection to silently ignore unknown url-modifiers?<br>
&lt;presenter_> RESOLVED: Unknown &lt;url-modifier>s get silently ignored (rather than invalidating the function).<br>
&lt;presenter_> AmeliaBR: So I think the rest of the issue is, align CSS's image loading support with HTML's support, via url modifiers.<br>
&lt;presenter_> TabAtkins: Agreed.<br>
&lt;presenter_> &lt;br><br>

GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1603#issuecomment-467221081 using your GitHub account
Received on Monday, 25 February 2019 23:05:57 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:44 UTC