You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[css-scroll-snap-1] Clarify that scroll-padding and scroll-snap-type on root propagate to viewport #3740
We propagate various properties that control overflow from the root to the viewport, e.g. overflow, scrollbar-width, etc. scroll-snap-type and scroll-padding aren't expected to be any different about this point, but it probably should be stated explicitly (as it is in css-scrollbars).
The CSS Working Group just discussed Clarify that scroll-padding and scroll-snap-type on root propagate to viewport, and agreed to the following:
RESOLVED: Accept the edits for https://github.com/w3c/csswg-drafts/issues/3740
The full IRC log of that discussion
<dael> Topic: Clarify that scroll-padding and scroll-snap-type on root propagate to viewport
<dael> github: https://github.com//issues/3740
<dael> Rossen_: fantasai are you on?
<dael> fantasai: Yeah. I think it was assumed by all of us scroll snap prop applied to viewport but we don't say so in the spec. I copied overflow draft and scrollbar draft to say prop from root but not body element
<fantasai> https://github.com/w3c/csswg-drafts/commit/b5afa1086cf344046ea87013f0c48b3800eaacd7
<dael> fantasai: Edits ^
<dael> florian: The way overflow prop from body is weird. Not doing weird is good, but isn't consistent good so can set both on body and they prop together
<dael> fantasai: Could set both on root instead. Don't prop scrollbar width or color
<dael> AmeliaBR: I haven't looked at edits, is it clear wording? Author if overflow on the body does scrollbars I'd expect that's where I put scroll snap. Maybe educate authors how that's weird and problematic but it's an extra level of lack of intuition
<dael> Rossen_: Agree. If body prop background color and overflow prop back to viewport and canvas it would make sense to have scroll prop. But as fantasai pointed out we want to stop all that legacy quirk behavior expansion of properties.
<dael> Rossen_: Couple says forward- continue adding them b/c this is what authors expect. Or not do it and teach people by making explicit test cases and educational material and that they will face that it doesn't work, ideally find and article and see body stuff is a quirk there to keep legacy web working but don't do that
<dael> Rossen_: Kinda more leaning not add to body
<dael> Rossen_: I do agree make sense to be explicitly pointed out apply to viewport
<dael> AmeliaBR: Skimming edits it looks quite sensible. There is a note about not prop from body but I don't know if we need to make that more author focused
<dael> florian: I guess that's enough. fantasai mentioned this is also case for scrollbar width. If we keep new stuff consistent and none work on body we have a fighting chance of getting people to set on root. I'm okay with edit as is if we make that the policy we follow
<dael> Rossen_: Other opinions?
<dael> Rossen_: Sounds like we're okay with the edits where scrollsnap properties prop from root. Obj to accepting edits?
<dael> RESOLVED: Accept the edits for https://github.com//issues/3740
Activity
[css-scroll-snap-1] Explicitly define that scroll-snap-type and scrol…
fantasai commentedon Mar 19, 2019
Agenda+ to confirm substantive change, republish CR.
css-meeting-bot commentedon Mar 20, 2019
The CSS Working Group just discussed
Clarify that scroll-padding and scroll-snap-type on root propagate to viewport, and agreed to the following:RESOLVED: Accept the edits for https://github.com/w3c/csswg-drafts/issues/3740The full IRC log of that discussion
<dael> Topic: Clarify that scroll-padding and scroll-snap-type on root propagate to viewport<dael> github: https://github.com//issues/3740
<dael> Rossen_: fantasai are you on?
<dael> fantasai: Yeah. I think it was assumed by all of us scroll snap prop applied to viewport but we don't say so in the spec. I copied overflow draft and scrollbar draft to say prop from root but not body element
<fantasai> https://github.com/w3c/csswg-drafts/commit/b5afa1086cf344046ea87013f0c48b3800eaacd7
<dael> fantasai: Edits ^
<dael> florian: The way overflow prop from body is weird. Not doing weird is good, but isn't consistent good so can set both on body and they prop together
<dael> fantasai: Could set both on root instead. Don't prop scrollbar width or color
<dael> AmeliaBR: I haven't looked at edits, is it clear wording? Author if overflow on the body does scrollbars I'd expect that's where I put scroll snap. Maybe educate authors how that's weird and problematic but it's an extra level of lack of intuition
<dael> Rossen_: Agree. If body prop background color and overflow prop back to viewport and canvas it would make sense to have scroll prop. But as fantasai pointed out we want to stop all that legacy quirk behavior expansion of properties.
<dael> Rossen_: Couple says forward- continue adding them b/c this is what authors expect. Or not do it and teach people by making explicit test cases and educational material and that they will face that it doesn't work, ideally find and article and see body stuff is a quirk there to keep legacy web working but don't do that
<dael> Rossen_: Kinda more leaning not add to body
<dael> Rossen_: I do agree make sense to be explicitly pointed out apply to viewport
<dael> AmeliaBR: Skimming edits it looks quite sensible. There is a note about not prop from body but I don't know if we need to make that more author focused
<dael> florian: I guess that's enough. fantasai mentioned this is also case for scrollbar width. If we keep new stuff consistent and none work on body we have a fighting chance of getting people to set on root. I'm okay with edit as is if we make that the policy we follow
<dael> Rossen_: Other opinions?
<dael> Rossen_: Sounds like we're okay with the edits where scrollsnap properties prop from root. Obj to accepting edits?
<dael> RESOLVED: Accept the edits for https://github.com//issues/3740
hiikezoe commentedon Apr 13, 2019
@fantasai, if I understand correctly the agreement on the IRC log, Example 5 should use html instead of body? I am confused about the example.
Bug 1544060 - Use the root element's primary frame to get scroll-padd…
Bug 1544060 - Use the root element's primary frame to get scroll-padd…
fantasai commentedon May 15, 2019
@hiikezoe Yes. Thanks. Fixed. :)
[scroll-snap] Fix viewport style propagation
[scroll-snap] Fix viewport style propagation
Bug 1544060 - Use the root element's primary frame to get scroll-padd…
Bug 1544060 - Use the root element's primary frame to get scroll-padd…
Bug 1544060 - Use the root element's primary frame to get scroll-padd…
[css-scroll-snap-1] Test propagation to viewport. w3c/csswg-drafts#3740
[css-scroll-snap-1] Test propagation to viewport. w3c/csswg-drafts#3740
[css-scroll-snap-1] Test propagation to viewport. w3c/csswg-drafts#3740
Bug 1686548 [wpt PR 27163] - [css-scroll-snap-1] Test propagation to …
Bug 1686548 [wpt PR 27163] - [css-scroll-snap-1] Test propagation to …
Bug 1544060 - Use the root element's primary frame to get scroll-padd…
Bug 1686548 [wpt PR 27163] - [css-scroll-snap-1] Test propagation to …