You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Nope! Hasn't been discussed before. Afaict tooltips are not clipped by overflow: hidden, but it seems like focus outlines are. See testcase.
Afaict the CSS specs explicitly allow focus outlines to be painted over everything else in https://www.w3.org/TR/CSS2/zindex.html#outlines but it probably looks weird to draw an outline around something that's invisible. Do you have some examples of where this is a problem for you?
Cropped tooltip: https://radogado.github.io/natuive/demos/postbank/#credit (red circle with question mark)
Focus outline: no example, but anytime a focused element is at the edge of a container with overflow: hidden, the default focus outline is cropped. I had to move the outline inside the element, but that's not ideal.
I think at least the outline should always be visible, it makes no sense to be cropped by overflow: hidden.
Thanks!
There is the trick of using position: absolute in the child and position: static in the parent, so that the containing block of the child is an ancestor of the parent. The problem is that usually I want to position or size the child with respect to the parent, which is not easy if the containing block is something else.
Yes, @fantasai was talking about native tooltips, which are rendered atop everything. That page is just showing some in-page element, which is affected by stacking/clipping contexts.
CSS is bound (for many reasons, mostly good) by the stacking/clipping context tree. "Escaping" that is difficult. The correct way to avoid being clipped by an ancestor is to not have an ancestor that clips you; in-page tooltips should be rendered as children of <body> and positioned with JS.
@tabatkins great advice, I'll rewrite my tooltip as child of body. Clipping the focus outline, though, makes no sense and is an accessibility problem. Thanks!
Not only that, but I for example for tooltips on buttons that need to have
overflow: hidden because they contain images (for example on crew profile
in contact page).
That will be very useful to have.
On Mon, 17 Dec 2018 at 11:02, Radoslav Sharapanov ***@***.***> wrote:
Another example would be a carousel where I need the controls to be
outside and visible, while the content is hidden. Something like
overflow-absolute-children: visible;
would be very useful. Thanks.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#3417 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AI0jbqwaQ1N8gAZzrV8DVaR2p-lV7bYsks5u52uwgaJpZM4ZLdF9>
.
Another example would be a carousel where I need the controls to be outside and visible
@radogado Can you show this example of the layout you are talking about and explain why your controls would be structured inside what needs to have hidden/scrollable overflow, but have their box(es) rendered outside? Can't imagine any scenario where I wouldn't just have the controls structured outside in the first place, as I wouldn't want them moving within the carousels hidden overflow?
The focus ring (outline) shouldn't be hidden by overflow rules. Currently it is cropped by overflow: hidden. It looks ugly and broken and the efforts for workarounds are too great and unnecessary. It's a pain for people trying to make sites accessible. Please at least add a CSS option to always display the focus ring.
Given the significant impl complexity of allowing some things to draw outside of an overflowing box, versus the quite trivial complexity of an author ensuring there's a little bit of padding on the box, and taking into the account the relatively small pain from authors not doing that (one edge of an outline doesn't show), I believe the right answer is to do nothing here, and evangelize when necessary to get pages to do their layouts slightly better.
Same. There are relatively simple layout-based solutions to make those cases usable (such as wrapping the possibly-overflowing content in a wrapper with overflow:auto).
For separate reasons, we're also pursuing specifying the "top layer" positioning mode that things like dialog and fullscreen elements in HTML use, so authors can have individual elements totally escape all containing contexts and be displayed on top of everything else in the page; this requires slightly more complexity in the JS, but will allow for things like the "custom autocomplete list that doesn't get clipped or overlapped while it's displayed" use-case to be done well.
The CSS Working Group just discussed Selective overflow: hidden, and agreed to the following:
RESOLVED: Close with no change
The full IRC log of that discussion
<emilio> topic: Selective overflow: hidden
<emilio> github: https://github.com//issues/3417
<emilio> florian: so the issue was raised about two topics but I want to focus on one
<emilio> ... there's someone who wants some amount of things to escape overflow: hidden
<emilio> ... the one I want to talk about is focus outlines
<emilio> ... because not seeing them is an accessibility issue
<emilio> ... there are various situations where this can happen
<emilio> ... one is you have a scroller...
<emilio> ... another is where the thing is completely hidden
<emilio> ... the problematic one is where the thing getting focus is completely visible
<emilio> ... in the UI spec we say that UAs have a fair amount of flexibility
<emilio> ... I don't think UAs take advantage of that
<emilio> ... but that's the question
<emilio> ... the issue was also hinting about positioned elements and such, but we've talked about those
<emilio> ... but for outlines there's no great conclusion
<emilio> smfr: how are focus outlines different from other outlines?
<smfr> s/smfr/Rossen/
<emilio> florian: they have different purposes
<emilio> ... there's a special value that can be different, `outline-style: auto`
<emilio> ... if you change it you are on your own but `outline-style: auto` is intended to provide that flexibility
<emilio> Rossen: on windows we don't have "native" outlines
<emilio> ... they're made to look and behave as similar to the ones in the OS
<emilio> ... but they're not native
<emilio> ... they're native to the browser, and yeah there's a default-ua-styled outline
<emilio> ... but (a) I don't believe this is any different than any outline from outline handling point-of-view
<emilio> ... (b) if other outlines are specified by the user (e.g. excel has multiple focuses etc)
<emilio> ... in all these things there's no "native" outline, it's overridden by the app
<emilio> ... how would we know they're used as focus indicators to give them this kind of behavior?
<emilio> ... so [reinstates]
<astearns> s/rein/re/
<emilio> ... it'll be difficult to try and categorize these two buckets and give them different behavior
<emilio> ... so I'd like this behavior to apply to both outlines
<emilio> q+
<flackr> q+
<emilio> florian: but outlines can be decorative and that'd have no reason to escape overflow
<emilio> ... so we'd need a different property or such
<emilio> Rossen: if you want a different outline value that the UA can use for its focus outlines, then that's reasonable
<emilio> florian: I'm not saying we should do that, but if we do then we should probably not make it automatic
<astearns> ack emilio
<astearns> emilio: agree with rossen. outline:auto can be special. focus outlines can look similar to carets - browers currently agree on what clips carets
<emilio> florian: difference with caret is that it's inside the thing, not around it
<emilio> ... so you won't clip the entirety of the caret usually
<emilio> ... but yeah not sure it changes the main point
<astearns> ack flackr
<emilio> flackr: two things. If we decided not to clip outlines, there'd be a bunch of edge cases with partially-clipped elements
<dholbert> q+
<emilio> ... I'm concerned about getting that right from an aesthetic POV
<emilio> ... can we modify the clip box? Providing an extra space for that?
<dbaron[m]> One thought, though, is about clipping of outlines on elements that �are� clipped...
<emilio> astearns: in some cases you don't know the dimensions of the outline
<Rossen_> q?
<emilio> flackr: yeah, won't solve all cases
<emilio> Rossen_: that was my idea with the optional outline value
<emilio> ... would be per element, would expand the clipping bounds
<emilio> ... you have the ability of today (clipped) and the new thing
<astearns> emilio: that would still cause the issue flackr raised - should not show the whole outline and not the button in a scroller
<astearns> ack dholbert
<emilio> dholbert: I have an adjacent scenario which is `contain: paint`
<emilio> ... if we are going to fix this in overflow: hidden, should it also escape `overflow: clip` and `contain: paint`?
<emilio> ... and would it break `contain: paint`?
<emilio> flackr: it would but fwiw you can expand the clip area of `contain: paint` (`overflow-clip-margin`)
<emilio> dholbert: yeah, but assuming these outlines are sorta implementation-defined it seems hard
<smfr> q+
<emilio> astearns: do you want a resolution for this? it seems there's consensus on making this opt-in, but work on all outlines
<astearns> ack smfr
<emilio> florian: yeah, that's enough discussion I think
<emilio> smfr: I'm concerned about implementation complexity if we need to track different bounds for outlines
<emilio> ... I think I've heard "only outlines would be painted outside the clipping area", but maybe that's not the case?
<emilio> florian: we weren't describing precisely describing how it'd work
<emilio> smfr: this is a source of incredible complexity for implementors
<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
<emilio> ... in the specific use case here (something positioned and overflow: hidden, then it's there)
<emilio> q+
<emilio> Rossen_: having these outlines add to the scrollable overflow would be enough
<emilio> ... the second layer of having these outlines escape I agree is very complex
<astearns> ack emilio
<smfr> q+
<smfr> q-
<smfr> q+
<emilio> smfr: the commenter was asking about escaping overflow: hidden, not scrollable overflow right?
<emilio> fantasai: making them scrollable overflow will change layout changes, and you probably don't want that
<fantasai> s/change layout/cause layout/
<emilio> smfr: we should make easy for authors to add the relevant padding around things
<emilio> ???: Do native platforms have the same issues?
<emilio> smfr: yes
<emilio> smfr: another usecase of the proposal was tooltips, isn't there a different proposal for that? anchored-positioning?
<emilio> florian: do you have links for that?
<emilio> smfr: I think gregwhitworth was working on that
<smfr> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/CSSAnchoredPositioning/explainer.md
<emilio> astearns: can you summarize and talk to the original proposer?
<emilio> florian: we can close now and re-open if the OP is not satisfied
<emilio> RESOLVED: Close with no change
<emilio> astearns: it was interesting to go through the options and strike-through all of them
<emilio> florian: yeah I thought it was better on a call than letting it linger for a couple years
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.
@radogado, although this conclusion isn't the one you hoped for, can you confirm that you can live with this conclusion? If not, do you think we overlooked something?
@frivoal Thank you so much for that summary. This issue has long been on my mind since working on Tether many years ago.
I’m quite excited about CSSAnchoredPositioning as described in that doc. Based on a quick reading, it seems to me that a faux-outline could potentially be implemented using a popup as a mimic:
A non-semantic use of “popup” by today’s common understanding of the word within UI design, but perhaps reasonable taken literally as the outline is popping up and out of the otherwise trapped overflow context.
Reacted by Florian Rivoal, Sammy Marsden and Jamie Mason
Activity
fantasai commentedon Dec 10, 2018
Nope! Hasn't been discussed before. Afaict tooltips are not clipped by
overflow: hidden, but it seems like focus outlines are. See testcase.Afaict the CSS specs explicitly allow focus outlines to be painted over everything else in https://www.w3.org/TR/CSS2/zindex.html#outlines but it probably looks weird to draw an outline around something that's invisible. Do you have some examples of where this is a problem for you?
radogado commentedon Dec 11, 2018
Cropped tooltip: https://radogado.github.io/natuive/demos/postbank/#credit (red circle with question mark)
Focus outline: no example, but anytime a focused element is at the edge of a container with overflow: hidden, the default focus outline is cropped. I had to move the outline inside the element, but that's not ideal.
I think at least the outline should always be visible, it makes no sense to be cropped by overflow: hidden.
Thanks!
jonjohnjohnson commentedon Dec 11, 2018
@radogado I think @fantasai was talking about native tooltips that show when a user rests their mouse while hovering elements with a title attribute?
Loirooriol commentedon Dec 12, 2018
There is the trick of using
position: absolutein the child andposition: staticin the parent, so that the containing block of the child is an ancestor of the parent. The problem is that usually I want to position or size the child with respect to the parent, which is not easy if the containing block is something else.tabatkins commentedon Dec 14, 2018
Yes, @fantasai was talking about native tooltips, which are rendered atop everything. That page is just showing some in-page element, which is affected by stacking/clipping contexts.
CSS is bound (for many reasons, mostly good) by the stacking/clipping context tree. "Escaping" that is difficult. The correct way to avoid being clipped by an ancestor is to not have an ancestor that clips you; in-page tooltips should be rendered as children of
<body>and positioned with JS.radogado commentedon Dec 17, 2018
@tabatkins great advice, I'll rewrite my tooltip as child of body. Clipping the focus outline, though, makes no sense and is an accessibility problem. Thanks!
radogado commentedon Dec 17, 2018
Another example would be a carousel where I need the controls to be outside and visible, while the overflowing content is hidden. Something like
would be very useful. Thanks.
Ernedar commentedon Dec 17, 2018
jonjohnjohnson commentedon Dec 17, 2018
@radogado Can you show this example of the layout you are talking about and explain why your controls would be structured inside what needs to have hidden/scrollable overflow, but have their box(es) rendered outside? Can't imagine any scenario where I wouldn't just have the controls structured outside in the first place, as I wouldn't want them moving within the carousels hidden overflow?
radogado commentedon Dec 18, 2018
Yes, the padded slider here: https://radogado.github.io/natuive/#slider
I had to add an additional wrapper to achieve that effect, which isn't ideal.
Thanks
OliverJAsh commentedon Jul 8, 2019
I submitted a use case which could fit into this: #4092
radogado commentedon Jan 3, 2020
Filed WebKit bug https://bugs.webkit.org/show_bug.cgi?id=205642
and @smfr redirected me back here.
Previous Chrome bug: https://bugs.chromium.org/p/chromium/issues/detail?id=462609
Focus ring should also escape masking by -webkit-mask. (Optionally)
Thanks
radogado commentedon Jan 28, 2020
The problem on Apple.com
tabatkins commentedon Jan 28, 2020
Given the significant impl complexity of allowing some things to draw outside of an overflowing box, versus the quite trivial complexity of an author ensuring there's a little bit of padding on the box, and taking into the account the relatively small pain from authors not doing that (one edge of an outline doesn't show), I believe the right answer is to do nothing here, and evangelize when necessary to get pages to do their layouts slightly better.
OliverJAsh commentedon Jan 28, 2020
@tabatkins How about more complicated use cases such as #4092?
tabatkins commentedon Jan 28, 2020
Same. There are relatively simple layout-based solutions to make those cases usable (such as wrapping the possibly-overflowing content in a wrapper with overflow:auto).
For separate reasons, we're also pursuing specifying the "top layer" positioning mode that things like
dialogand fullscreen elements in HTML use, so authors can have individual elements totally escape all containing contexts and be displayed on top of everything else in the page; this requires slightly more complexity in the JS, but will allow for things like the "custom autocomplete list that doesn't get clipped or overlapped while it's displayed" use-case to be done well.radogado commentedon Jan 29, 2020
The focus ring is a vital part of the global OS interaction and shouldn't be bound to page layout rules.
frivoal commentedon Jul 28, 2021
Agenda+ to seek group feedback on this issue.
css-meeting-bot commentedon Jul 29, 2021
The CSS Working Group just discussed
Selective overflow: hidden, and agreed to the following:RESOLVED: Close with no changeThe full IRC log of that discussion
<emilio> topic: Selective overflow: hidden<emilio> github: https://github.com//issues/3417
<emilio> florian: so the issue was raised about two topics but I want to focus on one
<emilio> ... there's someone who wants some amount of things to escape overflow: hidden
<emilio> ... the one I want to talk about is focus outlines
<emilio> ... because not seeing them is an accessibility issue
<emilio> ... there are various situations where this can happen
<emilio> ... one is you have a scroller...
<emilio> ... another is where the thing is completely hidden
<emilio> ... the problematic one is where the thing getting focus is completely visible
<emilio> ... in the UI spec we say that UAs have a fair amount of flexibility
<emilio> ... I don't think UAs take advantage of that
<emilio> ... but that's the question
<emilio> ... the issue was also hinting about positioned elements and such, but we've talked about those
<emilio> ... but for outlines there's no great conclusion
<emilio> smfr: how are focus outlines different from other outlines?
<smfr> s/smfr/Rossen/
<emilio> florian: they have different purposes
<emilio> ... there's a special value that can be different, `outline-style: auto`
<emilio> ... if you change it you are on your own but `outline-style: auto` is intended to provide that flexibility
<emilio> Rossen: on windows we don't have "native" outlines
<emilio> ... they're made to look and behave as similar to the ones in the OS
<emilio> ... but they're not native
<emilio> ... they're native to the browser, and yeah there's a default-ua-styled outline
<emilio> ... but (a) I don't believe this is any different than any outline from outline handling point-of-view
<emilio> ... (b) if other outlines are specified by the user (e.g. excel has multiple focuses etc)
<emilio> ... in all these things there's no "native" outline, it's overridden by the app
<emilio> ... how would we know they're used as focus indicators to give them this kind of behavior?
<emilio> ... so [reinstates]
<astearns> s/rein/re/
<emilio> ... it'll be difficult to try and categorize these two buckets and give them different behavior
<emilio> ... so I'd like this behavior to apply to both outlines
<emilio> q+
<flackr> q+
<emilio> florian: but outlines can be decorative and that'd have no reason to escape overflow
<emilio> ... so we'd need a different property or such
<emilio> Rossen: if you want a different outline value that the UA can use for its focus outlines, then that's reasonable
<emilio> florian: I'm not saying we should do that, but if we do then we should probably not make it automatic
<astearns> ack emilio
<astearns> emilio: agree with rossen. outline:auto can be special. focus outlines can look similar to carets - browers currently agree on what clips carets
<emilio> florian: difference with caret is that it's inside the thing, not around it
<emilio> ... so you won't clip the entirety of the caret usually
<emilio> ... but yeah not sure it changes the main point
<astearns> ack flackr
<emilio> flackr: two things. If we decided not to clip outlines, there'd be a bunch of edge cases with partially-clipped elements
<dholbert> q+
<emilio> ... I'm concerned about getting that right from an aesthetic POV
<emilio> ... can we modify the clip box? Providing an extra space for that?
<dbaron[m]> One thought, though, is about clipping of outlines on elements that �are� clipped...
<emilio> astearns: in some cases you don't know the dimensions of the outline
<Rossen_> q?
<emilio> flackr: yeah, won't solve all cases
<emilio> Rossen_: that was my idea with the optional outline value
<emilio> ... would be per element, would expand the clipping bounds
<emilio> ... you have the ability of today (clipped) and the new thing
<astearns> emilio: that would still cause the issue flackr raised - should not show the whole outline and not the button in a scroller
<astearns> ack dholbert
<emilio> dholbert: I have an adjacent scenario which is `contain: paint`
<emilio> ... if we are going to fix this in overflow: hidden, should it also escape `overflow: clip` and `contain: paint`?
<emilio> ... and would it break `contain: paint`?
<emilio> flackr: it would but fwiw you can expand the clip area of `contain: paint` (`overflow-clip-margin`)
<emilio> dholbert: yeah, but assuming these outlines are sorta implementation-defined it seems hard
<smfr> q+
<emilio> astearns: do you want a resolution for this? it seems there's consensus on making this opt-in, but work on all outlines
<astearns> ack smfr
<emilio> florian: yeah, that's enough discussion I think
<emilio> smfr: I'm concerned about implementation complexity if we need to track different bounds for outlines
<emilio> ... I think I've heard "only outlines would be painted outside the clipping area", but maybe that's not the case?
<emilio> florian: we weren't describing precisely describing how it'd work
<emilio> smfr: this is a source of incredible complexity for implementors
<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
<emilio> ... in the specific use case here (something positioned and overflow: hidden, then it's there)
<emilio> q+
<emilio> Rossen_: having these outlines add to the scrollable overflow would be enough
<emilio> ... the second layer of having these outlines escape I agree is very complex
<astearns> ack emilio
<smfr> q+
<smfr> q-
<smfr> q+
<emilio> smfr: the commenter was asking about escaping overflow: hidden, not scrollable overflow right?
<emilio> fantasai: making them scrollable overflow will change layout changes, and you probably don't want that
<fantasai> s/change layout/cause layout/
<emilio> smfr: we should make easy for authors to add the relevant padding around things
<emilio> ???: Do native platforms have the same issues?
<emilio> smfr: yes
<emilio> smfr: another usecase of the proposal was tooltips, isn't there a different proposal for that? anchored-positioning?
<emilio> florian: do you have links for that?
<emilio> smfr: I think gregwhitworth was working on that
<smfr> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/CSSAnchoredPositioning/explainer.md
<emilio> astearns: can you summarize and talk to the original proposer?
<emilio> florian: we can close now and re-open if the OP is not satisfied
<emilio> RESOLVED: Close with no change
<emilio> astearns: it was interesting to go through the options and strike-through all of them
<emilio> florian: yeah I thought it was better on a call than letting it linger for a couple years
frivoal commentedon Jul 30, 2021
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:
outline-style: autooutlines in the scrollable overflow instead of the ink overflow. That wouldn't really help with the stated use case ofoverflow:hidden, but it might be better for related situation withoverflow:scrolloroverflow: 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.
frivoal commentedon Jul 30, 2021
@radogado, although this conclusion isn't the one you hoped for, can you confirm that you can live with this conclusion? If not, do you think we overlooked something?
adamschwartz commentedon Aug 5, 2021
@frivoal Thank you so much for that summary. This issue has long been on my mind since working on Tether many years ago.
I’m quite excited about CSSAnchoredPositioning as described in that doc. Based on a quick reading, it seems to me that a faux-outline could potentially be implemented using a popup as a mimic:
A non-semantic use of “popup” by today’s common understanding of the word within UI design, but perhaps reasonable taken literally as the outline is popping up and out of the otherwise trapped overflow context.