WICG / virtual-scroller

Other
2k stars 83 forks source link

Scrolling animations #157

Closed rtorr closed 5 years ago

rtorr commented 5 years ago

Please close without obligation to answering if this is just noise.

I develop web apps on platform which restricts vram/memory in general. All of the ux and input/focus is used using a game pad. If you haven’t guessed, it’s on the PS4 :).

We use a lot of virtual lists for this reason. However, unlike most apps, we have to build an experience that works well at being consumed from the couch and using a game pad.

We typically use css’s translate function to do the actual “scrolling”. This allows for hardware acceleration etc which means nice a smooth animations. We calculate all of the positioning in js land.

Would this use case be possible with this new element?

domenic commented 5 years ago

That's for your interest; this is definitely not noise!

I'm a little unclear on what the "use case" you're talking about here. Is it having virtual scrollers that are scrolled using a gamepad? Or is it having virtual scrollers whose scrolling is hardware-accelerated?

Our intention is for virtual scroller to work the same as other scrollers on the platform, e.g. <div style="overflow: auto; height: 100px;"></div>. In some (all?) browsers, the scrolling of those is hardware-accelerated. I know less about gamepads, but I imagine that if such <div> scrollers aren't scrollable with gamepads today, that'd be considered a bug in browsers.

Does this help?

rtorr commented 5 years ago

Correct me if I am wrong, but animating scrolling is not hardware accelerated. If you are using input to control natural scroll behavior, sure.

The use case is less about a game pad specifically, but more on how we have to achieve these types of interactions on low hardware requirements.

Think about netflix ui (on a console) with unlimited amounts of tiles for media consumption. Animating down one row at a time as tiles are selected. To achieve what we do, we use translate on the containing element that is within the "scroll view". Using an easing function with raf can only get you so far.

Another cool feature which might be already thought through is having an event object that could tell you from/to coordinates, what new elements would be added etc. That way at least some of the logic of creating a virtual-scroller is not in app code, but we could still have an escape hatch while still using a lot of internal features and calculations.

think something like

let scrollerEl = document.createElement('virtual-scroller')

// no idea of how options are going to be implemented so bare with me here

let scroller = scrollerEl({
  width: 5,
  height: 100,
  children: {height: 5, width: 5, data:[0..100]}
})

scrollerEl.addEventListener('scrollTo', scrollHandler)

scoller.scrollTo({x: 10});

function scrollHandler(e){
  // e gives new calculations
 // do math and apply css or whatever ease function you want to whatever element
}
jogibear9988 commented 5 years ago

What should I use atm if I used iron-list before? As iron-list (as whole polymer)is in maintenance?

domenic commented 5 years ago

Correct me if I am wrong, but animating scrolling is not hardware accelerated. If you are using input to control natural scroll behavior, sure.

Are you aware of .scrollIntoView({ behavior: "smooth" }) or similar?

Think about netflix ui (on a console) with unlimited amounts of tiles for media consumption. Animating down one row at a time as tiles are selected. To achieve what we do, we use translate on the containing element that is within the "scroll view".

It sounds like what you really want for this experience is CSS scroll snap. This article is pretty good too: https://nolanlawson.com/2019/02/10/building-a-modern-carousel-with-css-scroll-snap-smooth-scrolling-and-pinch-zoom/ .

As noted above, since virtual-scroller is meant to be equivalent to normal div scrollers, all these techniques (like CSS snap points or smooth behavior for scrollTo/scrollIntoView) will work there too.

Another cool feature which might be already thought through

I'm not sure I quite understand this. We do plan to have a rangechange event which tells you which elements have been become into view, due to scrolling or similar. Maybe that's what you're referring to?

domenic commented 5 years ago

@jogibear9988 that's not really on-topic for this thread, so I will mark your comment (and my reply) as such. But, I suggest asking the folks who maintain iron-list.

rtorr commented 5 years ago

I think you answered all of my questions. I was unaware of that smooth option. This should all work nicely together!