Hacker News new | past | comments | ask | show | jobs | submit login
New CSS Features in Firefox 68 (hacks.mozilla.org)
108 points by bzbarsky 6 months ago | hide | past | web | favorite | 44 comments



I viewed the code pen example on my phone, and the bottom of the sections are cut off in each of the snapped positions. So, even the canonical example is making a ton of content inaccessible to people with minor motor control (that allow them to swipe and tap, but not keep their finger in a one pixel radius for extended periods of time).

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.


(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.


I want to use Firefox on my phone, but it's UI is just so confusing - specifically the tab switching flow. When you try to switch tabs, the whole screen is replaced, the typically white background is replaced with a dark background, and the tabs are shown as tiny rectangles. And a very fast animation which makes my head spin. Why don't they just copy the tab switching from mobile Chrome?

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.


Nobody is going to switch from Chrome to Firefox if the UI is radically different.

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.


Anecdata:

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.


Frankly I would, and do. I use mobile Firefox for its features like adblocking extensions and reader mode but it's always a less pleasant experience than mobile Chrome because it's less snappy and intuitive.


>Nobody is going to switch from Chrome to Firefox if the UI is radically different.

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.


> 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


How many Chrome users use it because they care about supporting Google


Could you please stop creating accounts for every few comments you post? We ban accounts that do that. This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html.

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/?query=by:dang%20community%20identity...


I don't know, but I'm not sure I understand your point


your motivation to switch to Firefox was based on your willingness to support them over Chrome. The other poster is saying maybe you switched to Firefox from Chrome (presumably, you don't say if you were primarily Chrome prior) due to a preference for supporting Mozilla over Google, but how many users are going to be motivated by that to move the needle?

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).


Thanks for explaining, it does make sense.

> 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.


I personally like the url bar at the bottom of the screen because its easier to reach. I can understand how this being configurable would be important though.



> but now they moved the URL bar to the bottom of the screen. Why?????

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.


OMG, why so long for ::marker ? Finally! :)


Seriously. This seems underrated. Very excited!


Pretty useless features. Don't you think that HTML is getting too complicated? This often happens with open source projects, when everyone starts adding features for themselves and the program ends up as a monster that nobody can maintain (see: openvpn, x11vnc and so on).

But on the scale of uselessness this cannot be even compared with dark mode support. Never needed it.


HTML is as complicated as you make it (or need it to be).

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.


Scroll snap is a useful feature. The way you can tell that it's useful is because a ton of sites are already doing it, but in a manual, hacky way with JavaScript. This works better and uses less code and CPU. A win all round.


> Scroll snap is a useful feature. The way you can tell that it's useful is because a ton of sites are already doing it, but in a manual, hacky way with JavaScript. This works better and uses less code and CPU. A win all round.

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.


What a silly comparison. Are you suggesting users find swipeable photo galleries as irritating as popup windows? Because they really don't. If they did then the photos app in both major mobile OSes would be infuriating.


That's a bit of an odd comparison to make. Scrollsnapping is a useful feature in many scenarios and as the previous comment mentioned the current way of doing it is hacky.

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.


I'm excited that scroll snapping has been implemented in Chrome, Safari, and now Firefox.


If the browser is going to allow scrolljacking, then I understand the case for it being implemented in the browser's CSS engine. But on so many sites it's a usability issue because space, pgup/pgdn, arrow keys (not to mention Vimium navigation) do not behave predictably.


Thankfully CSS rules can be overridden by the user. :)

Takes a bit of hoop jumping though.


I am glad Mozilla took their time, because their implementation is better than the one in Chrome. If I open https://codepen.io/rachelandrew/pen/vwMyMr in Chrome and use the scrollbar arrow buttons to scroll up from the second section, it reverts back to the original position...


Yikes, and pretty broken with arrow keys in Chrome. I filed https://bugs.chromium.org/p/chromium/issues/detail?id=989738 on that.


How about a simple, single, CSS property that can simply say:

"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.


Well there is one for the first: `text-align: center;`.

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?


display: flex; justify-content: center; align-items: center;


Those will clip child content when they overflow. There is a fix, but only supported by Firefox currently:

justify-content: safe center; align-items: safe center;


I mean, if we're going for multiple attributes anyway, this has worked since long before flexbox:

On the parent:

  position: relative;
On the element to be centered:

  position: absolute;
  top: 50%;
  left: 50%;
  transform: translate(-50%, -50%);


The css debugging sounds great. I've never understood why there isn't a console for css debugging in dev tools.




Applications are open for YC Summer 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: