Web Watch

I didn’t tune in for the WWDC stuff this year. I can remember being excited for that each year, eagerly anticipating what cool thing was coming next. However, for the past few years, I’ve found the announcements to be mostly mundane. This year, unless they were going to announce new and better laptops, I wasn’t overly excited.

But when reading the recaps and tweets that followed the event, I was pretty intrigued to see the Apple Watch is now going to be able to support web content. The initial details were a bit scant, but Erik Runyon took the time to jot down some information he found in a video from WWDC.

It looks like WebKit on the watch is optimized for reading, as most probably thought it would. Some features are turned off (video, service workers, fonts, etc) and text-heavy pages automatically activate Reader Mode.

However, the watch also supports, from the sounds of it, a mostly full web experience.

If you don’t do anything to optimize your content, the watch will attempt to adapt already responsive sites to fit on the watch display. It does this by preserving 320 CSS pixel layouts and computing the initial scale to fit within the watch screen. So even if you set an initial scale of 1 at 320pt, the watch will scale it down to 0.49 initial scale at 156pt. It also reports its dimensions as 320x357 CSS pixels rather than the actual watch screen dimensions. It will also avoid horizontal scrolling.

The watch will also provide a way for you to optimize your layout specifically for the smaller sizes (though I’ll be honest, I question whether we needed a separate meta tag to accomplish this):

Now if you want to optimize your content specifically, you’ll need to add yet another meta tag.

<meta name=“disabled-adaptations” content=“watch”>

This will tell the watch to ignore its default adaptations and display as instructed in the CSS. So even if you have a media query at min-width 320px, the watch will not use it since its screen is smaller. Essentially, this meta tag will allow Webkit to treat the display width as the true width of Apple Watch, which are 272x340px for the 38mm, and 312x390px for the 42mm watch.

Now, who knows if this is going to take off. As Ethan pointed out in his post, we’re pretty terrible at predicting how people are going to use the web. I don’t immediately see any particular situations where I personally would want web access on my wrist. But that’s just me, and it would be foolish of me to project my situation onto everyone else. The only limitations of the web are the ones we place on it through our assumptions.

What interests me most about the web on a watch are the constraints that the hardware places.

The median site sends about 351kb of compressed JavaScript to “mobile” devices according to HTTP Archive. That’s roughly 1.7-2.4MB of uncompressed JavaScript the browser has to parse, compile, and execute. That little S3 processor is going to struggle if we try to serve anything close to the amount of JavaScript that we serve to everything else.

Of course, I haven’t seen anything yet about how the watch is going to treat all that JavaScript in the first place. They’ve decided to limit other expensive features. With JavaScript being so CPU-intensive, I wouldn’t be the least bit surprised if they limited JavaScript functionality in some way as well.

It would make complete sense to me if WebKit on the watch follows the approach that was taken by proxy browsers like Opera Mini, Puffin, UC Mini and the rest of their kin. In those cases, parsing, rendering, layout and JavaScript functionality are all handled on an intermediary server. That server then passes a snapshot of the page to the device. This enables lower-powered hardware to serve web content without overtaxing itself. In that situation, JavaScript functionality is typically limited to whatever can complete on the server within X amount of seconds.

Of course, that’s just speculation. And, I have to admit, fairly unlikely speculation. The idea of Apple using a proxy-browser seems a little un-Apple-like to me. But it doesn’t matter in the end, because where Apple finds a way to limit JavaScript execution or gives us free reign to shoot ourselves in the foot, ultimately the outcome is the same for developers.

The organizations that made the least assumptions about the people using them are going to be the ones ahead. The folks who made sure their markup was semantic and robust, so that reader mode wasn’t an issue; the folks who built their sites to be resilient and performant; the folks who used progressive enhancement—those folks are going to be just fine.

It’s not a new lesson, but it’s one we do tend to have to revisit from time to time. When we build our sites in a way that allows people using less-capable devices, slower networks and other less than ideal circumstances, we end up better prepared for whatever device or technology comes along next.

As Jeremy Keith wrote in Resilient Web Design: “The best way to be future-friendly is to be backwards‐compatible.”