(the context here is scroll behavior, not markers)

I too tried their codepens and my immediate reaction was "I hope nobody ever does this."

This definitely feels like one of those Ian Malcolm moments. "Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should."

Having the position jump away from where I just put it feels extremely hostile.

The important line here is this:

> The update in Firefox 68 brings the Firefox implementation in line with Scroll Snap as implemented in Chrome and Safari

While "and Safari" is a less-relevant detail here, the general point is: where there is a monopoly, minority browsers will often need to implement user-hostile features in order to remain relevant/up-to-date/compatible.

Web devs today don't test in Firefox, they test in Chrome. They might have a webdriver/saucelabs/etc. setup with Firefox/IE/Edge thrown in but in terms of day-to-day these are afterthoughts.

I only test in Firefox, because FF is my browser of choice. Everyone else in the office only tests on Chrome because that is their browser of choice. We all know it is wrong, but cross browser compatibility makes it so much easier to forget that there are subtle differences.

Fun fact, we recently found a performance issue on one of our products which I was completely unaware of because it didn't affect. Even now, we cannot get Chrome to match FF's performance especially (of all things) for Google maps. Just goes to show that basic assumptions that Chrome is faster than Firefox are not 100% accurate. Like most things, it depends.

>Web devs today don't test in Firefox, they test in Chrome.//

It's kind of an aside, but is that true? I only do small scale solo dev but I test in like a dozen UA as the bare minimum I can get away with.

Presumably you're being slightly hyperbolic and saying that devs who are under major constraints will target Chrome?

What we do at my work is assign each developer a browser. I only use Firefox. Another coworker only uses Chrome. Etc. This way we will hopefully find any major browser issues before they get to QA.

The actual important line is the next one:

> In addition, it removes the old properties which were part of the earlier Scroll Snap Points Specification.

The earlier API was based on a working draft spec and has been available since 2015 in Firefox (Chrome only brought it out without a flag in 2018), so this isn't a recent development.

https://caniuse.com/#search=scroll%20snap

> I viewed the code pen example on my phone

> but not keep their finger in a one pixel radius for extended periods of time

I know you're exaggerating some, but this isn't even close to what I'm seeing: You can drag the entire content area to scroll, not just the scrollbar, and you can drag it past its container to keep scrolling. This is normal for scrolling on mobile, and the snap behavior doesn't affect it.

I do agree that the snap behavior is annoying, it's just nowhere near as bad as you describe...

The CodePen is not great on mobile, but that has everything to do with the CodePen mobile UI and nothing to do with CSS scroll snapping. If anything scroll snapping helps those with poor motor skills as it requires less precision in movement... because it snaps.

No, it's pretty bad on desktop too. If I try to scroll a little bit to read the bottom of the first section (which doesn't quite fit in the 300px height), I get snapped to the second section, with no way of reading the last part of the first section without "maintaining" the scroll by click+dragging the scroll bar without releasing it. It's a pretty bad experience overall.

Removing the `mandatory` value from the attribute makes it a little better (in that the snapping is more a suggestion but you're still able to at least scroll such that all content is accessible), but it's still frustrating that the scroll position is hijacked.

Direct link to codepen: https://codepen.io/rachelandrew/pen/RmOoXY for those that want to try it.