Re: [csswg-drafts] [css-contain][css-sizing] Behavior of slightly offscreen content having `content-visibility:auto` and `contain-intrinsic-size` when UA margin around the viewport is 0 (#8407)

The CSS Working Group just discussed ``[css-contain][css-sizing] Behavior of slightly offscreen content having `content-visibility:auto` and `contain-intrinsic-size` when UA margin around the viewport is 0``, and agreed to the following:

* `RESOLVED: content-visibility: auto forces contain-intrinsic-size to gain an auto value, and we'll define that auto value for contain-intrinsic-size so it works with all the current values, and then make sure that the last remembered size is forgotten when contain-intrinsic-size changes (specifying where in rendering step it happens) so we can deal with the cases that Rob brought up.`

<details><summary>The full IRC log of that discussion</summary>
&lt;dbaron> jihye: This issue is related to `content-visibility: auto` and `contain-intrinsic-size`.<br>
&lt;dbaron> jihye: It's an edge case.  It's a problem for both Firefox and Chrome.<br>
&lt;dbaron> jihye: If the UA margin is set to 0, and the content is specified with `content-visibility: auto` and `contain-intrinsic-size`... if this content is slightly offscreen, as a result the content flashes.<br>
&lt;dbaron> jihye: I would like to have a resolution on 2 major questions:<br>
&lt;dbaron> jihye: 1. Is this kind of flashing reasonable... what is the expected result?  Flashing or stable?<br>
&lt;dbaron> jihye: 2. If the result should be stable, what is the final result that is shown?<br>
&lt;dbaron> jihye: My opinion is that for (1) the result should be a stable layout because I understand the purpose of `content-visibility: auto` with `contain-intrinsic-size` is to improve rendering performance, so this kind of flashing result decreases performance.  I think stable layout is better.<br>
&lt;oriol> q+<br>
&lt;dbaron> jihye: My opinion for (2) is that I want to pursue a way that improves rendering performance, so keeping the offscreen element offscreen would be a reasonable result, but I'm not sure how to define that.  So I discussed this the github issue with Oriol, and we discussed whether we can define a new description of "maybe relevant".  I'm not sure how to define this, need more opinions.<br>
&lt;TabAtkins> q+<br>
&lt;dbaron> Oriol: I agree we should try to achieve a stable layout... when setting content-visibility to auto we could say contain-intrinsic-size automatically gets the auto keyboard.   (missed)  So it would keep a stable size and stop flickering between two sizes.<br>
&lt;dbaron> Florian: I think it's a good solution, satisfies the expection that Jihye had.<br>
&lt;astearns> ack TabAtkins<br>
&lt;dbaron> TabAtkins: I support Oriol's proposal as well.<br>
&lt;emilio> q+<br>
&lt;dbaron> Oriol: Then there's a detail: the `auto` keyword of `contain-intrinsic-size` can only be mixed with lengths, but the initial value is `none`.  So we'd need to add the `auto none` combination.<br>
&lt;dbaron> TabAtkins: Want to look into the spec, but initially that sounds reasonable.<br>
&lt;astearns> ack emilio<br>
&lt;dbaron> emilio: 2 questions:  (1) In principle it doesn't seem useful to have it behave as non-`auto` (or `none auto`??)... but is there a use case that people may be using.  (2) Allowing `auto none` feels a bit odd but I guess it's all right?   If ??? then we wouldn't completely lose that length.<br>
&lt;dbaron> astearns: sounds like we would lose the length at computed or used value time<br>
&lt;dbaron> emilio: I'm a bit concerned about people using lengths.  IIRC, `auto` is supported along with lengths, so you can specify a length and remember a size as if it was laid out.<br>
&lt;dbaron> oriol: you can't specify `auto` alone, it's `auto` mixed with a length.<br>
&lt;dbaron> emilio: so if you specify `contain-intrinsic-size` and a pair of lengths, we'd turn it into `auto` and pair of lengths, but not just...<br>
&lt;dbaron> chrishtr: I think upgrading to `auto` with a length is better, that way author can provide placeholder sizing before first render.<br>
&lt;dbaron> emilio: They can do it manually if they don't specify `auto` and then we wouldn't touch it, but the idea is to do this automatically.<br>
&lt;dbaron> chrishtr: c-i-s: width height would be the same as c-i-s: auto width height.<br>
&lt;dbaron> emilio: Agree that's desired.<br>
&lt;dbaron> oriol: If author specified 10px 20px, it would become auto 10px 20px.<br>
&lt;dbaron> emilio: That seems worth clarifying before resolving, but SGTM.<br>
&lt;dbaron> astearns: So only in the case where it's set to `none` it would become `auto none`.<br>
&lt;dbaron> astearns: ... so that's why we need to add it to the grammar.<br>
&lt;dbaron> oriol: yes, we need to allow this combination so we can upgrade to it<br>
&lt;dbaron> emilio: behavior differences between none and 0?<br>
&lt;dbaron> oriol: mostly the same, but with grid-template properties or multicolumn they can differ<br>
&lt;dbaron> TabAtkins: there's a note in the spec where setting explicit intrinsic inner size can be different than having no(?) child<br>
&lt;dbaron> emilio: seems reasonable to allow auto mixed with none<br>
&lt;flackr> q+<br>
&lt;TabAtkins> s/no(?)/no or one/<br>
&lt;astearns> ack oriol<br>
&lt;dbaron> chrishtr: To other question:  I don't know of use cases for not having `auto`.  If we had it in original spec, we probably would have made it the default.<br>
&lt;dbaron> chrishtr: Want to point out possible web compat risk, not sure if it's a big deal.<br>
&lt;dbaron> emilio: I think as long as we don't suppress the author specified sizes if there are any, we should mostly be fine.<br>
&lt;dbaron> emilio: But I could imagine someone working around this weird behavior by expecting the items offscreen to collapse, and collapsing ...<br>
&lt;astearns> ack flackr<br>
&lt;dbaron> chrishtr: I think it's worth trying<br>
&lt;dbaron> flackr: I can think of a use case:  you're rotating your device, so you as an author know general shape of elements will be dramatically different from last remembered size... so might want to reset to contain-intrinsic-size rather than remembering the size in that case.<br>
&lt;dbaron> TabAtkins: That produces an observable difference-- that's the flicker case we're already trying to avoid?<br>
&lt;dbaron> flackr: Isn't flicker avoided by scroll anchoring?<br>
&lt;florian> q+<br>
&lt;dbaron> flackr: That is, isn't the flicker avoided by scroll anchoring keeping elements anchored to their position onscreen?<br>
&lt;dbaron> vmpstr: they are, but you can construct cases where it doesn't work like in the issue example<br>
&lt;dbaron> flackr: But if you can ? cases that are ? portrait-like or landscape-like, you can ???<br>
&lt;dbaron> vmpstr: Setting contain-intrinsic-size to new values should presumably (not sure) reset the last remembered size?<br>
&lt;dbaron> emilio?: I don't think it does.<br>
&lt;dbaron> ?: we should do that<br>
&lt;dbaron> flackr: That addresses my use case.<br>
&lt;florian> q-<br>
&lt;TabAtkins> "At the time that ResizeObserver events are determined and delivered, if an element has a last remembered size but does not have contain-intrinsic-size: auto, remove its last remembered size."<br>
&lt;dbaron> chrishtr: So if a style change occurs that changes value of contain-intrinsic-size it will blow away the last remembered size until it renders again?<br>
&lt;dbaron> flackr: SGTM<br>
&lt;chrishtr> sounds fine<br>
&lt;dbaron> emilio: I think that's reasonable but we need to define precisely when that forgetting happens.<br>
&lt;dbaron> emilio: I think we already had some interop issues there... Oriol can probably confirm.<br>
&lt;TabAtkins> We can definitely add to that condition to make it forget upon a value change, yeah.<br>
&lt;dbaron> astearns: sounds like we're coming to agreement, that the resolution should be that content-visibilty: auto forces contain-intrinsic-size to gain an auto value, and we'll define that auto value for contain-intrinsic-size so it works with all the current values, and then make sure that the last remembered size is updated in the right place so we can deal with the cases that Rob brought up.<br>
&lt;dbaron> chrishtr: sounds like everything to me<br>
&lt;dbaron> jihye: sounds good to me.<br>
&lt;dbaron> dbaron: (substitution of text)<br>
&lt;dbaron> chrishtr: and specify where in rendering step it occurs<br>
&lt;dbaron> RESOLVED: content-visibility: auto forces contain-intrinsic-size to gain an auto value, and we'll define that auto value for contain-intrinsic-size so it works with all the current values, and then make sure that the last remembered size is forgotten when contain-intrinsic-size changes (specifying where in rendering step it happens) so we can deal with the cases that Rob brought up.<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8407#issuecomment-1440466558 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 22 February 2023 17:25:35 UTC