[css-contain] :root/body viewport propagation and containment #5913

lilles · 2021-02-01T12:15:03Z

While investigating containment for container queries I've encountered the issue of propagating html/body properties to the viewport. The simple case for container queries is that if you set containment on the html element, expecting the size of the html element being determined without looking at descendants. But if the body element changes the writing-mode, that writing-mode is propagated to the viewport, but also affects the used value for the html element.

This is a circularity problem for container queries because you can have:

<style>
  html { contain: strict }
  body { writing-mode: horizontal-tb }
  @container (min-width: 1000px) { body { writing-mode: vertical-lr } }
</style>

and the width of html element may change because of the writing-mode which would then flip to a different writing-mode which gives a circularity.

Disregarding container queries, there is a question if there is an issue with propagation and containment for root/body propagation. Consider this case:

<!doctype html>
<html>
  <head>
    <title>
      The layout of the html element depends on the overflow property of the
      body element which is propagated to the viewport. There are other properties
      which are propagated to the viewport, but also affects the used value of the
      html element. That is, the writing-mode. The used value for writing-mode on
      the html element depends on the computed value for writing-mode on the body
      element. Is there enough text to break this line now?
    </title>
    <style>
      html { overflow: visible; contain: strict }
      body { overflow: scroll; }
      head, title { display: block; }
    </style>
  </head>
  <body></body>
</html>

All of Blink, WebKit, Gecko propagate the overflow:scroll to the viewport affecting the layout of the html root element.

Should containment somehow stop propagation to html/viewport?

css-meeting-bot · 2021-02-17T18:02:27Z

The CSS Working Group just discussed [css-contain] :root/body viewport propagation and containment.

The full IRC log of that discussion

<dael> Topic: [css-contain] :root/body viewport propagation and containment
<dael> github: https://github.com//issues/5913
<dael> rune: encountered looking at container queries
<Rossen_> q
<Rossen_> ack faceless
<dael> rune: We prop the writing mode from body to root inclduing affecting used value for root element. Causes circularity if we don't say if we have containment on html don't prop to viewport. Wondering if it makes sense
<dael> rune: Mostly thought about writing mode, but other properties too
<hober> q+
<dael> florian: Interesting problem. What's the solution other than making contain not apply?
<dael> rune: Make contain not prop to viewport
<dael> Rossen_: Wasn't that way more impactful on compat?
<dael> florian: Not nec since existing content doesn't contain on body or root
<dael> hober: There is b/c sites exist over time and worked on by different dev. Current maintainer might want the new shiny thing and not realize site depends on viewport prop. They add this and cause a freaky action at a distance bug where other things stop working. How do you figure that out?
<hober> q-
<dael> florian: I don't want to break prop. Doesn't seem as action at a distance. Containment at root isn't meant as neutral. So not worried about action at a disance. But some of the prop is probably there because they're useful. I don't htink containment on root or body is useful so not apply seems fine
<jensimmons> q?
<dael> rune: Fine with that. Want to get rid of circularity.
<fantasai> for the record, propagation from root to viewport is necessary and useful; and propoagation from body is just a hack we had to introduce for compat
<miriam> q+
<fantasai> I also agree with Florian that making containment just not apply is fine, I can't think any reason why it would be useful
<dael> jensimmons: Agree with hober. I've already seen people teaching that best way to use container queries is to apply on root. May theoretically make no sense to use, but people will be confused by where to put containment. It's attractive to put on root
<dael> florian: Confused as to why, but I believe they do
<iank_> q+
<leaverou> That's so bizarre. Isn't that basically like a MQ?
<dael> jensimmons: If it's impossible to do something with a sensible default it becomes an exercise to teach webdev to not do something stupid. I would lean toward can we make it not terrible by default? The webdev are already saying just put it on the root and it'll work
<Rossen_> ack miriam
<Rossen_> ack iank_
<dael> miriam: I haven't seen people talking about jsut apply to root, but reason you might want to is for face that container queries resolve against actual font size and MQ resolve against external font size. That's one place where might be useful on the root even though MQ do most of it.
<dael> iank_: My personal opinion is not too worried about stopping prop. From my m emory we added prop as a convenience or a compat issue that people put writing mode on body and we didn't want to switching to orthogonal and back. This cleans it up
<dael> iank_: From what I've seen webdev will but it on the root and the body. Seems like an edge case.
<dael> iank_: I think what rune and florian propose sounds well reasoned
<Rossen_> q+
<Rossen_> ack florian
<Rossen_> q-
<miriam> +1 resolve container against root
<dael> florian: Two things. Containment and container query. I think if we set container query so if there's no container it resolves against root then no need to contain root. If you container query w/o container you resolve against top level and no need to apply containment to body. Would that be weird?
<dael> Rossen_: I was on queue to highlight there's a ton of compat in the history. Especially the tail end of body or html which are used for setting up viewport. I don't think we should minimize potential compat impact. As hober pointed out someone could adjust styles and not realize they're effecting lots of stuff
<florian> q+ to ask jen something
<dael> Rossen_: At the same time I'm hearing there are potentially use cases to have containment on body or html. Whatever the use cases are we have to understand and figure out if we need to support them and figure out what's the appropriate behavior for backwards prop. Maybe a middle ground to support backwards compat while allowing containment
<dael> florian: jensimmons I want to check if I understand. What I thought you said is there are people who want to do container queries in general and some of the time it'll be in a grid and sometimes it's not in anything and in those cases they don't want a MQ for non-contained cases and they set the query on the root
<dael> florian: If that's what you're saying I think we can work off the root to answer query. But did I miss?
<dael> jensimmons: Both. People will set on the root b/c used to have to set it somewhere. They're going to be lazy and stick it where they want
<dael> florian: Queries or jsut containment?
<dael> jensimmons: While using container queries. Will they combine it with a switch in writing modes, maybe. If it's really hard it might we worth the extra effort, but don't assume it's an edge case
<dael> florian: Making container queries on anything makes sense. If you need containment to get container queries makes sense to have containment. If you container query for anything it could work
<dael> jensimmons: They're going to stick a design system container where they want. Sometimes in flow, sometimes deep in dom. They won't re-write the code depending on the context
<dael> florian: Under that pattern makes sense to allow and the containment part appleid to root does nothing. Query when not contained asks the root. Don't have to break cycles, just go all the way up
<dael> jensimmons: Maybe. not sure
<fantasai> +1 florian
<Rossen_> q?
<miriam> +1 florian
<dael> florian: Need to see if it works, but general approach makes sense
<dael> iank_: Not sure it works, florian. Need to think. You can set...specically setting html element and youc an set properties which means will mismatch from viewport size I believe
<dael> iank_: So you'll have logical mismatch
<dael> florian: max-width on htlp element?
<dael> iank_: Yeah, or set a direct width. I forget exatly what applies, but you'll have a mismatch between html element and viewport
<dael> rune: If you spec containment on root html element such that container queries should work on thml element we'll instead use viewport?
<dael> florian: Yes, but iank_ has a point too
<dael> iank_: Yeah, I think if the choice is matching...you can set width on html element. If decision is making that resolve against viewport vs fixing containment I'm not wild about containing queries being special to one html element and having it match against viewport in one case
<Rossen_> q?
<dael> florian: I need to think. I feel like there's a shortcut but the one I mentioned earlier is wrong
<dael> florian: I'd like to try and find a way out of this that doesn't require breaking backwards prop of things
<dael> fantasai: I don't have problem breaking prop from body. It shouldn't have existed.
<dael> fantasai: If we want to break prop from body, jsut do it
<dael> myles: Not unreasonable, but this is wrong time to make that kind of big change
<dael> iank_: This is only breaking if we have containment applied on body. This isn't a big change. If people are worried about compat, I'm not, but we can ad a use counter
<dael> myles: I think jensimmons made a compelling arguement that it will not be uncommon
<dael> iank_: I think it's uncommon at the moment. I agree it could become common and you're opting in
<dael> florian: If you add a component with container queries and not paying attention to where and you don't check arabic, only english, you broke arabic
<dael> Rossen_: iank_ are you offering to collect some date?
<dael> s/date/data
<dael> iank_: I think I might offer rune to collect data. I also think this will only break vertical writing mode pages
<dael> Rossen_: We're at top of the hour. How about the following. If we can get data, great. jensimmons I'd ask you to dig out some of these examples of devs or designers talking about htis on root that would be helpful
<dael> jensimmons: It's in random convos and slack channels. It's not blog posts. It's the first hot take. Just set it on the root. We can teach them not to do it, but if that's the first take there's something attractive. It's a sign it's not edge case
<dael> florian: I think we should make it work, just aim for least breaky
<dael> Rossen_: It will come to a compromise so let's make sure it's the right one
<dael> Rossen_: We're a bit over, thanks for staying. That was great discussion

lilles · 2021-04-07T08:43:25Z

A new proposal:

What if we propagate properties from body to viewport as if no container queries match, but the computed style on body will be evaluated as for any other element.

So in the case below the computed overflow on body will be 'visible', but the value propagated to the viewport will be 'scroll':

<style>
  html {
    width: 500px;
    contain: layout size;
  }
  body {
    overflow: scroll;
  }
  @container (min-width: 400px) {
    body {
      overflow: visible;
    }
  }
  @container (max-width: 400px) {
    body {
      overflow: hidden;
    }
  }
</style>

That means we need to store the propagated properties separately. Implementation-wise for Blink, it would probably be done by computing a separate set of computed values for body if the the body computed style depends on container queries for any of the propagated properties.

If the author refrains from adding overflow, writing-mode, etc inside @container rules for body, there should be no extra cost.

lilles · 2021-04-27T15:46:41Z

I've done a Blink implementation of the alternative proposal to see if it could work.

What I did was to cascade these properties in a separate step for <body>:

direction
overflow
writing-mode
display

where the three first are the ones propagated to the viewport which may affect layout, hence affects container queries, and display because the display property may affect whether the properties should propagate to the viewport or not in the first place.

lilles · 2021-04-29T11:30:37Z

I have tried to outline the alternatives I have found in this document.

Note that one of the alternatives is relying on the resolution for issue #6178.

mirisuzanne · 2021-04-29T19:42:33Z

Since we agreed to deprecate propagation from the body element, I don't think we should go out of the way to preserve the behavior, beyond what's required for backwards-compatibility.

Even if #6178 doesn't require root containment by default, that does seem like a very popular/desirable option for authors to add explicitly - and it would be unfortunate if we had to disallow that entirely.

css-meeting-bot · 2021-05-05T23:46:18Z

The CSS Working Group just discussed [css-contain] :root/body viewport propagation and containment, and agreed to the following:

RESOLVED: If there is containment on body or root it stops propagation from body to root

The full IRC log of that discussion

<dael> Topic: [css-contain] :root/body viewport propagation and containment
<dael> github: https://github.com//issues/5913
<dael> miriam: Not the one that raise this but rune isn't here. Can't speak for browser engineers. Seems like users that would want to do containment at root. Would not like to disallow, but he has a few other proposals
<dael> miriam: No strong feelings
<dael> iank_: There's 3 solutions from prop direction writing modes.
<dael> iank_: The first is the giant hammer no one wants which is disallow on body
<dael> iank_: Second is when container quereis apply we stop body prop up to viewport
<dael> iank_: Third option is to do prop but don't let it change after that. Stuck at initial value
<dael> iank_: Means if you have container query on html element and spec body under 500px changes writing mode wouldn't work
<dael> iank_: I think I prefer the 2nd option. When we have containment applied we don't form propagation. However, 2 valid solutions
<dael> florian: Agree with iank_. Prop from body is for compat reasons. In general containment is not an operation that changes nothing. It changes layout b/c contains things. Saying it contains prop it's fine. If you need it on the root, set it there
<dael> iank_: Not allowing you to dynamically change those properties inside container queries seems bad to 2nd
<dael> fantasai: 2nd is if you apply containment to root or body we don't do body prop but do from html root element
<dael> florian: If you do on body doesn't prop to root but can't contain root
<dael> florian: No cotnainment on root. On body is possible, but stops prop from body
<dael> fantasai: Does contain apply to root general?
<dael> florian: Not defined
<dael> fantasai: If it does it would make sense that would aslo block prop.
<dael> iank_: Problematic case is html element then body. Put a container query and the body can change style and prop to root
<dael> fantasai: Yes, not allowed. Containment on root or body shoudl block body from prop.
<dael> fantasai: Nothing shoudl block root from prop
<dael> fantasai: Assuming containment on root can be done. If it does not apply if it blocks body no strong opinion
<dael> florian: Don't recall talking about cotnainment on root.
<dael> miriam: It is a use case people want. Might be able to get close with body containment. People are wanting the ability
<dael> florian: Can you explain why root?
<dael> miriam: I don't know people have thought through body or root. Main is you could adjust body based on root query. There is a case to use a cotnainer query isntead of MQ for viewport b/c cotnainer lets you respond to actual font size and dimensions rather than browser or user font size.
<dael> iank_: Once people get their hands on container queries they won't think about viewport MQs much anymore. They'll attach container query to root to adjust viewport
<dael> fantasai: Givenw e're expecting containment to apply to root with an effect of some kind it should also block body from propagating
<dael> fantasai: Prop: containment does nto block root from propagating, but it does block body
<dael> florian: Containment to the body makes sense. Still confused on root
<dael> fantasai: If containing the body and prevents prop, why wouldn't containing and ancestor block?
<dael> florian: Doing it outer edge of thing being container. Means root doesn't effect parent. Doesn't change how things inside are effected. Might be useful
<dael> fantasai: Containment means child doesn't interact with ancestors, right?
<dael> florian: Yeah, okay. I can see it
<miriam> +1 fantasai
<dael> fantasai: Interface of container some things applya nd some don't, but child shouldn't interact with grandparent
<dael> florian: Body to root maybe should be blocked.
<dael> fantasai: Body to root? Does that happen?
<dael> iank_: Root is HTML element?
<dael> florian: Yes
<dael> iank_: Containment applies to html element fine.
<dael> astearns: Prop: If there is containment on body it stops prop from body to root?
<dael> florian: On body or root
<dael> astearns: Prop: If there is cotnainment on body or root it stops prop from body to root
<dael> RESOLVED: If there is containment on body or root it stops propagation from body to root

fantasai · 2021-05-05T23:46:56Z

Note that propagation from root to viewport is not affected by containment.

lilles · 2021-05-10T13:21:38Z

Just a couple of clarifying questions/statements:

Containment on the html root element stops propagation from body, containment on body should be irrelevant.
By containment, do we mean any containment?
And by containment, we mean used (applied?) containment, since some properties implies containment without affecting the computed value, like content-visibility?
Also that would make this resolution compatible with introducing a separate syntax for defining what becomes a container for container queries, since that would typically also make the containment used/applied but not affect computed value for contain.
Should the edits go into the relevant specs for body propagation like writing-modes, overflow, and backgrounds, or should this be a common section for body propagation in css-contain?

lilles · 2021-05-11T23:07:36Z

Re-opening for getting the questions above clarified.

lilles · 2021-05-15T10:41:45Z

Agenda+ to clarify resolution. See: #5913 (comment)

fantasai · 2021-05-19T16:52:00Z

IIRC containment on the body also stops propagation.

css-meeting-bot · 2021-05-19T16:57:08Z

The CSS Working Group just discussed [css-contain] :root/body viewport propagation and containment, and agreed to the following:

RESOLVED: specify this in CSS Contain
RESOLVED: If the used value of contain is other than the default we break propagation

The full IRC log of that discussion

<dael> Topic: [css-contain] :root/body viewport propagation and containment
<dael> github: https://github.com//issues/5913#issuecomment-836692271
<dael> futhark: I was not in APAc so clarification. Resolution says stops prop if there is containment. Applied or contain property?
<dael> futhark: Does paint containment stop it? Any containment?
<dael> futhark: And then there is which spec does this go into? Varios specs that talk about prop or the CSS Contain spec?
<dael> futhark: I don't know if anybody had opinions
<dael> astearns: So where does this get specified?
<dael> florian: Suggest contain spec, possibley with notes
<dael> astearns: Objections to spec this in CSS Contain
<dael> RESOLVED: specify this in CSS Contain
<dael> astearns: What types of containment change prop?
<dael> astearns: Any non-default or all of the values that create a container?
<dael> futhark: Problem with those that establish a container is we may need to change behavior as we add values
<dael> futhark: Can spec as the containment nec to establish a container but that breaks content if you use containment for all things
<dael> astearns: Downside to saying we break prop for non-default value?
<dael> futhark: Don't think so. Not strictly necessary
<dael> florian: Feels overkill, but is it really bad?
<dael> fantasai: My thoughts exactly
<dael> florian: We're not effecting any amount of prop from root, it's from body to root?
<dael> futhark: Body to viewport and potentially root
<dael> futhark: Also for applied containment. Used or applied
<dael> astearns: Sounds like your preference is that if the used value of containment is other than default it breaks prop
<dael> futhark: Yep
<dael> astearns: Slgihtly worried that things which use contain:paint might depend on prop but can't think of a reason
<iank_> I think its a non-issue here
<dael> florian: Absense of container quereis doing containment on body might not be common
<dael> astearns: Prop: If the used value of contain is other than the default we break propagation
<dael> astearns: Obj?
<dael> RESOLVED: If the used value of contain is other than the default we break propagation
<chrishtr> \o/
<dael> astearns: other questions on your list?
<dael> futhark: no
<florian> s/Absense of container quereis doing containment on body might not be common/In the absense of container quereis, doing containment on body might not be common, so we're probably fine/

See w3c/csswg-drafts#5913

frivoal · 2021-05-20T12:54:46Z

@lilles, I've landed the spec changes and an bunch of tests. Let me know if anything seems off.

Addresses #5913

lilles · 2021-05-26T12:46:03Z

Sorry, didn't see this before. We only need this for containment on the root html element. If you have containment on body, that should not be a problem. I thought we discussed that, but I don't see that from the meeting notes.

… with containement, a=testonly Automatic update from web-platform-tests Tests for outwards propagation from body with containement (#29057) See w3c/csswg-drafts#5913 -- wpt-commits: 314ebc0b6b2212a5626eb692d4d6daf3a9dd6052 wpt-pr: 29057

frivoal · 2021-05-31T05:36:27Z

Meetings notes / resolution apply to both equally, so on procedural grounds, we're covered.
Propagation from body is a compat hack anyway, so since containment on body is a new thing, we can make the change without breaking things.
Even if it's not strictly needed for container queries, from a containment standpoint in general, I think it is beneficial anyway:
- on every other element, a change of the overflow property from visible/clip/hidden to auto/scroll can only affect the layout of descends. On body, since it'd change the viewport, it can affect the layout of the element itself. Same thing for writing-mode. Disabling that is a good thing to have
- similarly for contain:paint, body is the only element where changing the background would require a repaint of ancestors (well, maybe except [css-contain][filter-effects] paint containment vs filter effects #6325, but that's another story)

@lilles So I think it's fine. If you think it's a problem we went this way, maybe reopen a more narrowly scoped issue?

Per resolution in [1]. [1] w3c/csswg-drafts#5913 Bug: 1200846 Change-Id: I50f142245cdb55b422f8a6f3d9690444bf3648aa

Per resolution in [1]. [1] w3c/csswg-drafts#5913 Bug: 1215265 Change-Id: I50f142245cdb55b422f8a6f3d9690444bf3648aa

Per resolution in [1]. Added behind a flag since this is a web facing change which needs an intent to ship. [1] w3c/csswg-drafts#5913 Bug: 1215265 Change-Id: I50f142245cdb55b422f8a6f3d9690444bf3648aa

Per resolution in [1]. Added behind a flag since this is a web facing change which needs an intent to ship. [1] w3c/csswg-drafts#5913 Bug: 1215265 Change-Id: I50f142245cdb55b422f8a6f3d9690444bf3648aa Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2897247 Reviewed-by: Anders Hartvoll Ruud <[email protected]> Commit-Queue: Rune Lillesveen <[email protected]> Cr-Commit-Position: refs/heads/master@{#890175}

…oot or body is contained, a=testonly Automatic update from web-platform-tests Do not propagate body styles when html root or body is contained Per resolution in [1]. Added behind a flag since this is a web facing change which needs an intent to ship. [1] w3c/csswg-drafts#5913 Bug: 1215265 Change-Id: I50f142245cdb55b422f8a6f3d9690444bf3648aa Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2897247 Reviewed-by: Anders Hartvoll Ruud <[email protected]> Commit-Queue: Rune Lillesveen <[email protected]> Cr-Commit-Position: refs/heads/master@{#890175} -- wpt-commits: cf84beafec2055bc7a7ba01fcaecd4f528f2f1dc wpt-pr: 29165

https://bugs.webkit.org/show_bug.cgi?id=233535 Patch by Rob Buis <[email protected]> on 2021-12-08 Reviewed by Alan Bujtas. Source/WebCore: Prevent direction/background/writing-mode propagation to RenderView in cases where contain is used. The reason is in the github issue and latest draft specification has been updated [1, 2]. [1] w3c/csswg-drafts#5913 [2] https://drafts.csswg.org/css-contain-2/ * rendering/RenderBox.cpp: (WebCore::RenderBox::styleDidChange): (WebCore::RenderBox::updateFromStyle): * rendering/RenderObject.cpp: (WebCore::shouldApplyAnyContainment): * rendering/RenderObject.h: * rendering/RenderView.cpp: (WebCore::RenderView::rendererForRootBackground const): LayoutTests: * TestExpectations: Canonical link: https://commits.webkit.org/244980@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@286672 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=233535 Patch by Rob Buis <[email protected]> on 2021-12-08 Reviewed by Alan Bujtas. Source/WebCore: Prevent direction/background/writing-mode propagation to RenderView in cases where contain is used. The reason is in the github issue and latest draft specification has been updated [1, 2]. [1] w3c/csswg-drafts#5913 [2] https://drafts.csswg.org/css-contain-2/ * rendering/RenderBox.cpp: (WebCore::RenderBox::styleDidChange): (WebCore::RenderBox::updateFromStyle): * rendering/RenderObject.cpp: (WebCore::shouldApplyAnyContainment): * rendering/RenderObject.h: * rendering/RenderView.cpp: (WebCore::RenderView::rendererForRootBackground const): LayoutTests: * TestExpectations: git-svn-id: http://svn.webkit.org/repository/webkit/trunk@286672 268f45cc-cd09-0410-ab3c-d52691b4dbfc

lilles added Agenda+ Agenda+ F2F and removed Agenda+ labels Feb 2, 2021

astearns added Agenda+ and removed Agenda+ F2F labels Feb 12, 2021

astearns removed the Agenda+ label Feb 17, 2021

fantasai added css-contain-1 css-contain-2 Current Work labels Mar 23, 2021

lilles added the Agenda+ label Apr 29, 2021

css-meeting-bot removed the Agenda+ label May 5, 2021

mozilla-apprentice mentioned this issue May 5, 2021

[css-contain] :root/body viewport propagation and containment mozilla/wg-decisions#536

Closed

mirisuzanne added the Closed Accepted by CSSWG Resolution label May 6, 2021

mirisuzanne closed this as completed May 6, 2021

lilles added Needs Edits Needs Testcase (WPT) labels May 10, 2021

lilles reopened this May 11, 2021

lilles added the Agenda+ label May 15, 2021

css-meeting-bot removed the Agenda+ label May 19, 2021

frivoal added a commit to web-platform-tests/wpt that referenced this issue May 20, 2021

Tests for outwards propagation from body with containement (#29057)

314ebc0

See w3c/csswg-drafts#5913

frivoal added Tested Memory aid - issue has WPT tests and removed Needs Edits Needs Testcase (WPT) labels May 20, 2021

frivoal added the Commenter Response Pending label May 20, 2021

frivoal added a commit that referenced this issue May 20, 2021

[css-contain] Disable propagation from body when containment is on

00b0acc

Addresses #5913

frivoal closed this as completed May 31, 2021

frivoal removed the Commenter Response Pending label May 31, 2021

frivoal self-assigned this May 31, 2021

chromium-wpt-export-bot mentioned this issue May 31, 2021

Do not propagate body styles when html root or body is contained web-platform-tests/wpt#29165

Merged

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue May 31, 2021

Do not propagate body styles when html root is contained

6ee74f0

Per resolution in [1]. [1] w3c/csswg-drafts#5913 Bug: 1200846 Change-Id: I50f142245cdb55b422f8a6f3d9690444bf3648aa

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jun 3, 2021

Do not propagate body styles when html root or body is contained

6da1ee6

Per resolution in [1]. [1] w3c/csswg-drafts#5913 Bug: 1215265 Change-Id: I50f142245cdb55b422f8a6f3d9690444bf3648aa

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jun 4, 2021

Do not propagate body styles when html root or body is contained

ff17268

Per resolution in [1]. [1] w3c/csswg-drafts#5913 Bug: 1215265 Change-Id: I50f142245cdb55b422f8a6f3d9690444bf3648aa

frivoal added the Tracked in DoC label Sep 6, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[css-contain] :root/body viewport propagation and containment #5913

[css-contain] :root/body viewport propagation and containment #5913

lilles commented Feb 1, 2021 •

edited

Loading

css-meeting-bot commented Feb 17, 2021

lilles commented Apr 7, 2021

lilles commented Apr 27, 2021

lilles commented Apr 29, 2021

mirisuzanne commented Apr 29, 2021

css-meeting-bot commented May 5, 2021

fantasai commented May 5, 2021

lilles commented May 10, 2021

lilles commented May 11, 2021

lilles commented May 15, 2021

fantasai commented May 19, 2021

css-meeting-bot commented May 19, 2021

frivoal commented May 20, 2021

lilles commented May 26, 2021

frivoal commented May 31, 2021

[css-contain] :root/body viewport propagation and containment #5913

[css-contain] :root/body viewport propagation and containment #5913

Comments

lilles commented Feb 1, 2021 • edited Loading

css-meeting-bot commented Feb 17, 2021

lilles commented Apr 7, 2021

lilles commented Apr 27, 2021

lilles commented Apr 29, 2021

mirisuzanne commented Apr 29, 2021

css-meeting-bot commented May 5, 2021

fantasai commented May 5, 2021

lilles commented May 10, 2021

lilles commented May 11, 2021

lilles commented May 15, 2021

fantasai commented May 19, 2021

css-meeting-bot commented May 19, 2021

frivoal commented May 20, 2021

lilles commented May 26, 2021

frivoal commented May 31, 2021

lilles commented Feb 1, 2021 •

edited

Loading