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

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

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Thu, 29 Jul 2021 23:49:02 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-889530475-1627602540-sysbot+gh@w3.org>
The CSS Working Group just discussed `Selective overflow: hidden`, and agreed to the following:

* `RESOLVED: Close with no change`

<details><summary>The full IRC log of that discussion</summary>
&lt;emilio> topic: Selective overflow: hidden<br>
&lt;emilio> github: https://github.com/w3c/csswg-drafts/issues/3417<br>
&lt;emilio> florian: so the issue was raised about two topics but I want to focus on one<br>
&lt;emilio> ... there's someone who wants some amount of things to escape overflow: hidden<br>
&lt;emilio> ... the one I want to talk about is focus outlines<br>
&lt;emilio> ... because not seeing them is an accessibility issue<br>
&lt;emilio> ... there are various situations where this can happen<br>
&lt;emilio> ... one is you have a scroller...<br>
&lt;emilio> ... another is where the thing is completely hidden<br>
&lt;emilio> ... the problematic one is where the thing getting focus is completely visible<br>
&lt;emilio> ... in the UI spec we say that UAs have a fair amount of flexibility<br>
&lt;emilio> ... I don't think UAs take advantage of that<br>
&lt;emilio> ... but that's the question<br>
&lt;emilio> ... the issue was also hinting about positioned elements and such, but we've talked about those<br>
&lt;emilio> ... but for outlines there's no great conclusion<br>
&lt;emilio> smfr: how are focus outlines different from other outlines?<br>
&lt;smfr> s/smfr/Rossen/<br>
&lt;emilio> florian: they have different purposes<br>
&lt;emilio> ... there's a special value that can be different, `outline-style: auto`<br>
&lt;emilio> ... if you change it you are on your own but `outline-style: auto` is intended to provide that flexibility<br>
&lt;emilio> Rossen: on windows we don't have "native" outlines<br>
&lt;emilio> ... they're made to look and behave as similar to the ones in the OS<br>
&lt;emilio> ... but they're not native<br>
&lt;emilio> ... they're native to the browser, and yeah there's a default-ua-styled outline<br>
&lt;emilio> ... but (a) I don't believe this is any different than any outline from outline handling point-of-view<br>
&lt;emilio> ... (b) if other outlines are specified by the user (e.g. excel has multiple focuses etc)<br>
&lt;emilio> ... in all these things there's no "native" outline, it's overridden by the app<br>
&lt;emilio> ... how would we know they're used as focus indicators to give them this kind of behavior?<br>
&lt;emilio> ... so [reinstates]<br>
&lt;astearns> s/rein/re/<br>
&lt;emilio> ... it'll be difficult to try and categorize these two buckets and give them different behavior<br>
&lt;emilio> ... so I'd like this behavior to apply to both outlines<br>
&lt;emilio> q+<br>
&lt;flackr> q+<br>
&lt;emilio> florian: but outlines can be decorative and that'd have no reason to escape overflow<br>
&lt;emilio> ... so we'd need a different property or such<br>
&lt;emilio> Rossen: if you want a different outline value that the UA can use for its focus outlines, then that's reasonable<br>
&lt;emilio> florian: I'm not saying we should do that, but if we do then we should probably not make it automatic<br>
&lt;astearns> ack emilio<br>
&lt;astearns> emilio: agree with rossen. outline:auto can be special. focus outlines can look similar to carets - browers currently agree on what clips carets<br>
&lt;emilio> florian: difference with caret is that it's inside the thing, not around it<br>
&lt;emilio> ... so you won't clip the entirety of the caret usually<br>
&lt;emilio> ... but yeah not sure it changes the main point<br>
&lt;astearns> ack flackr<br>
&lt;emilio> flackr: two things. If we decided not to clip outlines, there'd be a bunch of edge cases with partially-clipped elements<br>
&lt;dholbert> q+<br>
&lt;emilio> ... I'm concerned about getting that right from an aesthetic POV<br>
&lt;emilio> ... can we modify the clip box? Providing an extra space for that?<br>
&lt;dbaron[m]> One thought, though, is about clipping of outlines on elements that are clipped...<br>
&lt;emilio> astearns: in some cases you don't know the dimensions of the outline<br>
&lt;Rossen_> q?<br>
&lt;emilio> flackr: yeah, won't solve all cases<br>
&lt;emilio> Rossen_: that was my idea with the optional outline value<br>
&lt;emilio> ... would be per element, would expand the clipping bounds<br>
&lt;emilio> ... you have the ability of today (clipped) and the new thing<br>
&lt;astearns> emilio: that would still cause the issue flackr raised - should not show the whole outline and not the button in a scroller<br>
&lt;astearns> ack dholbert<br>
&lt;emilio> dholbert: I have an adjacent scenario which is `contain: paint`<br>
&lt;emilio> ... if we are going to fix this in overflow: hidden, should it also escape `overflow: clip` and `contain: paint`?<br>
&lt;emilio> ... and would it break `contain: paint`?<br>
&lt;emilio> flackr: it would but fwiw you can expand the clip area of `contain: paint` (`overflow-clip-margin`)<br>
&lt;emilio> dholbert: yeah, but assuming these outlines are sorta implementation-defined it seems hard<br>
&lt;smfr> q+<br>
&lt;emilio> astearns: do you want a resolution for this? it seems there's consensus on making this opt-in, but work on all outlines<br>
&lt;astearns> ack smfr<br>
&lt;emilio> florian: yeah, that's enough discussion I think<br>
&lt;emilio> smfr: I'm concerned about implementation complexity if we need to track different bounds for outlines<br>
&lt;emilio> ... I think I've heard "only outlines would be painted outside the clipping area", but maybe that's not the case?<br>
&lt;emilio> florian: we weren't describing precisely describing how it'd work<br>
&lt;emilio> smfr: this is a source of incredible complexity for implementors<br>
&lt;emilio> Rossen_: I'd like to amend what I said, which is a compromised first step would be to at least consider the "special" areas as scrollable overflow<br>
&lt;emilio> ... in the specific use case here (something positioned and overflow: hidden, then it's there)<br>
&lt;emilio> q+<br>
&lt;emilio> Rossen_: having these outlines add to the scrollable overflow would be enough<br>
&lt;emilio> ... the second layer of having these outlines escape I agree is very complex<br>
&lt;astearns> ack emilio<br>
&lt;smfr> q+<br>
&lt;smfr> q-<br>
&lt;smfr> q+<br>
&lt;emilio> smfr: the commenter was asking about escaping overflow: hidden, not scrollable overflow right?<br>
&lt;emilio> fantasai: making them scrollable overflow will change layout changes, and you probably don't want that<br>
&lt;fantasai> s/change layout/cause layout/<br>
&lt;emilio> smfr: we should make easy for authors to add the relevant padding around things<br>
&lt;emilio> ???: Do native platforms have the same issues?<br>
&lt;emilio> smfr: yes<br>
&lt;emilio> smfr: another usecase of the proposal was tooltips, isn't there a different proposal for that? anchored-positioning?<br>
&lt;emilio> florian: do you have links for that?<br>
&lt;emilio> smfr: I think gregwhitworth was working on that<br>
&lt;smfr> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/CSSAnchoredPositioning/explainer.md<br>
&lt;emilio> astearns: can you summarize and talk to the original proposer?<br>
&lt;emilio> florian: we can close now and re-open if the OP is not satisfied<br>
&lt;emilio> RESOLVED: Close with no change<br>
&lt;emilio> astearns: it was interesting to go through the options and strike-through all of them<br>
&lt;emilio> florian: yeah I thought it was better on a call than letting it linger for a couple years<br>

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

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 29 July 2021 23:49:04 UTC

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