Tags: safari

8

sparkline

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.

Delay

Mobile browser vendors have faced a dilemma for quite a while. They’ve got this double-tap gesture that allows users to zoom in on part of a page (particularly handy on non-responsive sites). But that means that every time a user makes a single tap, the browser has to wait for just a moment to see if it’s followed by another tap. “Just a moment” in this case works out to be somewhere between 300 and 350 milliseconds. So every time a user is trying to click a link or press a button on a web page, there’s a slight but noticeable delay.

For a while, mobile browsers tried to “solve” the problem by removing the delay if the viewport size had been set to non-scalable using a meta viewport declaration of user-scalable="no". In other words, the browser was rewarding bad behaviour: sites that deliberately broke accessibility by removing the ability to zoom were the ones that felt snappier than their accessible counterparts.

Fortunately Android changed their default behaviour. They decided to remove the tap delay for any site that had a meta viewport declaration of width=device-width (which is pretty much every responsive website). That still left Apple.

I discussed this a couple of years ago with Ted (my go-to guy on the inside of the infinite loop):

He’d prefer a per-element solution rather than a per-document meta element. An attribute? Or maybe a CSS declaration similar to pointer events?

I thought for a minute, and then I spitballed this idea: what if the 300 millisecond delay only applied to non-focusable elements?

After all, the tap delay is only noticeable when you’re trying to tap on a focusable element: links, buttons, form fields. Double tapping tends to happen on text content: divs, paragraphs, sections.

Well, the Webkit team have announced their solution. As well as following Android’s lead and removing the delay for responsive sites, they’ve also provided a way for authors to declare which elements should have the delay removed using the CSS property touch-action:

Putting touch-action: manipulation; on a clickable element makes WebKit consider touches that begin on the element only for the purposes of panning and pinching to zoom. This means WebKit does not consider double-tap gestures on the element, so single taps are dispatched immediately.

So to get the behaviour I was hoping for—no delay on focusable elements—I can add this line to my CSS:

a, button, input, select, textarea, label, summary {
  touch-action: manipulation;
}

That ought to do it. I suppose I could also throw [tabindex]:not([tabindex="-1"]) into that list of selectors.

It probably goes without saying, but you shouldn’t do:

* { touch-action: manipulation; }

or:

body { touch-action: manipulation; }

That default behaviour of touch-action: auto is still what you want on most elements.

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.

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.

Safari askew

I rolled out a new addition to the Huffduffer home page earlier this week. If you aren’t logged in, everything looks the same as before: under the heading Create a podcast of found sounds, there’s a short list giving the low-down on what you can do:

  1. Find links to audio files on the Web.
  2. Huffduff the links—add them to your podcast.
  3. Subscribe to podcasts of other found sounds.

But if you are logged in, then a different list appears, this one showing the activity since you last logged in:

  1. How much has been huffduffed.
  2. How much huffduffing your collective has done.
  3. How many people have joined.

Programming this was pretty straightforward. Every time a new session is started—either because you log in or because you return to the site with a “remember me” cookie—a timestamp is recorded. I just need to select the activity since the previous timestamp. Easy peasy.

Except it wasn’t working for me.

I went through all the usual debugging procedures, poring over my code, but I couldn’t find anything wrong. Finally, after plenty of observation, I spotted the pattern that was causing the problem. Bizarrely, every time I opened my browser, a new timestamp was being recorded for my Huffduffer account.

Here’s the problem:

  1. I visit Huffduffer a lot.
  2. I use Safari as my web browser.

One of the new features in Safari 4 is the “Top Sites” view:

Thanks to Top Sites, you can enjoy a stunning, at-a-glance preview of your favorite websites without lifting a finger. Safari 4 tracks the sites you browse and ranks your favorites, presenting up to 24 thumbnails on a single page.

It does indeed look very pretty (if not quite stunning). But here’s the kicker:

Wonder which sites have changed since your last visit? Sites with a star in the upper-right corner have new content.

How does Safari know which sites have changed? It effectively “visits” the site, screwing up your stats in the process. If you have a cookie stored for that site, Safari will use it. This has led to some skewing of Stack Overflow’s ranking system. It’s also the root of my problem with Huffduffer.

As far as I can tell, I just have to suck it up. Safari reports the same user-agent string regardless of whether it’s fetching a URL for the Top Sites list or fetching a URL to render for an end user.

Oh, well. At least this is a problem that will only affect people who visit Huffduffer a lot (and use Safari as their browser). The new homepage feature will work just fine for everyone else.

Hmmm… that new version of Camino looks mighty tempting.

Update: Martin Sutherland writes to tell me the results of his research into this:

The user-agent that Safari reports when it performs a Top Sites call to your server is exactly the same as for a normal call, but a Top Sites request does transmit an additional HTTP header as part of the request: “X-Purpose: preview”.

Excellent! I should be able to sniff for that header and, if I find it, not log the timestamp.

Audio ga-ga

Huffduffer is written in HTML5. For the most part, this is no different to writing in any other flavour of HTML, just with a simpler DOCTYPE.

For the time being, I’m not using any of the new structural elements like section, article or footer. I am, however, making use of the audio element. Browsers that don’t understand this element—that would be most of them—aren’t left with nothing. Between the opening and closing audio tags, I’ve included an old-fashioned Flash movie for streaming the audio. This is exactly what is envisioned in the spec:

Content may be provided inside the audio element. User agents should not show this content to the user; it is intended for older Web browsers which do not support audio, so that legacy audio plugins can be tried.

Right now, Safari is about the only browser that includes support for audio. Alas, the way it implements that support is flawed. Safari pre-loads the file referenced in the src attribute. That works fine as long as there’s only one or two audio elements on a page but as soon as you get above that—as you do on Huffduffer—then everything starts to drag and your internet connection takes a hammering as the browser tries to suck down every file.

There appears to be no way of stopping this through the DOM. There’s a whole slew of properties that can be specified in the markup or manipulated with JavaScript:

  • autoplay
  • start
  • loopstart
  • loopend
  • end
  • playcount
  • controls

…but none of them can be used to instruct the browser not to pre-load audio (as far as I can tell). After trying to read the spec I’m still not sure if Safari is implementing the “correct” behaviour. It might well be. But in this case, the correct behaviour is certainly not the desired behaviour. I downloaded the nightly build of Webkit and the behaviour hasn’t changed there.

Support for the audio element is on its way in Firefox 3.1, albeit in a crippled Ogg-only way. I sincerely hope it doesn’t follow Safari’s precedent with pre-loading.