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

Re: [csswg-drafts] [css-overflow] Selective overflow: hidden (#3417)

From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
Date: Fri, 30 Jul 2021 00:03:27 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-889534819-1627603406-sysbot+gh@w3.org>
To summarize, the CSSWG discussion roughly concluded that:
* as far as tooltips are concerned, this is likely going to be addressed by https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/CSSAnchoredPositioning/explainer.md
* As far as outlines are concerned, it's complicated:
  * We cannot make it apply to all outlines. Some are used for focus, some are used for decoration. So anything would have to be opt-in
  * We can think of various ways to make the outline visible. But none of them are great: either they are very complex to implement, or provide no so great UX, or both. For example, if you just don't clip the outlines at all, you can end up with visible outlines around scrolled-out-of-view elements, or around partly scrolled-out-of-view elements, and that's not great. Pulling the outline to the top layer would have that problem, compounded by the fact that the element might be obscured by something else on top. We'd probably get a somewhat more pleasant UX by having two different clip-bounds for a scroll container: one for everything, and another one, slightly larger, just for outlines. But given the complexity of stacking contexts, z-index, compositing, various kind of clipping, etc, this is something no implementer would be interested in doing.
  * This problem also exist in native platform's UI toolkits, and they'd don't deal with it either as far as we know.
  * We also considered including `outline-style: auto` outlines in the scrollable overflow instead of the ink overflow. That wouldn't really help with the stated use case of `overflow:hidden`, but it might be better for related situation with `overflow:scroll` or `overflow: auto`. But means that outlines appearing and being removed as people focus things in and out would now have an impact on layout, and that doesn't seem reasonable.
  All in all, while the CSS-WG sympathizes with the problem, we didn't think it was practical to address it.

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

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 30 July 2021 00:03:29 UTC

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