Workaround CSS for smooth scrolling buggy in Google Chrome
Hello, following a video of Kevin, I think I discovered smooth scroll and enabled it right away, only to find it breaks in-page anchor links from a table of contents.
I currently have this code:
It breaks links on Google Chrome, there is jumping to the anchor, these links don't work, I saw the bug on their issue tracker, seems they haven't fixed it since 2022, basically you cannot do that. It breaks JavaScript jumps as well, but I don't use those.
Now in order to rescue this for Safari, Firefox, and all the well behaved browsers, how to wrap it in a media query, such that it gets executed on everything not Google Chrome. Webkit itself is not enough to see the bug, I think it's their JavaScript engine interfering.
So, I guess, I want the thing that shall not exist, a browser query. I know that people select browser versions by prefix availability, are there such for use with Google Chrome detection?
My web searches are in vain. Nobody does that thing. But then, does everybody just not use the feature then?
29 Replies
Do you have an example of this, cause it works for me in chrome, ff, edge* just fine.
I even use it in a @media prefers reduce motion cause its not great for everone.
My page is this: https://nuitka.net/doc/user-manual.html#requirements
Nuitka User Manual — Nuitka the Python Compiler
User Manual of Nuitka with the details on how to use it
I assume you enable the CSS via Inspector or some other cool trick, or do you need me to revert this bit:
The table of contents works with smooth scroll and I surely will add the media queries for reduced motion, contrast, etc. in the coming months. But the hard jumps are really incovinient. The links there are standard anchor links, and neither my Chrome on Windows, nor a helpers Chome on macOS could do any of the links.
yea there is some odd ness going on there
so you are not using any JS scroll stuff?
Like its just html?
was about to ask if you had the link to the issue 😆
I want to avoid JavaScript as much as possible, esp. if there is no need. If CSS can do it nowadays, why use JavaScript.
yea odd one I don't understand 🤷♂️
It's because it's also scrolling the sidebar too... hmm
That sidebar overflow is something I mean to get rid of, but haven't done it yet
You mean, if the scrolling there doesn't overflow, the bug is not triggered?
If i remove the sidebar, it works fine.
Like overflow:none or so, would hard solve it now
Yup facts
this fixes it
Ah, I see 🙂
interesting footgun 😮
makes notes so he does not eat this foot
Also that whole class seems to do nothing xD (I just nuked it off the html and all works great)
I create a static static with Sphinx and Read The Docs theme, but I am moving away from it. The sidebar has a hamburger menu on mobile, that I would currently be unable to replicate, but otherwise for me it's JavaScript non-sense, waiting for Kevin's video about how to make a Hamburger menu with CSS 🙂
Don't go crazy avoiding JS
Like for a menu toggle tha tis just fine. I don't think the CSS/HTML only solutions are much better
You can do it, but that's something you should use JS for
if anything they are worse really
"hacks"
yup, and in general, the hacky css-only solutions mean whatever it is, is much less accessible.
They are, I thought it would be the other way around, and the HTML annotations drive accessiblity?
Yeah, but we need to toggle things within the HTML when opening/closing things, to provide proper context
Are you talking accessibility in terms of blind users, or movement impaired
So checkboxes that make no real sense pop up, I get that
both
keyboard users will want to interact with a
<button>, and for screen readers, you'll have a aria-expanded attribute, which will switch from true or false, depending on if the menu the button controls is or isn't opened.I just joined your paytreon btw
🥰
I saw the sidebar from Sphinx does it, but Pagespeed complains about it being incorrect. At some point I will try and replace it like I said, probably with something that needs no scrolling and expansion. Unorganised content is no excuse for wide menus.
Anyway, out of here, this is solved 🙂