- 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
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> <presenter_> Topic: URL modifiers for image loading<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/1603<br> <presenter_> ScribeNick: presenter_<br> <presenter_> AmeliaBR: So there are several modifiers that exist in HTML image loading.<br> <presenter_> #1603 is crossorigin.<br> <presenter_> AmeliaBR: background-images don't need crossorigin info, so if it's the first thing it sees, browser fetches it without crossorigin.<br> <presenter_> AmeliaBR: If you then use it for something else that *does* care about CORS, browser has to fetch a second time.<br> <presenter_> AmeliaBR: Or it just gets reused and errors.<br> <presenter_> AmeliaBR: Both are suboptimal.<br> <presenter_> AmeliaBR: Can get around it today by adding a <link rel=preload>, but then need to alter markup to adjust CSS.<br> <presenter_> AmeliaBR: So having a way to indicate in CSS that something should be requested with crossorigin permissions for later would be useful.<br> <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> <fremy> ScribeNick: presenter_<br> <fantasai> hober: I agree that CSS and HTML should match here.<br> <fantasai> hober: But both should be sitting on top of Fetch. Fetch should hav esome keywords, and we use those keywords<br> <presenter_> hober: I agree that CSS should match here, but both should be in Fetch and these should be based on this.<br> <presenter_> AmeliaBR: good point<br> <presenter_> AmeliaBR: I think all of these should be addressed together with a common syntax.<br> <hober> s/CSS should match/CSS should match HTML/<br> <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> <astearns> https://github.com/w3c/csswg-drafts/issues/2994<br> <astearns> https://github.com/w3c/csswg-drafts/issues/2095<br> <astearns> https://github.com/w3c/csswg-drafts/issues/3659<br> <presenter_> AmeliaBR: Other ones open are #2994 on preloading something, #2095 for async decoding, and #3650 for lazy loading<br> <presenter_> AmeliaBR: issues for async and lazyload is that browser defaults for CSS images are different from HTML content images.<br> <xfq> s/#3650/#3659/<br> <presenter_> AmeliaBR: Maybe can't copy html, need to think about what makes sense for CSS specifically<br> <presenter_> jensimmons: Yes, we need this. Proposal is to put the burden on authors to set this up correctly?<br> <presenter_> jensimmons: Authors already have a hard time on CORS compat.<br> <presenter_> jensimmons: Can we put the burden on the browser instead?<br> <presenter_> TabAtkins: I suspect not. These are all behavior changes, so changing defaults could break changes.<br> <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> <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> <presenter_> astearns: So on the align-with-fetch issue, does Fetch have keywords for all these topics we can follow?<br> <presenter_> emilio: Firefox already does async decoding on all images.<br> <presenter_> myles_: Really? We did that but had to roll it out.<br> <presenter_> emilio: We do it unless it's something our image library can tell is fast.<br> <presenter_> TabAtkins: Is ther an attribute for async decoding on <img>? Not sure we should do anything img doesn't.<br> <bkardell_> proposed* I think<br> <presenter_> AmeliaBR: Yeah, there's a `decoding="auto|sync|async"` attribute proposal.<br> <chris> :)<br> <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> <presenter_> TabAtkins: Not defined right now. We should decide how we want to do error handling<br> <presenter_> myles_: We solved this for src() with forgiving handling, split on top-level commas and ignore unknown stuff.<br> <presenter_> astearns: Yeah, good to match.<br> <AmeliaBR> URL modifiers https://drafts.csswg.org/CSS-values/#url-modifiers<br> <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> <presenter_> TabAtkins: Yes.<br> <presenter_> fremy: Edge currently ships with the quoted-url-as-function-token behavior.<br> <presenter_> emilio: Also Firefox.<br> <presenter_> astearns: So any objection to silently ignore unknown url-modifiers?<br> <presenter_> RESOLVED: Unknown <url-modifier>s get silently ignored (rather than invalidating the function).<br> <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> <presenter_> TabAtkins: Agreed.<br> <presenter_> <br><br> </details> -- 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