Mobile Zone is brought to you in partnership with:

Mobile and web 2.0 developer, consultant and speaker. Author of "Programming the Mobile Web" book, published by O'Reilly in 2010. Forum Nokia Champion. Maximiliano is a DZone MVB and is not an employee of DZone and has posted 35 posts at DZone. You can read more from them at their website. View Full User Profile

Safari on iOS 7 and HTML5: Problems, Changes and New APIs

09.24.2013
| 48736 views |
  • submit to reddit
Apple has rolled out iOS 7, and the new devices iPhone 5S and iPhone 5C. As expected, Apple has published just 10 percent of the necessary information for web developers, and I can say without fear of mistake that this is the buggiest Safari version since 1.0. In this post, I’ll show you the new APIs and abilities and most of the problems that you will need to deal with right now if you have a website or a web app.

In a Nutshell

Don’t have time to read the long post?

  • UI Changes: Toolbar tint, problems with new full-screen navigation, new home screen icon sizes; no <title> usage on iPhone; possible conflicts with new gestures
  • New Devices: Nothing new about them for web developers; same as iPhone 5
  • HTML5 Markup: Video tracks, <progress>, REMOVED support for input type=datetime
  • HTML5 APIs: Page Visibility, AirPlay API, canvas enhancements, REMOVED support for Shared Workers, Web Speech Synthesis API, unprefixed Web Audio and Animation Timing, Mutation Observer and other minor additions. BIG PROBLEM with WebSQL using more than 5Mb
  • CSS: Regions, sticky position, FlexBox, ClipPath, unprefixed Transitions and other enhancements
  • Home Screen Web Apps: SEVERAL SEVERE PROBLEMS (for example, no alert support!)
  • Native Web Apps: Web View Pagination, JavaScript runtime for native apps and video playing new abilities

The New Browser

Safari, as well as other native apps, has received the biggest update in the user interface and experience since version 1.0. These changes will affect how users interact with websites and how your web app will react.

Toolbar Tint

Safari will now tint the toolbars (the URL bar and the bottom toolbar) based on the background color when loading the page and the current main color behind the bars while scrolling.

If you want to “hack” the initial tint and have different backgrounds for the body and the tint without adding noise to the HTML (such as new containers), just use the following CSS hack:

body {
background-color: blue; /* for the tint */
background-image: linear-gradient(to bottom, green 0%, green 100%); /* for the body */
}

In this hack we define both background color and image; the content will use the image, in this case a gradient (it can also be a data URI 1px image). In the next examples, you can see the first two samples with the same color (just a background) and the last examples with one tint color and other background color for the body.

tint

Full Screen and Big Problems for HTML5 Apps and Games

Web browsing is now always in full screen on iPhone and iPod touch. When the user scrolls the page in portrait orientation, the bottom toolbar will disappear and the URL bar is transformed to a small semi-transparent bar at the top. On landscape, after the user scrolls the page, the bottom toolbar and the Host domain bar will both disappear, leaving it in complete full screen mode.

The toolbar and full URL bar will appear again when the user taps on the domain host at the top, or the user starts to scroll back to the top.

The next picture shows how the UI changes before and after scrolling in landscape and portrait mode:

fullscreen2

The problems are:

  • The resize event is not firing anymore when the toolbar is appearing/disappearing.
  • We can’t detect changes with JavaScript or media queries.
  • The old hack of using window.scrollTo to hide the URL bar doesn’t work anymore; therefore, there is no way to hide the URL bar or toolbar without user intervention scrolling the page.
  • If you are not using a natural scroll, you will have problems (detailed below).
  • UPDATE 19/9: The bottom part of the canvas is not interactive anymore (details later).

If you are using a “non natural” scrolling layout, such as iframes, sections with overflow:scroll or a JavaScript-based scrolling mechanism, toolbars will never hide. And even more problematic, if somehow the user gets into full screen mode, he will not be able to go back again to normal mode. As an example, see the Twitter website (using overflow: scroll) on landscape mode where your scrolling area is less than 50 percent of the screen and toolbars never go away.

twitter

To be honest, if you go portrait and then landscape again, sometimes you will get full screen without scrolling, but you can’t get out of it. You need to test it to get the idea of the problem.

Scrolling back to restore toolbars makes things complicated for HTML5 games also. Because this post has started in the Apple Forum while in Beta 1, a lot of people were complaining about this problem, such as:

  • Richard Davey: “This is actually a real issue for us. It has broken the display of all of our games on the BBC site (try anything on http://www.bbc.co.uk/cbeebies/ for example). With the removal of the full-screen button and the removal of this ‘hack’ we’ve no way to make our games go full screen. So they are crammed into a tiny window in the middle of the browser on iPhones. (…) When you enter a page in landscape mode, only 2/3rd’s of the screen area is available. Controls cover a full 1/3rd of the screen."
  • TheFlashGuy: “We need more control over the appearance / disappearance of the browser bars when in landscape mode. It’s far too easy for a user to break out of this mode just by touching the top or bottom of the screen. This breaks a lot of websites and web apps whose major ui nav elements tend to sit in the top or bottom of the content area.”

There is no way to have a truly fullscreen experience on your website. This was one of the wonderful aspects of iOS 6, and losing it is a major step backwards.

- Richard Davey.

Bottom Toolbars and Interactive Elements

When in full screen mode, the bottom portion of the page is not interactive anymore. This problem affects any toolbar, link or form item that is in the bottom part of the viewport while in full screen mode (after scroll). For example, fixed toolbars at the bottom are one example.

When you click on that portion of the viewport, it doesn’t matter where you click. It will just fire the full screen dismiss action. Therefore, Safari toolbars will appear and you will need to tap again on the interactive item to activate it. For example, two taps will be necessary to activate a button. To test it, go here, scroll and try to click on the bottom toolbar.

For example, if you try to click "Albums" in the next image, it will just open the Safari toolbar and you need to click "Albums" again to go there.

bottom-toolbar

Title

The next big change in Safari’s UI on iPhone is the title area. The page’s title on iPhone was replaced by the current host (the domain), as you can see in next image. The page’s title is only available when browsing tabs on iPhone.

On iPhone with iOS 7 your page’s <title> will be ignored while the user is browsing the document.

On iPad, there is no full screen mode; the toolbar and title bar are always visible.

New Add to Home Button

iOS 7 has changed the Share icon and it has a new Add to Home Screen button.
The whole UI has changed, including new icons replacing the Share icon with a new style, so every website that is inviting the user to add it to bookmarks or to the Home Screen needs to update the icon.

Gestures

The operating system and Safari itself now offer new gestures that might impact your website, mostly if you are detecting gestures yourself.

A.) Control Center: It appears when you swipe up from the bottom of the screen. In this version, because of the full screen, the bottom of the screen might be part of your website, and not the Safari toolbar. Therefore, be careful when suggesting the user do a swipe up from the bottom of the canvas.

B.) History Gesture: The second and probably more problematic gesture is the swipe right and left from the borders. They will cause Safari to trigger the back and forward action in the browsing history à la Internet Explorer in Windows 8 mode. This gesture might have some conflicts with your website if you are inviting users to swipe left or right without some nice margins around (to be honest, you have the same problem right now with Chrome, too).

The problem is even weirder on single page web apps (inside Safari) when using the History API or using a hash hack to manage app states. When the user starts a back gesture, he will see two images of the same app, but the user will be on the same app. And when you have side-by-side scroll gestures, such as the Yahoo! homepage, you might have usability issues if the user starts the gesture from the border (it even trigger touch events for just a while):

The swipe right and left gesture from the borders will trigger a back or forward action in browser's history.

This gesture and the back animation (slide to the right) are also conflicting with some UI frameworks, such as jQuery Mobile or Sencha Touch. When the user gestures to go back, two animations will be rendered (by the browser and after that by the framework). Also, when the previous page was left at one specific scroll position, the snapshot during the slide animation is OK, but then the page loads from the top, not keeping the scroll position.

There is no way to prevent these gestures, as they are managed by the OS or the browser itself.

Hopefully, the History gestures are not available on home screen web apps or UIWebViews (such as PhoneGap apps).

Icon Sizes

The new OS icons are 5 percent bigger in 7.0 than in previous version, for example 120 by 120 on Retina iPhone devices instead of the previous 114 by 114. System icons are also flat now, and they don’t have the shiny effect anymore, so we might want to update our icons to match the new design. To do that, we can use the same apple-touch-icon link with the new size values.

The apple-touch-icon precomposed version is still supported, but it will produce the same results as the apple-touch-icon, as now there are no shiny effects on icons. If we define both, the precomposed version will take precedence.

Available icon sizes for iOS 7 are:

  • iPhone or iPod Touch retina: 120×120
  • iPad non-retina (iPad 2 and iPad mini): 76×76
  • iPad retina: 152×152 
We need to remember that iOS 7 is not available for any non-retina iPhone-factor device. If we don’t provide the new sizes, the device will pick the iOS 6-related one. If you want to cover all the possible icons for iOS, the code will look like:

<!-- non-retina iPhone pre iOS 7 -->
<link rel="apple-touch-icon" href="icon57.png" sizes="57x57">
<!-- non-retina iPad pre iOS 7 -->
<link rel="apple-touch-icon" href="icon72.png" sizes="72x72">
<!-- non-retina iPad iOS 7 -->
<link rel="apple-touch-icon" href="icon76.png" sizes="76x76">
<!-- retina iPhone pre iOS 7 -->
<link rel="apple-touch-icon" href="icon114.png" sizes="114x114">
<!-- retina iPhone iOS 7 -->
<link rel="apple-touch-icon" href="icon120.png" sizes="120x120">
<!-- retina iPad pre iOS 7 -->
<link rel="apple-touch-icon" href="icon144.png" sizes="144x144">
<!-- retina iPad iOS 7 -->
<link rel="apple-touch-icon" href="icon152.png" sizes="152x152">

Bookmarks and Favorites

While on bookmarks there are new icons available (see left image below), it seems there is no way yet to define those icons specifically, as well as the text.

For the favorites (see right image below) that appear when you click on the URL bar, it seems to use the apple-touch-icon link, but it doesn’t follow any sizes rule, and I’ve found weird situations, such as some websites with a proper link element that won't take the icon for favorites.

favorites2

Published at DZone with permission of Maximiliano Firtman, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)