The first polyfill is for polyfilling the JavaScript methods window.scroll({ behavior: 'smooth') and Element.scrollIntoView(), the second one (disclosure: written by me) syncs it up with the CSS. There are also ways to use it with IE, and the awesome stuff described here like respecting (prefers-reduced-motion: reduce)will still work ππ»
Thanks! Interesting approach to use font-family to pass data to JS. Maybe itβs an idea to also (or instead) allow use of a CSS custom property? The font-family trick feels a bit hacky, it might stand in the way of people using your library.
But afaik it's the only reliable way to detect CSS unknown to the browser without having to collect/fetch every single stylesheet on a page (with something like getElementsByTagName), parse through all of them with a Regex and repeat that every time some styles change. There's actually a library that helps with that so implementation isn't a problem, but it's quite the added runtime cost for such a small feature, so I decided against it.
Custom properties are a good idea
(thanks!) and I'll add them, but the use case there is basically just "I need smooth scroll in Edge but don't care about older browsers" as older browsers without scrollBehavior most likely lack support for custom properties as well π
Edit: And yup, the approach is interesting for sure, but I can't really take "credit" for it: took the idea from a quite popular object-fit polyfill β which is why my PostCSS plugin is just a fork of theirs with a few adjustments :D
Oh, Safari, you're right!
I think you convinced me, I'll go with --scroll-behavior as default and only offer the font-family detection as option to support legacy browsers like IE π€π»
...and I don't think running getComputedStyle(el).fontFamily when an anchor with a local href is clicked is so bad for performance that it justifies dropping IE support, do you? Or do you mean the performance impact of polyfilling smooth scroll in general?
I havenβt tested it but the scroll behavior itself might be too much.
getComputedStyle returns a live object so youβll only have to request it once, but even if you requested it multiple times I donβt think it would be problematic.
I'm using it on the documentation site and it works smoothly, even on IE9 with requestAnimationFrame substituted as setTimeout(fn, 0) π
Also used it just fine on a production site that's very heavy on smooth scrolling (while at the same time running a position: sticky polyfill runtime), so I'm not too concerned about performance. :)
And didn't know getComputedStyle returns a live binding, thanks for the info! Will take this into account next time I update the package ππ»
So, current strategy:
Have custom property --scroll-behavior as default/recommended way of adjusting the behavior
Keep supporting fontFamily and inline styles for legacy support/convenience
Do you think it's worth it having the custom property that's used be configurable, so users can use some other property instead of --scroll-behavior if they want?
To go with these changes, the PostCSS Plugin shall compile scroll-behavior: smooth to:
scroll-behavior:smooth;--scroll-behavior:smooth;
and if browserslist includes browsers without support for custom properties, compile to:
scroll-behavior:smooth;--scroll-behavior:smooth;font-family:'scroll-behavior: smooth',/* user defined fonts */;
(while accepting { customProperty: boolean, fontFamily: boolean } config so users can overwrite this behavior)
Do you have any feedback on this?
(sorry to bother you but your input was very valuable so far π)
Looks good to me! Love the very structured approach. π
Careful with wanting to support everything. Could increase library size, might introduce weird bugs (certainly on very old browsers) sometimes a simple mustard cut is a lot better for everyone.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
To those concerned about browser support:
Add these polyfills to your HTML:
and use a custom property on
html
in addition to the normal CSS property:The first polyfill is for polyfilling the JavaScript methods
window.scroll({ behavior: 'smooth')
andElement.scrollIntoView()
, the second one (disclosure: written by me) syncs it up with the CSS. There are also ways to use it with IE, and the awesome stuff described here like respecting(prefers-reduced-motion: reduce)
will still work ππ»Full docs: jonaskuske.github.io/smoothscroll-... β
Thanks! Interesting approach to use font-family to pass data to JS. Maybe itβs an idea to also (or instead) allow use of a CSS custom property? The font-family trick feels a bit hacky, it might stand in the way of people using your library.
Yep, it's definitely hacky (but totally works)! π
But afaik it's the only reliable way to detect CSS unknown to the browser without having to collect/fetch every single stylesheet on a page (with something like
getElementsByTagName
), parse through all of them with a Regex and repeat that every time some styles change. There's actually a library that helps with that so implementation isn't a problem, but it's quite the added runtime cost for such a small feature, so I decided against it.Custom properties are a good idea
(thanks!) and I'll add them, but the use case there is basically just "I need smooth scroll in Edge but don't care about older browsers" as older browsers without
scrollBehavior
most likely lack support for custom properties as well πEdit: And yup, the approach is interesting for sure, but I can't really take "credit" for it: took the idea from a quite popular object-fit polyfill β which is why my PostCSS plugin is just a fork of theirs with a few adjustments :D
Donβt forget about Safari ;-)
Might be a good idea to just not have it on IE11 as the performance impact might not be worth it.
Oh, Safari, you're right!
I think you convinced me, I'll go with
--scroll-behavior
as default and only offer thefont-family
detection as option to support legacy browsers like IE π€π»...and I don't think running
getComputedStyle(el).fontFamily
when an anchor with a local href is clicked is so bad for performance that it justifies dropping IE support, do you? Or do you mean the performance impact of polyfilling smooth scroll in general?Awesome.
I havenβt tested it but the scroll behavior itself might be too much.
getComputedStyle returns a live object so youβll only have to request it once, but even if you requested it multiple times I donβt think it would be problematic.
I'm using it on the documentation site and it works smoothly, even on IE9 with
requestAnimationFrame
substituted assetTimeout(fn, 0)
πAlso used it just fine on a production site that's very heavy on smooth scrolling (while at the same time running a
position: sticky
polyfill runtime), so I'm not too concerned about performance. :)And didn't know
getComputedStyle
returns a live binding, thanks for the info! Will take this into account next time I update the package ππ»So, current strategy:
--scroll-behavior
as default/recommended way of adjusting the behaviorfontFamily
and inline styles for legacy support/convenience--scroll-behavior
if they want?To go with these changes, the PostCSS Plugin shall compile
scroll-behavior: smooth
to:and if
browserslist
includes browsers without support for custom properties, compile to:(while accepting
{ customProperty: boolean, fontFamily: boolean }
config so users can overwrite this behavior)Do you have any feedback on this?
(sorry to bother you but your input was very valuable so far π)
Looks good to me! Love the very structured approach. π