bramus,
@bramus@front-end.social avatar

Just before the weekend, Scroll-Driven Animations got enabled by default in Chrome Canary 🎉

That means you no longer need to enable the Experimental Web Platform Features flag when visiting https://scroll-driven-animations.style which holds a bunch of demos and tools.

bramus,
@bramus@front-end.social avatar

Some things still need to be polished, but it’s already in a good enough state to try things out.

To keep track of how the implementation progresses, star https://crbug.com/1023424 to stay up-to-date.

Should you happen to find a bug, please file one at https://crbug.com

kizu,
@kizu@front-end.social avatar

@bramus Hey hey!

There are two bugs that are very weird in my use-case:

https://bugs.chromium.org/p/chromium/issues/detail?id=1447321
https://bugs.chromium.org/p/chromium/issues/detail?id=1447323

The example for it is a bit convoluted, but when I tried reducing it, the issue became less apparent, so I decided to keep most of the code (and to actually demonstrate the desired use-case).

bramus,
@bramus@front-end.social avatar

@kizu Thanks for reporting. There’s some known issues with animations that run on the compositor not being timed correctly.

Workaround is to force a main thread animation. Easiest way to achieve that is to add some (non-number) custom prop in the keyframes, like you also found out.

I’ve linked up your bugs to the main tracking one.

kizu,
@kizu@front-end.social avatar

@bramus Thanks!

kizu,
@kizu@front-end.social avatar

@bramus Hey hey! After one of the most recent updates (116.0.5793.0) there seemed to be some changes to how scroll-driven animations work with sticky positioning — and it really feels like a regression, at least for my case:

https://codepen.io/kizu/pen/OJBvoRp

I remember it was mentioned somewhere that there are changes to this combination, but in the case like above I would really expect the sticky to work exactly as non-sticky, but maybe I'm missing something? And is there a way to make what I want now?

bramus,
@bramus@front-end.social avatar

@kizu As per spec, sticky should stretch/pause the range. You can always track a parent wrapper if you want non-sticky behavior.

kizu,
@kizu@front-end.social avatar

@bramus Can you elaborate on the “parent wrapper”? Sticky element cannot have a wrapper that would have the same height as the sticky element itself, as in this case the sticky element would stop being sticky if I understand correctly what you mean.

johannes,
@johannes@front-end.social avatar

@kizu @bramus It seems like we keep bumping into sticky situations with sticky positioning, don't we? 😄

The current behavior of 'position: sticky' is just too limiting, and it's particularly frustrating that its position box must be contained inside its containing block. No room for a helpful wrapper there! 🙅‍♂️

If only we could find a more flexible way of defining the "sticky constraint rectangle," it would make our lives a whole lot easier 😄

https://github.com/w3c/csswg-drafts/issues/2496

kizu,
@kizu@front-end.social avatar

@johannes @bramus I wonder if anchor positioning could be applied to this in some way? As a lot of sticky cases really sound like them being anchored either to the viewport or to the previously stuck elements, which feels like it could be expressed via sticky position maybe?

johannes,
@johannes@front-end.social avatar

@kizu @bramus Are you proposing to allow for making one sticky element stick to another sticky element using anchor positioning? 🤔

I know this isn't valid, but something like:

h1 {   
 anchor-name: --heading;   
 position: sticky;   
 top: 0;   
}

h2 {  
 postion: sticky;   
 top: anchor(--heading bottom);  
}  
kizu,
@kizu@front-end.social avatar

@johannes @bramus Yep, something like this! There are many cases like this in the wild (some examples in the issue you linked), where we'd want the sticky element to ”know” about other currently stuck elements.

In this case we would probably want something like a max() to choose between the previously stuck element and the “scrollbox”.

johannes,
@johannes@front-end.social avatar

@kizu @bramus Nice 😄. Wonder if that could work.

Maybe someone should open an issue on the Anchor Positioning spec, if there isn’t one already? 😇

bramus,
@bramus@front-end.social avatar
johannes,
@johannes@front-end.social avatar

@bramus @kizu 😄

bramus,
@bramus@front-end.social avatar

If you need an intro on Scroll-Driven Animations, go check out my #GoogleIO talk which has a section on this.

https://youtube.com/watch?v=oDcb3fvtETs&t=335s

(Also covered are View Transitions, Individual Transform Properties, and CSS linear())

bramus,
@bramus@front-end.social avatar

If you’re more into reading, then https://developer.chrome.com/articles/scroll-driven-animations/ will float your boat.

bramus,
@bramus@front-end.social avatar

Finally, all demos and tools mentioned in both the article and talk can be found on this minisite.

https://scroll-driven-animations.style/

Source available through the ℹ️ box, or by viewing the source (it’s good ‘ole HTML+ CSS(+JS); there is no framework nor build system involved)

  • All
  • Subscribed
  • Moderated
  • Favorites
  • random
  • DreamBathrooms
  • magazineikmin
  • hgfsjryuu7
  • vwfavf
  • mdbf
  • ethstaker
  • Youngstown
  • slotface
  • ngwrru68w68
  • rosin
  • PowerRangers
  • kavyap
  • everett
  • khanakhh
  • anitta
  • thenastyranch
  • osvaldo12
  • tacticalgear
  • Durango
  • cubers
  • InstantRegret
  • GTA5RPClips
  • tester
  • cisconetworking
  • modclub
  • Leos
  • normalnudes
  • provamag3
  • All magazines