Bug 244357

Summary: overflow overlay missing
Product: WebKit Reporter: John A. Bilicki III <jab_creations>
Component: ScrollingAssignee: Nobody <webkit-unassigned>
Status: RESOLVED DUPLICATE    
Severity: Normal CC: ahmad.saleem792, karlcow, mmaxfield, simon.fraser, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: Safari 15   
Hardware: Unspecified   
OS: Unspecified   
See Also: https://bugs.webkit.org/show_bug.cgi?id=244783
Attachments:
Description Flags
PArtial PNG screensshot of recent project showing centered text not vertically aligned with one parent scrolling and the other is not.
none
Test
none
Two h2 elements, one within overflow, the other is not. While both centered visually the two compared appear "off" because of the scrollbar hence why overflow: overlay is neccesary. none

John A. Bilicki III
Reported 2022-08-25 13:35:19 PDT
While working on a graphically rich visual design I noticed that the text on the second row was not properly centered with the text on the first row. The second row had a scrollbar and thus the scrollbar's width offset the position of the text on the second row which made it look unprofessional. After some research I came across overflow: overlay; and it immediately fixed the issue! Well, at least in Blink/Chrome. In the DOM Inspector Safari 15.6 shows both overflow: overlay; and overflow-y: overlay; without any complaints however the text on the two rows is clearly not centered. - I could theoretically superficially muck up my code and add some horizontal margin to try to balance it out however that is a temporary fix and not cross-browser compatible (would break Blink/Chrome). - The caniuse website suggests that it was deprecated in favor of scrollbar-gutter...did...did anyone actually ready what scrollbar-gutter does?! I could theoretically use it on the first row instead of overflow: overlay for the scrolling parent of the second row...however Safari doesn't support this either. Though scrollbar-gutter is at best an inverted approach and while welcome in it's own right over-complicates things in this scenario. - I can't use scrollbar-width because it's total subjective trash that has zero cross-browser OR cross-platform compatibility because Apple, Google, Microsoft and Mozilla will NOT inherently agree to what "thin" means and the fools working on it refused to implement ANY STANDARD EXISTING VALUES thus absolutely negating the point of that CSS property. 🙄︀ - Safari apparently supported overflow: overlay;...and then someone disabled it internally...why?! So someone please plug that part of the code back in and tell whoever broke it to leave it alone!
Attachments
PArtial PNG screensshot of recent project showing centered text not vertically aligned with one parent scrolling and the other is not. (12.94 KB, image/png)
2022-09-01 15:08 PDT, John A. Bilicki III 		no flags
Details
Test (280 bytes, text/html)
2022-09-07 22:34 PDT, Myles C. Maxfield 		no flags
Details
Two h2 elements, one within overflow, the other is not. While both centered visually the two compared appear "off" because of the scrollbar hence why overflow: overlay is neccesary. (1.13 KB, application/xhtml+xml)
2022-09-08 00:00 PDT, John A. Bilicki III 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Simon Fraser (smfr)
Comment 1 2022-08-25 13:46:56 PDT
overflow:overlay is treated like overflow:auto in Safari. You can get some context here: https://github.com/w3c/csswg-drafts/issues/6090
John A. Bilicki III
Comment 2 2022-08-25 14:02:32 PDT
Simon, fantastic! Found a link on that page to where the code that broke this feature can be found which is here: https://trac.webkit.org/changeset/236341/webkit Please undo the damages so we don't have to keep convoluting our code to get text centered properly.
Simon Fraser (smfr)
Comment 3 2022-08-25 14:08:07 PDT
WebKit has no intention to re-implement overflow:overlay. Whether scrollbars are overlay or not is a user decision (system-wide), not an author decision.
John A. Bilicki III
Comment 4 2022-08-28 07:47:55 PDT
Progress is the reduction of suffering. I read the rest of that page and your attempt to appear reasonable was absolutely in vain. You have decided to misuse your position to enforce your personal petty beliefs on literally an entire platform wasting thousands of hours if not more of designers and developers struggling to make things right for their clients. Additionally you speak as though you represent the entirity of WebKit to feed your own petty ego. You are nothing short of a petty tyrant and all "standards" you and people like you are null and void.
Myles C. Maxfield
Comment 5 2022-08-28 15:12:01 PDT
This kind of language is unacceptable. Please be more professional or you will be banned. Can you describe the technical problem you’re trying to solve in more detail (ideally by attaching a reduced HTML page? I’m having trouble understanding what you mean when you say “second row” and “first row.” Are you using a table? Are you trying to get a particular interaction of the scroll track and horizontal centering?
Radar WebKit Bug Importer
Comment 6 2022-09-01 13:36:16 PDT
<rdar://problem/99454720>
John A. Bilicki III
Comment 7 2022-09-01 15:08:38 PDT
Created attachment 462081 [details] PArtial PNG screensshot of recent project showing centered text not vertically aligned with one parent scrolling and the other is not. Myles, in my designs I never have the <body> overflow as it means the menus will disappear from view after scrolling. So I create a <div id="body"> element as the primary scrolling element. The base DOM appears as so: <body> <div id="body"><h1>Primary Header</h1></div> <header> <nav id="location">...</nav> <nav id="menu">...</nav> </header> <footer>...</footer> </body> The #location and #menu are in the primary header (body > header). Since there is no scrollbar (overflow: visible) the text (when centered, most designs) becomes offset from the primary header when it is also centered (most designs). This is much easier for me to screenshot and visualize on Windows via Paint from the Waterfox Classic browser. In the screen shot I added various contexts so let me address what you're seeing: 1. I changed the font-family, font-size, letter-spacing and word-spacing to all be the same and to all use span elements to get as much consistency between the two elements as possible. 2. I added a background-color to each element so you can see where the content cuts off. 3. Since this is a small part of a page I cropped the image though took the scrollbar from the far right (2560x1440 and maximized browser) and moved it to where it would be to keep things simple. 4. I added single-pixel red lines to show how the two span elements of centered text are not centered. 5. I added a yellow line to each side of the scrollbar. 6. Since I care about pixel-perfect layouts (important to know when browsers have bugs) I literally count individual pixels in many designs to make sure nothing is "off". So I added a diagonal line to each set of red lines and the two yellow lines to make it easier to zoom-in and count how many pixels wide each measurement is. Even in normal circumstances where the text isn't given ridiculous amounts of contrast it stands out to be clearly misaligned. That is where overflow: overlay comes in. By applying it to the #body primary scrollbar the width if removed and the text on the #location and the h1 center together properly. In my designs I use modest amounts of margins and I literally have over over a couple hundred versions of browsers for testing and test both desktop and mobile to ensure that visitors will see content without any bugs. By removing the effective width of the scrollbar everything on both levels becomes properly centered and I don't have to dump JavaScript in to the equation to calculate the scrollbar's width and start doing all sorts of wonky things. Most especially since Linux, OS X, Windows are not going to inherently agree to some kind of universal scrollbar width making JavaScript even more necessary. If you think the performance hit from something like that is concerning imagine amateurs running five copies of jQuery. Because the current design I've been working on is not for a client though for show I decided in this case to let Gecko and WebKit browsers just have misaligned text. Though clients have persistently nit-picked about a few pixels here and there in spite of not having a technical eye and in these circumstances we will dump JavaScript to fix CSS problems. The if condition for that starts with !CSS.supports('overflow','overlay') and will only run for browsers that return true/don't support overlay. If a web designer/developer screws up a website that people don't like it they will simply go elsewhere however that should not mean I have to be condemned to waste hours of my life because someone is forcing their personal preferences with no meaningful weight on to not only an entire rendering engine though also turning a standard in to a pseudo-standard. As the lead developer for a web platform we outright ignore CSS scrollbar-width as "thin" is completely relative: Linux, Mac and Windows aren't going to agree and Blink, Gecko and WebKit aren't going to agree. If it becomes that important (and there is potential) I will just outright set everything to overflow: hidden; and literally recreate my own scrollbars with which I have total control over the functionality and design and so will amateurs that do not care or are even aware of topics such as accessibility. So removing functionality not only damages the browsers using the rendering engine it also makes all of the efforts people have put in to those aspects ultimately irrelevant and outright ignored. So we can either have the functionality restored or we can all ultimately waste each other's time.
Myles C. Maxfield
Comment 8 2022-09-07 22:34:10 PDT
Created attachment 462197 [details] Test I wrote up a test .html file based on your description. Can you verify that this test .html file demonstrates the problem? It shows two lines of text which are intended to have the same horizontal position.
John A. Bilicki III
Comment 9 2022-09-08 00:00:00 PDT
Created attachment 462198 [details] Two h2 elements, one within overflow, the other is not. While both centered visually the two compared appear "off" because of the scrollbar hence why overflow: overlay is neccesary. I created and have attached a file with a visual. Unfortunately since the scrollbar-width is invalid there is no way (that I know of offhand) to purposely increase the scrollbar width to emphasize the misalignment. Since there are some Mac users with very high resolution screens I will mention that my Mac Mini is running on a 24 inch screen set to 1920x1200 and my PC on a 32 inch screen set to 2560x1440. I have Mac OS 12.5 and Safari 15.6 installed. On my PC I primarily test with Waterfox Classic. The issue is clearly demonstrated on both browsers. I used a block text character to make it easier to see the misalignment. Both h2 elements have the exact same text and the only changes to the fonts were the font-size to make it easier to visually pick up the difference created by the scrollbar.
Karl Dubost
Comment 10 2023-02-16 21:58:26 PST
Gecko has shipped overflow: overlay as an alias of auto https://bugzilla.mozilla.org/show_bug.cgi?id=1817189 Also this is probably a duplicate of Bug 244357
Karl Dubost
Comment 11 2023-02-16 21:59:46 PST
> Also this is probably a duplicate of Bug 244357 I meant Bug 244783
Ahmad Saleem
Comment 12 2023-06-15 12:29:44 PDT
Do we need to do anything after bug 189811? _________ Although, if needed or we are missing any piece, we can do this: In 'RenderStyleConstants.h', we add 'Overlay': https://searchfox.org/wubkat/source/Source/WebCore/rendering/style/RenderStyleConstants.h#267 In 'RenderStyleConstants.cpp', we add 'Overlay' case in switch: case Overflow::Overlay: ts << "overlay"; break; ^ https://searchfox.org/wubkat/source/Source/WebCore/rendering/style/RenderStyleConstants.cpp#747 In 'StyleAdjuster.cpp', we add following to make 'overlay' as alias of 'auto' similar to Gecko & Blink: if (style.overflowX() == Overflow::Overlay) style.setOverflowX(Overflow::Auto); if (style.overflowY() == Overflow::Overlay) style.setOverflowY(Overflow::Auto); https://searchfox.org/wubkat/source/Source/WebCore/style/StyleAdjuster.cpp#504 ^ here or nearby where it is appropriate. In 'CSSPrimitiveValueMappings.h', add case for 'Overlay': case Overflow::Overlay: return CSSValueAuto; https://searchfox.org/wubkat/source/Source/WebCore/css/CSSPrimitiveValueMappings.h#902 _______ Although, we are already passing below WPT test: https://wpt.fyi/results/css/css-overflow/overflow-overlay.html?label=master&label=experimental&aligned=&q=overlay _____ ^ bug 189811 sufficient? __________ Plus bug 243783 seems to be duplicate.
Simon Fraser (smfr)
Comment 13 2024-10-08 19:57:56 PDT
*** This bug has been marked as a duplicate of bug 243783 ***
Note You need to log in before you can comment on or make changes to this bug.