[css-scroll-snap-1] Clarify that scroll-padding and scroll-snap-type on root propagate to viewport

[fantasai]

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).

[fantasai]

Agenda+ to confirm substantive change, republish CR.

[css-meeting-bot]

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

[hiikezoe]

@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.

[fantasai]

@hiikezoe Yes. Thanks. Fixed. :)