New CSS Features in Firefox 68
hacks.mozilla.org
hacks.mozilla.org
Such issues tend to crop up later in life, precisely when you need to start cranking the font size up (and therefore get outside of the configurations checked during usability testing), so this is not only hitting a big percentage of the population, it will eventually hit a sizable fraction of the currently-healthy people reading this comment.
Which circle of Dante’s guide to web development in the inferno are we in again? I’m having trouble keeping track.
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 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.
> 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.
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?
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.
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.
> 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...
They also have a new version of mobile Firefox, which will replace the current one at some point in the future. It's called Firefox Preview. I tried it, tab switching is acceptable, but now they moved the URL bar to the bottom of the screen. Why????? So I've uninstalled it and I'm back to Chrome.
Nobody is going to switch from Chrome to Firefox if the UI is radically different.
I did. I care a lot more about supporting Mozilla than I care about UI though
If you were using Chrome before, Mozilla was around before and their motivations were the same: why did you switch to Chrome in the first place? I'd imagine the motivations there are the ones that are most common (after all, Google ended up eating Firefox's and IE's lunch somehow).
> but how many users are going to be motivated by that to move the needle
1 is enough to disprove "Nobody is going to switch from Chrome to Firefox if the UI is radically different" which was my point. zazaraka is projecting their displeasure on a lot of people.
HN is a community. Users needn't use their real name, but do need some identity for others to relate to. Otherwise we may as well have no usernames and no community, and that would be a different kind of forum. https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...
You could easily make the argument that no one is going to switch from Chrome if Firefox is very similar too because there'd be no good reason to.
Guessing what users will do is a waste of time. You have to do experiments and actually measure it.
I switched back almost 10 years ago (because Google creeps me out), and the UI differences made it much harder.
I ended up tweaking firefox with extensions to make it look and behave like Chrome as much as possible, then gradually turned it back to the default UI. It made the switch far more pleasant.
I've actually had a lot of success getting non-techie Android users I know to switch to Firefox when they found out that it has proper adblocking available via Ublock Origin. They're usually quite willing to learn a new UI if it means that they no longer have to deal with advertising infestations.
Because on a phone, your thumbs are already down there. No need to stretch to reach the URL bar. I can see users switching to Firefox because of that convenience.
But on the scale of uselessness this cannot be even compared with dark mode support. Never needed it.
Useful in the same way that popup windows are. Developers certainly liked those - they were such a useful tool to annoy users with! And now "real" popup windows are blocked and developers create them the hacky way with JavaScript. The circle of life.
Popups are an entirely different thing but there are legitimate uses for these too. There was never any work around for popups, it's a simple one line of code, you just need to make sure its opened in a trusted event such as a real user click to ensure the user actually wanted the pop up to show.
If you don't need [insert-shiny-feature-here], don't use it.
In terms of this update...
::marker support is very useful and something we've been asking to have for years.
Scroll snapping is also very useful as most sites implement it in very hacky JS.
Takes a bit of hoop jumping though.
"horizontally center this text inside its rectangular element"
And another one for:
"vertically center this text inside its rectangular element"
The issue of centering wrapped multiline text has been solved in many UI libraries.
justify-content: safe center; align-items: safe center;
On the parent:
position: relative;
position: absolute;
top: 50%;
left: 50%;
transform: translate(-50%, -50%);But things can quickly get very complicated. This all needs to be done in the context of a ton of other CSS rules that could alter layout. And by the way, what do you mean by "vertically centered"? Using the font's baseline? Text top? Bottom? How are we dealing with text overflow if there isn't enough room in your rectangular element?