Posted on

“Cancelable” Smooth Scrolling

Here’s the situation: Your site offers a “scroll back to top” button, and you’ve implemented smooth scrolling. As the page scrolls back to the top, users see something that catches their eye and they want to stop the scrolling, so they do a smidge of a scroll on the mouse wheel,, trackpad, or whatever. That’s what I mean by cancellable. Without any further action, the scroll event goes to the destination. Cancellable means you can stop it with a subsequent scroll. I find the cancellable behavior better UX, although I have no data to back that up.

I’m finding some discrepancies between browsers, as well as between CSS and JavaScript on how this all works.

Scroll down on this demo and give it a shot:

Here’s what I experienced on the browsers I have easy access to:

CSS Smooth ScrollJavaScript Smooth Scroll
ChromeCancellable (Speed: Slowish)Not Cancellable
FirefoxCancellable (Speed: Very Fast!)Cancellable (Speed: Fast!)
SafariNo Smooth ScrollingNo Smooth Scrolling
EdgeCancellable (Speed: Fast)Not Cancellable
iOSNo Smooth ScrollingNo Smooth Scrolling

If it was up to me, I’d:

  • make smooth scroll actions triggered either through CSS or JavaScript cancellable.
  • define “cancellable” because it isn’t really the right word. Maybe “interrupted”? Or “controlled”? Ideas welcome!
  • make the speed controllable, or if not, attempt to get browsers to agree on a medium-ish speed (that stays consistent regardless of scroll distance).
  • make Safari have it. Smooth scrolling makes things like carousels without JavaScript very practical, and that’s great, particularly on mobile where iOS Safari is forced on Apple devices.

The post “Cancelable” Smooth Scrolling appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Posted on

CSS-Only Carousel

It's kind of amazing how far HTML and CSS will take you when building a carousel/slideshow.

  1. Setting some boxes in a horizontal row with flexbox is easy.
  2. Showing only one box at a time with overflow and making it swipable with -webkit-overflow-scrolling is easy.
  3. You can make the "slides" line up nicely with scroll-snap-type.
  4. A couple of #jump-links is all you need to make navigation for it, which you can make all nice and smooth with scroll-behavior.

See the Pen
Real Simple Slider by Chris Coyier (@chriscoyier)
on CodePen.

Christian Schaefer has taken it a little further with next and previous buttons, plus an auto-play feature that stops playing once interaction starts.

See the Pen
A CSS-only Carousel Slider by Christian Schaefer (@Schepp)
on CodePen.

About that auto-play thing — it's a bonafide CSS trick:

  1. First I slowly offset the scroll snap points to the right, making the scroll area follow along due to being snapped to them.
  2. After having scrolled the width of a whole slide, I deactivate the snapping. The scroll area is now untied from the scroll snap points.
  3. Now I let the scroll snap points jump back to their initial positions without them "snap-dragging" the scroll area back with them
  4. Then I re-engage the snapping which now lets the scroll area snap to a different snap point 🤯

Cool.

JavaScript-powered slideshows (e.g. with Flickty) can be real nice, too. There is just something neat about getting it done with so little code.

See the Pen
Flickity - wrapAround by Dave DeSandro (@desandro)
on CodePen.

The post CSS-Only Carousel appeared first on CSS-Tricks.

Posted on

Downsides of Smooth Scrolling

Smooth scrolling has gotten a lot easier. If you want it all the time on your page, and you are happy letting the browser deal with the duration for you, it's a single line of CSS:

html {
  scroll-behavior: smooth;
}

I tried this on version 17 of this site, and it was the second most-hated thing, aside from the beefy scrollbar. I haven't changed the scrollbar. I like it. I'm a big user of scrollbars and making it beefy is extra usable for me and the custom styling is just fun. But I did revert to no smooth scrolling.

As Šime Vidas pointed to in Web Platform News, Wikipedia also tried smooth scrolling:

The recent design for moved paragraphs in mobile diffs called for an animated scroll when clicking from one instance of the paragraph in question to the other. The purpose of this animation is to help the user stay oriented in terms of where the paragraph got moved to.

We initially thought this behavior would benefit Minerva in general (e.g. when using the table of contents to navigate to a page section it would be awesome to animate the scroll), but after trying it out decided to scope this change just to the mobile diffs view for now

I can see not being able to adjust timing being a downside, but that wasn't what made me ditch smooth scrolling. The thing that seemed to frustrate a ton of people was on-page search. It's one thing to click a link and get zoomed to some header (that feels sorta good) but it's another when you're trying to quickly pop through matches when you do a Find on the page. People found the scrolling between matches slow and frustrating. I agreed.

Surprisingly, even the JavaScript variant of smooth scrolling... 

document.querySelector('.hello').scrollIntoView({ 
  behavior: 'smooth' 
});

...has no ability to adjust timing. Nor is there a reliable way to detect if the page is actively being searched in order to make UX changes, like turning off smooth scrolling.

Perhaps the largest downside of smooth scrolling is the potential to mismanage focus. Scrolling to an element in JavaScript is fine, so long as you almost move focus to where you are scrolling. Heather Migliorisi covers that in detail here.

The post Downsides of Smooth Scrolling appeared first on CSS-Tricks.