[CSS-images] Specify fallback behavior when replaced or background image content not available

[chrishtr]

There appears to be no spec language for what paints to the screen when the replaced content
of an or CSS backgroud image is not available at paint time, either due to being in process
of 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

[fantasai]

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 image() yet). I suppose we can extend the wording to include images that have not yet loaded.

[tabatkins]

Yeah, I think "invalid image" should cover the loading case as well.

[AmeliaBR]

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.

[tabatkins]

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 image() fallback handle loading images as well.

(image() will need to discriminate here, too - we don't want a loading fallback to fall back to another URL! Basically, if it's currently depending on a loading image, it should skip all further images that require loading, and fall back all the way to a CSS-generated image or color.)

[fantasai]

OK, we've defined “loading image” as a term somewhat distinct from “invalid image”, see changes at: 846d21d

Agenda+ for CSSWG review.

[css-meeting-bot]

The CSS Working Group just discussed Specify fallback behavior when replaced or background image content not available.

The full IRC log of that discussion

Topic: Specify fallback behavior when replaced or background image content not available
github: https://github.com//issues/1984
Changeset https://github.com/w3c/csswg-drafts/commit/846d21d922fa4a47abea7be3ab57bcf3ebf62395
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.
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
TabAtkins: Making sure this is okay and wording looks good
AmeliaBR: Loading image state that includes images that are lazy load that hasn't started loading?
TabAtkins: Yeah
Rossen_: Anything else besides a call to action?
TabAtkins: We'll need resolution. We can ask next week if want time to review. Else can resolve now
Rossen_: Do people feel this is trivial enough to resolve?
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
TabAtkins: Okay.
AmeliaBR: Good point. Might need explicit call out. An image that previously allowed an image but is now loading new data
s/allowed/loaded/
TabAtkins: You're right. We should call that out. We should call out an image being replaced as a sub category of loading image.
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?
TabAtkins: Accidental may. Contexts are none right now. Image function will once it's defined.
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
fantasai: We made a distinction there. One is required, one optional
TabAtkins: Makes sense
wait am I missing something? I thought some browsers rendered the alt text before an image was downloaded
TabAtkins: I think we should take myles's edits and then bring back to list. Let myles review and try and resolve next week
and thought that was specified in the HTML spec
that's a fallback rendering, technically :)
agreed
Rossen_: Next week we'll review again. Next week as APAC time, a reminder.
however the issue didn't mention alt text so I'm confused

[henke37]

jonathanKingston/css-fetch-integration#1 seems relevant when it comes to defining how images are loaded.

[css-meeting-bot]

The CSS Working Group just discussed Specify fallback behavior when replaced or background image content not available.

The full IRC log of that discussion

Topic: Specify fallback behavior when replaced or background image content not available
github: https://github.com//issues/1984
astearns: TabAtkins added but he's IRC only
fantasai: Have some discussion from last week
fantasai: Wanted to get WG review I believe. Then we were supposed to make edits
astearns: Needs edits tag was removed
fantasai: I'll fix that
astearns: Maybe were edits...There is a PR
https://github.com/w3c/csswg-drafts/commit/73d7635574d54f5afb154b5bcf24a2fc086e2093
AmeliaBR: There were edits 3 weeks ago discussed last week. nothign since last week

[css-meeting-bot]

The CSS Working Group just discussed Specify fallback behavior when replaced or background image content not available.

The full IRC log of that discussion

Topic: Specify fallback behavior when replaced or background image content not available
github: https://github.com//issues/1984
there might be clarifications needed about wavy and double lines…. https://github.com//issues/4134 fantasai was tasked with working on the spec.
https://github.com/w3c/csswg-drafts/commit/3f884b87c54b38afd7742fb8e123a7d27ddd3ac4
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
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
TabAtkins: If Apple wants to review that's fine but want to do soonish
myles: Can I give myself an end of week deadline?
TabAtkins: Next call is fine.
Rossen_: Next week's call is fine. TabAtkins anything else on this?
TabAtkins: It's good

[litherum]

The current text looks fine.

[emilio]

FWIW we have some edge cases in this area that would be nice to clarify, including #218 / #2831, where there's no interop in sight, but they may not be in scope of this issue.

[css-meeting-bot]

The CSS Working Group just discussed Specify fallback behavior when replaced or background image content not available, and agreed to the following:

• RESOLVED: Loading images are not invalid but treated similarly as explained in https://drafts.csswg.org/css-images-3/#image-values

The full IRC log of that discussion

Topic: Specify fallback behavior when replaced or background image content not available
github: https://github.com//issues/1984
fantasai: Just waiting on myles to review
myles: I did review and commented on issue
Rossen_: Said it looks fine
Rossen_: Let's try and resolve. Any additional comments or concerns? Anyone need summary before we resolve?
Rossen_: I'll take silence as a no.
TabAtkins: Prop: Accept edits to images spec about specifying behavior of not yet loaded images [missed]
I'm on mobile, not wifi, wtffffff
fantasai: Prop: Specify what's happening when you're loading image and add text explaining what you do while it's loading
https://drafts.csswg.org/css-images-3/#image-values
fantasai: Added a section for what it means for an image to be in process of loading and what you're supposed to do ^
fantasai: [reads]
That wording on loading images sounds great to me!
👍
Rossen_: For those hearing this for the first time, any questions or comments?
chris: sgtm. It covers and don't need anything else
Rossen_: Prop: Loading images are not invalid but treated similarly as explained in https://drafts.csswg.org/css-images-3/#image-values
Rossen_: Fair summary?
fantasai: Yes
Rossen_: Comments or objections?
RESOLVED: Loading images are not invalid but treated similarly as explained in https://drafts.csswg.org/css-images-3/#image-values
https://drafts.csswg.org/issues?spec=css-images-3&doc=cr-2012