-
Notifications
You must be signed in to change notification settings - Fork 715
[CSS-images] Specify fallback behavior when replaced or background image content not available #1984
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
See “invalid image” in https://drafts.csswg.org/css-images-3/#image-values which is the spec prose that's currently active (no one implements |
Yeah, I think "invalid image" should cover the loading case as well. |
For content images, at least, browsers treat loading images (blank space or partial image render) differently from invalid images (broken-image icon). Not sure whether its worthwhile to have a similar distinction for CSS images. It might be worth testing to see what browsers currently do. |
Yeah, letting the UA discriminate between those cases when doing its ultimate fallback seems fine, and will just need some extra prose. But it would be good, I think, to let ( |
OK, we've defined “loading image” as a term somewhat distinct from “invalid image”, see changes at: 846d21d Agenda+ for CSSWG review. |
…mage() aware of it. Properly specify behavior of image() when it contains only a URL, and that URL is invalid/loading. #1984
The CSS Working Group just discussed The full IRC log of that discussion<dael> Topic: Specify fallback behavior when replaced or background image content not available<dael> github: https://github.com//issues/1984 <fantasai> Changeset https://github.com/w3c/csswg-drafts/commit/846d21d922fa4a47abea7be3ab57bcf3ebf62395 <dael> TabAtkins: Request for review b/c change to CR Images 3. Chris__ pointed out innvalid counts things not finished same as fails. Doing fallback based on invalid images would treat them the same and this doesn't seem desirable. Shouldn't fallback to a second image if the image hasn't finished loading. <dael> TabAtkins: Separated the concepts and you're allowed to be smarter in certain specific ways. Image functio will be different on how we do fallback <dael> TabAtkins: Making sure this is okay and wording looks good <dael> AmeliaBR: Loading image state that includes images that are lazy load that hasn't started loading? <dael> TabAtkins: Yeah <dael> Rossen_: Anything else besides a call to action? <dael> TabAtkins: We'll need resolution. We can ask next week if want time to review. Else can resolve now <dael> Rossen_: Do people feel this is trivial enough to resolve? <dael> myles: We did a bunch on async image decoding last year. In cases when script involved it changed css and html attributes dynamically. As script changes from one image to another the interstitial state mattered. THis is tricky to get right. I should take this to our team and make sure it matches our research <dael> TabAtkins: Okay. <dael> AmeliaBR: Good point. Might need explicit call out. An image that previously allowed an image but is now loading new data <AmeliaBR> s/allowed/loaded/ <dael> TabAtkins: You're right. We should call that out. We should call out an image being replaced as a sub category of loading image. <dael> smfr: I would like clarification on the loading case; it says may trigger fallback rendering in contexts that offer it. Is it a may in UA may and what are the contexts? <dael> TabAtkins: Accidental may. Contexts are none right now. Image function will once it's defined. <dael> fantasai: It isn't. While an image loading you may trigger fallback but you don't have to. You may want a loading image icon. B/c not broken we wanted to let UA decide correct thing, fallback or loading indication. That's why next sentence is must <dael> fantasai: We made a distinction there. One is required, one optional <dael> TabAtkins: Makes sense <tantek> wait am I missing something? I thought some browsers rendered the alt text before an image was downloaded <dael> TabAtkins: I think we should take myles's edits and then bring back to list. Let myles review and try and resolve next week <tantek> and thought that was specified in the HTML spec <fantasai> that's a fallback rendering, technically :) <tantek> agreed <dael> Rossen_: Next week we'll review again. Next week as APAC time, a reminder. <tantek> however the issue didn't mention alt text so I'm confused |
jonathanKingston/css-fetch-integration#1 seems relevant when it comes to defining how images are loaded. |
The CSS Working Group just discussed The full IRC log of that discussion<dael> Topic: Specify fallback behavior when replaced or background image content not available<dael> github: https://github.com//issues/1984 <dael> astearns: TabAtkins added but he's IRC only <dael> fantasai: Have some discussion from last week <dael> fantasai: Wanted to get WG review I believe. Then we were supposed to make edits <dael> astearns: Needs edits tag was removed <dael> fantasai: I'll fix that <dael> astearns: Maybe were edits...There is a PR <astearns> https://github.com/w3c/csswg-drafts/commit/73d7635574d54f5afb154b5bcf24a2fc086e2093 <dael> AmeliaBR: There were edits 3 weeks ago discussed last week. nothign since last week |
The CSS Working Group just discussed The full IRC log of that discussion<dael> Topic: Specify fallback behavior when replaced or background image content not available<dael> github: https://github.com//issues/1984 <jensimmons> there might be clarifications needed about wavy and double lines…. https://github.com//issues/4134 fantasai was tasked with working on the spec. <TabAtkins> https://github.com/w3c/csswg-drafts/commit/3f884b87c54b38afd7742fb8e123a7d27ddd3ac4 <dael> TabAtkins: When we spoke last time waiting on Apple; myles wanted to review. fantasai committed text for replaced image. Want to ensure spec did not rule out leaving image in place while waiting for new image <fantasai> jensimmons, for the record, I think what I was actioned to write was that the line thickness, amplitude, and frequency should scale together (not necessarily strictly proportionally, but roughly proportionally), and double simlar to border-width: double in the same way <dael> TabAtkins: If Apple wants to review that's fine but want to do soonish <dael> myles: Can I give myself an end of week deadline? <dael> TabAtkins: Next call is fine. <dael> Rossen_: Next week's call is fine. TabAtkins anything else on this? <dael> TabAtkins: It's good |
The current text looks fine. |
The CSS Working Group just discussed
The full IRC log of that discussion<dael> Topic: Specify fallback behavior when replaced or background image content not available<dael> github: https://github.com//issues/1984 <dael> fantasai: Just waiting on myles to review <dael> myles: I did review and commented on issue <dael> Rossen_: Said it looks fine <dael> Rossen_: Let's try and resolve. Any additional comments or concerns? Anyone need summary before we resolve? <dael> Rossen_: I'll take silence as a no. <dael> TabAtkins: Prop: Accept edits to images spec about specifying behavior of not yet loaded images [missed] <TabAtkins> I'm on mobile, not wifi, wtffffff <dael> fantasai: Prop: Specify what's happening when you're loading image and add text explaining what you do while it's loading <fantasai> https://drafts.csswg.org/css-images-3/#image-values <dael> fantasai: Added a section for what it means for an image to be in process of loading and what you're supposed to do ^ <dael> fantasai: [reads] <chris> That wording on loading images sounds great to me! <AmeliaBR> 👍 <dael> Rossen_: For those hearing this for the first time, any questions or comments? <dael> chris: sgtm. It covers and don't need anything else <dael> Rossen_: Prop: Loading images are not invalid but treated similarly as explained in https://drafts.csswg.org/css-images-3/#image-values <dael> Rossen_: Fair summary? <dael> fantasai: Yes <dael> Rossen_: Comments or objections? <dael> RESOLVED: Loading images are not invalid but treated similarly as explained in https://drafts.csswg.org/css-images-3/#image-values <fantasai> https://drafts.csswg.org/issues?spec=css-images-3&doc=cr-2012 |
There appears to be no spec language for what paints to the screen when the replaced content
of an
<img>
or CSS backgroud image is not available at paint time, either due to being in processof being loaded, or due to an async decode.
Image fallbacks appear to be (partially?) specified in the presence of the image() function as part of
css images level 4. https://www.w3.org/TR/css-images-4/#image-fallbacks. This needs to be
extended more generally.
I think the best behavior is to fall back to whatever content painted underneath the paint phase that
would have drawn the image. e.g. if step 1.2. or step 7.1 of the algorithm below had no image content,
still paint but just skip those steps.
https://www.w3.org/TR/CSS2/zindex.html
See also whatwg/html#1920
@vmpstr @tabatkins
The text was updated successfully, but these errors were encountered: