The Uncertain Web: Pointer Event Polyfill and Chrome Fragmentation

Fat Stacks

The Uncertain Web might be out, but that doesn’t mean that I’m done talking about the current state of the open web platform. I’m going to get back to writing a little bit here (as there are no more books on the immediate horizon) and as part of that I’m going to cover some topics that relate to the book under this “the Uncertain Web” headline. Two such topics have bubbled to the surface in recent weeks.

Chrome Fragmentation

Peter Paul-Koch wrote about the ongoing fragmentation of Chrome (specifically Chromium based browsers) last week. He’s identified 11 separate versions on mobile and he details his findings in his post “Chrome continues to fall apart at brisk pace.

There are a lot of things about this that tie into what I’m talking about in the book.

For starters, you might assume that if you test in Chrome on a single Android device or, even worse, test in Chrome on the desktop with just the emulation feature of the Developer Tools you’re fine since it’s all “just Chrome.” That’s clearly not the case. This is exactly what I’m talking about when I urge you to “question your assumptions.”

Secondly, the importance of testing with real devices can’t be understated. I outlined a luxury testing strategy in the book that targeted a half dozen separate Android versions. As PPK’s article illustrates even that is not enough to get the full picture. Still, even falling short of a perfect testing plan, getting a variety of different devices running different Android flavors is important to ensure that you’re really testing your site or application and aren’t merely kicking the tires. Multiply that across iOs, Windows, and whatever else strikes your fancy and you’ll have a robust testing regime for the current state of the web.

Finally, this Chromium soup illustrates the importance of sticking to the tried and true methods of web development that we’ve established over the past decade and a half. Building baseline experiences that work across the broadest range of browsers and devices is going to be the best way to reach the widest possible audience. You shouldn’t have to worry about what browser people are using. 11 versions of Chrome shouldn’t keep you up at night. As long as you’re paying attention to features, using feature detection and device characteristics using media queries you’re going to be better off than if you’re sitting around fixating on the different versions and trying to piece together the differences into some bizarre matrix of pain.

I know there are a lot of people out there that have started to put together sites that only work in Chrome (including knuckleheads from Google that really ought to know better and should be setting a better example for the rest of the web.) That’s a terrible idea to begin with as there are hundreds of millions of people on other browsers out there. Then you factor in this inability to define what “Chrome” even is, and it’s clear that this new-fangled “this site is best viewed in Chrome” trend is even worse than the old-school “this site is best viewed in Internet Explorer” trend. At least back then it was a monoculture with just a handful of variations of IE in the wild and the browser’s penetration was nearly 90%.

Put some PEP in your Step

Since it’s an important aspect of modern web development that remains confusing for many developers, I wrote a whole chapter in the book on dealing with user input on the web. The importance of properly handling user input on the web should be obvious. If you can’t handle clicks of the mouse and taps of the finger on a screen, you’re not going to get very far as a web developer. It’s a complicated mess and plenty of smart people screw it up.

Check out Patrick H. Lauke’s Getting touchy presentation for the best possible overview (that doesn’t involve me re-writing a whole book chapter here.)

The tone of the chapter in The Uncertain Web was initially a hopeful one. There’a technology out there, Pointer Events, created by Microsoft and adopted by the W3C that unifies user input (mouse, finger, stylus, whatever) into a single API. When I initially wrote the chapter, there was support in Internet Explorer (obviously,) intent to implement from Firefox and an open issue to do the same (behind a flag) in Chromium. If all three had fallen into line then there would have been some possibility of forcing Safari’s hand and getting them, too, to implement this simplified interface. That was my hope at least and my tone (originally) reflected that.

Them, during the technical review for the book, the Chromium issue was closed. The Chrome team had decided against implementing Pointer Events in favor of unspecified “enhancements” to the existing Touch APIs So, I had to rewrite the chapter and cast Chrome as the villain in this particular tale. It was a bummer. Especially as, at the same time, the Polymer team deprecated support for their Pointer Events Polyfill. Suddenly we were down one browser and had no supported, high quality polyfill for the technology.

That’s the way the book went out the door. User input on the web was still a mess and Google was the villain.

Then, as the book was finally making its way onto the shelves it was announced that the jQuery foundation was taking over maintenance of the Pointer Events Polyfill. At least in my house, there was much rejoicing.

It’s still early days in the transition, but the project is already active on Github. I’m watching the project. You should too.

Pointer Events are, whatever Google thinks, a better solution to handling user input on the web. Beyond it being easier to code, and it is, it also does away with the conceptual problem many people have with this corner of web development. Despite serious effort from a lot of people, developers still think of it as a binary “touch” or “mouse” choice. It’s not.

If people start to think about “pointers” as a unified interface maybe people will stop doing things like the following example I’ve pulled from Wired.

If you visit with a touch enabled laptop, mouse clicks simply don’t work. To activate many interactive elements you have to touch the screen. It’s super annoying.

Here’s why it happens.

Looking at their code, they’re using a ternary operator to create an event alias named touchity, by using crude test to set the event name as touchstart on browsers with touch capability and click on everything else:

var touchity = ( ('ontouchstart' in window) ||  (window.DocumentTouch  && document instanceof DocumentTouch) ) ? 'touchstart' : 'click'; 

So, later on, when events are bound and touchity is passed into jQuery’s $.on, under the hood, only touchstart or click is set:

$('.wp35-gallery .nav').add('.curtain').on(touchity, function(e) 
  if (isThisADoubleTap()) {
  if ($(this).hasClass('next') 
      || ( === 'curtain-right')) {
  } else {

This breaks on any device with a mouse and a touch screen. For a personal example, with my current set-up I’ve got a touch enabled laptop set up as a workstation 90% of the time. The laptop itself has a touch screen. The external monitor does not. When I visit wired, I get the “touchstart” events even though the screen I’m using isn’t touch enabled. This means the browser being touch-enabled is true on one screen, but not the other, no matter what the browser API reports to their crude test.

To activate a slideshow or other link on I need to drag the window from the external monitor to my laptop, reach up and touch the screen.


Pointer Events helps to make fundamental conceptual errors like that go away because you never think about whether it’s touch or mouse or stylus or three dimensional gesture or eye tracking or thought control or whatever. You just have a pointer.

So, follow the project, use the polyfill and then we can all bug Google to get back on the side of the angels.

Oh Yeah… It’s Out. You’d Think I Would Have Mentioned That Before.

Strangely I posted some book updates last week and forgot to mention that Professional jQuery has been out for a couple of weeks now.. I haven’t seen it yet, but I like to know that it’s out there. Looking back on my work, I think it’s actually pretty good. Normally my own writing makes me cringe, but this stuff is still pretty good.

For those of you keeping track, my contribution was Chapters 10-14. Cesar Otero basically set up the basics of jQuery, and then I came along and talked about fancy stuff, like code optimization (Chapter 10: Writing Effective jQuery Code, Chapter 11: jQuery Template, and Chapter 13: Advanced Asynchronous Programming with jQuery Deferred,) plugin development (Chapter 12: Writing jQuery Plugins) and unit testing (Chapter 14: Unit Testing with QUnit.)

Professional jQuery

The Amazon page is updated with my name (even if the cover is still listing just the single author), so it’s as good a time as any to officially announce Professional jQuery, a book I co-authored for WROX over the past few months.

The project fell into my lap during a period in which I had a lot of time available to write, so it was a serendipitous opportunity that ended up working out perfectly.

When I came on board, the book was half finished and much of the structure was in place, so I was tasked with finishing out the remaining content and putting some polish to the existing chapters through the author review process. It was a lot of fun to do and exposed me to more depth in the jQuery API than I ever would have gotten simply as a consumer of the library.

In interviews now I tell candidates “pretend I’m Google if you have any questions about the jQuery API” when we’re going through code samples and I’m not really kidding.*

The book is broken into two sections, an introduction to jQuery/JavaScript basics and a section on Applied jQuery, which is where the “Professional” part of the title really comes into play. Most of that Applied jQuery section is my work and I’m very pleased with that content. I wrote a lot about jQuery and JavaScript best practices for speed and maintainability, introduced jQuery Templates, talked about the new Deferred object, went in-depth into unit testing with QUnit and did a long chapter on plugin development.

I learned a lot just writing it, so hopefully if you pick the book up you’ll learn a thing or two in reading it.

Speaking of interviews… while I’ve had some good luck hiring and am no longer a team of 1, I am looking for a senior JavaScript engineer to join my team. Why join me? I’m an awesome boss (even my interviews are fun) and the work is almost entirely focused on web application development using the latest/greatest web technologies. What more could you want?

Recent Reading (JS Natives Duke it Out, Regexp in jQuery, Performance, a New Image Format?)

Sorry, it’s been a while. I’ve been busy at work, I’ve been wringing every last bit out of summer on my bike, and I’ve spent a lot of my free time on my upcoming CSS presentation, so I haven’t been posting as much as I would like. Fall is here. Which means I should have more time for writing. That’s cool.

Anyway, to break the ice here are a few articles that have recently caught my attention.
Continue reading “Recent Reading (JS Natives Duke it Out, Regexp in jQuery, Performance, a New Image Format?)”