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