-
Notifications
You must be signed in to change notification settings - Fork 677
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-overflow-4] Do not remove overflow: overlay #6090
Comments
(I'm sad about this and really wish we could all move to overlay scrollbars, as it would make many parts of CSS less complicated, but oh well.) |
sooo.. there is nothing we could do? |
Specs can't force implementations; they exist to help increase interoperability between implementations (and guide the design of features in conjunction with the impls). We currently have one major impl (Safari) with a stated preference for definitely not doing this, and the other impls are at best apathetic about the feature at the moment. So, from the spec side of things, there's not much we can do; I prefer writing specifications, not speci-fiction. ^_^ From the author side, you can put pressure on the impls by filing bugs or +1ing existing bugs, and/or making noise and gathering support on blogs and social media. If the impls change their stance as a result of webdev pressure, we can revisit the issue. |
Also, note that while that's not exactly the same thing, there's also the |
I saw it, not sure if any browsers support it yet. I tried using it. |
Chromium based browsers still have an implementation of Sebastian |
I can dig it up if necessary, but @smfr was very explicit about considering |
I made it a synonym for overflow:auto in webkit: https://trac.webkit.org/changeset/236341/webkit |
@smfr they might be the same at the first sight also with |
Not yet, but should be coming soon to a chrome near you. |
So it seems to be that time, apperantly. The So I did do that, However, I don't think I have figured out how to use the property properly or maybe it is broken, I'm not sure. Are there any examples with |
To those confused, |
I was told to create a comment here again, to create a follow up. What acts as a new way to create overlay scrollbars? A way to make the scrollbar-gutter go in overlay mode. Did anyone get that to work? |
Can you show some examples of where author control over whether scrollbars are overlay scrollbars would be useful? |
@smfr what a bizarre question. Could you define "useful" a bit more strictly? After all, you could say none of CSS is "useful". Here's a stab at it, at least: Author control over overlay scrollbars is useful because it let's you create layouts that work the same on all platforms, and don't need to handle having overflow and not differently, and make more space available for interesting content, and they are just better looking, and in fact every platform has moved to using some variant of them in their native UX, so they are more familiar than gutter scrollbars to most users. Is that enough? |
To allow the gutter of the scrollbar have a transparent background, potentially hiding it when it is unused or something. The workaround might be javascript, but it destroys the integration features from browsers. With integration features, I mean stuff like this: When using CTRL + F as example. This wouldn't easily be possible if the entire scrollbar has to get removed. See this JSFiddle in Google Chrome as an example: https://jsfiddle.net/3awLgj5v/ |
The choice of whether scrollbars should be overlay scrollbars or not is generally a user choice, not a web author choice. If the user chose overlay scrollbars at the OS level, overriding this decision at the author level is not very user-friendly (same with the opposite). |
When is it a user choice to have overlay scrollbars? I can't think of any examples, it's always an artifact of the OS or UI library being used. Given that the web equivalent to a UI library is generally expected to be building your components completely styled (or rebuilt and replaced!) with CSS it seems entirely in scope to have any and all appearance and behavior be author controlled for any component within the viewport, at least in theory, and scrollbars are a glaring exception. (It's not the only one: select is also famously difficult to customize to fit in with the rest of the design or to add desired features, but at least that is replaceable cleanly; custom reimplementations of scrollbars have many terrible effects) |
It was way easier to do it with CSS. Why require JS? |
@karl-police not sure what you mean: this issue is about being able to use CSS. I'm not advocating using JS for a scrollbar, literally the opposite, but there are plenty of people who have done exactly that (with all the problems) because we don't have any portable way to do it with CSS. |
you mean a way to do it with CSS, with custom rules? or with overflow: overlay? |
This should be first a choice of the developers before the users. Let me argue. Let's say you have a web application and you have several groups stacked on top of each other that scroll to the right (horizontally). By defining "overlay" as an alias of "auto", the vertical scroll bar of the page will cause a hole on the right border of the interface. What do you think will happen? Users will complain to the web developers that the interface is "glitched" and that the horizontally scrollable groups cut off before reaching the end of the window in width. Maybe I'm wrong, and I sincerely hope I'm wrong, but the scrollbar-gutter feature doesn't seem to fix this problem at all and it will simply cause a deep and sincere sense of hatred among users because their favorite applications/websites are broken. Maybe there is a modern solution to this problem but it is funny to think that those who want the overlay alias have not proposed any alternative. "Excuse us, there is nothing we can do about it. This is a feature that has been removed by web browser developers." Here's what's going to happen. Do you really think about the web developers before you start removing features you consider "useless" or "unknown to you"? What right do you have to consider these features as unused or unknown? On what do you base such nonsense? Do you have any statistics on the use of the overlay value on the whole web? I don't think so. The ones who will receive the complaints from the users will be without a doubt neither the developers of these browsers, nor the ones who decided to remove this feature, but us, developers. I may sound like an angry person here, but at some point someone has to say it. Let me speak for all the web applications you are going to break. What alternative do we have before our web applications get broken by this change? |
So since |
@Paper-Folding, use |
This property currently has not supported by chrome browser, I don't regard this as a good solution, at least for now. |
It is, see https://bugs.chromium.org/p/chromium/issues/detail?id=891944 and https://bugs.webkit.org/show_bug.cgi?id=231590 for progress. |
@rthrejheytjyrtj545 It's not a proper replacement since the scrollbar will still push the content in rather than being displayed over the content. |
@patrickgalbraith, of course, but no one (Apple Inc.) is going to return the original. You can use JS to calculate the width of the scrollbar and |
@rthrejheytjyrtj545 I have tried that approach but it doesn't work unfortunately and introduces a lot of edge cases. |
Is there any other way to produce the same effect? |
Removing this from potentially being adopted by the wider web was a huge mistake. I mean look at this mess it's worse for A11y than this one property. |
@smfr Fixed |
This is a thoughtless "solution" to an entirely made-up problem. There was a 20% increase in usage of This "solution" goes against the interests of web developers and it is very effectively degrading user experience across hundreds of UI frameworks that contain lightboxes (image galleries) and overlay dialogs. Most use With this alias degradation there are now millions of devices running Chromium browsers wasting their CPU cycles on layout recomputes in response to pointless reflows caused by the lack of overlay scrollbars. Similarly, loading screens (aka splash screens) of web apps are affected as there is an immediate layout shift once the splash screen is hidden leading to a terrible first impression. As of today, July 11, 2023, there are no standardized CSS-only alternatives to <body> Lack of implementation from WebKit team has marginal overall impact with their low penetration on desktop market where overlay scrollbars are not system default. |
This issue has been closed and there is no interest in reopening it in the CSSWG. I am also sad we don't have overlay scrollbars everywhere, but in the absence of agreement among browser vendors to ship this, adding it to the spec won't accomplish anything. As I stated in the beginning of this issue, the appropriate place to register complaints is with browser vendors. I'm going to lock this issue, as further discussion won't accomplish anything. |
I came from https://stackoverflow.com/questions/23200639/transparent-scrollbar-with-css/56365213#56365213 where someone commented that "overlay" would be deprecated.
I saw on stackoverflow that people do still find that question and find it very helpful. So, I asked at Mozilla mail and they linked me this #92 and then told me to go to MDN for uhh... I believe it was related to push changes for the docs. But I came here instead, to know if it is still deprecated.
So, is it still deprecrated? And if yes, can this be undone? It's still being used? Hm, I do believe there are better ways to maybe implement the feature, so "overflow" can be used for other things, but I didn't see that yet.
The text was updated successfully, but these errors were encountered: