HTML5 Boilerplate 6.0 Released

drink

If you’ve been paying attention, you will have noticed that HTML5 Boilerplate 6.0.0 came out a few weeks ago. If not, it did. 6.0.1 has since been released.

It was a long time coming and I’m super happy to have it shipped. It was a lot of fun. Working with a project like this invariably means you have to do new things, so getting a major release out the door (where you have to touch everything) is a fun, educational experience. And, of course, working with the community is also pretty great.

Thanks!

Anyway, it was a big release and featured a lot of nifty stuff including:

  • We finally removed IE8 Support. This was a change that we had been discussing for some time and it was one of the first things I pushed through when I started taking a more active role on the project. Thanks to everyone for their help and input on this one.
  • We finally added a sample web app manifest file. That code had been percolating for years and it finally shipped.
  • We upgraded to Modernizr 3 and added a sample Mondernizr config so that people can do their own custom builds locally. Our Modernizr file is now created at build-time and I reworked the default detects to be more, er, modern.
  • We found out someone unaffiliated with the project had published the project to npm, so we took control of the package (thank you npm– support you were awesome) and published an official npm package.
  • And… lots of other great work by many contributors, including a ton of great work late in the process by Christian Oliff. Thanks to everyone for your contributions.

As a note, we still have an open bug that we’d love to get your input on– macOS – VoiceOver / Chrome announcing visually hidden text out of order · Issue #1985 · h5bp/html5-boilerplate. It’s an Apple bug with accessibility concerns that we’d like to work around.

As for what’s next… I’ll be opening up a couple of new issues for discussion this week, I think. So keep your eyes on the repo and join in on the fun.

Filling the Void Part 1: Random Projects and SSL via Let’s Encrypt

As I mentioned last month, my last long-term project ended in December. Between the holidays and then two separate instances of thinking I had something lined up and it falling through, I’ve only been working part-time over the past few weeks. While I’d prefer to be working full time (please reach out if you’re looking for help with anything) I have made myself useful over the past few weeks with side-projects and tinkering with new technology. I figured it might be fun to go through some of what I’ve been up to. This is the first of two posts detailing what I’ve done on my “winter break.”

SSL with Let’s Encrypt

One of my favorite projects has been switching several of my domains over to HTTPS using the free certs from Let’s Encrypt. I was really excited when my long-time host, FutureQuest announced support for Let’s Encrypt, including automatic updates. I love that this free path to secure communication exists and was excited to take advantage of it when my host offered it. Paying a one-time $25 setup fee is a lot better than the cost of an SSL certificate.

I was worried about what the drive to encryption by Google and others would do to smaller web publishers and businesses. I understand the need for and heartily support encrypted communication across all channels, I just hated the idea that small-fry publishers would get punished (in search ranking, etc.) for being insecure when the cost would be prohibitive for many publishers. Let’s Encrypt removes that monetary hurdle. Great stuff.

Futurequest’s implementation was pretty easy so the only difficulty was in getting WordPress working well with SSL (all three sites so far have been WordPress.) Generally, that was okay. A clean WordPress install is fine, but once you get into a real-world installation things get icky. Every migration included at least one instance where the site in question completely blew up because of one plugin or another. The good news is I was able to work around all those issues pretty easily (deleting plugins is especially easy) and am now running up and running on HTTPS on three of my sites.

Pretty sweet.

Time for a Refresh

One of the earliest projects I worked on was a refresh of the $100,000 Club and the All Time Record Comic Book Sales SVG visualization (a scatter plot.) Both of those projects are on Angular 1 and going back and updating them several years later was a lot of fun. I’d had a few things I wanted to do with the visualization for a few years and I jumped at the chance to implement them. It’s much nicer under the hood now.

All that code is on github.

Random Projects

As the above indicates, I do a lot of comic book related research and code. I have continued to document the Edgar Church Collection and have also started to document other named comic book collections. Free data for comic book people.

I’d like to do something interesting with the Edgar Church data this year. We’ll see what I come up with.


That’s round one. Round two, with Angular 2, React and Auerlia, will drop sometime next week.

A Few Paragraphs on Angular 2

Look! I’m back! I may end up writing here more often that I have over the past couple of years as I’m significantly cutting back on the amount of time I spend on Twitter. If you’ve enjoyed me saying “get off my lawn” on Twitter over the past few months, you’ll have to come here to read those thoughts. There is the benefit of paragraphs and formatting on the site, so there’s that. If you’re curious what the hell I’m talking about, this tweet-storm is a great example. That kind of stuff will live here now, if the mood strikes me.

The mood has struck! Read on!


I just finished up a long-term consulting gig and, while I’m kicking off a shorter-term a project for another long-term client, I’m also looking to set up my next big project. That’s the big question for me right now- what am I going to be doing for 2017?

As part of that process, I’m finally going to do a deep dive into Angular 2. I worked with it a little bit at my last client, but that’s not really enough for me to really feel like I know it. People are interested in it. I’m interested in it. So… I’m looking at it.

I’m starting with Switching to Angular 2. I’ve got a bunch of Angular 1.* experience so a book written for people looking to move from 1 to 2 seems like a decent place to start.

Between the book and the exposure I had to it on my previous project, my initial take is that it feels like everything that’s right and wrong about the web all wrapped up into one package.

It’s “right” in that it’s really well put together. The general framework architecture combined with the use of TypeScript make it a very compelling alternative for certain types of applications and teams. Like Angular 1 before it, it works for me for some things.

It’s “wrong” in that it’s just ridiculous. It doesn’t make sense for most of what people actually need to do on the web.

Modern web development is generally too damn complicated for its own good. That complexity is heightened by the interconnected, patchwork nature of modern front end development. If you buy into this mode of development you are relying on a matrix of software that no human could possibly vet. You’re basically acknowledging you’re going to live with random bugs, dependency issues, and reams of alpha software you’re supposed to trust going into production.

Angular 2 is exactly that.

On my first project with Angular 2, I experienced weeks of flaky builds as the development landscape shifted randomly underneath us. Many dependencies were also flaky and/or barely maintained. So much fun! Once the builds stabilized, I was flabbergasted to take a look at how much code was required to run the application. node_modules had over 1000 dependencies and our main.bundle.js was over 4.5MB. This was for a read-only application. It didn’t even do anything. I can’t help but think that’s ridiculous. For complicated, large-scale applications I can see the benefits, but for something simple… holy cow that’s a lot of code to solve the kinds of problems I was able to solve with a few hundred KB of pure JavaScript in 2006.

More on it as I get deeper into this dive.


On a final, related note, I’m really interested in exploring a way to marry the best of modern web development with a more stable, accessible (in both senses) and minimalist approach. There’s got to be something more appropriate for smaller applications and general “web” development.

Happy Birthday Palatino Consulting!

My business turned two years old on Friday. Yay my business!

So, how’s it been?

Great.

It’s truly been a joy working for myself over the past two years. I really wish I’d done it sooner.

One thing that’s been a negative is the fact that I haven’t done any writing or speaking engagements since The Uncertain Web was released. It’s a bummer, but that’s the way it’s gone. I’ve been busy with paid work and, to be honest, I was a bit burned out from writing three books in three years, so a long break has been good for me.

I’ve actually got a pretty big backlog of ideas to go through. There’s been a lot of bullshit flowing through front end development over the past couple of years and I have “big thoughts” on all of it. Considering how busy I’ve been so far in 2016, I doubt that I’ll get a change to write about it, but if I do, I promise I’ll make you laugh.

I’ve also had the opportunity to work with a variety of technologies over the past couple of years, so I have opinions (real, working opinions) on just about everything out there right now. That’s fun and would be fun to share.

We’ll see.

(Don’t hold your breath, though!)

One thing that I have kept up with is open source work. I haven’t been a demon or anything, but I have been knocking off some work pretty consistently over this year especially. That’s always fun.

One thing I should mention is that I occasionally need some development help. I’m especially interested in WordPress, Angular and pure HTML+CSS freelancers. Shoot me an email if that sounds like you.

Doing the Same Thing Over and Over Again and Expecting Different Results

Here I am taking a shot at shorter form writing. Watch me write!

The biggest job/career related error I made this past year was going against my own policy and talking to a company I had a bad feeling about from the beginning. I’ve actually known about this company for a long time and think poorly of them. The thing is, a recruiter came along and told me how much they were paying for a high profile role they were trying to source. That number was higher than the honestly very high number I have in my head to go work for someone else at this point. So, against my better judgment and against my own stated policy of not talking to people unless I’m sure the company will be a good fit, I talked to them.

I’m a dumb-ass.

The one part of the conversation that sticks with me is the “big” question in the interview. Apparently, they’ve got a lot of separate development teams who have worked in multiple versions of Angular on different components that have to play nice together on the same page. As you can imagine that has caused problems. Apparently, they’re also kicking off some development using React. With that cluster in mind, they asked, how would I help solve the issues they were having with all these interoperability concerns at an architectural level.

My answer was simple. I said, “Stop doing that. Don’t use React and standardize on one Angular version.”

I could hear the frustration in the interviewer’s voice as he said, “that’s not really an option” as if pointing out the obvious solution to their self-inflicted problem was an insult to him personally. I could tell he wanted to hear some hair-brained technical solution (“I know we’ll write REACTANGULAR and it will normalize across all Angular versions”) that would rescue them from a disaster of their own making, without having to do hard work. He lead me down that path a little with some follow-up questions. The thing is, that’s precisely the kind of bullshit is never going to come out of my mouth. I wasn’t going to blow smoke up his ass just so that he can ignore the obvious solution. To me, when you’re doing something so fundamentally wrong, the best solution is to bite the bullet and do something fundamentally right to counteract it.

How they thought introducing an entire second library to the mix was a good idea is something that will forever confound me. They’ve already identified this as a problem and they’re willingly making it more complex. That’s insanity.

Suffice it to say, they didn’t like me for the role.

So many companies are obsessed with being on latest and greatest libraries and frameworks. If, like this company, you want to be a great engineering organization you should focus on doing great work. If you’re architecture is a patchwork monster it doesn’t matter if you’ve got the new and shiny. You’ve just got a new and shiny patchwork monster.

Palatino Consulting, One Year In

While I’ve been consulting independently for slightly more than a year, I’ve been doing so under the Palatino Consulting banner for exactly one year, this week.

It’s been going pretty well, thanks for asking.

I’m at the point now where I’m starting to think about whether or not I want to expand this business to include more than just me. The opportunity is there (and has been since day one, to be honest), I’m just not sure if that’s the way I want to go. I like my simple life right now, but I do miss having a team to work with so I’m tempted to start to expand. Maybe, like the founding of the business itself, I’ll be forced into a decision one way or another by some circumstance. At least in this case it will be positive (some opportunity I can’t pass up) rather than negative (getting laid off.)

The one downside to the success is that I’ve had a hard time finding time to write . Which is fine on a lot of levels as I like what I’m doing and working for myself makes even the longest week a lot more satisfying. This is especially true because, unlike many people putting in 60 hour weeks, I get paid for every minute of my time.

Fireworks
Fireworks by Flickr user maf04

Still, I’d like to share more here as a lot of what I talk about in the book is still going strong, but I’ve found it hard to get into the flow of writing again after 3 or so years writing books back-to-back. We’ll see how it goes. I may try to take some baby steps with short pieces and see if the habit sticks.

If not, remember- I’ve still got the web’s back.

Current Status: For Hire

My current long-term consulting gig is ending at the end of June and, being a fan of managing uncertainty (did you see how I did that?) I’m trying to line something up for the summer sooner rather than later. I’m sure I’ll find something (I’ve got recruiters knocking down my door), but I’m also interested in finding something that will be fun and/or challenging so I’m making a concerted effort to let the world know.

If you’re interested you can check out the small site for my consulting business

I’m on LinkedIn

View Rob Larsen's LinkedIn profileView Rob Larsen’s profile

This is what I do

  • Front End Architecture
  • Training
  • Front end development, with a focus on the following:
    • General JavaScript and jQuery development
    • AngularJS applications and components
    • RWD (Responsive web design) development
    • Mobile web sites and applications
    • Web performance consulting
    • Pixel perfect CSS layouts
  • Process and standards development

Drop me a line if you’re interested

Google Chrome Reverses Course- Will Implement Pointer Events

This is great news. One of the worst chapters from a standards perspective in The Uncertain Web was on user input. At the time I wrote the chapter, I had a relatively positive tone. The flow of the chapter led to a discussion of Pointer Events and how, with support in IE and intended implementation in both Firefox and Chrome, we were on the cusp of having a sane way to deal with user input across devices and form factors.

Then it all went to hell.

Here’s what I wrote in the book:

As you’ve read in the chapter on user input, the Pointer Events specification, proposed by Microsoft, favored by Firefox and adopted by the W3C, is up in the air because Chrome isn’t sure whether or not they are going to support it. This was announced after I finished the chapter on user input. I found out via Twitter that Chrome was going to pull planned support for Pointer Events and felt about as deflated as I’ve ever felt about a web standards topic. For one thing, I like Pointer Events. I’m not sharing them as the way of the future just to be hip and share the new stuff. I really like them. Secondly, Google’s proposed alternative, “incrementally extending our existing input APIs” doesn’t really offer much of a salve to the wound of two wasted years looking for this specification to get off the ground and into browsers.

Maybe, like the door on +picture+ being reopened and bursting through to get into the specification, the already specified Pointer Events’ work will come back from the dead and make it into Chrome and the rest of modern browsers. The Chrome team are listening to feedback, so hopefully that’s just what’s going to happen.

We shall see.

Here’s what I wrote when Chrome announced the changed status of the original intent to implement:

I’ve already had to rewrite a book chapter on input on the web because of Chrome dropping support for Pointer Events (you were the good guys- along with IE you form an 800lb gorilla) to be a lot more bleak (now Chrome is the bad guys and we don’t have any solution on the horizon.) Nothing would please me more than to revert to the original take on that chapter.

I also don’t want to pin my hopes on this issue getting sorted out on the vague promise of “extensions” to the existing screwed up mess. What guarantee do we have that Apple will be any more interested in “extensions.” Will Chrome’s BFFs on the IE team be interested in “extensions?” If we’re looking at incremental extensions as the solution (with no more details than that,) I will be retired, drinking coffee at Sant’Eustachio Il Caffè and struggling my way through La Gazzetta dello Sport before the issue of user input on the modern web is sorted out in a way that benefits developers and end users. Smart people are doing stupid things with this stuff because it’s a complicated issue. Browser vendors and the W3C have to lead on this and sort it out from up on high because the bottom up approach isn’t working right now.

Thankfully, the Chrome team listened to reason (and a flood of negative feedback for their decision) and have reversed course.

Now we just need to get the new jQuery-driven version of the Pointer Events polyfill project ready for prime time and we’ll be all set.


As an aside, if there’s one good thing that came out of Chrome’s decision is that they Polymer team deprecated the Pointer Events Polyfill and passed the codebase over to jQuery. The Polymer version of the polyfill had a high barrier to entry to even get to use. I just linked to a version in my own code repo for the book because I hated the idea of forcing people to go through a multiple-dependency, poorly documented rigmarole just to “install” the polyfill. The jQuery team will, eventually, have a handy download link right on the site- like a normal project.

Navigating the Uncertain Web

The current talk I’m giving distills the second chapter of The Uncertain Web into 45 or so minutes (I’ve got the powerpoint on Github if you’re interested.)

As I continue to discuss topics relating to the book here on the blog, I thought it would be useful to outline the core concepts of that chapter in an even shorter format so that even if you haven’t read the book (and you should really read the book- it’s great) or haven’t had the good fortune to see me speak you have some sense of what I’m talking about as an approach to tame the web’s uncertainty.

Here are the basic ideas.

Don’t Blame the Web for Being the Web
The web is a diverse place that’s getting more diverse every single day.

If you accept the web’s diversity (and maybe even celebrate it) and you find yourself getting angry about one thing (maybe Internet Explorer 8) or another (the stock Android Browser) just take a minute to remind yourself that this is just the way the web is.

Repeat after me: This is just the way the web is.

Since there’s competition in the browser space, there’s always going to be a bad browser. When the current bad browser goes away a new one takes it’s place at the bottom of the pile. You just have to accept that and move on with your life.

Identify and Embrace Your Audience
You would think this second general concept would go without saying, but…. You really need to identify and embrace your audience

Do you know who your audience is? You’d be surprised how many clients I’ve had who couldn’t answer this very well at all.

While you can look at web-scale statistics for browser and operating system market share to get some idea of where things are, the only metrics that truly matter are those for your specific audience.

Test and Pray for the Best
This third general concept used to be much easier. Nowadays we’ve got to test in as many devices as we can and then pray for the best in the ones we don’t have direct experience with.

Once you’ve identified your audience, where they are and what they’re using it’s time to define the technical demographics you’re going to target with testing and active support.

You’re never going to test everything. The days of testing 95% of the web with one PC running IE6 and toggling between two screen resolutions are long gone. Test with as many real devices as you can and have a plan for what broad range of devices and operating systems you’re going to support. “Android” isn’t good enough. “Android 2.3 and up” is better and saying you’re going to dig up a Moto X means you’ve got your full game face on.

Focus on Optimal, Not Absolute Solutions
This concept has been with me for many years. My prime example is the many arguments I’ve had against putting in the extra effort to add rounded corners in older IE.

These days you need to focus on optimal, not absolute solutions.

Your site is not an absolute thing. The best possible site you can have will be the best possible site for everyone that visits it. If that means it’s a high DPI, 25MB monstrosity for a guy on a MacBook air in a coffee shop in Palo Alto or just a logo and an unordered list for someone on a-rented-by-the-minute phone in Lagos, then that’s the way it is.

People are used to sites looking different on different devices so take advantage of it and provide them with the best possible experience for their particular setup.

Embrace Accessibility
This concept is unfortunately something I have to call out, but people don’t focus enough on accessibility for the pure sake of it, so here we are.

On the modern web we need to embrace accessibility.

If your site is accessible you’re guaranteeing that you’ll be able to reach the largest possible audience.

You’re also doing the right thing.

I can’t stress that enough. You should be doing this anyway.

Lose Your Technology Biases
This general concept is one that drives me particularly nuts.

You’ve got to lose your technology biases.

Tech folks generally have great hardware and new, high powered smart phones and tablets. Most other people in the world don’t. Tech folks tend to forget that.

Not everyone has a fast machine. Test on crummy hardware and crummy phones.

Not everyone is on a Mac. In fact, the vast majority of people on the desktop are still running Windows, no matter what it looks like at conferences. Test on Windows and test in IE.

Not everyone is on an iPhone. Don’t design your experiences around iOS.

Embrace Empathy
This concept runs through much of what we’ve already discussed, but I still like to call it out. We need to embrace empathy.

Don’t blind yourself to what your audience actually is by assuming that they are just like you.

They’re not. Your average experience at work, at home or on your phone is almost certainly an optimal view of your site. You’re an expert at using the web. Make sure you look at it, really look at it, in every scenario you can muster. Sure, we’re all guilty of demoing code under the best possible circumstances. That’s natural. The thing is, that demo is the ideal vision of your site run by an expert. The thing you’re actually building, the down and dirty version, is for people with a completely different relationship with technology than yours.

Try to get in their shoes instead of assuming everyone else is in yours.

Lose Your Stack Biases
This is a new pet peeve that has cropped up over the past couple of years.

Lose your stack biases.

Your users don’t care if your stack is clever. What they care about is the speed, usability, look and feel, interactivity and features of your site. If your stack isn’t adding to one of those then you might be going down the road to stack obsession.


This is the foundation of what I’m talking about these days. This is all covered in much greater detail in the book and in my talks, but the overall gist is here. Now that I’ve gotten this out of the way I’ll get back to diving into the continuing evolution of the web and what we can do about it to make it the best web it can be.

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.