It’s very hard to build a responsive, touch-enabled carousel. Or any draggable container. So hard, in fact, that many (ok Hacker News, a few! 5 in fact.) years ago at Zynga, we’ve spent months to build our own scrolling abstraction that handled the calculations for smooth scrolling, panning and zooming. That project was the Zynga Scroller, built by Sebastian Werner and me. We outperformed all other solutions at the time, including the popular Scrollability library by Joe Hewitt, but it still wasn’t fast enough to deal with large, unruly DOMs on mobile devices.

And then came Internet Explorer 10.

Perfect, expressive zooming and panning

IE10 added a new set of prefixed CSS properties that allow you to programmatically control panning, scrolling and zooming. With these APIs, one could take what required a pretty advanced JS library causing all sorts of performance issues and trim that code down to two lines of additional CSS. Literally:

<style>
  .container {
    width: 500px;
    overflow-x: auto;
    overflow-y: hidden;
    white-space: nowrap;
    /* Set up points to which scrolling will snap */
    -ms-scroll-snap-points-x: snapInterval(0px, 100%);
    /* Require that scrolling always end at a snap point */ 
    -ms-scroll-snap-type: mandatory; 
  } 
</style> 
<div class="container"> 
  <img src='1.jpg'><img src='2.jpg'><img src='3.jpg'> 
</div>

Magical “just-working” performance

This isn’t just a mindblowingly simple way of creating a pannable list. It is also the fastest way. I remember when a buddy from Microsoft visited us at the Zynga HQ to troubleshoot a HTML5 game’s performance on the then-upcoming Surface. With our Scroller library and a heavily advanced paginated world map, our game performed at 15-20fps during level selection. This was after weeks of prior optimization and we thought it was the best we could do. Replacing our hundreds of lines of logic with two lines of CSS instantly bumped us to a perfect 60fps. It was fucking insane.

A future that just wouldn’t come around

I thought I had glimpsed at the future of mobile web development. I was convinced usage of this new properties would explode, and we’d see fast, beautiful mobile web experiences everywhere in the upcoming months. This, I thought, would bring in an era of modern mobile development, and other browsers would soon catch up. Boy was I wrong.

Most people have never heard about these, likely including you. Previously, YQL was my go-to example of a tragically underutilized API, but this one took the throne. When Microsoft attempted a much-too-late effort at standardization, from what I can tell, it generated very little interest or attention in the community. I’m not even sure why exactly: IE’s bad image issues, late standardization, too little advertising/evangelism? The good news is that standardization is apparently ongoing, and we can only hope that as soon other browsers become interested, the public will, too. I learned an important lesson anyway:

It’s not enough to build the future. You need to lead the way towards it.

Share this post