Journal tags: apple

33

sparkline

SafarIE

I was moaning about Safari recently. Specifically I was moaning about the ridiculous way that browser updates are tied to operating system updates.

But I felt bad bashing Safari. It felt like a pile-on. That’s because a lot of people have been venting their frustrations with Safari recently:

I think it’s good that people share their frustrations with browsers openly, although I agree with Baldur Bjarnason that’s good to avoid Kremlinology and the motivational fallacy when blogging about Apple.

It’s also not helpful to make claims like “Safari is the new Internet Explorer!” Unless, that is, you can back up the claim.

On a recent episode of the HTTP 203 podcast, Jake and Surma set out to test the claim that Safari is the new IE. They did it by examining Safari according to a number of different measurements and comparing it to the olden days of Internet Explorer. The result is a really fascinating trip down memory lane along with a very nuanced and even-handed critique of Safari.

And the verdict? Well, you’ll just to have to listen to the podcast episode.

If you’d rather read the transcript, tough luck. That’s a real shame because, like I said, it’s an excellent and measured assessment. I’d love to add it to the links section of my site, but I can’t do that in good conscience while it’s inaccessible to the Deaf community.

When I started the Clearleft podcast, it was a no-brainer to have transcripts of every episode. Not only does it make the content more widely available, but it also makes it easier for people to copy and paste choice quotes.

Still, I get it. A small plucky little operation like Google isn’t going to have the deep pockets of a massive corporation like Clearleft. But if Jake and Surma were to open up a tip jar, I’d throw some money in to get HTTP 203 transcribed (I recommend getting Tina Pham to do it—she’s great!).

I apologise for my note of sarcasm there. But I share because I care. It really is an excellent discussion; one that everyone should be able to access.

Update: the bug with that episode of the HTTP 203 podcast has been fixed. Here’s the transcript! And all future episodes will have transcripts too:

Browsers

I mentioned recently that there might be quite a difference in tone between my links and my journal here on my website:

’Sfunny, when I look back at older journal entries they’re often written out of frustration, usually when something in the dev world is bugging me. But when I look back at all the links I’ve bookmarked the vibe is much more enthusiastic, like I’m excitedly pointing at something and saying “Check this out!” I feel like sentiment analyses of those two sections of my site would yield two different results.

My journal entries have been even more specifically negative of late. I’ve been bitchin’ and moanin’ about web browsers. But at least I’m an equal-opportunities bitcher and moaner.

I wish my journal weren’t so negative, but my mithering behaviour has been been encouraged. On more than one occasion, someone I know at a browser company has taken me aside to let me know that I should blog about any complaints I might have with their browser. It sounds counterintuitive, I know. But these blog posts can give engineers some ammunition to get those issues prioritised and fixed.

So my message to you is this: if there’s something about a web browser that you’re not happy with (or, indeed, if there’s something you’re really happy with), take the time to write it down and publish it.

Publish it on your website. You could post your gripes on Twitter but whinging on Jack’s website is just pissing in the wind. And I suspect you also might put a bit more thought into a blog post on your own site.

I know it’s a cliché to say that browser makers want to hear from developers—and I’m often cynical about it myself—but they really do want to know what we think. Share your thoughts. I’ll probably end up linking to what you write.

Updating Safari

Safari has been subjected to a lot of ire recently. Most of that ire has been aimed at the proposed changes to the navigation bar in Safari on iOS—moving it from a fixed top position to a floaty bottom position right over the content you’re trying to interact with.

Courage.

It remains to be seen whether this change will actually ship. That’s why it’s in beta—to gather all the web’s hot takes first.

But while this very visible change is dominating the discussion, invisible changes can be even more important. Or in the case of Safari, the lack of changes.

Compared to other browsers, Safari lags far behind when it comes to shipping features. I’m not necessarily talking about cutting-edge features either. These are often standards that have been out for years. This creates a gap—albeit an invisible one—between Safari and other browsers.

Jorge Arango has noticed this gap:

I use Safari as my primary browser on all my devices. I like how Safari integrates with the rest of the OS, its speed, and privacy features. But, alas, I increasingly have issues rendering websites and applications on Safari.

That’s the perspective of an end-user. Developers who have to deal with the gap in features are more, um, strident in their opinions. Perry Sun wrote For developers, Apple’s Safari is crap and outdated:

Don’t get me wrong, Safari is very good web browser, delivering fast performance and solid privacy features.

But at the same time, the lack of support for key web technologies and APIs has been both perplexing and annoying at the same time.

Alas, that post also indulges in speculation about Apple’s motives which always feels a bit too much like a conspiracy theory to me. Baldur Bjarnason has more to say on that topic in his post Kremlinology and the motivational fallacy when blogging about Apple. He also points to a good example of critiquing Safari without speculating about motives: Dave’s post One-offs and low-expectations with Safari, which documents all the annoying paper cuts inflicted by Safari’s “quirks.”

Another deep dive that avoids speculating about motives comes from Tim Perry: Safari isn’t protecting the web, it’s killing it. I don’t agree with everything in it. I think that Apple—and Mozilla’s—objections to some device APIs are informed by a real concern about privacy and security. But I agree with his point that it’s not enough to just object; you’ve got to offer an alternative vision too.

That same post has a litany of uncontroversial features that shipped in Safari looong after they shipped in other browsers:

Again: these are not contentious features shipping by only Chrome, they’re features with wide support and no clear objections, but Safari is still not shipping them until years later. They’re also not shiny irrelevant features that “bloat the web” in any sense: each example I’ve included above primarily improving core webpage UX and performance. Safari is slowing that down progress here.

But perhaps most damning of all is how Safari deals with bugs.

A recent release of Safari shipped with a really bad Local Storage bug. The bug was fixed within a day. Yay! But the fix won’t ship until …who knows?

This is because browser updates are tied to operating system updates. Yes, this is just like the 90s when Microsoft claimed that Internet Explorer was intrinsically linked to Windows (a tactic that didn’t work out too well for them in the subsequent court case).

I don’t get it. I’m pretty sure that other Apple products ship updates and fixes independentally of OS releases. I’m sure I’ve received software updates for Keynote, Garage Band, and other pieces of software made by Apple.

And yet, of all the applications that need a speedy update cycle—a user agent for the World Wide Web—Apple’s version is needlessly delayed by the release cycle of the entire operating system.

I don’t want to speculate on why this might be. I don’t know the technical details. But I suspect that the root cause might not be technical in nature. Apple have always tied their browser updates to OS releases. If Google’s cardinal sin is avoiding anything “Not Invented Here”, Apple’s downfall is “We’ve always done it this way.”

Evergreen browsers update in the background, usually at regular intervals. Firefox is an evergreen browser. Chrome is an evergreen browser. Edge is an evergreen browser.

Safari is not an evergreen browser.

That’s frustrating when it comes to new features. It’s unforgivable when it comes to bugs.

At least on Apple’s desktop computers, users have the choice to switch to a different browser. But on Apple’s mobile devices, users have no choice but to use Safari’s rendering engine, bugs and all.

As I wrote when I had to deal with one of Safari’s bugs:

I wish that Apple would allow other rendering engines to be installed on iOS devices. But if that’s a hell-freezing-over prospect, I wish that Safari updates weren’t tied to operating system updates.

Safari 15

If you download Safari Technology Preview you can test drive features that are on their way in Safari 15. One of those features, announced at Apple’s World Wide Developer Conference, is coloured browser chrome via support for the meta value of “theme-color.” Chrome on Android has supported this for a while but I believe Safari is the first desktop browser to add support. They’ve also added support for the media attribute on that meta element to handle “prefers-color-scheme.”

This is all very welcome, although it does remind me a bit of when Internet Explorer came out with the ability to make coloured scrollbars. I mean, they’re nice features’n’all, but maybe not the most pressing? Safari is still refusing to acknowledge progressive web apps.

That’s not quite true. In her WWDC video Jen demonstrates how you can add a progressive web app like Resilient Web Design to your home screen. I’m chuffed that my little web book made an appearance, but when you see how you add a site to your home screen in iOS, it’s somewhat depressing.

The steps to add a website to your home screen are:

  1. Tap the “share” icon. It’s not labelled “share.” It’s a square with an arrow coming out of the top of it.
  2. A drawer pops up. The option to “add to home screen” is nowhere to be seen. You have to pull the drawer up further to see the hidden options.
  3. Now you must find “add to home screen” in the list
  • Copy
  • Add to Reading List
  • Add Bookmark
  • Add to Favourites
  • Find on Page
  • Add to Home Screen
  • Markup
  • Print

It reminds of this exchange in The Hitchhiker’s Guide To The Galaxy:

“You hadn’t exactly gone out of your way to call attention to them had you? I mean like actually telling anyone or anything.”

“But the plans were on display…”

“On display? I eventually had to go down to the cellar to find them.”

“That’s the display department.”

“With a torch.”

“Ah, well the lights had probably gone.”

“So had the stairs.”

“But look you found the notice didn’t you?”

“Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of The Leopard.’”

Safari’s current “support” for adding progressive web apps to the home screen feels like the minimum possible …just enough to use it as a legal argument if you happen to be litigated against for having a monopoly on app distribution. “Hey, you can always make a web app!” It’s true in theory. In practice it’s …suboptimal, to put it mildly.

Still, those coloured tab bars are very nice.

It’s a little bit weird that this stylistic information is handled by HTML rather than CSS. It’s similar to the meta viewport value in that sense. I always that the plan was to migrate that to CSS at some point, but here we are a decade later and it’s still very much part of our boilerplate markup.

Some people have remarked that the coloured browser chrome can make the URL bar look like part of the site so people might expect it to operate like a site-specific search.

I also wonder if it might blur “the line of death”; that point in the UI where the browser chrome ends and the website begins. Does the unified colour make it easier to spoof browser UI?

Probably not. You can already kind of spoof browser UI by using the right shade of grey. Although the removal any kind of actual line in Safari does give me pause for thought.

I tend not to think of security implications like this by default. My first thought tends to be more about how I can use the feature. It’s only after a while that I think about how bad actors might abuse the same feature. I should probably try to narrow the gap between those thoughts.

Upgrades and polyfills

I started getting some emails recently from people having issues using The Session. The issues sounded similar—an interactive component that wasn’t, well …interacting.

When I asked what device or browser they were using, the answer came back the same: Safari on iPad. But not a new iPad. These were older iPads running older operating systems.

Now, remember, even if I wanted to recommend that they use a different browser, that’s not an option:

Safari is the only browser on iOS devices.

I don’t mean it’s the only browser that ships with iOS devices. I mean it’s the only browser that can be installed on iOS devices.

You can install something called Chrome. You can install something called Firefox. Those aren’t different web browsers. Under the hood they’re using Safari’s rendering engine. They have to.

It gets worse. Not only is there no choice when it comes to rendering engines on iOS, but the rendering engine is also tied to the operating system.

If you’re on an old Apple laptop, you can at least install an up-to-date version of Firefox or Chrome. But you can’t install an up-to-date version of Safari. An up-to-date version of Safari requires an up-to-date version of the operating system.

It’s the same on iOS devices—you can’t install a newer version of Safari without installing a newer version of iOS. But unlike the laptop scenario, you can’t install any version of Firefox of Chrome.

It’s disgraceful.

It’s particularly frustrating when an older device can’t upgrade its operating system. Upgrades for Operating system generally have some hardware requirements. If your device doesn’t meet those requirements, you can’t upgrade your operating system. That wouldn’t matter so much except for the Safari issue. Without an upgraded operating system, your web browsing experience stagnates unnecessarily.

For want of a nail

  • A website feature isn’t working so
  • you need to upgrade your browser which means
  • you need to upgrade your operating sytem but
  • you can’t upgrade your operating system so
  • you need to buy a new device.

Apple doesn’t allow other browsers to be installed on iOS devices so people have to buy new devices if they want to use the web. Handy for Apple. Bad for users. Really bad for the planet.

It’s particularly galling when it comes to iPads. Those are exactly the kind of casual-use devices that shouldn’t need to be caught in the wasteful cycle of being used for a while before getting thrown away. I mean, I get why you might want to have a relatively modern phone—a device that’s constantly with you that you use all the time—but an iPad is the perfect device to just have lying around. You shouldn’t feel pressured to have the latest model if the older version still does the job:

An older tablet makes a great tableside companion in your living room, an effective e-book reader, or a light-duty device for reading mail or checking your favorite websites.

Hang on, though. There’s another angle to this. Why should a website demand an up-to-date browser? If the website has been built using the tried and tested approach of progressive enhancement, then everyone should be able to achieve their goals regardless of what browser or device or operating system they’re using.

On The Session, I’m using progressive enhancement and feature detection everywhere I can. If, for example, I’ve got some JavaScript that’s going to use querySelectorAll and addEventListener, I’ll first test that those methods are available.

if (!document.querySelectorAll || !window.addEventListener) {
  // doesn't cut the mustard.
  return;
}

I try not to assume that anything is supported. So why was I getting emails from people with older iPads describing an interaction that wasn’t working? A JavaScript error was being thrown somewhere and—because of JavaScript’s brittle error-handling—that was causing all the subsequent JavaScript to fail.

I tracked the problem down to a function that was using some DOM methods—matches and closest—as well as the relatively recent JavaScript forEach method. But I had polyfills in place for all of those. Here’s the polyfill I’m using for matches and closest. And here’s the polyfill I’m using for forEach.

Then I spotted the problem. I was using forEach to loop through the results of querySelectorAll. But the polyfill works on arrays. Technically, the output of querySelectorAll isn’t an array. It looks like an array, it quacks like an array, but it’s actually a node list.

So I added this polyfill from Chris Ferdinandi.

That did the trick. I checked with the people with those older iPads and everything is now working just fine.

For the record, here’s the small collection of polyfills I’m using. Polyfills are supposed to be temporary. At some stage, as everyone upgrades their browsers, I should be able to remove them. But as long as some people are stuck with using an older browser, I have to keep those polyfills around.

I wish that Apple would allow other rendering engines to be installed on iOS devices. But if that’s a hell-freezing-over prospect, I wish that Safari updates weren’t tied to operating system updates.

Apple may argue that their browser rendering engine and their operating system are deeply intertwingled. That line of defence worked out great for Microsoft in the ‘90s.

Web browsers on iOS

Safari is the only browser on iOS devices.

I don’t mean it’s the only browser that ships with iOS devices. I mean it’s the only browser that can be installed on iOS devices.

You can install something called Chrome. You can install something called Firefox. Those aren’t different web browsers. Under the hood they’re using Safari’s rendering engine. They have to. The app store doesn’t allow other browsers to be listed. The apps called Chrome and Firefox are little more than skinned versions of Safari.

If you’re a web developer, there are two possible reactions to hearing this. One is “Duh! Everyone knows that!”. The other is “What‽ I never knew that!”

If you fall into the first category, I’m guessing you’ve been a web developer for a while. The fact that Safari is the only browser on iOS devices is something you’ve known for years, and something you assume everyone else knows. It’s common knowledge, right?

But if you’re relatively new to web development—heck, if you’ve been doing web development for half a decade—you might fall into the second category. After all, why would anyone tell you that Safari is the only browser on iOS? It’s common knowledge, right?

So that’s the situation. Safari is the only browser that can run on iOS. The obvious follow-on question is: why?

Apple at this point will respond with something about safety and security, which are certainly important priorities. So let me rephrase the question: why on iOS?

Why can I install Chrome or Firefox or Edge on my Macbook running macOS? If there are safety or security reasons for preventing me from installing those browsers on my iOS device, why don’t those same concerns apply to my macOS device?

At one time, the mobile operating system—iOS—was quite different to the desktop operating system—OS X. Over time the gap has narrowed. At this point, the operating systems are converging. That makes sense. An iPhone, an iPad, and a Macbook aren’t all that different apart from the form factor. It makes sense that computing devices from the same company would share an underlying operating system.

As this convergence continues, the browser question is going to have to be decided in one direction or the other. As it is, Apple’s laptops and desktops strongly encourage you to install software from their app store, though it is still possible to install software by other means. Perhaps they’ll decide that their laptops and desktops should only be able to install software from their app store—a decision they could justify with safety and security concerns.

Imagine that situation. You buy a computer. It comes with one web browser pre-installed. You can’t install a different web browser on your computer.

You wouldn’t stand for it! I mean, Microsoft got fined for anti-competitive behaviour when they pre-bundled their web browser with Windows back in the 90s. You could still install other browsers, but just the act of pre-bundling was seen as an abuse of power. Imagine if Windows never allowed you to install Netscape Navigator?

And yet that’s exactly the situation in 2020.

You buy a computing device from Apple. It might be a Macbook. It might be an iPad. It might be an iPhone. But you can only install your choice of web browser on one of those devices. For now.

It is contradictory. It is hypocritical. It is indefensible.

Implementors

The latest newsletter from The History Of The Web is a good one: The Browser Engine That Could. It’s all about the history of browsers and more specifically, rendering engines.

Jay quotes from a 1992 email by Tim Berners-Lee when there was real concern about having too many different browsers. But as history played out, the concern shifted to having too few different browsers.

I wrote about this—back when Edge switched to using Chromium—in a post called Unity where I compared it to political parties:

If you have hundreds of different political parties, that’s not ideal. But if you only have one political party, that’s very bad indeed!

I talked about this some more with Brian and Stuart on the Igalia Chats podcast: Web Ecosystem Health (here’s the mp3 file).

In the discussion we dive deeper into the naunces of browser engine diversity; how it’s not the numbers that matter, but representation. The danger with one dominant rendering engine is that it would reflect one dominant set of priorities.

I think we’re starting to see this kind of battle between different sets of priorities playing out in the browser rendering engine landscape.

Webkit published a list of APIs they won’t be implementing in their current form because of security concerns around fingerprinting. Mozilla is taking the same stand. Google is much more gung-ho about implementing those APIs.

I think it’s safe to say that every implementor wants to ship powerful APIs and ensure security and privacy. The issue is with which gets priority. Using the language of principles and priorities, you could crudely encapsulate Apple and Mozilla’s position as:

Privacy, even over capability.

That design principle would pass the reversibility test. In fact, Google’s position might be represented as:

Capability, even over privacy.

I’m not saying Apple and Mozilla don’t value powerful APIs. I’m not saying Google doesn’t value privacy. I’m saying that Google’s priorities are different to Apple’s and Mozilla’s.

Alas, Alex is saying that Apple and Mozilla don’t value capability:

There is a contingent of browser vendors today who do not wish to expand the web platform to cover adjacent use-cases or meaningfully close the relevance gap that the shift to mobile has opened.

That’s very disappointing. It’s a cheap shot. As cheap as saying that, given Google’s business model, Chrome wouldn’t want to expand the web platform to provide better privacy and security.

Apple’s attack on service workers

Apple aren’t the best at developer relations. But, bad as their communications can be, I’m willing to cut them some slack. After all, they’re not used to talking with the developer community.

John Wilander wrote a blog post that starts with some excellent news: Full Third-Party Cookie Blocking and More. Safari is catching up to Firefox and disabling third-party cookies by default. Wonderful! I’ve had third-party cookies disabled for a few years now, and while something occassionally breaks, it’s honestly a pretty great experience all around. Denying companies the ability to track users across sites is A Good Thing.

In the same blog post, John said that client-side cookies will be capped to a seven-day lifespan, as previously announced. Just to be clear, this only applies to client-side cookies. If you’re setting a cookie on the server, using PHP or some other server-side language, it won’t be affected. So persistent logins are still doable.

Then, in an audacious example of burying the lede, towards the end of the blog post, John announces that a whole bunch of other client-side storage technologies will also be capped to seven days. Most of the technologies are APIs that, like cookies, can be used to store data: Indexed DB, Local Storage, and Session Storage (though there’s no mention of the Cache API). At the bottom of the list is this:

Service Worker registrations

Okay, let’s clear up a few things here (because they have been so poorly communicated in the blog post)…

The seven day timer refers to seven days of Safari usage, not seven calendar days (although, given how often most people use their phones, the two are probably interchangable). So if someone returns to your site within a seven day period of using Safari, the timer resets to zero, and your service worker gets a stay of execution. Lucky you.

This only applies to Safari. So if your site has been added to the home screen and your web app manifest has a value for the “display” property like “standalone” or “full screen”, the seven day timer doesn’t apply.

That piece of information was missing from the initial blog post. Since the blog post was updated to include this clarification, some people have taken this to mean that progressive web apps aren’t affected by the upcoming change. Not true. Only progressive web apps that have been added to the home screen (and that have an appropriate “display” value) will be spared. That’s a vanishingly small percentage of progressive web apps, especially on iOS. To add a site to the home screen on iOS, you need to dig and scroll through the share menu to find the right option. And you need to do this unprompted. There is no ambient badging in Safari to indicate that a site is installable. Chrome’s install banner isn’t perfect, but it’s better than nothing.

Just a reminder: a progressive web app is a website that

  • runs on HTTPS,
  • has a service worker,
  • and a web manifest.

Adding to the home screen is something you can do with a progressive web app (or any other website). It is not what defines progressive web apps.

In any case, this move to delete service workers after seven days of using Safari is very odd, and I’m struggling to find the connection to the rest of the blog post, which is about technologies that can store data.

As I understand it, with the crackdown on setting third-party cookies, trackers are moving to first-party technologies. So whereas in the past, a tracking company could tell its customers “Add this script element to your pages”, now they have to say “Add this script element and this script file to your pages.” That JavaScript file can then store a unique idenitifer on the client. This could be done with a cookie, with Local Storage, or with Indexed DB, for example. But I’m struggling to understand how a service worker script could be used in this way. I’d really like to see some examples of this actually happening.

The best explanation I can come up with for this move by Apple is that it feels like the neatest solution. That’s neat as in tidy, not as in nifty. It is definitely not a nifty solution.

If some technologies set by a specific domain are being purged after seven days, then the tidy thing to do is purge all technologies from that domain. Service workers are getting included in that dragnet.

Now, to be fair, browsers and operating systems are free to clean up storage space as they see fit. Caches, Local Storage, Indexed DB—all of those are subject to eventually getting cleaned up.

So I was curious. Wanting to give Apple the benefit of the doubt, I set about trying to find out how long service worker registrations currently last before getting deleted. Maybe this announcement of a seven day time limit would turn out to be not such a big change from current behaviour. Maybe currently service workers last for 90 days, or 60, or just 30.

Nope:

There was no time limit previously.

This is not a minor change. This is a crippling attack on service workers, a technology specifically designed to improve the user experience for return visits, whether it’s through improved performance or offline access.

I wouldn’t be so stunned had this announcement come with an accompanying feature that would allow Safari users to know when a website is a progressive web app that can be added to the home screen. But Safari continues to ignore the existence of progressive web apps. And now it will actively discourage people from using service workers.

If you’d like to give feedback on this ludicrous development, you can file a bug (down in the cellar in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying “Beware of the Leopard”).

No doubt there will still be plenty of Apple apologists telling us why it’s good that Safari has wished service workers into the cornfield. But make no mistake. This is a terrible move by Apple.

I will say this though: given The Situation we’re all living in right now, some good ol’ fashioned Hot Drama by a browser vendor behaving badly feels almost comforting.

Timing

Apple Inc. is my accidental marketing department.

On April 29th, 2010, Steve Jobs published his infamous Thoughts on Flash. It thrust the thitherto geek phrase “HTML5” into the mainstream press:

HTML5, the new web standard that has been adopted by Apple, Google and many others, lets web developers create advanced graphics, typography, animations and transitions without relying on third party browser plug-ins (like Flash). HTML5 is completely open and controlled by a standards committee, of which Apple is a member.

Five days later, I announced the first title from A Book Apart: HTML5 For Web Designers. The timing was purely coincidental, but it definitely didn’t hurt that book’s circulation.

Fast forward eight years…

On March 29th, 2018, Apple released the latest version of iOS. Unmentioned in the press release, this update added service worker support to Mobile Safari.

Five days later, I announced the 26th title from A Book Apart: Going Offline.

For a while now, quite a few people have cited Apple’s lack of support as a reason why they weren’t investigating service workers. That excuse no longer holds water.

Once again, the timing is purely coincidental. But it can’t hurt.

The web on my phone

It’s funny how times have changed. Remember back in the 90s when Microsoft—quite rightly—lost an anti-trust case? They were accused of abusing their monopolistic position in the OS world to get an unfair advantage in the browser world. By bundling a copy of Internet Explorer with every copy of Windows, they were able to crush the competition from Netscape.

Mind you, it was still possible to install a Netscape browser on a Windows machine. Could you imagine if Microsoft had tried to make that impossible? There would’ve been hell to pay! They wouldn’t have had a legal leg to stand on.

Yet here we are two decades later and that’s exactly what an Operating System vendor is doing. The Operating System is iOS. It’s impossible to install a non-Apple browser onto an Apple mobile computer. For some reason, the fact that it’s a mobile device (iPhone, iPad) makes it different from a desktop-bound device running OS X. Very odd considering they’re all computers.

“But”, I hear you say, “What about Chrome for iOS? Firefox for iOS? Opera for iOS?”

Chrome for iOS is not Chrome. Firefox for iOS is not Firefox. Opera for iOS is not Opera. They are all using WebKit. They’re effectively the same as Mobile Safari, just with different skins.

But there won’t be any anti-trust case here.

I think it’s a real shame. Partly, I think it’s a shame because as a developer, I see an Operating System being let down by its browser. But mostly, I think it’s a shame because I use an iPhone and I’m being let down by its browser.

It’s kind of ironic, because when the iPhone first launched, it was all about the web apps. Remember, there was no App Store for the first year of the iPhone’s life. If you wanted to build an app, you had to use web technologies. Apple were ahead of their time. Alas, the web technologies weren’t quite up to the task back in 2007. These days, though, there are web technologies landing in browsers that are truly game-changing.

In case you hadn’t noticed, I’m very excited about Service Workers. It’s doubly exciting to see the efforts the Chrome on Android team are making to make the web a first-class citizen. As Remy put it:

If I add this app to my home screen, it will work when I open it.

I’d like to be able to use Chrome, Firefox, or Opera on my iPhone—real Chrome, real Firefox, or real Opera; not a skinned version of Safari. Right now the only way for me to switch browsers is to switch phones. Switching phones is a pain in the ass, but I’m genuinely considering it.

Whereas I’m all talk, Henrik has taken action. Like me, he doesn’t actually care about the Operating System. He cares about the browser:

Android itself bores me, honestly. There’s nothing all that terribly new or exciting here.’

save one very important detail…

IT’S CURRENTLY THE BEST MOBILE WEB APP PLATFORM

That’s true for now. The pole position for which browser is “best” is bound to change over time. The point is that locking me into one particular browser on my phone doesn’t sit right with me. It’s not very …webby.

I’m sure that Apple are not quaking in their boots at the thought of myself or Henrik switching phones. We are minuscule canaries in a very niche mine.

But what should give Apple pause for thought is the user experience they can offer for using the web. If they gain a reputation for providing a sub-par web experience compared to the competition, then maybe they’ll have to make the web a first-class citizen.

If I want to work towards that, switching phones probably won’t help. But what might help is following Alex’s advice in his answer to the question “What do we do about Safari?”:

What we do about Safari is we make websites amazing …and then they can’t not implement.

I’ll be doing that here on adactio, over on The Session (and Huffduffer when I get around to overhauling it), making progressively enhanced, accessible, offline-first, performant websites.

I’ll also be doing it at Clearleft. If you work at an organisation that wants a progressively-enhanced, accessible, offline-first, performant website, we should talk.

Without delay

When I wrote about mobile Safari adding support for touch-action: manipulation, I finished with this snarky observation:

Anyway, I’m off to update my CSS even though this latest fix probably won’t land in mobile Safari until, oh ….probably next October.

Historically, Apple have tied mobile Safari updates to iOS version number increments, and they happen about once a year. But this time, it looks like my snark was unfounded:

On Safari for iOS, the 350 ms wait time to detect a second tap has been removed to create a “fast-tap” response. This is enabled for pages that declare a viewport with either width=device-width or user-scalable=no. Authors can also opt in to fast-tap behavior on specific elements by using the CSS touch-action property, using the manipulation value.

That’s from the release notes for Safari 9.1—a point release.

I’m very pleased to have been absolutely wrong with my prediction of Apple’s timing.

Home screen

Remy posted a screenshot to Twitter last week.

A screenshot of adactio.com on an Android device showing an Add To Home Screen prompt.

That “Add To Home Screen” dialogue is not something that Remy explicitly requested (though, of course, you can—and should—choose to add adactio.com to your home screen). That prompt appears in Chrome on Android as the result of a fairly simple algorithm based on a few factors:

  1. The website is served over HTTPS. My site is.
  2. The website has a manifest file. Here’s my JSON manifest file.
  3. The website has a Service Worker. Here’s my site’s Service Worker script (although a little birdie told me that the Service Worker script can be as basic as a blank file).
  4. The user visits the website a few times over the course of a few days.

I think that’s a reasonable set of circumstances. I particularly like that there is no way of forcing the prompt to appear.

There are some carrots in there: Want to have the user prompted to add your site to their home screen? Well, then you need to be serving on a secure connection, and you’d better get on board that Service Worker train.

Speaking of which, after I published a walkthrough of my first Service Worker, I got an email bemoaning the lack of browser support:

I was very much interested myself in this topic, until I checked on the “Can I use…” site the availability of this technology. In one word “limited”. Neither Safari nor IOS Safari support it, at least now, so I cannot use it for implementing mobile applications.

I don’t think this is the right way to think about Service Workers. You don’t build your site on top of a Service Worker—you add a Service Worker on top of your existing site. It has been explicitly designed that way: you can’t make it the bedrock of your site’s functionality; you can only add it as an enhancement.

I think that’s really, really smart. It means that you can start implementing Service Workers today and as more and more browsers add support, your site will appear to get better and better. My site worked fine for fifteen years before I added a Service Worker, and on the day I added that Service Worker, it had no ill effect on non-supporting browsers.

Oh, and according to the Webkit five year plan, Service Worker support is on its way. This doesn’t surprise me. I can’t imagine that Apple would let Google upstage them for too long with that nice “add to home screen” flow.

Alas, Mobile Safari’s glacial update cycle means that the earliest we’ll see improvements like Service Workers will probably be September or October of next year. In the age of evergreen browsers, Apple’s feast-or-famine approach to releasing updates is practically indistinguishable from stagnation.

Still, slowly but surely, game-changing technologies are landing in browsers. At the same time, the long-term problems with betting on native apps are starting to become clearer. Native apps are still ahead of what can be accomplished on the web, but it was ever thus:

The web will always be lagging behind some other technology. I’m okay with that. If anything, I see these other technologies as the research and development arm of the web. CD-ROMs, Flash, and now native apps show us what authors want to be able to do on the web. Slowly but surely, those abilities start becoming available in web browsers.

The pace of this standardisation can seem infuriatingly slow. Sometimes it is too slow. But it’s important that we get it right—the web should hold itself to a higher standard. And so the web plays the tortoise while other technologies race ahead as the hare.

It’s interesting to see how the web could take the desirable features of native—offline support, smooth animations, an icon on the home screen—without sacrificing the strengths of the web—linking, responsiveness, the lack of App Store gatekeepers. That kind of future is what Alex is calling progressive apps:

Critically, these apps can deliver an even better user experience than traditional web apps. Because it’s also possible to build this performance in as progressive enhancement, the tangible improvements make it worth building this way regardless of “appy” intent.

Flipkart recently launched something along those lines, although it’s somewhat lacking in the “enhancement” department; the core content is delivered via JavaScript—a fragile approach.

What excites me is the prospect of building services that work just fine on low-powered devices with basic browsers, but that also take advantage of all the great possibilities offered by the latest browsers running on the newest devices. Backwards compatible and future friendly.

And if that sounds like a naïve hope, then I humbly suggest that Service Workers are a textbook example of exactly that approach.

100 words 082

Apple launched the iPad five years ago. A few months after its release, I bought one of those first-generation iPads. I used it for a while before concluding that, much as I had suspected, it wasn’t the right device for me. But it was the perfect device for my mother. So I gave the iPad to my mother.

Sure enough, it worked out great for her. But now it’s getting quite long in the tooth. So now I’ve given her a new iPad for her birthday; one that’s lighter, faster, and—crucially—comes with a camera. It’s a Facetime device.

100 words 015

An article in Wired highlights a key feature of the new Apple watch—to free us from the tyranny of the smartphone screen.

I’ve never set up email on my phone.

If I install an app on my phone, the first thing I do is switch off all notifications. That saves battery life and sanity.

The only time my phone is allowed to ask for my attention is for phone calls, SMS, or FaceTime (all rare occurrences). I initiate every other interaction—Twitter, Instagram, Foursquare, the web. My phone is a tool that I control, not the other way around.

iOS Six Fix

Last Christmas I gave you my bug report. Well, more of a whinge really. Scott put together a much better bug report and test page:

When the meta viewport tag is set to content=”width=device-width,initial-scale=1”, or any value that allows user-scaling, changing the device to landscape orientation causes the page to scale larger than 1.0. As a result, a portion of the page is cropped off the right, and the user must double-tap (sometimes more than once) to get the page to zoom properly into view.

Yes, it’s the old orientation and scale bug in Mobile Safari.

I’m pleased to report that as of iOS version 6, this bug seems to have finally been squashed. Hallelujah!

Given the relatively rapid upgrade path for iPhone, iPod Touch and iPad users, it won’t be long until we can remove our clever solutions for working around this problem.

Stand down, hackers, stand down. This bug has been taken care of.

Jeremy caught the mantis

Relations

When I was writing about browser-developer relations yesterday, I took this little dig at Safari:

Apple, of course, dodges the issue entirely by having absolutely zero developer relations when it comes to their browser.

A friend of mine who works at Apple took me to task about this on Twitter (not in the public timeline, of course, but by direct message). I was told I was being unfair. After all, wasn’t I aware of Vicki Murley, Safari Technologies Evangelist? I had to admit that I wasn’t.

“What’s her URL?” I asked.

“URL?”

“Of her blog.”

“She doesn’t have one.”

That might explain why I hadn’t heard of her. Nor have I seen her at any conferences; not at the Browser Wars panels at South by Southwest, nor at the browser panels at Mobilsm.

The Safari Technologies Evangelist actually does speak at one conference: WWDC. And the videos from that conference are available online …if you sign on the dotted line.

Now, I’m not saying that being in developer relations for a browser vendor means that you must blog or must go to conferences. But some kind of public visibility is surely desirable, right? Not at Apple.

I remember a couple of years back, meeting the Safari evangelist for the UK. He came down to Brighton to have lunch with me and some of the other Clearlefties. I remember telling him that I could put him touch with the organisers of some mobile-focused conferences because he’d be the perfect speaker.

“Yeah,” he said, “I’m not actually allowed to speak at conferences.”

An evangelist who isn’t allowed to evangelise. That seems kind of crazy to me …and I can only assume that it’s immensely frustrating for them. But in the case of Apple, we tend to just shrug our shoulders and say, “Oh, well. That’s Apple. That’s just the way it is.”

Back when I was soliciting questions for this year’s browser panel at Mobilism, Remy left a little rant that began:

When are we, as a web development community, going to stop giving Apple a free fucking pass? They’re consistently lacking in the open discussion in to improving the gateway to the web: the browser.

And he ended:

Even the mighty PPK who tells entire browser vendors “fuck you”, doesn’t call Apple out, allowing them to slither on. Why is it we continue to allow Apple to get away with it? And can this ever change?

When I next saw Remy, I chuckled and said something along the usual lines of “Hey, isn’t that just the way it is at Apple?” And then Remy told me something that made me rethink my defeatist accepting attitude.

He reminded me about the post on Daring Fireball where John describes the sneak peak he was given of Mountain Lion:

But this, I say, waving around at the room, this feels a little odd. I’m getting the presentation from an Apple announcement event without the event. I’ve already been told that I’ll be going home with an early developer preview release of Mountain Lion. I’ve never been at a meeting like this, and I’ve never heard of Apple seeding writers with an as-yet-unannounced major update to an operating system. Apple is not exactly known for sharing details of as-yet-unannounced products, even if only just one week in advance. Why not hold an event to announce Mountain Lion — or make the announcement on apple.com before talking to us?

That’s when Schiller tells me they’re doing some things differently now.

And that, said Remy, is exactly why now is the time to start pushing back against Apple’s opaque developer relations strategy when it comes to Safari: they’re doing some things differently now.

He’s right.

Apple’s culture of secrecy has served them very, very well for some things—like hardware—but it’s completely at odds with the spirit of the web. That culture clash is most evident with Safari; not just a web browser, but a web browser built on the open-source Webkit platform.

I’m sure that Vicki Murley is great at her job. But her job will remain limited as long as she is hampered by the legacy of Apple’s culture.

That culture of secrecy is not written in stone. It can change. It should change. And the time for that change is now.

iWish

Dear Apple Claus,

I’ve been a very good boy this year so I hope you don’t me asking for a little present. What I’d really like for Christmas is for you to fix that strange orientation scaling bug in Mobile Safari.

Just in case you’ve forgotten about it, my friend Scott—who has been a very, very good boy this year (what with that whole Boston Globe thing)—put together a test page quite a while back to demonstrate the problem.

Basically, if I set meta name="viewport" content="width=device-width, initial-scale=1.0" then it means a pixel should be equal to a pixel: in portrait view, the width should be 320 pixels; in landscape view the width should be 480 pixels. But in Mobile Safari, if I move from portrait to landscape, the width jumps to a value larger than 480 pixels, which means the hapless user must double tap to bring the scale down to 1:1.

Now, admittedly, I could just set meta name="viewport" content="width=device-width" and leave it at that (or I could additionally declare minimum-scale=1.0). But then when the user changes from portrait to landscape, although it doesn’t have the same over-zooming behaviour, it does scale up. That means I’m not getting the full 480 pixels (it’s effectively still a 320 pixel wide display, even in landscape).

I could make the bug disappear by adding maximum-scale=1.0 or user-scaleable=no but that’s the cure that kills the patient. I also did some hacking with Shi Chuan but what we come up with still feels fairly clunky.

So that’s why I’m writing to you, Father Applemas. Won’t you fix this bug for me?

My friend PPK thinks you won’t fix this bug because it would trigger a reflow (and repaint) of the page …but I know that can’t be the reason because the bug doesn’t occur when going from landscape to portrait!

Also—and this is the really strange part—If I’m looking at a web page on my iPhone/Pod in a custom browser (like the Twitter app), rather than using Mobile Safari, then the bug doesn’t occur.

I don’t get, Apple Claus. Why have one behaviour for webviews in other people’s apps and a different behaviour for your own app?

Anyway, if you could see your way to granting this boy’s wish, it would make for a webby Christmas.

Hugs and kisses,

Jeremy

P.S. By this time next year, it would be lovely to have access to the camera (and other device APIs) from the browser …but I’m getting ahead of myself.

Update: the bug has been fixed in iOS 6.

Super-Toys Last All Summer Long

When I was in Boston for An Event Apart back in May, I bought an .

That makes it sound like a very casual act. Back then, iPads were in very short supply. When I asked an employee at the Apple Store in Boston if they had any iPads in stock, he didn’t answer Hmm… let me check, or Not at the moment. He answered Oh, God no!

Fortunately, Malarkey was far more persistent than I and managed, through means fair or foul, to track down the only two iPads for sale in all of Beantown.

I used the device for two months and then, as predicted, I gave it to my mother. It was definitely the right decision. She loves it. She’s using it all the time, surfing the web wherever she pleases.

I liked using the iPad, but I didn’t love it. Once the novelty wore off, I found I had few good reasons to use it rather than use my Macbook.

Some observations from a Summer spent in the company of the iPad…

The iPad is almost exactly the wrong weight. It’s just that little bit too heavy to comfortably hold in one hand. It’s no coincidence that all of iPad demonstrations show it resting on a raised leg. I found that if I was using the iPad for any length of time, I would adopt a more and more relaxed, nay… slouchy position. Before I knew it, I was supine on the sofa, one leg raised with the iPad resting against it, like a Roman emperor waiting to be fed individually-peeled grapes.

The iPad is a great device for reading. I rediscovered the power of RSS. The iPad is also a great device for browsing the web. The problem is, I don’t really browse the web that much. Instead, I browse, I bookmark, I quote, I huffduff, I copy, I paste, I tweet, I share. Using an iPad made me realise that the web is very much a read/write medium for me. While it’s possible to do all those things on the iPad, it isn’t easy.

The tell-tale moment came when I was reading something on the iPad—supine on the sofa, of course—that I wanted to post to Delicious. Rather than fill in a form using the iPad’s on-screen keyboard, I found myself putting the iPad down and reaching for my Macbook just to accomplish that one little task. That’s when I knew it wasn’t the ideal device for me.

Don’t get me wrong: I’m not joining in the chorus of those silly enough to say that the iPad can’t be used for creating, editing and updating. That conclusion would be far too absolute and Boolean. But I think the iPad favours consumption more than creation. And that’s okay. That still makes it a great device for many people—such as my mother.

There’s one big fly in the ointment of the iPad as a device for non-geeks—such as my mother—and that’s the out-of-the-box experience. John Gruber pointed this out in his review of the iPad:

One thing that is very iPhone-like about iPad is that when you first take it out of the box, it wants to be plugged into your Mac or PC via USB and sync with iTunes. … It creates an impression that the iPad does not stand on its own. It’s a child that still needs a parent. But it’s not a young child. It’s more like a teenager. It’s close. So close that it feels like it ought to be able to stand on its own.

My mother has an old G3 Ruby iMac which doesn’t have USB 2, so I had to set up the iPad on my machine before giving it to her. It’s such a shame that this step is even necessary. I love the idea of a portable touchscreen device that you can simply turn on for the first time, connect to a WiFi network, and start surfing the web.

Perhaps later versions of the iPad will support account synching via . Perhaps later versions of the iPad will support multiple accounts, which would make it a great family household device. Perhaps later versions of the iPad will have a front-facing camera and support FaceTime. Perhaps later versions of the iPad will be slimmer and lighter.

Perhaps I will get a later version of the iPad.

The iPad and the web

Before Apple launched the , I managed to refrain from adding to the deluge of speculation and rumour. Now that the much-anticipated tablet has been unveiled, I can’t resist jotting down my thoughts.

Now, this is just my reaction to a piece of technology. I feel a need to clarify that because discourse on the internet has a strange way of getting warped. Someone says I like Italian food, and someone else responds with Why do you hate Mexican food? Someone says I enjoyed watching Avatar, and someone else hears Everyone should enjoy watching Avatar. So bear in mind that this is just my personal reaction. I’m not saying that everyone should share my feelings. ‘Twould be a very dull world indeed in which we all felt the same.

I didn’t watch Steve Jobs unveiling the iPad—I was busy learning at a Skillswap event—but when I was reading up about it afterwards, I thought to myself I’m probably going to get an iPad…

Actually, at this point I need to take care of something:

Mum, if you’re reading this, could you stop now please? Thanks. Love you.

Anyway, as I was saying, I thought to myself I’m probably going to get an iPad …for my mother.

Honestly, there isn’t much on offer in the iPad that I don’t already have in my Macbook. I don’t think it is the device for me. But it is most definitely the device for my mother. I don’t mean “a theoretical persona such as one’s mother,” I mean my mother.

My mother is currently using a that used to belong to me. When she started using this machine, she had never used a keyboard, much less a computer. I am very, very glad that her first computer was a Mac and that she’s never had to deal with the world of pain that is Windows, but even a Mac has a learning curve for someone who’s never used a computer before.

I remember explaining what the cursor was and how the mouse controlled it. When I said “move it up”, she lifted up the mouse off the table. Thinking about it, the mouse isn’t as straightforward as we think: moving the mouse left and right does map to moving the cursor left and right, but moving the mouse forward and backward maps to moving the cursor up and down. Both the cursor and the mouse move on two-dimensional surfaces but only half the movements of the mouse correspond directly to movements of the cursor.

In computer years, a G3 iMac is ancient. It’s amazing that it still runs at all. I’ve been thinking for a while now about what would make a suitable replacement. A newer iMac would be good but they’re a little pricey for something that’s going to be used for web surfing, email, some digital photography and little else. A laptop would be nice. Now that my mother has WiFi, there’s no need for her to have to remain in one place to use her computer. But laptops are fiddly things with fiddly trackpads.

The iPad strikes me as the Goldilocks solution. It’s just right. If the European pricing follows the general Apple conversion rate, the iPad should be pretty darn affordable. It would be nice if it came with an iSight for iChatting; that might well get added in a later version. Web surfing, email and photo browsing are all not just possible, but likely to be pleasurable. That’s because the multitouch control mechanism is likely to feel far more intuitive than either a mouse or a trackpad. (Caveat: I haven’t used an iPad. Take my opinion, and the opinions of anyone else who hasn’t actually used one, with a heaped tablespoon of salt.)

So I’m probably going to get an iPad, but for someone else. If it came with nothing more than a WiFi connection and a web browser, it would still be a worthwhile device for my mother. In fact, the idea of using a computing device based around a browser is what’s driving the . Google’s vision is one wherein the file system and the hard drive are far less important than the web browser and the web server.

That’s why I’m slightly mystified about the App Store grumblings. Yes, it’s a closed system that Apple controls completely. But the same devices that support the App Store also come with a very advanced web browser. Personally, I think that if a device is capable of running HTML, CSS and JavaScript, I don’t think it can be described as “closed”.

Don’t like the closed nature of the App Store? Don’t use it. Use the web instead. That’s the point that PPK was making, albeit a bit stridently. Admittedly, if you want to make money directly from an app, you might have a harder time of it on the web than on the App Store. Make your app distribution bed and lie in it.

I’ve already seen people on Twitter sharing some ideas for the uses to which the iPad could be put:

  • displaying sheet music on a music stand,
  • showing recipes on a kitchen worktop,
  • playing scrabble, sudoku and crosswords,
  • reading comics,
  • reading magazines a la Mag+,
  • reading books in a way that doesn’t involve the silly page-turning visual metaphor built into the iBooks app.

All of those are great ideas and all of them can be implemented on the web. Remember that Mobile Safari already has excellent support for canvas, audio, video and offline storage. No App Store required. As Simon St. Laurent puts it, web developers can rule the iPad.

I understand the concerns of my fellow geeks who see the read-only nature of the iPad as restrictive compared to the read-write nature of laptop and desktop computers. Rafe Colburn asks Is the iPad the harbinger of doom for personal computing?:

I think that it’s a real possibility that in 10 years, general purpose computers will be seen as being strictly for developers and hobbyists.

Alex Payne foresees a tinkerer’s sunset:

The thing that bothers me most about the iPad is this: if I had an iPad rather than a real computer as a kid, I’d never be a programmer today.

While I understand and to a certain extent, share these forebodings, I’m cautiously optimistic that these fears won’t be realised. The iPad isn’t going to replace laptop or desktop computers; it’s a different kind of machine for a different kind of user.

Frasier Spiers welcomes the glimpse that the iPad offers us of information processing dissolving into behaviour when he writes:

If the iPad and its successor devices free these people to focus on what they do best, it will dramatically change people’s perceptions of computing from something to fear to something to engage enthusiastically with. I find it hard to believe that the loss of background processing isn’t a price worth paying to have a computer that isn’t frightening anymore.

Nik agrees:

Yes, it’s an entirely prescriptive way of computing - one that the hackers, tinkerers and geeks will find alien and protest about its lack of openness. But here’s the thing: for the people who the iPad is aimed at it really doesn’t matter that this experience is prescriptive.

I think he’s right. The iPad isn’t for geeks but I can foresee geeks, like me, buying iPads for members of their family …if for no other reason than to reverse the trend of the holiday season becoming the tech support season.

I’m not usually one for predictions, but I think I’ll try my hand at one now. The iPad will be the best-selling device to be purchased as a gift for Christmas 2010.

Accessimobility

When the original came out, it was pretty impressive. Every subsequent iteration has featured improvements of varying levels of impressiveness. The latest version, though, has bowled me over.

I’m not talking about faster speeds, bigger storage, or any new fangled gizmos or geegaws. I’m talking about VoiceOver in the iPhone.

Watch the video to get the low-down. Then read this first-hand account of using an accessible touch-screen device.

That’s quite a design challenge: an accessible touch-screen device! I doff my hat in the general direction of the Apple engineers who rose to this challenge.

Speaking of exciting developments in the world of accessibility…

The second Accessibility 2.0 conference will be taking place in London on the 22nd of this month. It was a cracking event last year and, judging by the line-up, this year is going to be a winner too. Grab a ticket now.