[Webkit-unassigned] [Bug 244357] overflow overlay missing

Thu Sep 1 15:08:38 PDT 2022

https://bugs.webkit.org/show_bug.cgi?id=244357

--- Comment #7 from John A. Bilicki III <jab_creations at yahoo.com> ---
Created attachment 462081

  --> https://bugs.webkit.org/attachment.cgi?id=462081&action=review

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20220901/8a756f07/attachment-0001.htm>