October 13, 2011 19

iOS5 for Web Developers


Now that iOS5 is out, here’s a follow up to my previous post A Web Developer’s Wishlist for iOS 5. If you want to know what has (and hasn’t) been added/changed to Mobile Safari in Apples latest OS update, read on past the break.

Things added/fixed in iOS5

  1. CSS Improvements

    In particular I was hoping for support for fixed positioning and scrollable sub sections. Apple has added both these features into iOS5. Using position: fixed now works as you might expect and its also possible to get one finger native/momentum scrolling sub sections using:

    overflow: scroll;
    -webkit-overflow-scrolling: touch;

    Here’s a video demonstrating the new feature

    It appears there may be a few bugs with the implementation still, most obviously whether a swipe should move the scrollable section or the main window. If you want to achieve overflow: scroll behaviour in a full screen web app, I recommend against using the native implementation and instead using a solution such as iScroll or Scrollability until Apple provides a solution for these problems.

  2. Better support for ‘window.print()’

    When AirPrint was introduced in iOS, window.print() worked when used inside Mobile Safari but not in a fullscreen webapp launching from the homescreen.

    This has changed in iOS5, and now full screen web apps run from the homescreen can also make successful calls to window.print().

Other changes I’ve noticed

Datetime HTML5 input element

The date, month, time, datetime & datetime-local input types now have custom UI inputs. The range type has also been implemented, rendering as a slider (doesn’t have a custom keyboard UI).

Date Month Time Datetime

Web Workers

Web Workers provide a mechanism for JavaScript code to be run on a separate thread. This is useful for expensive tasks that might take a long time and means that the UI won’t block whilst waiting for these tasks to complete.

For more information see MDN – Using web workers and HTML5 Rocks – The Basics of Web Workers.

Other features found via caniuse.com

Here’s a few other noteworthy changes thats to a comparison search on caniuse.com

  1. contenteditable attribute
  2. WOFF font support
  3. Inline SVG
  4. MathML
  5. XMLHttpRequest2 (but no file upload?)
  6. defer and async attribute for external scripts

Things not added/fixed in iOS5

  1. WebGL

    Close, but no cigar. Modernizr reports support but the 3d context isn’t publicly available. Here’s the official explanation:

    WebGL will not be publicly available in iOS 5. It will only be available to iAd developers (source)

  2. Viewport Improvements

    Current meta tag support is useful but it does pose some problems, especially if you wish to treat different devices differently. Suppose you’re using media queries to render your site differently for iPhone & iPad, you may wish to prevent scaling on iPhone but not on iPad. This (as far as I have found) isn’t possible without conditionally adding the metatags server side.

    If these viewport controls were controlled via CSS then we could use the same media queries to deliver different settings to different devices!

    It doesn’t look like anything has changed here.

    Update: Thanks to David Storey for pointing out that there is a W3C draft spec for this: CSS Device Adaptation.

  3. Better support for adding bookmarklets

    Again, doesn’t look like anything has changed.

  4. requestAnimationFrame()

    Request Animation Frame

    Not this time.

  5. Remote Debug API

    It doesn’t appear that this has made its way into iOS5 but in the meantime you can use the fantastic Weinre (now part of the PhoneGap project) to remotely debug your web apps on mobile devices.

If I’ve missed anything be sure to let me know in the comments!

  • Anonymous

    Awesome roundup joe, thanx :D  can’t wait till they jailbreak it so I can install hehe

  • http://twitter.com/dstorey David Storey

    Hi Joe,

    Regarding 2. Viewport Improvements

    There is a spec fording this in CSS, developed and implemented by Opera. It will be great once WebKit gets support for this. http://dev.w3.org/csswg/css-device-adapt/

  • http://www.joelambert.co.uk Joe Lambert

    Thanks David, that is exactly what I was hoping for but didn’t know there was a spec in the works.

    It looks like this is pretty early days for this, at what stage would a vendor start to implement functionality from a draft spec?

  • Pingback: iOS 5 Crib Sheet « JK Speaks

  • Pingback: Taking the Compass out for a drive | FunctionSource Development

  • http://www.facebook.com/PuckPuck Pierre Tessier

    You can add a viewport meta tag, dynamically using Javascript.  I have done this for other projects and it works great.  Still would rather see this be done in pure CSS, but that doesn’t stop someone from dynamically inserting the viewport based on the device type.

  • http://www.joelambert.co.uk Joe Lambert

    Ah, hadn’t thought of that. I suspect this leads to a level of browser sniffing? I see how it could be done by interrogating the screen size etc but I wonder if its just “easier” to sniff?

    I also wonder how this impacts the loading of assets? Seems like a good work around but I’m looking forward to the spec @twitter-72623:disqus mentioned below :)

  • Alex Grande

    Yes, thanks a lot for this round up. What bugs are you seeing for overflow scroll? I notice sometimes the whole view is grabbed and not the scrollable content, but this seems like a very minor issue compared to being forced to override default touch behavior. Go to soundcloud.com on your iPhone. The fixed header with native scrolling is fantastic. Now go to plus.google.com on your iPhone. The scrolling is obviously javascript-driven and slightly buggy. More so than native scrolling.

    Anyway, the date inputs are rocking!

  • http://twitter.com/dstorey David Storey

    It really depends on the vendor interest. Some things get implemented very early in the draft cycle (even before announcement if it is proposed by one vendor who really want the feature). Opera implemented this very soon after proposing it to the CSS WG. Sometimes vendors play it safe and wait for everything to settle down.

    I’m not sure of any plans yet to implement it in browsers other than Opera, but it has been discussed in the CSS WG so other vendors are not against it at least. It will be implemented prefixed (which is a pain for -at-rules as you need to define the same block multiple times. Once it reaches Candidate Rec then vendors can implement without the prefix.

    I couldn’t find a bug in the WebKit bug tracker so I created one https://bugs.webkit.org/show_bug.cgi?id=70370

  • http://www.joelambert.co.uk Joe Lambert

    Thanks for adding the ticket, will keep an eye on it!

    I agree that vendor prefixes are a pain for -at-rules but they’re definitely better than not having the feature at all!

  • Anonymous

    Nice post, although I was not able to get window.print() working in a full screen web app. The dialog pops up, but no document is printed. Any thoughts?

  • http://www.joelambert.co.uk Joe Lambert

    Can you print from other apps? The issue in previous iOS versions was that the dialog would not show at all when window.print() was called when running as a full screen web app.

    I was able to print from the dialog when I tested this, so unless this is a new bug in 5.0.1 I think its most likely a more general issue between your device and the printer?

    Sorry, probably not as helpful as you’d have liked

  • http://www.joelambert.co.uk Joe Lambert

    I agree that the new browser scrolling is infinitely better than JavaScript scrolling (potentially). 

    The problem is as you outline, that when you’re at the limit of the scrollable section the viewport is scrolled rather than just the scrollable section. This might not be an issue when viewed in a browser but when creating web apps for deployment on the homescreen (or in the app store via PhoneGap) this gives a significantly reduced UX when compared to native apps.

    I think the usecase for -webkit-overflow-scrolling: touch; really is all about web apps, so the default behaviour should be to not scroll the viewport.

  • Anonymous

    I can print from other native apps and mobile safari fine. Even my web app in mobile safari (not full screen) can print. iPad1 with ios 5 (have to check if it’s 5.0.1)

  • http://www.joelambert.co.uk Joe Lambert

    I’ve just double checked with my original test code and I’m now getting what you’re experiencing. The dialog pops up fine allowing me to select a printer but as soon as I press the ‘Print’ button the dialog disappears without the usual printing splash screen.

    I’ll try find out if this is a known bug

  • http://www.joelambert.co.uk Joe Lambert

    I’ve filed a bug with Apple, hopefully this will get fixed in the next point update

  • Anonymous

    I also tested it on iPhone, same thing. The dialog shows up, but no splash screen and print. Non full screen app prints on iPhone 4s 5.0

  • Eion

    Looks to be fixed in 5.1

  • http://www.rackmountsales.com/ Rack Mount Monitor

    iOS5 is awesome some the tweaks that this operating system has is minor but very helpful to make peoples life much easier and that’s what Apple are good at making stuff easier for users. I find a lot of developers never knew it existed even in older versions of iOS.