W3C home > Mailing lists > Public > public-css-archive@w3.org > July 2021

Re: [csswg-drafts] [css-overflow-3] Clarify padding-bottom in overflow content (#129)

From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
Date: Tue, 27 Jul 2021 23:33:52 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-887901550-1627428830-sysbot+gh@w3.org>
As far as I can tell, other than possible editorial tweaks to make the prose cleaner, the only reminaing open quesiton is that of “[3]” in https://github.com/w3c/csswg-drafts/issues/129: do we add that padding in the inline-end of block-flow or not (limited to the case of justify-content: normal).

I think that:
* adding it is nicer in terms of readibility / spacing, as it allows content not to smash in the border even though you specified padding.
* adding it in places where it wasn't included before is likely to cause scrollbars to appear where they were none before, and that would be considered unacceptable breakage

That would mean that even though the current webkit/blink behavior is odd, it represents the most padding we'll ever get, so we might want to spec that.

However, the blink/webkit "odd" behavior is *really* odd: they  add the scroll container’s padding to the inline-end of inline *children* of the container, but not to other descendents of the container, be they block containers or inline descendents other than children.

This is not just weird, it also violates the principle that inserting an unstyled div should make no difference to the layout.

We probably should for consistency, and never add that padding to the inline-end.

-- 
GitHub Notification of comment by frivoal
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/129#issuecomment-887901550 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 27 July 2021 23:33:53 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:39 UTC