[css-overflow] Overflow propagation when the element propagated from is display: none · Issue #3779 · w3c/csswg-drafts (original) (raw)
Comments
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue
…. r=dholbert
This switches nsFrameSetFrame's hacky frame construction codepath to operate on the flattened tree, since it made me a bit more comfortable about it (all layout should operate on is the flattened tree, though in this cause this should not cause any web-observable behavior change, since can't be a shadow host per spec, and we no longer support XBL-in-content).
That doesn't need to compute styles lazily. You only need to compute styles lazily in descendants of display: none elements, and even though this code doesn't check on display: none on the children, the parent element should never have display: none (since we're creating an nsFrameSetFrame for it).
There are other places that still call into this (apart from getComputedStyle).
One is nsImageFrame's cursor code. Given the elements referencing an image map could be anywhere, we need to have lazy computation here.
The other is the viewport style propagation stuff. There shouldn't be a need for LazyComputeBehavior::Allow on the document element in order to check the viewport styles propagation, since the root element can't have display: none ancestors. But we run that code before actually constructing the doc element containing block, which is when we do the initial document styling.
We could remove that with some more effort, but it's not worth it right now, since we need to keep using it for the , since the document element could be display: none itself, and we propagate the overflow styles in that case still. I filed w3c/csswg-drafts#3779 to potentially change that.
Differential Revision: https://phabricator.services.mozilla.com/D25455
--HG-- extra : moz-landing-system : lando
mykmelez pushed a commit to mykmelez/gecko that referenced this issue
…. r=dholbert
This switches nsFrameSetFrame's hacky frame construction codepath to operate on the flattened tree, since it made me a bit more comfortable about it (all layout should operate on is the flattened tree, though in this cause this should not cause any web-observable behavior change, since can't be a shadow host per spec, and we no longer support XBL-in-content).
That doesn't need to compute styles lazily. You only need to compute styles lazily in descendants of display: none elements, and even though this code doesn't check on display: none on the children, the parent element should never have display: none (since we're creating an nsFrameSetFrame for it).
There are other places that still call into this (apart from getComputedStyle).
One is nsImageFrame's cursor code. Given the elements referencing an image map could be anywhere, we need to have lazy computation here.
The other is the viewport style propagation stuff. There shouldn't be a need for LazyComputeBehavior::Allow on the document element in order to check the viewport styles propagation, since the root element can't have display: none ancestors. But we run that code before actually constructing the doc element containing block, which is when we do the initial document styling.
We could remove that with some more effort, but it's not worth it right now, since we need to keep using it for the , since the document element could be display: none itself, and we propagate the overflow styles in that case still. I filed w3c/csswg-drafts#3779 to potentially change that.
Differential Revision: https://phabricator.services.mozilla.com/D25455
lilles pushed a commit to lilles/csswg-drafts that referenced this issue
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue
When documentElement/body doe not generate a box, its background will not propagate to the viewport (see [1]). This removes the need for calling EnsureComputedStyle() on documentElement/body.
The CSSWG has also resolved that to be the case also for other properties propagated to the viewport[2].
Some of the wpt tests for body propagation didn't actually have a body element. Added.
[1] https://drafts.csswg.org/css-backgrounds/#special-backgrounds [2] w3c/csswg-drafts#3779 (comment)
Bug: 987207
Change-Id: I06e618e2acd2926b5ae4831bf5825e13e970d035
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue
When documentElement/body does not generate a box, its background will not propagate to the viewport (see [1]). This removes the need for calling EnsureComputedStyle() on documentElement/body.
The CSSWG has also resolved that to be the case also for other properties propagated to the viewport[2].
Some of the wpt tests for body propagation didn't actually have a body element. Added.
[1] https://drafts.csswg.org/css-backgrounds/#special-backgrounds [2] w3c/csswg-drafts#3779 (comment)
Bug: 987207
Change-Id: I06e618e2acd2926b5ae4831bf5825e13e970d035
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue
When documentElement/body does not generate a box, its background will not propagate to the viewport (see [1]). This removes the need for calling EnsureComputedStyle() on documentElement/body.
The CSSWG has also resolved that to be the case also for other properties propagated to the viewport[2].
Some of the wpt tests for body propagation didn't actually have a body element. Added.
[1] https://drafts.csswg.org/css-backgrounds/#special-backgrounds [2] w3c/csswg-drafts#3779 (comment)
Bug: 987207
Change-Id: I06e618e2acd2926b5ae4831bf5825e13e970d035
aarongable pushed a commit to chromium/chromium that referenced this issue
When documentElement/body does not generate a box, its background will not propagate to the viewport (see [1]). This removes the need for calling EnsureComputedStyle() on documentElement/body.
The CSSWG has also resolved that to be the case also for other properties propagated to the viewport[2].
Some of the wpt tests for body propagation didn't actually have a body element. Added.
[1] https://drafts.csswg.org/css-backgrounds/#special-backgrounds [2] w3c/csswg-drafts#3779 (comment)
Bug: 987207
Change-Id: I06e618e2acd2926b5ae4831bf5825e13e970d035 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1547974 Commit-Queue: Rune Lillesveen futhark@chromium.org Reviewed-by: Anders Hartvoll Ruud andruud@chromium.org Cr-Commit-Position: refs/heads/master@{#680834}
frivoal added a commit that referenced this issue
…s. (#4148)
- [css-overflow-3] Do not propagate overflow from boxless elements.
Edits for #3779.
- applied -> propagated
Co-Authored-By: Florian Rivoal git@florian.rivoal.net
- canvas -> viewport
Co-Authored-By: Florian Rivoal git@florian.rivoal.net
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue
…pagation., a=testonly
Automatic update from web-platform-tests Handle display:contents for viewport propagation.
When documentElement/body does not generate a box, its background will not propagate to the viewport (see [1]). This removes the need for calling EnsureComputedStyle() on documentElement/body.
The CSSWG has also resolved that to be the case also for other properties propagated to the viewport[2].
Some of the wpt tests for body propagation didn't actually have a body element. Added.
[1] https://drafts.csswg.org/css-backgrounds/#special-backgrounds [2] w3c/csswg-drafts#3779 (comment)
Bug: 987207
Change-Id: I06e618e2acd2926b5ae4831bf5825e13e970d035 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1547974 Commit-Queue: Rune Lillesveen futhark@chromium.org Reviewed-by: Anders Hartvoll Ruud andruud@chromium.org Cr-Commit-Position: refs/heads/master@{#680834}
--
wpt-commits: d40f18ae072cab633cfb34fb883e12c87c1bc191 wpt-pr: 18039
xeonchen pushed a commit to xeonchen/gecko that referenced this issue
…pagation., a=testonly
Automatic update from web-platform-tests Handle display:contents for viewport propagation.
When documentElement/body does not generate a box, its background will not propagate to the viewport (see [1]). This removes the need for calling EnsureComputedStyle() on documentElement/body.
The CSSWG has also resolved that to be the case also for other properties propagated to the viewport[2].
Some of the wpt tests for body propagation didn't actually have a body element. Added.
[1] https://drafts.csswg.org/css-backgrounds/#special-backgrounds [2] w3c/csswg-drafts#3779 (comment)
Bug: 987207
Change-Id: I06e618e2acd2926b5ae4831bf5825e13e970d035 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1547974 Commit-Queue: Rune Lillesveen futhark@chromium.org Reviewed-by: Anders Hartvoll Ruud andruud@chromium.org Cr-Commit-Position: refs/heads/master@{#680834}
--
wpt-commits: d40f18ae072cab633cfb34fb883e12c87c1bc191 wpt-pr: 18039
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue
…isplay: contents elements. r=dholbert
Resolution is at:
Tests are at https://chromium-review.googlesource.com/c/chromium/src/+/1547974, I'll make sure to wait until they're in the tree and ensure they're passing.
Note that we need to ensure in the frame constructor that the document element is styled before calling UpdateViewportScrollStylesOverride(). This saves duplicated work (since ResolveStyleLazily throws away the style).
ResolveStyleLazily already returns out of date styles, unless the element is not
styled yet, or is in a display: none subtree, in which case it computes and
returns a new (up-to-date) style.
So the switch to the FFI call only should change behavior for the display: none subtree case (since we ensure the unstyled case isn't hit by styling the document earlier). But that case is one of the cases we're interested in changing, conveniently.
Depends on D40080
Differential Revision: https://phabricator.services.mozilla.com/D39204
--HG-- extra : moz-landing-system : lando
xeonchen pushed a commit to xeonchen/gecko that referenced this issue
…isplay: contents elements. r=dholbert
Resolution is at:
Tests are at https://chromium-review.googlesource.com/c/chromium/src/+/1547974, I'll make sure to wait until they're in the tree and ensure they're passing.
Note that we need to ensure in the frame constructor that the document element is styled before calling UpdateViewportScrollStylesOverride(). This saves duplicated work (since ResolveStyleLazily throws away the style).
ResolveStyleLazily already returns out of date styles, unless the element is not
styled yet, or is in a display: none subtree, in which case it computes and
returns a new (up-to-date) style.
So the switch to the FFI call only should change behavior for the display: none subtree case (since we ensure the unstyled case isn't hit by styling the document earlier). But that case is one of the cases we're interested in changing, conveniently.
Depends on D40080
Differential Revision: https://phabricator.services.mozilla.com/D39204
natechapin pushed a commit to natechapin/wpt that referenced this issue
When documentElement/body does not generate a box, its background will not propagate to the viewport (see [1]). This removes the need for calling EnsureComputedStyle() on documentElement/body.
The CSSWG has also resolved that to be the case also for other properties propagated to the viewport[2].
Some of the wpt tests for body propagation didn't actually have a body element. Added.
[1] https://drafts.csswg.org/css-backgrounds/#special-backgrounds [2] w3c/csswg-drafts#3779 (comment)
Bug: 987207
Change-Id: I06e618e2acd2926b5ae4831bf5825e13e970d035 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1547974 Commit-Queue: Rune Lillesveen futhark@chromium.org Reviewed-by: Anders Hartvoll Ruud andruud@chromium.org Cr-Commit-Position: refs/heads/master@{#680834}
gecko-dev-updater pushed a commit to marco-c/gecko-dev-comments-removed that referenced this issue
…. r=dholbert
This switches nsFrameSetFrame's hacky frame construction codepath to operate on the flattened tree, since it made me a bit more comfortable about it (all layout should operate on is the flattened tree, though in this cause this should not cause any web-observable behavior change, since can't be a shadow host per spec, and we no longer support XBL-in-content).
That doesn't need to compute styles lazily. You only need to compute styles lazily in descendants of display: none elements, and even though this code doesn't check on display: none on the children, the parent element should never have display: none (since we're creating an nsFrameSetFrame for it).
There are other places that still call into this (apart from getComputedStyle).
One is nsImageFrame's cursor code. Given the elements referencing an image map could be anywhere, we need to have lazy computation here.
The other is the viewport style propagation stuff. There shouldn't be a need for LazyComputeBehavior::Allow on the document element in order to check the viewport styles propagation, since the root element can't have display: none ancestors. But we run that code before actually constructing the doc element containing block, which is when we do the initial document styling.
We could remove that with some more effort, but it's not worth it right now, since we need to keep using it for the , since the document element could be display: none itself, and we propagate the overflow styles in that case still. I filed w3c/csswg-drafts#3779 to potentially change that.
Differential Revision: https://phabricator.services.mozilla.com/D25455
UltraBlame original commit: ae9783be99324502017f3c9bfc92cb811fd1993e
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified that referenced this issue
…. r=dholbert
This switches nsFrameSetFrame's hacky frame construction codepath to operate on the flattened tree, since it made me a bit more comfortable about it (all layout should operate on is the flattened tree, though in this cause this should not cause any web-observable behavior change, since can't be a shadow host per spec, and we no longer support XBL-in-content).
That doesn't need to compute styles lazily. You only need to compute styles lazily in descendants of display: none elements, and even though this code doesn't check on display: none on the children, the parent element should never have display: none (since we're creating an nsFrameSetFrame for it).
There are other places that still call into this (apart from getComputedStyle).
One is nsImageFrame's cursor code. Given the elements referencing an image map could be anywhere, we need to have lazy computation here.
The other is the viewport style propagation stuff. There shouldn't be a need for LazyComputeBehavior::Allow on the document element in order to check the viewport styles propagation, since the root element can't have display: none ancestors. But we run that code before actually constructing the doc element containing block, which is when we do the initial document styling.
We could remove that with some more effort, but it's not worth it right now, since we need to keep using it for the , since the document element could be display: none itself, and we propagate the overflow styles in that case still. I filed w3c/csswg-drafts#3779 to potentially change that.
Differential Revision: https://phabricator.services.mozilla.com/D25455
UltraBlame original commit: ae9783be99324502017f3c9bfc92cb811fd1993e
gecko-dev-updater pushed a commit to marco-c/gecko-dev-comments-removed that referenced this issue
…pagation., a=testonly
Automatic update from web-platform-tests Handle display:contents for viewport propagation.
When documentElement/body does not generate a box, its background will not propagate to the viewport (see [1]). This removes the need for calling EnsureComputedStyle() on documentElement/body.
The CSSWG has also resolved that to be the case also for other properties propagated to the viewport[2].
Some of the wpt tests for body propagation didn't actually have a body element. Added.
[1] https://drafts.csswg.org/css-backgrounds/#special-backgrounds [2] w3c/csswg-drafts#3779 (comment)
Bug: 987207
Change-Id: I06e618e2acd2926b5ae4831bf5825e13e970d035 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1547974 Commit-Queue: Rune Lillesveen <futharkchromium.org> Reviewed-by: Anders Hartvoll Ruud <andruudchromium.org> Cr-Commit-Position: refs/heads/master{#680834}
--
wpt-commits: d40f18ae072cab633cfb34fb883e12c87c1bc191 wpt-pr: 18039
UltraBlame original commit: b0a2ce5298cfff788febf0b952db102419a4753b
gecko-dev-updater pushed a commit to marco-c/gecko-dev-comments-removed that referenced this issue
…isplay: contents elements. r=dholbert
Resolution is at:
Tests are at https://chromium-review.googlesource.com/c/chromium/src/+/1547974, I'll make sure to wait until they're in the tree and ensure they're passing.
Note that we need to ensure in the frame constructor that the document element is styled before calling UpdateViewportScrollStylesOverride(). This saves duplicated work (since ResolveStyleLazily throws away the style).
ResolveStyleLazily already returns out of date styles, unless the element is not
styled yet, or is in a display: none subtree, in which case it computes and
returns a new (up-to-date) style.
So the switch to the FFI call only should change behavior for the display: none subtree case (since we ensure the unstyled case isn't hit by styling the document earlier). But that case is one of the cases we're interested in changing, conveniently.
Depends on D40080
Differential Revision: https://phabricator.services.mozilla.com/D39204
UltraBlame original commit: 400b06aac33e27a53b1ff0da585cd57035661d4c
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified-and-comments-removed that referenced this issue
…. r=dholbert
This switches nsFrameSetFrame's hacky frame construction codepath to operate on the flattened tree, since it made me a bit more comfortable about it (all layout should operate on is the flattened tree, though in this cause this should not cause any web-observable behavior change, since can't be a shadow host per spec, and we no longer support XBL-in-content).
That doesn't need to compute styles lazily. You only need to compute styles lazily in descendants of display: none elements, and even though this code doesn't check on display: none on the children, the parent element should never have display: none (since we're creating an nsFrameSetFrame for it).
There are other places that still call into this (apart from getComputedStyle).
One is nsImageFrame's cursor code. Given the elements referencing an image map could be anywhere, we need to have lazy computation here.
The other is the viewport style propagation stuff. There shouldn't be a need for LazyComputeBehavior::Allow on the document element in order to check the viewport styles propagation, since the root element can't have display: none ancestors. But we run that code before actually constructing the doc element containing block, which is when we do the initial document styling.
We could remove that with some more effort, but it's not worth it right now, since we need to keep using it for the , since the document element could be display: none itself, and we propagate the overflow styles in that case still. I filed w3c/csswg-drafts#3779 to potentially change that.
Differential Revision: https://phabricator.services.mozilla.com/D25455
UltraBlame original commit: ae9783be99324502017f3c9bfc92cb811fd1993e
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified that referenced this issue
…pagation., a=testonly
Automatic update from web-platform-tests Handle display:contents for viewport propagation.
When documentElement/body does not generate a box, its background will not propagate to the viewport (see [1]). This removes the need for calling EnsureComputedStyle() on documentElement/body.
The CSSWG has also resolved that to be the case also for other properties propagated to the viewport[2].
Some of the wpt tests for body propagation didn't actually have a body element. Added.
[1] https://drafts.csswg.org/css-backgrounds/#special-backgrounds [2] w3c/csswg-drafts#3779 (comment)
Bug: 987207
Change-Id: I06e618e2acd2926b5ae4831bf5825e13e970d035 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1547974 Commit-Queue: Rune Lillesveen <futharkchromium.org> Reviewed-by: Anders Hartvoll Ruud <andruudchromium.org> Cr-Commit-Position: refs/heads/master{#680834}
--
wpt-commits: d40f18ae072cab633cfb34fb883e12c87c1bc191 wpt-pr: 18039
UltraBlame original commit: b0a2ce5298cfff788febf0b952db102419a4753b
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified-and-comments-removed that referenced this issue
…pagation., a=testonly
Automatic update from web-platform-tests Handle display:contents for viewport propagation.
When documentElement/body does not generate a box, its background will not propagate to the viewport (see [1]). This removes the need for calling EnsureComputedStyle() on documentElement/body.
The CSSWG has also resolved that to be the case also for other properties propagated to the viewport[2].
Some of the wpt tests for body propagation didn't actually have a body element. Added.
[1] https://drafts.csswg.org/css-backgrounds/#special-backgrounds [2] w3c/csswg-drafts#3779 (comment)
Bug: 987207
Change-Id: I06e618e2acd2926b5ae4831bf5825e13e970d035 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1547974 Commit-Queue: Rune Lillesveen <futharkchromium.org> Reviewed-by: Anders Hartvoll Ruud <andruudchromium.org> Cr-Commit-Position: refs/heads/master{#680834}
--
wpt-commits: d40f18ae072cab633cfb34fb883e12c87c1bc191 wpt-pr: 18039
UltraBlame original commit: b0a2ce5298cfff788febf0b952db102419a4753b
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified that referenced this issue
…isplay: contents elements. r=dholbert
Resolution is at:
Tests are at https://chromium-review.googlesource.com/c/chromium/src/+/1547974, I'll make sure to wait until they're in the tree and ensure they're passing.
Note that we need to ensure in the frame constructor that the document element is styled before calling UpdateViewportScrollStylesOverride(). This saves duplicated work (since ResolveStyleLazily throws away the style).
ResolveStyleLazily already returns out of date styles, unless the element is not
styled yet, or is in a display: none subtree, in which case it computes and
returns a new (up-to-date) style.
So the switch to the FFI call only should change behavior for the display: none subtree case (since we ensure the unstyled case isn't hit by styling the document earlier). But that case is one of the cases we're interested in changing, conveniently.
Depends on D40080
Differential Revision: https://phabricator.services.mozilla.com/D39204
UltraBlame original commit: 400b06aac33e27a53b1ff0da585cd57035661d4c
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified-and-comments-removed that referenced this issue
…isplay: contents elements. r=dholbert
Resolution is at:
Tests are at https://chromium-review.googlesource.com/c/chromium/src/+/1547974, I'll make sure to wait until they're in the tree and ensure they're passing.
Note that we need to ensure in the frame constructor that the document element is styled before calling UpdateViewportScrollStylesOverride(). This saves duplicated work (since ResolveStyleLazily throws away the style).
ResolveStyleLazily already returns out of date styles, unless the element is not
styled yet, or is in a display: none subtree, in which case it computes and
returns a new (up-to-date) style.
So the switch to the FFI call only should change behavior for the display: none subtree case (since we ensure the unstyled case isn't hit by styling the document earlier). But that case is one of the cases we're interested in changing, conveniently.
Depends on D40080
Differential Revision: https://phabricator.services.mozilla.com/D39204
UltraBlame original commit: 400b06aac33e27a53b1ff0da585cd57035661d4c
fantasai added a commit that referenced this issue
…e from 'display: none' elements. Do propagate from 'display: contents' elements. #3779