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 Wired.com 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) 
{
  autoPlay('forceStop');
  if (isThisADoubleTap()) {
    e.preventDefault();
  }
  if ($(this).hasClass('next') 
      || (event.target.id === 'curtain-right')) {
    offsetSlide(1);
  } else {
    offsetSlide(-1);
  }
}); 

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 wired.com I need to drag the window from the external monitor to my laptop, reach up and touch the screen.

Sigh.

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.

Windows Apps for Web and Front End Developers

Spurred on by this post by Rey Bango, I thought I’d share some of the tools I’m using myself when working on Windows. Rey’s post is great, but since Window-based developers are under-served by the community (even though there are a lot of us) I figured it couldn’t hurt to add my own options. These are almost all in addition to the tools Rey mentions as I use a lot of the same tools in his post.

Visual Studio 2012

As I mentioned, I’m going to try to avoid a lot of repetition of Rey’s options in this post (which is why you won’t see Sublime Text mentioned, even though it’s #3 in my code editor triumvirate.) Still, I feel like I have to add in my two cents on VS2012. One of the weird things about the web developer community is that, as a whole, we recognize that the tools we have aren’t as good as they should be. Some of this stuff is hard to do right or do efficiently and doing both is often the domain of the real experts. Then, in the very next breath, some folks will pile onto Microsoft and Adobe with as much vitriol as they can manage. The thing is, and this is something you pick up pretty quickly when you start to work with XAML, Silverlight and Flex refugees on the open web stack, Adobe and Microsoft created pretty sweet tools and APIs. People could get their jobs done. No, they weren’t perfect but their developers felt empowered. It’s surprising that they stick around at all, after they see what our ragtag band has to offer.

VS2012 is one of those tools. Yes, it costs money. Yes, it only runs on Windows. Yes, it’s a multi-GB install. No, it has no street cred. All that said, even out of the box it’s a powerful editor for web tech and, if you take the time to configure it properly it’s ridiculous.

I’ve been using this more and more recently.

Adobe Dreamweaver

This isn’t necessarily a Windows-only thing, of course. But still, it’s worth pointing out as Dreamweaver gets a bad rap.

Yes, it’s a WYSIWYG editor that people have made awful things with for 15 years and people disparage “Dreamweaver developers” as people who don’t know how to hand-code anything.

The thing is, while it can be those things, it’s also pretty great. From the beginning (FWIW, the first version I used, 1.2, came out in 1998), Dreamweaver has embraced and understood JavaScript in ways that other editors only started to recently. Dreamweaver extensions are written in JS so JavaScript isn’t some add-on, it’s core to the product. It’s also the heir of HomeSite, the great web-centric text editor that was my bread and butter for nearly the entire 2000s.

While it’s still got WYSIWYG features aplenty, it’s a fine, configurable editor with great code hinting, excellent site management tools and plenty of opportunities for automation. Mixed with Adobe Fireworks, you can smoothly move between graphics files and your web editor for even more webtastic power. My go-to editor at home where I’m running CS6.

I love being able to open an HTML document and having the full context of the attached files available when I’m editing. You always remain in the context of the HTML page, even when you’re switching back and forth between the attached JavaScript and CSS files.

TextPad

My utility text editor. If I need to open and manipulate a big text file on Windows I do it with TextPad.

MarkdownPad

A great editor for Markdown files. Buy the $15 license and get support for Github flavored markdown right on your Windows desktop.

Paint.net

I run CS6 at home. Having a big monitor, mouse, scanner, etc. make for a better experience with my CS6 Creative Cloud subscription. That said, I have a Lenovo Yoga that I spend a lot of time on and having Paint.net on it for basic image manipulation. It’s a great image editing app. It’s not a Photoshop replacement but for an image editing utility it can’t be beat.

Minimalist GNU for Windows/Minimal SYStem

If you’ve installed Git for Windows, you’ll know these projects as “Git Bash.” While I’m a fan of Powershell and pin it to my taskbar, I’m glad to have this scaled down Bash prompt available to me as well. It’s surprisingly robust.

WinSCP

I’ve just started using this tool as a replacement for FileZilla and like it. The difference maker for me is that the local window is just an Explorer window, which means that all the customization I have on the Explorer context menu are available right in the WinSCP interface. When you’re trying to put out a fire, it’s a big deal to be able to fall back on consistent patterns (right click> open in Sublime Text, for example)

WinMerge

I don’t get bent out of shape with conflicts because I’ve got WinMerge. It’s just good software.

Mongoose

While I’m as happy to spin up a node server to test locally as the next guy, double clicking a file to start up a quick web server is super convenient. No command line needed. Drop mongoose.exe in a folder, double click and you’re good to go. Pretty sweet little app.

7 Zip

The Swiss Army knife for compressed files.

Java, Ruby, Perl, Python, and Node installed and on my path

Many doors open up if you’ve got common programming languages installed and on your path. I’ve obviously made good use of Java over the years, but I commonly use Node, Python, and even Ruby tools.

S3Fox

While much of the work I do with Amazon S3 and Cloudfront is automated, occasionally you need to get up there and poke around. S3Fox adds an FTP style interface for AWS right into a Firefox tab.


Those are my additions to the Windows web dev canon. What else is out there? What are we missing?

I’m Presenting on CSS in October

I haven’t posted about this yet. I’m an incredible idiot. I’m presenting at the Boston PHP group in October. My presentation is a couple of weeks before Steve Krug. No pressure.

I hope to see you there 🙂

Learn CSS (with me)

Is CSS still a mystery to you? Do you find yourself editing your styles over and over justo get them to display correctly in IE and Firefox? Have you created a powerful application, and want it to look nice and clean? Do you want to take your knowledge of CSS and Design to the next level?

In this presentation Rob Larsen will step through the basics of Cascading Style Sheets (CSS,) the visual language of the Web. Starting with the most fundamental concepts and finishing with concrete examples illustrating common patterns, this presentation will serve as a launching point for those new to CSS and will strengthen the understanding of the core principles for developer or designer more experienced with CSS.

In this event you will learn:

  • Basics of CSS
  • Design & Layout
  • Web Standards
  • Rich Visual Behaviors
  • CSS1, CSS2, CSS3
  • Frameworks, Abstractions, etc.
  • Dealing with cross browser support
  • Separation of style, content and behavior
  • Testing
  • Tips & Tricks

If you still fumble with CSS and want to take your experience to the next level, then this event is for you.

About the presenter:
Rob Larsen has more than 11 years of experience building and designing web sites and web applications. Currently he’s a Consultant at Isobar, working for some of the world’s largest brands.

Prior to joining Isobar, Rob was the Principal Presentation Engineer at Cramer. At Cramer, Rob and his team produced standards-based, accessible and SEO-friendly sites and rich media applications. Before that, Rob worked for several years as a consultant for clients like Compete, Duracell, Gillette, Boston’s Museum of Science, PC Connection, RSA Security, State Street Corporation and Webex.

I’m Going to Enjoy Writing Code for Internet Explorer 9 (I Can’t Believe I Just Typed Those Words)

In case you missed it the latest Internet Explorer 9 Platform Preview is out and it’s a thing of beauty. It added Canvas support so the first thing I did was run it through some demo code. It’s faster than Chrome. Visibly faster. No benchmarks needed. It’s such an incredible difference from the current Internet Explorer family which are many times slower than the good browsers out there.

The good news doesn’t stop there. There’s actual standards support.

PPK enthuses:

In the past few days I’ve been revising the CSS compatibility table with information about the latest crop of browsers. There’s no doubt about it: this is IE9’s show. It just supports nearly everything. No hassle, no buts.

And then enthuses some more:
Continue reading “I’m Going to Enjoy Writing Code for Internet Explorer 9 (I Can’t Believe I Just Typed Those Words)”

My Personal View of Browser Market Share is Pretty Sweet- Firefox Rules, Chrome is Massive, IE6 is Nearly Dead

Here are the numbers for DrunkenFist.com in the year 2009. There were 614,333 visits to that domain last year and the top browsers broke down like this:

Browser # of Visits % of Visits
Firefox 342429 55%
Internet Explorer 162977 26%
Chrome 35801 5.8%
Safari 33545 5.4%
Opera 22826 3.7%

Continue reading “My Personal View of Browser Market Share is Pretty Sweet- Firefox Rules, Chrome is Massive, IE6 is Nearly Dead”