[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

jihyerish · 2023-02-07T05:13:25Z

In the description about the element being relevant,
there is the recommended UA margin around the viewport to use for deciding whether the element is on-screen or not.

NOTE: This margin is meant to allow the user agent to begin preparing for an element to be in the viewport soon. A margin of 50% is suggested as a reasonable default.

But if the margin is set to 0% and the content having content-visibility:auto is slightly offscreen,
then the content looks flashing.

Here is the test code shows the behavior above:

Sample code (Live demo)

...
<style>
.outer {
    position: absolute;
    left: -1px;
    background: black;
    padding-right: 10px;
    padding-bottom: 10px;
}

.inner {
    content-visibility: auto;
    contain-intrinsic-size: 50px 50px;
    background: red;
}
</style>

<div class="outer">
  <div class="inner" id="target">  
  </div>
</div>

...

This happens because when IntersectionObserver for content-visibility triggers, the content isn't considered relevant at first. Then contain-intrinsic-size applies to the content and it makes the element relevant to the user.
Thus becoming relevant to the user, the content has its size as 0x0 again.
This causes the content not to be considered relevant again and continues the loop, and as a result, it looks like the content is flashing.

When I check this case for both chrome and firefox after setting the UA margin as 0,
the results are the same. The content is flashing.

NOTE: How to modify UA margin 0

Chromium:

change kViewportMarginPercentage value as 0 in "third_party/blink/renderer/core/display_lock/display_lock_document_state.h"

Gecko:

go to "about:config" in firefox

change layout.css.content-visibility-relevant-content-margin value as 0

I guess the expected result of this case is that the content shows a stable layout (without flashing).
But maybe what happens now is the reasonable result.
What would be the appropriate behavior for this?

CC @vmpstr

(This is related to gecko bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1804761)

The text was updated successfully, but these errors were encountered:

Loirooriol · 2023-02-07T15:34:34Z

(Do not open if you are in risk of epileptic seizures) Simpler testcase, doesn't require changing kViewportMarginPercentage nor layout.css.content-visibility-relevant-content-margin:

<!DOCTYPE html>
<style>
body {
  position: absolute;
  left: -200vmax;
  content-visibility: auto;
  contain-intrinsic-size: 1000vmax 1000vmax;
  background: red;
}
</style>

jihyerish · 2023-02-10T07:00:53Z

There are several topics to discuss in this issue

(1) Does the result of this issue show a stable layout?

If the result of this layout is stable,
(2) What is the rendered result? (What is the final state of the content? relevant or not-relevant?)
(3) Which process makes the stable rendered result?

Here is my opinion about the topics above.
(1): YES. The expected result is a stable layout.
I understand that the purpose of using content-visibility: auto with contain-intrinsic-size is to improve rendering performance.
But if the result of this issue is decided to unstable layout, it is against the purpose of those properties

(2): Not-relevant
In this case, the element is positioned offscreen intentionally (with left).
This means, the author of this code may want to make the content not-relevant and that's why positioning the element as it is.

(3): Consider the relevancy of the element by intended or unintended visibility change
"intended or unintended visibility change" may be ambiguous.
Let's say, the intended visibility change is changing the visibility of the element within the viewport triggered by scrolling, moving focus, and animation effect.
And the visibility change triggered by applying contain-intrinsic-size is an unintended visibility change.

Therefore, the examples in this issue are unintended visibility change and the content is considered as not-relevant.

Loirooriol · 2023-02-10T15:50:40Z

I'd also prefer a stable layout.
I'm not sure what you mean with "not-relevant", I think it would make more sense to not skip its contents (as if relevant) so that it stays off-screen (as if not relevant). Testcase

<!DOCTYPE html>
<style>
body {
  height: 500vh;
}
div {
  width: 500px;
  position: absolute;
  content-visibility: auto;
  contain-intrinsic-height: 1000vmax;
  background: red;
}
</style>
<div>Scroll down</div>
<p style="width: min-content; padding-top: 2em;">
   Lorem ipsum dolor sit amet consectetur adipiscing elit sed do eiusmod tempor incididunt ut labore et dolore magna aliqua rutrum quisque non tellus orci ac id aliquet lectus proin nibh nisl condimentum id eu volutpat odio facilisis mauris sit amet est placerat in egestas erat pulvinar pellentesque habitant morbi tristique senectus et netus pellentesque nec nam aliquam sem et tortor consequat viverra tellus in hac habitasse platea dictumst vestibulum mattis aliquam faucibus purus in massa tempor nec feugiat amet mattis vulputate enim nulla aliquet porttitor lacus sem et tortor consequat id porta nibh venenatis cras lobortis feugiat vivamus at augue eget arcu dictum varius sem nulla pharetra diam sit amet nisl suscipit adipiscing bibendum tincidunt ornare massa eget egestas purus viverra accumsan in nisl luctus venenatis lectus magna fringilla elementum nisi quis eleifend quam adipiscing vitae proin sagittis aliquam ut porttitor leo a diam sed augue lacus viverra vitae congue eu consequat ac massa tempor nec feugiat nisl pretium fusce id velit at risus viverra adipiscing at in tellus integer feugiat et tortor consequat id porta nibh venenatis cras sed felis porttitor lacus luctus accumsan tortor posuere ac ut malesuada bibendum arcu vitae elementum curabitur vitae libero enim sed faucibus turpis in eu aliquet lectus proin nibh nisl condimentum pellentesque dignissim enim sit amet venenatis urna non diam phasellus vestibulum lorem sed tellus integer feugiat scelerisque varius morbi enim nunc faucibus sagittis purus sit amet volutpat consequat mauris nunc congue enim diam vulputate ut pharetra sit ornare arcu dui vivamus arcu felis bibendum ut tristique enim facilisis gravida neque convallis a cras semper auctor neque ullamcorper morbi tincidunt ornare massa luctus accumsan tortor posuere ac ut consequat semper viverra non odio euismod lacinia at quis in mollis nunc sed id semper risus in hendrerit facilisis magna etiam tempor orci eu sapien eget mi proin sed libero enim sed faucibus turpis eu turpis egestas pretium aenean pharetra nisl pretium fusce id velit ut mauris vitae ultricies leo integer malesuada nunc felis bibendum ut tristique et egestas quis ipsum suspendisse ultrices nulla posuere sollicitudin aliquam ultrices eleifend quam adipiscing vitae proin sagittis nisl rhoncus mattis lacus viverra vitae congue eu malesuada fames ac turpis egestas sed tempus urna et pharetra risus quis varius quam quisque id dictum varius duis at consectetur lorem turpis egestas integer eget aliquet nibh praesent tristique magna tempor id eu nisl nunc mi ipsum faucibus vitae aliquet sit amet luctus venenatis lectus magna fringilla urna porttitor rhoncus rhoncus aenean vel elit scelerisque mauris pellentesque rhoncus est pellentesque elit ullamcorper dignissim sed vulputate odio ut enim blandit volutpat urna nec tincidunt praesent semper lacus suspendisse faucibus interdum posuere lorem urna neque viverra justo nec ultrices dui sapien eget est placerat in egestas erat imperdiet sed nec ultrices dui sapien eget mi odio morbi quis commodo odio nibh mauris cursus mattis molestie a iaculis at erat cursus turpis massa tincidunt dui ut ornare lectus sit viverra orci sagittis eu volutpat morbi tempus iaculis urna id volutpat lacus senectus et netus et malesuada fames ac turpis volutpat consequat mauris nunc congue nisi curabitur vitae nunc sed velit dignissim nisl rhoncus mattis rhoncus urna neque viverra hac habitasse platea dictumst vestibulum rhoncus est pellentesque egestas sed tempus urna et pharetra pharetra massa massa commodo elit at imperdiet dui accumsan sit amet nulla facilisi erat nam at lectus urna duis convallis condimentum mattis pellentesque id nibh.
</p>

I think it would be unexpected if you start scrolling down, the red box initially disappears, but then when it reached the margin for being considered not relevant, it suddenly becomes visible due to size containment.

So I think elements could be classified as "not relevant" or "maybe relevant". Only the "not relevant" case would skip contents with content-visibility: auto. Elements with this circularity would be "maybe relevant".

jihyerish · 2023-02-13T02:11:07Z

I'm not sure what you mean with "not-relevant", I think it would make more sense to not skip its contents (as if relevant) so that it stays off-screen (as if not relevant)

I meant "not-relevant" as the opposite of "relevant", which means skipping its contents

Testcase

This is a nice example to think about 👍
Yes, in this case, not skipping the element having content-visibility: auto and contain-intrinsic-height (considering it as relevant) is clearly proper.

I want to pursue a way that improves rendering performance.
So I agree with keeping the offscreen elements as offscreen (skipped content).

But I'm not sure about classifying this circularity element as "maybe relevant", because the element will stay as offscreen always.
The user cannot see it, so it always won't be relevant to the user. (If we interpret "relevant to user" as "user can interact with this element")

Therefore, I'm curious about what will be the appropriate description to process the circularity element in terms of the spec:

maybe relevant (maybe not skipped element), so contain-intrinsic-size won't be applied
not relevant (skipped element), but contain-intrinsic-size won't be applied

Loirooriol · 2023-02-13T05:45:31Z

A simpler solution may be saying that content-visibility: auto forces contain-intrinsic-size to gain the auto value at computed or used value time. I actually can't imagine why someone would want to use content-visibility: auto without contain-intrinsic-size having auto.

But there is the case of contain-intrinsic-size: none. Circularities typically occur when contain-intrinsic-size is set to a big length, but can also happen with none: testcase. So we would need to add auto none (#7737), or turn it into auto 0px.

css-meeting-bot · 2023-02-22T17:25:31Z

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.

The full IRC log of that discussion

<dbaron> jihye: This issue is related to `content-visibility: auto` and `contain-intrinsic-size`.
<dbaron> jihye: It's an edge case. It's a problem for both Firefox and Chrome.
<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.
<dbaron> jihye: I would like to have a resolution on 2 major questions:
<dbaron> jihye: 1. Is this kind of flashing reasonable... what is the expected result? Flashing or stable?
<dbaron> jihye: 2. If the result should be stable, what is the final result that is shown?
<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.
<oriol> q+
<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.
<TabAtkins> q+
<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.
<dbaron> Florian: I think it's a good solution, satisfies the expection that Jihye had.
<astearns> ack TabAtkins
<dbaron> TabAtkins: I support Oriol's proposal as well.
<emilio> q+
<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.
<dbaron> TabAtkins: Want to look into the spec, but initially that sounds reasonable.
<astearns> ack emilio
<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.
<dbaron> astearns: sounds like we would lose the length at computed or used value time
<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.
<dbaron> oriol: you can't specify `auto` alone, it's `auto` mixed with a length.
<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...
<dbaron> chrishtr: I think upgrading to `auto` with a length is better, that way author can provide placeholder sizing before first render.
<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.
<dbaron> chrishtr: c-i-s: width height would be the same as c-i-s: auto width height.
<dbaron> emilio: Agree that's desired.
<dbaron> oriol: If author specified 10px 20px, it would become auto 10px 20px.
<dbaron> emilio: That seems worth clarifying before resolving, but SGTM.
<dbaron> astearns: So only in the case where it's set to `none` it would become `auto none`.
<dbaron> astearns: ... so that's why we need to add it to the grammar.
<dbaron> oriol: yes, we need to allow this combination so we can upgrade to it
<dbaron> emilio: behavior differences between none and 0?
<dbaron> oriol: mostly the same, but with grid-template properties or multicolumn they can differ
<dbaron> TabAtkins: there's a note in the spec where setting explicit intrinsic inner size can be different than having no(?) child
<dbaron> emilio: seems reasonable to allow auto mixed with none
<flackr> q+
<TabAtkins> s/no(?)/no or one/
<astearns> ack oriol
<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.
<dbaron> chrishtr: Want to point out possible web compat risk, not sure if it's a big deal.
<dbaron> emilio: I think as long as we don't suppress the author specified sizes if there are any, we should mostly be fine.
<dbaron> emilio: But I could imagine someone working around this weird behavior by expecting the items offscreen to collapse, and collapsing ...
<astearns> ack flackr
<dbaron> chrishtr: I think it's worth trying
<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.
<dbaron> TabAtkins: That produces an observable difference-- that's the flicker case we're already trying to avoid?
<dbaron> flackr: Isn't flicker avoided by scroll anchoring?
<florian> q+
<dbaron> flackr: That is, isn't the flicker avoided by scroll anchoring keeping elements anchored to their position onscreen?
<dbaron> vmpstr: they are, but you can construct cases where it doesn't work like in the issue example
<dbaron> flackr: But if you can ? cases that are ? portrait-like or landscape-like, you can ???
<dbaron> vmpstr: Setting contain-intrinsic-size to new values should presumably (not sure) reset the last remembered size?
<dbaron> emilio?: I don't think it does.
<dbaron> ?: we should do that
<dbaron> flackr: That addresses my use case.
<florian> q-
<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."
<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?
<dbaron> flackr: SGTM
<chrishtr> sounds fine
<dbaron> emilio: I think that's reasonable but we need to define precisely when that forgetting happens.
<dbaron> emilio: I think we already had some interop issues there... Oriol can probably confirm.
<TabAtkins> We can definitely add to that condition to make it forget upon a value change, yeah.
<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.
<dbaron> chrishtr: sounds like everything to me
<dbaron> jihye: sounds good to me.
<dbaron> dbaron: (substitution of text)
<dbaron> chrishtr: and specify where in rendering step it occurs
<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.

Loirooriol · 2023-02-22T19:21:54Z

I had to drop before the end of the discussion, but I don't think @flackr's use case is particularly concerning: if you rotate your device, and then this makes the element with content-visibility: auto become visible, then it will stop skipping its contents and it will remember the new size. If it stays off-screen then it will keep the old size, which may not be the right one in the current orientation, but the user doesn't see it and if it ever becomes visible again it will get the right size. The only problem could be that when 1px becomes visible, the new size can be bigger and then for the user it may be a sudden apparition of e.g. 100px. But this is mitigated when the implementation uses a margin: https://drafts.csswg.org/css-contain/#relevant-to-the-user

The element is "on-screen": its paint containment box's overflow clip edge intersects with the viewport, or a user-agent defined margin around the viewport.
Note: This margin is meant to allow the user agent to begin preparing for an element to be in the viewport soon. A margin of 50% is suggested as a reasonable default.

emilio · 2023-04-05T00:11:43Z

Should this check happen at computed value time or used value time? Computed seems a bit easier to implement, if we don't expect contain-intrinsic-size to introduce dependencies on other properties, probably... @vmpstr does chromium have any preference here?

vmpstr · 2023-04-05T01:28:57Z

I kind of think that used value is actually a little easier to deal with. I'm not sure what's meant to happen if there's a developer style that says something like content-visibility: auto; contain-intrinsic-size: none !important. I assume the language that says c-v auto forces c-i-s auto supersedes any other style interaction, which is why at used value time we can just check either one of those.

But computed style time would also work. In Blink, we just have to be careful about the ordering: first we need to adjust to have c-i-s auto and then do all the required work to deal with c-i-s auto

I guess I'm saying I have no strong preference, so if computed is easier for Gecko, then we can go with that

flackr · 2023-04-05T05:12:02Z

I had to drop before the end of the discussion, but I don't think @flackr's use case is particularly concerning: if you rotate your device, and then this makes the element with content-visibility: auto become visible, then it will stop skipping its contents and it will remember the new size. If it stays off-screen then it will keep the old size, which may not be the right one in the current orientation

If the contain-intrinsic size changed it is very likely that the layout has changed in a way that affects the size of the item. If we assume the remembered size is almost certainly wrong then it seems pointless to remember it over resetting everything to a uniform size - the newly specified contain intrinsic size - which is likely to be a better guess for the size.

but the user doesn't see it and if it ever becomes visible again it will get the right size. The only problem could be that when 1px becomes visible, the new size can be bigger and then for the user it may be a sudden apparition of e.g. 100px.

I disagree that this is the only problem. Having vastly different sizes leads to large adjustments in scroll size and position which makes things strange for users dragging scrollbars.

vmpstr · 2023-05-29T18:42:27Z

Agenda+ to answer Emilio's question #8407 (comment) -- Should the check for content-visibility: auto and contain-intrinsic-size interaction happen at computed value time or used value time?

We think computed value time is fine, but wanted to make sure the group thinks so too.

khushalsagar · 2023-07-11T17:41:52Z

Setting the computed value to auto + whatever was the result of the style cascade makes sense. To be precise, this is based on the computed value for content-visibility.

khushalsagar · 2023-07-12T15:29:49Z

The use-case @flackr brought up above sounds reasonable in principle. I'm trying to think through whether it can create the same situation that this issue is trying to address : a circularity where applying the length specified in contain-intrinsic-size causes the element to repeatedly toggle between relevant to the user and not. The author could inadvertently change the style in one of the callbacks dispatched during the rendering update in such a way. But that seems like a bug that the author would be able to detect and fix, and not being able to trivially reset the size for cases like rotation seems worse.

css-meeting-bot · 2023-07-12T16:16:16Z

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: The check mentioned by Vlad occurs at computed-value time

The full IRC log of that discussion

<astearns> https://github.com//issues/8407#issuecomment-1567418798
<fantasai> TabAtkins: We think computed value time is fine, but wanted to check with other people
<TabAtkins> TabAtkins: Spec is already edited, remaining quesiton is just about the timing of the check.
<TabAtkins> emilio: Only concern about computed value time is if we expect the c-i-s value to gain more dependencies
<TabAtkins> emilio: But i think that's unlikely, and computed value is generally easier to deal with, cheaper
<khush> +1 to computed value
<TabAtkins> TabAtkins: so proposed reoslution is that the timing of the check occurs at computed-value time
<TabAtkins> astearns: objections?
<TabAtkins> RESOLVED: The check mentioned by Vlad occurs at computed-value time

This patch implements a resolution on w3c/csswg-drafts#8407 (comment) With a follow-up resolution that this should happen at computed value time (same issue). I2P&S is here: https://groups.google.com/a/chromium.org/g/blink-dev/c/aYpmS8hP2UQ/m/CO4wGRiYCQAJ Note that the current implementation sets this behind an experimental flag, pending I2S approval. R=andruud@chromium.org Bug: 1418453 Change-Id: I06ad14460c1e620b3f35937d09a3317c563905e0

This patch implements a resolution on w3c/csswg-drafts#8407 (comment) With a follow-up resolution that this should happen at computed value time (same issue). I2P&S is here: https://groups.google.com/a/chromium.org/g/blink-dev/c/aYpmS8hP2UQ/m/CO4wGRiYCQAJ Note that the current implementation sets this behind an experimental flag, pending I2S approval. R=andruud@chromium.org Bug: 1418453 Change-Id: I06ad14460c1e620b3f35937d09a3317c563905e0 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4685406 Commit-Queue: Vladimir Levin <vmpstr@chromium.org> Reviewed-by: Khushal Sagar <khushalsagar@chromium.org> Cr-Commit-Position: refs/heads/main@{#1170651}

…contain-intrinsic-size: auto, a=testonly Automatic update from web-platform-tests CV/CIS: content-visibility: auto forces contain-intrinsic-size: auto This patch implements a resolution on w3c/csswg-drafts#8407 (comment) With a follow-up resolution that this should happen at computed value time (same issue). I2P&S is here: https://groups.google.com/a/chromium.org/g/blink-dev/c/aYpmS8hP2UQ/m/CO4wGRiYCQAJ Note that the current implementation sets this behind an experimental flag, pending I2S approval. R=andruud@chromium.org Bug: 1418453 Change-Id: I06ad14460c1e620b3f35937d09a3317c563905e0 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4685406 Commit-Queue: Vladimir Levin <vmpstr@chromium.org> Reviewed-by: Khushal Sagar <khushalsagar@chromium.org> Cr-Commit-Position: refs/heads/main@{#1170651} -- wpt-commits: c6fb50b0e11397aceaff70ddae8bd08c036ac4c5 wpt-pr: 41025

…contain-intrinsic-size: auto, a=testonly Automatic update from web-platform-tests CV/CIS: content-visibility: auto forces contain-intrinsic-size: auto This patch implements a resolution on w3c/csswg-drafts#8407 (comment) With a follow-up resolution that this should happen at computed value time (same issue). I2P&S is here: https://groups.google.com/a/chromium.org/g/blink-dev/c/aYpmS8hP2UQ/m/CO4wGRiYCQAJ Note that the current implementation sets this behind an experimental flag, pending I2S approval. R=andruudchromium.org Bug: 1418453 Change-Id: I06ad14460c1e620b3f35937d09a3317c563905e0 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4685406 Commit-Queue: Vladimir Levin <vmpstrchromium.org> Reviewed-by: Khushal Sagar <khushalsagarchromium.org> Cr-Commit-Position: refs/heads/main{#1170651} -- wpt-commits: c6fb50b0e11397aceaff70ddae8bd08c036ac4c5 wpt-pr: 41025 UltraBlame original commit: 56052b674c85aed2057def6ebf9c6b864895897f

…contain-intrinsic-size: auto, a=testonly Automatic update from web-platform-tests CV/CIS: content-visibility: auto forces contain-intrinsic-size: auto This patch implements a resolution on w3c/csswg-drafts#8407 (comment) With a follow-up resolution that this should happen at computed value time (same issue). I2P&S is here: https://groups.google.com/a/chromium.org/g/blink-dev/c/aYpmS8hP2UQ/m/CO4wGRiYCQAJ Note that the current implementation sets this behind an experimental flag, pending I2S approval. R=andruudchromium.org Bug: 1418453 Change-Id: I06ad14460c1e620b3f35937d09a3317c563905e0 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4685406 Commit-Queue: Vladimir Levin <vmpstrchromium.org> Reviewed-by: Khushal Sagar <khushalsagarchromium.org> Cr-Commit-Position: refs/heads/main{#1170651} -- wpt-commits: c6fb50b0e11397aceaff70ddae8bd08c036ac4c5 wpt-pr: 41025 UltraBlame original commit: 56052b674c85aed2057def6ebf9c6b864895897f

…contain-intrinsic-size: auto, a=testonly Automatic update from web-platform-tests CV/CIS: content-visibility: auto forces contain-intrinsic-size: auto This patch implements a resolution on w3c/csswg-drafts#8407 (comment) With a follow-up resolution that this should happen at computed value time (same issue). I2P&S is here: https://groups.google.com/a/chromium.org/g/blink-dev/c/aYpmS8hP2UQ/m/CO4wGRiYCQAJ Note that the current implementation sets this behind an experimental flag, pending I2S approval. R=andruudchromium.org Bug: 1418453 Change-Id: I06ad14460c1e620b3f35937d09a3317c563905e0 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4685406 Commit-Queue: Vladimir Levin <vmpstrchromium.org> Reviewed-by: Khushal Sagar <khushalsagarchromium.org> Cr-Commit-Position: refs/heads/main{#1170651} -- wpt-commits: c6fb50b0e11397aceaff70ddae8bd08c036ac4c5 wpt-pr: 41025 UltraBlame original commit: 56052b674c85aed2057def6ebf9c6b864895897f

…contain-intrinsic-size: auto, a=testonly Automatic update from web-platform-tests CV/CIS: content-visibility: auto forces contain-intrinsic-size: auto This patch implements a resolution on w3c/csswg-drafts#8407 (comment) With a follow-up resolution that this should happen at computed value time (same issue). I2P&S is here: https://groups.google.com/a/chromium.org/g/blink-dev/c/aYpmS8hP2UQ/m/CO4wGRiYCQAJ Note that the current implementation sets this behind an experimental flag, pending I2S approval. R=andruud@chromium.org Bug: 1418453 Change-Id: I06ad14460c1e620b3f35937d09a3317c563905e0 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4685406 Commit-Queue: Vladimir Levin <vmpstr@chromium.org> Reviewed-by: Khushal Sagar <khushalsagar@chromium.org> Cr-Commit-Position: refs/heads/main@{#1170651} -- wpt-commits: c6fb50b0e11397aceaff70ddae8bd08c036ac4c5 wpt-pr: 41025

https://bugs.webkit.org/show_bug.cgi?id=259645 Reviewed by Tim Nguyen. This was approved here: w3c/csswg-drafts#8407 (comment) Already implemented in Chromium and gecko. * LayoutTests/imported/w3c/web-platform-tests/css/css-contain/content-visibility/content-visibility-068-expected.txt: * Source/WebCore/rendering/style/RenderStyle.h: * Source/WebCore/rendering/style/RenderStyleSetters.h: (WebCore::RenderStyle::containIntrinsicWidthAddAuto): (WebCore::RenderStyle::containIntrinsicHeightAddAuto): * Source/WebCore/style/StyleAdjuster.cpp: (WebCore::Style::Adjuster::adjust const): Canonical link: https://commits.webkit.org/267180@main

jihyerish added the css-contain-2 Current Work label Feb 7, 2023

jihyerish added the css-sizing-4 label Feb 13, 2023

jihyerish added the Agenda+ label Feb 14, 2023

css-meeting-bot removed the Agenda+ label Feb 22, 2023

chromium-helper mentioned this issue Feb 22, 2023

[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 chromium-helper/csswg-resolutions#40

Closed

mozilla-apprentice mentioned this issue Feb 22, 2023

[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 mozilla/wg-decisions#1039

Closed

astearns added the Needs Edits label Feb 22, 2023

vmpstr mentioned this issue Mar 8, 2023

[css-contain] content-visibility: auto visibility check timing needs details #8542

Closed

Loirooriol mentioned this issue May 14, 2023

[css-sizing] Add contain-intrinsic-size: auto none? #7737

Open

vmpstr added Agenda+ Async Resolution: Proposed Candidate for auto-resolve with stated time limit labels May 29, 2023

This was referenced Jun 16, 2023

contain-intrinsic-size: auto none syntax support mozilla/standards-positions#827

Closed

contain-intrinsic-size: auto none syntax support WebKit/standards-positions#205

Closed

[css-sizing-4] Add contain-intrinsic-size: auto none syntax #8989

Merged

css-meeting-bot removed the Agenda+ label Jul 12, 2023

mozilla-apprentice mentioned this issue Jul 12, 2023

[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 mozilla/wg-decisions#1156

Open

fantasai added Closed Accepted by CSSWG Resolution and removed Async Resolution: Proposed Candidate for auto-resolve with stated time limit labels Jul 12, 2023

vmpstr mentioned this issue Jul 13, 2023

content-visibility: auto forces contain-intrinsic-size: auto WebKit/standards-positions#228

Closed

chromium-wpt-export-bot mentioned this issue Jul 13, 2023

CV/CIS: content-visibility: auto forces contain-intrinsic-size: auto web-platform-tests/wpt#41025

Merged

vmpstr mentioned this issue Jul 24, 2023

content-visibility: auto forces contain-intrinsic-size: auto w3ctag/design-reviews#876

Closed

1 task

rwlbuis mentioned this issue Aug 22, 2023

[content-visibility] Make c-v: auto add auto to contain-intrinsic-size WebKit/WebKit#16226

Merged

Loirooriol mentioned this issue Oct 15, 2023

[css-values] Idea to make "var() for regular properties" implementable #9454

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[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

[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

jihyerish commented Feb 7, 2023 •

edited

Loading

Loirooriol commented Feb 7, 2023

jihyerish commented Feb 10, 2023

Loirooriol commented Feb 10, 2023

jihyerish commented Feb 13, 2023 •

edited

Loading

Loirooriol commented Feb 13, 2023

css-meeting-bot commented Feb 22, 2023

Loirooriol commented Feb 22, 2023

emilio commented Apr 5, 2023

vmpstr commented Apr 5, 2023

flackr commented Apr 5, 2023

vmpstr commented May 29, 2023

khushalsagar commented Jul 11, 2023

khushalsagar commented Jul 12, 2023

css-meeting-bot commented Jul 12, 2023

[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

[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

Comments

jihyerish commented Feb 7, 2023 • edited Loading

Loirooriol commented Feb 7, 2023

jihyerish commented Feb 10, 2023

Loirooriol commented Feb 10, 2023

jihyerish commented Feb 13, 2023 • edited Loading

Loirooriol commented Feb 13, 2023

css-meeting-bot commented Feb 22, 2023

Loirooriol commented Feb 22, 2023

emilio commented Apr 5, 2023

vmpstr commented Apr 5, 2023

flackr commented Apr 5, 2023

vmpstr commented May 29, 2023

khushalsagar commented Jul 11, 2023

khushalsagar commented Jul 12, 2023

css-meeting-bot commented Jul 12, 2023

[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

[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

jihyerish commented Feb 7, 2023 •

edited

Loading

jihyerish commented Feb 13, 2023 •

edited

Loading