Breaking the Mobile WebTechniques and best practices for web experiences on mobile devices2016-03-22T23:11:09Zhttp://www.mobilexweb.com/feed/atomWordPresshttp://www.mobilexweb.com/wp-content/uploads/2015/09/cropped-mobileweb-icon-32x32.pngfirthttp://www.firt.mobihttp://www.mobilexweb.com/?p=3872016-03-22T23:08:22Z2016-03-22T23:07:50ZTweet

Usually minor updates on iOS don’t bring news to Safari and web developers. That’s not the case on iOS 9.3: new APIs, support for Responsive Images, a new weird viewport attribute and new devices in the market make us check what’s new.

Overview

Changes with iOS 9.3 for web developers and designers:

iPhone SE is equal to iPhone 5(s)

iPad Pro 9.7″ is equal to iPad Mini / Air but with 3D Touch support when Apple Pencil is used. Images with ICC profile are now supported

New devices

The new 4” iPhone SE (Something edition?) device is the same as iPhone 5(s) in terms of web design and development. That means a viewport of 320 CSS pixels when a mobile viewport meta tag is used (compared to 360 CSS pixels of iPhone 6 and 414 CSS pixels of 6+), and a device pixel ratio of 2. No 3D Touch is supported.

In terms of iPads, the new 9.7” iPad Pro (yes, that’s the official name) exposes same viewport as iPad Air and iPad Mini compared with the original 12.9” iPad Pro. Touch Events v2 API is supported when used with Apple Pencil (that is, the force value is available on each Touch object).

Aos, the 9.7” iPad Prohas a new display supporting Wide Color and True Tone so we have a better range of colors available. Well now Safari now supports Images with ICC Profiles inside (confirmed on Twitter) so if you work in professional imaging you may be happy about this. A CSS Media Query to detect displays that support more colors is on the way for a future version (it’ll be great for the new picture element)

Responsive Images with <picture>

The HTML 5.1 <picture> element has finally arrived to Safari (both iOS and Mac), so we can now finally embrace Responsive Images with native support. The picture element allows us to define multiple image sources based on a media query and/or a format type using different <source> child elements (à la <video> element). We can use alternatives for art direction or to support different formats.

Therefore, we can define different images candidates based on different rules, such as the viewport’s size, with a fallback <img> tag.

Also, it can be mixed with srcset to provide different resolution versions and with type we can use several image types if we want to offer different versions. This feature can be used to support new formats (such as WebP, JPEG-2000, JPEG-XR, SVG or future formats) without JavaScript frameworks or server-side detection. For example, we can serve WebP versions for Chrome/Firefox users and PNG versions for iOS and other devices.

Fast Tap: 300ms delay removed

At this point we all know that on iOS we have a ~300ms delay on every click event (including when you tap on a link) before actually firing it to wait for a second tap.

Starting with iOS 9.3, Safari won’t have this delay on any content if one of two rules are met: 1) a mobile viewport, either with width=device-width or user-scalable=no or 2) using the touch-action: manipulation CSS attribute (coming from the Pointer Events spec that Apple actually don’t support) on elements and containers.

Great news for web performance!

CSS Variables

CSS Variables finally arrived to iOS following other browsers. You might want to use it only when it’s supported so you can use backward values, @support or JavaScript’s CSS.supports to detect them.

CSS Will-Change

Safari now supports the CSS Will Change spec that is great for optimizing performance. The will-change property lets us specify that one particular element will have some chances (for example we will animate it later, or we will change its content) so the browser can apply some performance improvements on it, such as using a hardware GPU layer on it or not.

Gesture events on Mac

Since Safari on iOS 2.0 we have non-standard gesture events to detect pinch and rotate gestures on iOS devices usually through gesturechange. These events are also available on Safari on the Mac when the user has a trackpad with gesture support, such as a MacBook or a Magic Mouse/Trackpad.

New Dialogs

JavaScript dialogs on Safari were using native iOS dialogs until today. Since 9.3, these dialogs (alert, confirm and prompt) changed the design. The new design looks different (see next image) and they don’t have the domain of the current website as a title.

Old JS Dialogs (top) and new JS Dialogs (bottom)

The main purpose of the change is usability. The new dialogs are modal within the tab but not within Safari. Therefore, you can change tabs, close the tab, get the URL bar or the toolbar (including back button) while a dialog is open. Before iOS 9.3 you had to close the dialog first. And now a background tab can’t request focus sending a modal popup.

These new dialogs are not available on Home Screen webapps or Web Views.

The new viewport shrink-to-fit attribute (that nobody understands)

Apple has added a new shrink-to-fit attribute to the viewport meta tag that I’m sure most people don’t understand. Let’s see what it means.

On iPad with iOS 9 we know we can have Safari running in Side view or Split view mode adding 9 more viewport’s widths to the default 2 on iPad (portrait and landscape). The new widths have to do with running Safari in 1/2 , 2/3 and 1/3 mode (both in viewport and landscape, for 7.9” and 9.7” iPads in one group and 12.9” iPad Pro in other group).

From iOS 9.0 Safari is exposing the actual viewport width instead of the typical 769px to the website so you can use responsive techniques to actually re-layout the content.

However, some websites (mostly doing user agent detection) thinks that if it’s an iPad (a tablet), then the width is at least 768px so the design have issues on smaller values that we get on Split/Side mode on iPad. Therefore, Apple since 9.0 implemented a solution: if your content has overflowed content on these smaller size modes, Safari makes a bigger viewport (up to 768px) and shrinks the content so it fits on the screen.

However, this idea also created lot of bugs on other websites with overflow content that instead of having a horizontal scrollbar as expected, they are being shrunk.

For example let’s say we have a width=device-width viewport meta tag, therefore the available viewport’s width should be equal to 320, 360, 438, 507, 639, 678, 694 or 981 as you can see in next image at the right (based on the iPad and situation – check my previous post for info).

Now, let’s say we have content with a fixed width of 600px and the user is not using a full-width Safari on the iPad. On these situations, Safari will expose a viewport of 600px (actual content) and the content will shrink to fit to the real viewport as in next image, so your text will be smaller than the standard size.

If you prefer to keep your viewport as expected and have horizontal scrollbars for the overflowed content, you can add a new attribute to the meta tag: shrink-to-fit=no and get that result as you can see in next image (bottom).

<meta name="viewport"content="width=device-width,shrink-to-fit=no">

Remember: this behavior happens only when the user is using your website with Safari in Split or Side View modes.

Remote Inspector

The Remote Inspector has new features, including:

Watch Expressions while debugging JavaScript

New Visual Styles sidebar editor (see image below)

HTML pseudo-elements are now visible in the DOM

Minor improvements

High Quality Rendering Canvas can be requested through a new imageSmoothingQuality property accepting “high” as a value

CSS border-image-repeat now accepts round and space

The “all”, “revert” and “unset” attributes are now accepted to clear cascading attributes

Advanced typographical settings for OpenType now available (such as font-variant-numeric). Check CSS Fonts v3 for more info: https://www.w3.org/TR/css-fonts-3/#font-variant-prop

I can’t believe it’s been a year since my last post in this blog; in the meantime, I’ve written articles at different magazines, while working on a new book and delivering several trainings around the world, including my next live training with O’Reilly Media.

But it’s time again to come back here and explain what I’ve found with iOS 9, the new devices (6S series and iPad Pro) and also the new OSs from Apple (watch OS 2 and tvOS 9 –yes, it’s version 9-) from a web developer’s point of view.

In a nutshell

If you don’t want to read the full article, here you have a summary:

New Devices

iPhone 6S and 6S plus have “3D touch”, a new hardware feature to detect pressure; a new API lets you work with the force.

iPad Pro changes iPads viewport to 1024px

No API seems to be there to support the new Apple Pen for iPad Pro on websites

New OS features for websites

Safari on iPad now can work in split mode with other apps at the same time, meaning that new viewports will become common

We still need to wait for Push Notification, camera access, Service Workers and other modern web-based APIs.

New OSs

tvOS for the new Apple TV: no browser, no web view available. JavaScript, XHR and DOM is available with TVML as the markup

watchOS for Apple Watch doesn’t have any browser or web view available.

New iOS Devices

iPhones 6S and 3D Touch

The new iPhone 6S and 6S are pretty much the same as the previous versions from a web design and development point of view. However, there is one feature that should take our attention: 3D Touch.

I’m not sure if Apple has just renamed “Force Touch” (available on Apple Watch and the latest MacBook) or if it’s just something similar but different for iPhone only. 3D Touch allows the OS and apps to detect pressure on the screen for each finger touching it. From a UX point of view the most important action is now a touch or drag with more pressure that will activate different mechanisms in the OS, such as peek and pop. The next question is: do we have access to these new ideas for websites? The answer is unclear today.

Safari for iOS 9 includes a new API for “Force Touch” but I’m not sure yet if this is the API to use the iPhone 6S 3D Touch or if it’s just the same API that is available on Safari for the MacBook with Force Touch that is inside iOS for no reason.

On the Force Touch API we have two additions

The click event handler will receive new properties inside the MouseEvent argument: webkitForce.

four new events are available on the DOM: (webkit)mouseforcewillbegin, mouseforcedown, mouseforceup and mouseforcechange. The next diagram gives you an idea on when these events are triggered.

Now, as you might realize from the name, these event are mouse-based and not touch-based. These events are officially there for the MacBook (therefore, clicks). Also, TouchEvent is not including the webkitForce value; it’s only on MouseEvent. Will it work on iPhone 6S and 6S+ with one finger? What will happen with more fingers? We’ll need to wait a few days for the final release for these devices. I’ll update this post at that point (follow me to get updates).

iPad Pro

The new iPad Pro (12.9”) has changed how iPads render websites. Until today, every iPad in the world (from the original iPad, to the iPad Air 4, to the iPad Mini) exposes a viewport with a width of 768px.

The iPad Pro with its bigger screen is different: it’s exposing 1024px for the viewport, so it can fit more content by default. Several sources have said (I thought it also) that the iPad Pro is a copy of the Microsoft Surface Pro. Well, IE/Edge on the Surface Pro also exposes 1024px as the viewport’s width J.

In terms of interaction, the iPad Pro doesn’t have 3D touch but it can be used with a Smart Keyboard and/or Apple Pen (with pressure detection). For the keyboard, there is nothing especial to talk about; if your website works well on desktop with keyboards, it should work the same on iPad Pro. For the Apple Pen, there is no API available to get pen’s pressure and angle from a website.

New iOS features for web sites

(Real?) Multitasking on iPad

On iOS 9, iPads allow two side-by-side apps to run at the same time simultaneously with three different techniques: Slide Over, Split View and Picture-in-Picture. Not every technique will be available to every iPad, based on hardware requirements. For example, for Slide Over you need iPad Air, iPad Mini 2 or newer.

Slide Over

Slide Over is supported by Safari, meaning that our website can be rendered in this mode. When our website is on Slide Over it’s being rendered in the right quarter of the screen on top of other native app.

This mode makes a new point for Responsive Web Design: a website that is optimized for iPad only can be rendered for a smaller screen on the same device without refreshing. Therefore, if you are doing server-side detection, the iPad version should somehow include the phone version or reload it after that.

In this mode, your website is being rendered as if it is a very large iPhone 5 offering a 320px-width viewport on all iPads (including the Pro) and all orientations. You can detect this mode in CSS through the media query:

Split View

On newer iPads, you can upgrade Side View to Split View where two apps share the screen working simultaneously.

On this mode, our website can be rendered…

as 1/3 of the screen, exposing a viewport’s width of an iPhone 5 on iPad Air/mini: 320px and a viewport similar to iPhone 6 for iPad Pro: 375px

as 1/2 of the screen, exposing a viewport’s width of 507px on iPad Air/mini and 678px on iPad Pro (landscape)

as 2/3 of the screen, exposing a viewport’s width of 694px on iPad Air/mini and 981px on iPad Pro (landscape)

Picture in Picture

On some newer iPads, a website with an HTML5 video tag can expose it to the new Picture in Picture mechanism. Through an API –later in this article- or automatically managed by the user, the video can continue playing even on top of other apps without your website being focused.

Responsive Web Design on iOS 9

The next diagram explains all the viewports available on iOS 9. Check your Responsive Web Design breakpoints to see if you are covering all of them

Safari View Controller

If you are a Twitter or Facebook user you’ve already seen how some native apps on iOS don’t open links in Safari by default. They try to keep you inside their app offering you an in-app browsing experience using the web view. The problem is that this web view doesn’t share cookies, sessions, autofill and bookmarks with the browser, so Safari View Controller comes to solve the problem.

Now, native apps can open websites in Safari View Controller that will offer the same Safari privacy, local storage, cookies and sessions while keeping the user under that app with “Done” button that will go back to the previous controller in the native app. This new controller also let us add custom actions in the Share button while the user is checking the web content that won’t be available inside Safari. The native app is also in control of blocking some content that we don’t want to be rendered inside that custom Safari’s instance.

Safari Web Controller is also a good idea when we need a web-based authentication, such as OAuth, instead of opening the browser that will redirect back to your app. Be careful, Safari Web Controller is only suitable for online, public web content. If you are serving web content that is private or local in your app, WKWebView is still the recommended way.

Safari Content Blockers

Safari on iOS 9 now supports a new kind of App Extensions: Content Blockers. These extensions that are being served with a native app from the AppStore can block any content inside safari, including: trackers, advertisement, custom fonts, big images, JavaScript files and more.

While we can’t disable content blockers as web developers, we should be aware of them. Some blockers such as Crystal are advertising that they can improve your navigation performance by installing it. Crystal claims to load websites 3.9x faster using 53% less bandwidth. The question is: what is the blocker blocking? This article covers some of the problems we might find in the future.

After iOS 9 launch, Peace -a content blocker- was ranked in the top 10 at App Store.
From a users’ perspective, if a website is not working properly because the active Content Blocker has block some important resource, you can now long press the reload button and reload the website without it (see next image from MacWorld.com

Content Blockers have the power of hiding an element and block loading a file using filters by CSS selector, domain, type or URL filter. For example, Purify Blocker offers the user advanced settings to block certain kind of contents, such as Web Fonts.

WKWebView enhancements

UIWebView is officially deprecated. While it’s still there, it’s not getting any of the new stuff and WKWebView on the other hand is taking its place. One of the most awaited features is now here: loading local files into WKWebView. Therefore, now Apache Cordova apps and other web content can use local files inside the iOS bundle without weird hacks.

Some other additions are now there too, such as the ability to query and manage the local storage of the web view (such as local storage or IndexedDB) from Swift or Objective-C through WKWebsiteDataStore. It allow us to also override the original data store and replacing it with something new, such as non-persistent one (Chrome for iOS was expecting this for their Incognito Mode).

Universal Links

If you own a website and a native app, now you can enhance user’s experience through Universal Links. It allows you to “own” your own domain inside the OS so any links to your website will be redirected to your own app.

Today, the way apps are doing this is through custom URIs, such as comgooglemaps:// for opening Google Maps from websites or other native iOS apps.

To offer this feature, you first need to have deep linking inside your native app, so every URL in Safari matches content inside your app. Then, you need to associate your domain at Apple’s website, acquire a SSL certificate for that domain and host a signed JSON file on it. This is to avoid third-party apps to “own” your domain when they don’t have it, such as owning twitter.com not being the original Twitter app.

The only drawback is that the user doesn’t seem to be in charge of choosing how to open the content (web-based or app-based), but let’s see how this evolves with time. In the near future, you might finding yourself clicking a link on a website or a Google’s search result and opening a native app without prior warning.

App Search

Apple has just entered the search market with its own web spider that we need to support to increase our visibility inside the new Spotlight iOS search and Siri. It’s also important when we have both a website and an app, because now Apple will index the content on our website but it might lead the user to the app instead.

While this will open a new chapter in SEO, it’s quite simple. You need to use markup standards, such as Web Schemas, AppLinks, OpenGraph or Twitter Cards with an App Banner with an app-argument if you have your own native app.

Apple has just released an App Search Validation Tool that will help you understand what do you need to add in your own website to support Apple Search

CloudKit JS

If you have a native app, you are probably saving user’s data on iCloud, but for now only iOS and Mac apps were allowed to get into that. Now, through CloudKit JS you can connect your website to iCloud data.

Back Button

When you link to a native app (through a custom URI or a Universal Link), now Safari will ask the user if she wants to open the link within the native app (see next image). If the user agrees, then the app will have a back button (top left) to go back to Safari to your website.

API Support

Navigation Timing API

Navigation Timing API is back on iOS 9. Just as a reminder, it was added in 8.0 and removed a week after with 8.1. This is good news for web performance. With this API we can measure with better precision timing, as well as receiving lots of timestamps about the loading process of the page that will be useful for tracking and for make decision in real time to improve the user experience.

Picture in Picture

For iOS only for now, the PiP API (known as Presentation Mode API) allow us to manually enter or exit the PiP mode for a <video> element if video. webkitSupportsPresentationMode is available.

CSS Scroll Snapping

Paginating content –such as a photo gallery- was always complicated on the web; using JavaScript frameworks, touch events, hacking scrollbars, etc. Apple is adding a nice CSS feature known as CSS Scroll Snapping. This feature adds a couple of CSS attributes to define snap zones (regular or irregular) so the scroll position will snap to these areas instead of stop at any position.

In this case, the horizontal scroll will do it by 100% of the width, so if we have different photos, we will never end seeing partial photos. It will paginate them. More interesting demos and examples in this article.

CSS Supports

CSS Supports has landed into iOS with both CSS @supports declaration and the JavaScript CSS Supports API from the CSS Conditional Rules Module Level 3 spec. Now, we can do something if we know that a CSS property with one specific value will be supported. For example:

Safari 9 for Mac OS El Capitán has a new redesigned Web Inspector. Fortunately, iOS 9 remote debugging is still working propertly with Safari 8 on Mac OS, so you don’t need to hurry and upgrade your Mac OS too.

Not sure who is really using this, but iOS 9 added some Dynamic Fonts used through -apple-font and they now use the San Francisco new font by Apple.

scrollingElement is now available

UPDATE: 20/9: <input type=file> now lets you select files from iCloud Drive and third-party apps if installed, such as Google Drive (next figure)

UPDATE: 20/9: You can’t mix HTTP and HTTPS resources when loading the page from HTTPS

Bugs

Bugs will appear over the few weeks and I’ll update this post as soon as I get more. For now, I’ve found:

a bug on Home Screen webapps where the apple-mobile-web-app-status-bar-style meta tag is being ignored. So you can’t now render your webapp behind the status bar as it was before using the value “black-translucent”.

UPDATE 20/9: Speech Synthesis API doesn’t work anymore

Did you find a bug? Besides posting it at Apple, you can report it here in the comments area or send it to @firt on Twitter. I’ll check it and post it here.

Still waiting for…

While Safari on Mac and Chrome on desktop and Android already support Push Notifications for websites, Safari on iOS is still missing the feature. In terms of APIs, we still not have: WebRTC, getUserMedia, Service Workers, FileSystem API, Network Information API, Battery Status API, Vibration API and more. What else are you waiting for on iOS?

watchOS and tvOS

watchOS 2.0 and tvOS 9.0 are coming too as iOS-based releases targeting specific devices (Apple Watches and new Apple TVs). From a user’s point of view, there is no browser. From a developer’s point of view, there is no Web View available.

While there are many people complaining (mostly about the lack of Web View), I’m still not sure if it’s a bad idea. But that is for another blog post. My guess is that Apple will try to bring “the web” to TV, watch and probably CarPlay users through Siri. So, if you follow the steps we saw before on “Apple Search” your content might be available from these devices through Siri as widgets or quick answers.

For Apple TV we have some kind of client-server webapp support through JavaScript, the DOM API and XMLHttpRequest. What’s the trick? No HTML or CSS support. It supports TVML, an XML-based markup optimized for specific content that can be rendered on the TV screen. This markup can be rendered from a native app that was distributed through the store, but the TVML can be generated server-side.

iOS 8 is finally here while the new iPhone 6 and iPhone 6 plus will appear in a few days. New APIs appears on scene, as well as new challenges to support the new screen sizes. I’ve been playing with the final version and here you have my findings.

An overview of this article:

Safari on iOS 8 in a nutshell

iPhone 6 and iPhone 6 Plus

New API support

New Safari features

Going Native with iOS 8

Safari extensions

New web design features

Video enhancements

The JavaScript side of iOS 8

Bugs and problems

As we are used with the company, Apple didn’t update any of the docs regarding Safari and iOS so all of the information here is based on my own testing and some information delivered at the WWDC.

The Remote Web Inspector works only from Yosemite; if you are still on previous versions of Mac you can use a Nightly WebKit build.

Compared to other mobile browsers, these are the features that didn’t come up on iOS 8:

Resolution media queries with dppx unit

getUserMedia

WebRTC

@viewport declaration

Datalist

WebP image format

iPhone 6 and iPhone 6 Plus

The iPhone 6 and iPhone 6 Plus are coming and with new screen sizes new challenges in terms of viewport and image sizes come with them. The iPhone 6 has 4.7″ and 750×1334 physical pixels (same 326dpi as iPhone 5s) while the iPhone 6 Plus includes a bigger 5.5″ with a Full HD 1080×1920 resolution (401 dpi). These new resolutions fall into what Apple called “Retina HD” displays, meaning… well, different than the previous Retina devices.

In terms of web development, the changes are in different places: default mobile viewport (when using width=device-width), pixel ratio useful for responsive images, icon sizes and launch images. Let’s see how this looks like:

Viewport size

If you are reading this post you probably know the viewport meta tag and the value width=device-width that we are used to to match the viewport size (the canvas where we render the page with the real screen size to avoid the zoomed out experience that we get when we open a desktop website on a mobile device.

You probably know that until today, all iPhones and iPods exposes a 320 CSS pixels width when using that viewport declaration. In a good decision, Apple has decided to bring us more space for content on iPhone 6 and iPhone 6 plus because they are wider than the previous versions. However, the values Apple is using are not matching 1:1 the current values on the market, such as on Android. While on Android 4.7-5″ devices will give you a viewport’s width of 360, iOS will deliver 375 and while on Android 5.5″ devices (such as Galaxy Note) you get a 400px viewport, on iPhone 6 plus you get a weird 414px width. This means roughly that we will see things 4% smaller on iOS compared to similar Android devices. Maybe it’s not a big deal but you should check if your websites are flexible enough to take advantage of the additional 14/15 pixels and you don’t have any visual glitch because of that.

You can emulate this viewports right now for testing purposes just changing the viewport

<meta name="viewport" content="width=375">

<meta name="viewport" content="width=414">

Device Pixel Ratio

In terms of Device Pixel Ratio, the iPhone 6 follows the same value as the previous Retina devices, using a value of 2. The iPhone 6 on the other way with 401 dpi needs a higher value. The real value should be around 2.60; however Apple has decided to give a shot on a new concept: rendered pixels, emulating a 3x device pixel ratio. If the DPR were 3x then the real physical screen (at 414 CSS pixels) should have a width of 1242 pixels but we know that is not true as the real width is 1080 pixels (13% smaller).

Therefore if you are providing 3x images for some Android devices, for example for the Galaxy S5 the image will be taken also for the iPhone 6 Plus but it will be resized by the browser before rendering it on the screen.

Icon sizes

A new icon size is available for iPhone 6 Plus, 180×180. iPhone 6 will use the same 120×120 that you should be using today for iOS 7 and (iPhone 4/5)s.

Detecting iPhones 6 server-side

I will update this post when the devices are on the street but so far it seems all the iPhones on iOS 8 (including 4S, 5, 5S, 5C, 6 and 6 plus) are using the same user agent, so we won’t be able to know server-side which device is there. Using JavaScript or Media Queries we can query on the viewport and/or the device pixel ratio to get an idea of where we are.

New API support

Two of the most expected APIs –since iOS 5- finally arrived to Safari on iOS 8: WebGL for 3D canvas and IndexedDB for NoSQL database storage. Also the Web Cryptography API and Navigation Timing API have landed on Safari for iOS.

With WebGL we can fully load a 3D environment talking directly to the video card with a non-so webby API –very similar to OpenGL-. WebGL was available on iOS since version 4.2 but it was always disabled. Now it is enabled by default in the browser, in a home screen webapp and also in the WebView adding a whole new world to web and game developers.

IndexedDB is the W3C answer to the deprecated WebSQL API that didn’t arrive into some browsers, such as Internet Explorer and Firefox. Now with iOS supporting IndexedDB, we can use the same API for database on all the mobile platforms. Safari is using the unprefixed version of this API

Regarding Navigation Timing API addition, it’s good news for web performance. With this API we can measure with better precision timing, as well as receiving lots of timestamps about the loading process of the page that will be useful for tracking and for make decision in real time to improve the user experience.

New Safari features

From a user’s point of view, Safari on iOS 8 has new features that might affect how our websites are rendered.

Pinch to Zoom

On iPhone (landscape only) and iPad (all orientations) if you pinch the screen (such as if you want to zoom out the page) you will get into a tab overview mode, which is nice, but it can potentially conflicts with pages that are already using the gesturechange event to provide pinch-to-zoom operation. If you are doing that, you can use event.preventDefault() on your event handler to avoid the default browser behavior.

No minimal-ui

Just 6 months ago, Apple introduced the Minimal UI mode through the minimal-ui value on the viewport. Well, today, it was announced (no reason given) that the Minimal UI mode is removed from iOS 8 and in fact, it’s true. It’s not working anymore.

Autocomplete and credit card scan

Safari has now an autocomplete feature for forms that will work automatically. When Safari detects a credit card form it will allow us to scan a credit card and using OCR type the credit card numbers automatically. I did several test and I didn’t have luck finding how Safari realized it’s a credit card form. It is working with PayPal, Netflix, Amazon and many other sites but not sure how it works. Not sure if the decision is client side or if it’s whitelisted somewhere on Apple’s servers.

(Image from 9to5Mac.com)

UPDATE 18/9: Safari also supports now the autocomplete attribute in the latest spec. It means that if you have a login form, Safari now supports the username, current-password and new-password values that will help Safari autofill the login form with data from the Keychain. Luis Abreu has a good article on this feature and other privacy-related enhancements in iOS8.

RSS is alive!

If you have a RSS feed descriptor on your website now your users will be able to subscribe to your site just browsing on it and opening the Bookmarks panel. There, the @ symbol section (Shared Links) will manage Subscriptions including a “Add current site” button. A bit hidden, but at least is there.

New updated toolbars

Both URL bar and toolbar for iOS and Android are now semi-transparent. On iOS 7 this behavior was available on just the URL bar on iOS only. That means that now the visible viewport on the first load includes the bottom toolbar and that on iPad we get the same tint color over the URL bar.

Finally, on iPhone landscape we have a new unified toolbar (similar to the iPad) where we have the URL and the toolbar just in one place at the top.

iPad-only updates

Since iOS 7, Safari on iPhone is hiding toolbars when scrolling the page but iPad didn’t get that behavior. From iOS 8 we do have it by default on both orientations. The difference on iPad landscape is that we still see a minimal title bar at the top, while on iPhone landscape you have a 100% full screen mode.

(oh, yes, that is subliminal advertising, that’s my book :P)

Safari on iPad also now includes a Sidebar on landscape which keeps the same viewport size in a smaller area. In terms of RWD it’s only affecting aspect-ratio.

Icon for bookmarks and frequent websites

Safari for iOS, for the first time, will also use the website’s icon for favorites and bookmarks; not just for when the user adds the website to the home page.

It will also use the icon for the suggestion list while you are typing in the URL bar.

Handoff

With handoff now users on Safari on iOS can continue reading the same page on a Mac with Yosemite connected to the same user. I couldn’t try this yet but you should verify that if you are using an m.* website with redirection you should redirect back the user to the desktop version from the mobile. Not sure yet how it’s going to work in terms of keeping the scroll position as it was advertised.

Going native with iOS8

First, let’s say that if you are redirecting your user from a website to the Apple Store to download your app without user’s interaction (a click for example) Safari will not allow it (fortunately).

Then, from an integration between web and native point of view we have two important news:

Safari extensions (covered later)

New way to share credentials between Safari and your native app so the user doesn’t need to login again

The new WebView

Finally, the greatest news for native webapps (hybrids) is the addition of a new Web View that matches the same API that is available on the Mac, meaning more features, cross-compatibility between Mac and iOS and most important:

A native way to communicate between JavaScript and native code through the postMessage interface

New classes configure the Web View similar to the power we have on Android’s Web View.

Nitro engine, which means ~4x faster JavaScript execution code compared to the current Web View. Do to that the Web View’s engine will be running in a different process and if you have several web views running at the same time they can share resources meaning less memory and faster execution.

The new Web View (WKWebKit) is part of a new framework (WebKit.framework) and it’s not 100% compatible in terms of the API with the old one (UIWebView). The old one is still there, so that means that all the apps out there using the Web View today will still use the old version until they update it.

At least on the GM version there is a bug with loading local files which might defer the good news to an iOS update for hybrids, including Cordova (PhoneGap) apps.

This means that now in iOS 8 we have four web runtimes available and compatibility, and bugs, might differ:

Safari

Web.app (the runtime used when you use a full-screen home webapp)

UIWebView (old)

WKWebView (new)

Here you can see a native app running HTML5Test.com on both UIWebView and WKWebView at the same time

This change will be particularly useful for pseudo-browsers and in-app browsers, such as Chrome on iOS or browsing inside Facebook app. According to MOVR Report from ScientiaMobile, 11.5% of iOS web browsing traffic comes from WebView-based apps.

Safari extensions

Safari on iOS 8 became the first pre-installed browser on the first 3 main platforms to support extensions or plugins (Firefox OS might be the one on the long tail). From iOS8, native apps from the AppStore can extend Safari in mainly two ways: as a Share extension or as a actions. Actions can work with the DOM, which is great because it means we will be able to read and change DOM elements from within native code.

All the extensions work after user’s interaction, meaning she needs to open the Share button and click on the Extension icon to enable it. There is no automatic extension so far for Safari.

The old Safari “Share” menu was also replaced with JavaScript-based extensions, for example the “Add to the Home Screen” action is now a JavaScript code inside Safari that searches using the DOM API for your meta tags.

Besides the examples on the Apple’s keynote (Bing translation or social network sharing), there are a couple of good examples out there of how this will improve web browsing. For example, 1Password and LastPassword announced their apps that will allow a Safari user to log in into any website without entering any details, even with Touch ID validation if you have a 5s, 6 or 6 plus.

Extensions can have their own UI on top of Safari or they can be just silent extensions that will do something with the DOM on current page.

Here the 1password action inside Safari:

Pocket.com also announced support for custom actions

I’m looking forward to see custom actions in Safari and what great thinks we can add on top of the mobile web with it.

New web design features

Let’s first list quickly the new additions and after that let’s get deeper into some of them

CSS Shapes

CSS object-fit

CSS Background Blend modes

word-spacing

CSS Compositing and Blending

Subpixel layout

Animated PNG supported

Parallax effects and Pull-to-refresh supported

SVG Fragments Identifiers (for SVG Sprites)

Image Source Set support

HTML Template support

Animated PNG

It seems to be just an anecdotic mention, but I think this is a huge deal. APNGs are a non-standard format similar to Animated GIFs, but based on the modern PNG format. Meaning the we can create animations that will use less bytes than current Animated GIFs and even with alpha transparent 32-bit bitmaps.

APNG (Animated PNG) is an unofficial standard for using PNGs for animations. The draft specification can be found at the Mozilla wiki. At the time of this writing, only Opera Mobile and Firefox since version 14 support APNG on mobile websites. The advantage of APNG over animated GIFs is the ability to use alpha channels and 32-bit images. A quick way to create APNG files is using APNG Edit, a free Firefox for desktop plug-in available from Mozilla’s Add-Ons.

Parallax effects and pull-to-refresh thanks to scroll events

If you were wondering why those fancy effects while you are scrolling were not compatible with iOS, it was because of the lack of scroll events being fired on iOS 7. Now on iOS 8 they are back so all the Parallax JS and CSS libraries will be compatible. Use them with caution, usability not guaranteed :)

This change is also useful to create pull-to-refresh and infinite scroll lists that will start loading next items while the user is scrolling.

It is worth mentioning that on the betas (removed on the final version) new events were tested onwebkitwillreveal[top|bottom|left|right] that were useful for making infinite scrolls faster. These new events were removed from the final verison.

Subpixel layout

Safari (and the other rendering engines) are now change CSS pixels from being integer to float values, allowing drawing and getting data in decimal “px” values. That means that CSS object model getters, such as offsetTop or clientWidth will receive fractional double values. Before iOS 8, rounded integral values were returned.

It also mean you can now draw hairlines (1 physical pixel) for retina devices. @Dielout has a good article on this.

SVG Fragment identifiers

Fragment identifiers from SVG is a method to link to one specific fragment or portion of an SVG instead of the root element. This feature allow us to sprite SVG images in one file taking advantage of one HTTP request and caching. Similar to CSS Sprites, but with SVG images instead and with ids instead of positions.

CSS Compositing and Blending

This new spec from the W3C describes how shapes of different elements are combined into a single image through new CSS attributes useful for HTML and SVG: mix-blend-mode, isolation and background-blend-mode. This proposal was created by Adobe to bring some of the features of Adobe’s product (such as Flash) to HTML5. On Adobe’s website you will find examples and documentation.

From a quick test on Adobe’s examples, it seems Blending is working but not Compositing, but this requires further testing (examples and testing suites are welcome).

CSS Shapes

CSS Shapes is another new spec for web designers from Adobe. CSS Shapes allows us to add a shape to a float (shape-outside property) which will lead to content next to the float will flow around the shape. There are other attributes as well to create complex shapes and fit content in our out of them.

Image Source Set

Apple originally defined the -webkit-srcset CSS function a while back and now it’s implemented on the HTML side for semantic images. Therefore we won’t need to do tricks for delivering images on different resolutions. iOS 8 supports the Image Source Set spec that means the usage of the new srcset attribute on <img> elements.

Therefore on iOS 8 we can use:

<img src="lores.png" srcset="hires.png 2x, superhires.png 3x">

In this case the iPhone 6 Plus will load the superhires file, other Retina iphones (including the 5S and the 6) the hires.png file and all the other devices (including those not supporting srcset at all) the lores.png file.

Unfortunately, no <picture> element supported on iOS yet that is the final Responsive Images spec that works with srcset.

HTML Template Support

The <template> element, now in the HTML5 spec is now available on iOS 8. This element is particularly useful for webapp work as all the content of <template> including CSS and JavaScript is not being parsed by the browser (similar to an HTML comment). The advantage is that we can use a template from JavaScript to clone it and create another real node that will be parsed when needed.

Video improvements

Video is important for Apple and iOS 8 introduces new features from a web’s perspective, including Full Screen support, Meta Data API and CSS layering.

I’ve seen reports saying that Media Source extensions is now available on iOS 8 but I couldn’t find it so I won’t say it’s there yet.

Full Screen API for video elements

Safari doesn’t support the Full Screen API and iOS 8 is not the exception. However, it’s now available in one particular situation: on <video> elements. Therefore, you can request Full Screen video playing after user’s interaction, such as a click, for example using:

The JavaScript side of iOS 8

Background execution: now JavaScript continues executing even being the inactive tab (timers are slowed down to 1s frequency) and even being Safari in the background.

Scroll events (including onwheel, but doesn’t seem to do anything)

Unprefixed Page Visibility API

UPDATE 9/18: Thanks to @alex_gibson report, it seems that on some iPhone 5 the 300ms delay on click events was removed (only at Safari), but not on WebViews or Safari on other devices on the same iOS 8 build number. The delay is still there at least on iPod touch, iPads and for other people on iPhone 5’s reported on this Twitter thread. I’ll keep this post updated upon further testing later.

window.doNotTrack was removed

window.currentScript is available

False alarm on Push Notifications for iOS

Some of us got a big surprise on the Apple website reading “iOS Website Push Notifications” but unfortunately seems to be a bug on the website because so far Safari accepts Push notifications only on Mac OS.

Bugs and problems

As we are used to with Safari and iOS releases, good news usually are opaqued with some bad news in form of important bugs affecting users. So far, I’ve seen these bugs. I’ll update the list based on your input, so if you’ve seen another bug please use the comments section below

File uploads are broken!! Every file upload is not working, you can select a file or take a picture and after that JavaScript will not get any data, as well as the server on a POST upload through HTML or XMLHttpRequest upload. The problem doesn’t seem to apply for home screen webapps.

On WKWebKit, local files can’t be loaded being a big problem with hybrid apps, including Cordova-based apps that need to still work with the old UIWebView until this problem is solved.

The Google’s annual developer conference gave us the preview release of Android L. There are some news I want to share with web and hybrid app developers, not only about Android but also for the future of other Google-based solutions, such as Chrome OS and Chrome Developer Tools for mobile development.

Websites and webapps as first class citizens

On Android L, native apps can expose different “windows” to the Recent App list on the operating system and it was already announced that Google Chrome will expose every tab as a window. Therefore, every tab opened in Chrome will appear in the OS as a different app removing visual differences between webapps and native apps.

On Android L each Chrome tab will appear in the Recent multitasking panel as other app

With the “Add to the homescreen” Webapp feature for fullscreen usage and a more powerful future version of that feature announced from the Chrome team, this feature will give us more power in the OS.

Android L WebView

Because there is no more “stock browser” promoted by Google on Android since KitKat, on the next version known as Android L so far, it’s more important to talk about the WebView.

I have confirmation from the Chrome engineering team that the final WebView on Android L will be based on Chromium 36 with WebGL and WebRTC enabled –compared to Chromium 30 without those APIs on KitKat and 33 on KitKat 4.4.3-.

UPDATE 6/29: WebAudio will also be enabled on L’s WebView, as well as a ~200% 2D Canvas performance improvement.

While on preview, the Android L SDK and preview firmwares available will use the beta version of that Chromium version.

New emulation tools coming to Chrome

The Chrome team has redesigned the emulation tools in Developer Tools available right now in Chrome. Starting today at Canary channel, you will find a new emulation tab with a new design and options.

New tools for mobile emulation on Chrome Developers Tools (only at Canary at the time of this writing)

Now, besides the previously available options of emulate viewport, touch events and user agent, we can:

Fit a big device with a scale option

See your media queries breakpoints on your code and quickly see layout differences

Throttle your network connection (just in your current tab) including emulation of bandwidth and latency for cellular connection.

Make the current tab offline

Also an experimental feature can be enabled to accelerate the remote debugging abilities.

Android One

Android One is a new effort from Google to bring Android smartphones to emerging markets with low prices. It was announced that the stock Android will be delivered in these devices, so we expect Chrome to be shipped on most of these phones by default.

Material design language on the web

Google has just released a new design language for multi-screen known as Material Design and the web is also a platform were we can take advantage of this new kind of interactions, visual controls and animations.

Android apps on Chrome

A feature -not ready yet- was announced for the future of Chrome OS: the ability to run Android native apps. That will allow the so far HTML5-only OS to run native apps. It’s not clear yet how are you going to install those apps or if we’ll need some kind of repackaging or cross-compilation.

There is no much information yet about how this is going to work. The only comment I could get from a Chrome engineer is that those apps will run through Native Client and that not every Android feature will be available –such as Intents or Broadcast Receivers-. Apps will appear in the App Launcher as any Chrome App.

Android apps will run on ChromeOS in the future

Each app will run in a “smartphone” window mode or a tablet mode as a Chrome OS window. Developers will need to make some small work, such as test and add support for non-touch devices with keyboard and pointer.

While this feature was announced for Chrome OS only I think it can easily be ported to Windows, Mac and Linux.

Google App Indexing

With Google App Indexing, we can link an HTML page with a deep link to your native Android App on Google Play Store. If the user already has the app, Google will invite the user to open the app instead of the link. You can even index your app’s content even if you don’t have a corresponding HTML site.

It seems there is no way to take advantage of this API from third-party websites.

New flavors of Android

In the case of Android Wear, already available on the Samsung Gear Live and the LG smartwatch, there is no browser available. The user can search by voice on Google and get a snippet on the watch. If the user clicks the snippet then the website will be opened in the phone. That is a difference with Google Glass, where you can actually browse the web.

UPDATE 6/29: Android Wear will not have access to a WebView, so the only way to render web content is to do it on the phone and send the rendered image to the Watch (native apps on Wear travel inside a smartphone app).

Android TV and Android Auto are also coming soon; these versions don’t have browsers, but they do have WebViews so hybrid development will be possible.

As you might know, iOS 7.0 included one of the buggiest browsers of all time for iPhones and iPads. After 5 months we have now the 7.1 update that wants to give some fresh air to web developers. Let’s see if Apple succeeded on the task.

Some other issues for Home Screen Webapps were already solved in 7.0.3 update a month after the initial launch, such as the ability to open external URLs and the usage of standard dialogs, such as alert.

Apple has patched 19 bugs in the Web Core (for Safari, WebView and Home Screen webapps) since 7.0.3 but it’s not clear which ones. There are some reports on some fixes on requestAnimationFrame and Web Workers.

New stuff

The browser in 7.1 is the same as in 7.0 in terms of APIs and abilities, so no new features to cover.

New minimal-ui viewport declaration

Don’t expect any update on the documentation on this (is anyone expecting an update in the outdated Safari docs anyway?), but the viewport meta tag now supports a new boolean property for iPhone and iPod touch: minimal-ui. And this is the biggest change in 7.1 for web developers.

<meta name="viewport" content="width=device-width, minimal-ui">

The presence of minimal-ui in the viewport will trigger a full-screen mode automatically that will be well-received by webapps and UI frameworks (such as Sencha Touch or jQuery Mobile).

This mode looks different based on orientation: it includes the iOS status bar and a small title bar on portrait and nothing on landscape (immersive mode). No URL bar or toolbar will appear on both orientations. That means there is no visible back button, besides the back gesture that is still available.

The hidden toolbars will appear as modal windows only after a tap on the top portion of the screen (compared to top or bottom on mormal mode).

It seems there is no way to set/unset the minimal UI dynamically from code unfortunately. I’m wondering why Apple didn’t go with the FullScreen Javascript API.

When in landscape there is no status bar or title bar, but the toolbars will appear when tapping on the top portion of your document. That also means that the first 40 physical pixels of the page should not be used for clickable elements on that orientation; that is 10 CSS pixels if you are using a width=device-width viewport or 20 CSS pixels on width=device-height (useful on portrait). You can draw there but no interaction is allowed; that means that we should not use something as a small select picker on the top as in the following example because it will just trigger the toolbars.

Some important things about the minimal UI feature:

No minimum document’s height need for getting the full-screen mode (compared to the old window.scrollTo trick).

Adding or removing the minimal-ui after onload have no effect, so no way to define or change it dynamically

No resize events will fire on show/hide

On landscape, you are in immersive mode; even the iOS status bar is hidden; however, the first 40 physical pixels are available for your document’s canvas but not for interaction

If you link two URLs with minimal UI, Safari will wait for the second page to load before showing the toolbars. Therefore, the process is seamless and it will be a minimal UI experience between all your linked HTMLs avoiding UI glitches.

Compatibility

A quick test says that adding minimal-ui is safe enough on the modern mobile web and different browsers, including Safari on iOS 6.x/7.0, Android Browser, Firefox, Google Chrome and IE will just ignore the declaration and set up a proper viewport anyway based on the other attributes. Chrome can trigger a warning on console that the value is not valid, but the rest of the declaration will be used.

Please, think twice before adding minimal-ui

While a full screen mode sounds good, it’s not the best solution for every kind of website or webapp.

Don’t use minimal-ui as the new default viewport value; use it with responsability.

Think about usability: the user will not have the back, the share and the tabs buttons available by default. If you are creating an inmersive game or a webapp with the main navigation controls then minimal-ui is a good idea; for content- and document-based websites, it might not be nice for the user.

If you are creating a webapp using a UI framework such as jQuery Mobile or Sencha Touch, using minimal-ui is a very good idea. UI glitches on iOS 7 on these frameworks’ animations were a big problem, basically when changing the browser’s history.

This mode is also particularly useful if you have a bottom toolbar (as Financial Times Webapp); in normal mode after scroll it will requiere two taps (check my previous post for more info)

The Financial Times webapp is already using the minimal UI mode; the only main difference here with previous operation is that the “Add to the Home Screen” button is no longer for easy access. Therefore future invitation bubbles should explain that you need to activate toolbars first (such as “Click at the top on the title, now click on Share, now Add to Home Screen).

Minimal-ui vs. full-screen after scroll

If you have a content that scrolls vertically the toolbars will also hide after the user scrolls down without a minimal ui declaration. However, they will come back after scrolling up and the main difference is that in this case, the canvas’ size will change. When using minimal-ui, the canvas size will always be the same and toolbars will appear as modal over it. In normal mode document’s size will change based on current toolbar status.

In the next example we can see what happens with fixed positioned elements on each situation.

Detecting minimal-ui mode using media queries

We can use media queries (specifically for iOS devices today) to detect if we are on minimal-ui mode or not (with a width=device-width viewport), using:
@media (device-height: 568px) and (height: 529px),
(device-height: 480px) and (height: 441px) {
/* minimal-ui is active */
}

I’m not saying this is a good idea, but for now it’s the only trick if we really need it.

Minimal-ui for iPad

The minimal-ui declaration is ignored by iPads, as there is no way to trigger a full-screen experience from Safari itself. We only have the old option of a home screen app.

Web SQL Bug

The Web SQL bug was finally solved and the API is already fully compatible again from 7.1.

Home screen webapp bugs

Here we have a match in terms of bugs solved and bugs still there. Unfortunately, a match means problems for us. Home screen webapps are still buggy in many ways, mostly regarding multitasking, opening several webapps at the same time and returning to previous webapp sessions or something seeing the current webapp as a background for the multitask view instead of the typical background (next image).

Compared with iOS 7.0 now AppCache is working again up to 25Mb for home screen webapps (while 50Mb can be reached with a user’s permission while in Safari).

After going forward and backward between webapps I’ve seen many times a “black effect” or a “white effect” that is, the webapp tries to reload after waking up and it doesn’t work leading to just a white screen or a black screen. The only way to get out of it is to close the webapp and try again.

The status bar by default is still black over black and we must use a meta tag to change it. Also as a problem without solution, the preview for a “minimized” webapp on the application history list is still just a white rectangle instead of the launch image or a screenshot of the last canvas.

Home screen webapps or minimal UI webapps?

Now that we have the minimal UI ability, and with all the bugs on Home Screen webapps, we should ask how useful or different home screen webapps are.

The main differences in favor of Home Screen webapps are:

Isolated storage and cache from Safari

Looks like a native app in the multitasking panel (App History) – with bugs.

Unlimited Web SQL storage

Isolated UI: users don’t see any URL bar, toolbar or tabs.

The main differences in favor or Minimal UI webapps are:

No need for a Home Screen icon

It can be loaded from a URL, bookmark or a Home Screen icon

On landscape, it is immersive mode (on a Home Screen webapp, you still have the OS’ status bar)

Any other bugs, problem or feature found?

Android 4.4 has made a big change in the OS’ internals for HTML5 development: it has replaced its original WebKit-based WebView with modern Chromium. The new Android Browser is also powered by Chromium but it’s not clear yet its future. Besides the good news, not everything looks exciting in these changes, let’s see why.

Every web developer that has played with native webapps, PhoneGap and the Android’s WebView knows how terrible it was in terms of performance and HTML5 compatibility. The same problems that most web developers suffer right now with the Android Browser -reported to be 32% of the mobile web browsing market share, compared with just 5% of the modern Chrome for Android according to Akamai.

I’ve been talking about this problem in a recent post this year –Android Browser: the eternal mobile browser-. Therefore I’m the first one to celebrate the beginning of the end for this dying web platform and the Chrome team now in charge of Android’s web runtimes.

Where is my browser?

Everybody at Android and Chrome team is talking about the new WebView but nobody is even mentioning what will happen to the browser. We all want Chrome as the default browser, but it seems it’s not there yet (licenses issues I guess).

I’ve even see a couple of members of the Chrome team saying that the stock Android Browser didn’t exist in the latest previous versions –which is not true-.

From a Google’s perspective, Android Browser sounds much like IE6 and nobody wants to talk about it. They give us the idea that Chrome has been powering web browsing in Android for a while, but that is only true for some particular Android devices –Nexuses and devices from top manufactures-. However, as I’ve mentioned before the relationship between users browsing with Android Browser and Chrome is still 7 to 1.

The question is: what will happen on 4.4 with the stock browser? We know that the Nexus 5 has Google Chrome by default; the question here is what will happen with other devices having in mind that average users don’t download browsers from the store and use what the devices offers for browsing.

Based on the emulator, the Android Browser is still there on the emulator and it’s using the classic browser UI with the Chromium 30 engine (it can coexist with Chrome but they will be radically different) Unfortunately, there is no mention of this on docs and blogs on Android 4.4. I hope we can get a real answer from the Android team soon about the future of the browser itself.

The good news

Remote debugging

Finally we have the ability to debug remotely Android native webviews –including PhoneGap apps- and the Android Browser and it works smoothly both from real devices and from the emulator. When we have an Android app opened with a web view or the Android Browser, the Chrome remote debugger tools will recognize it as a “Chrome 30” session and we have the full package of excellent tools for debug, profile and test our webapps.

HTML5 new features

Compared with the classic web view and the Android Browser until 4.3, we have now support for:

Server Sent events

Web Sockets

Web Workers

Advanced form input selectors, such as date and time

FileSystem API

IndexedDB

MediaCapture Stream ??? test

Animation Timing API

Page Visibility API

Canvas Blend modes

CSS3 Flexbox (latest version)

CSS3 Filters

Even matching Chrome 30 for Android, the Web View (and potentially the Android Browser) will not have support (no reasons given) for:

WebGL

WebRTC

WebAudio

FullScreen

Form validation

Compared with the classic Web View, the new one doesn’t have

Network Information API

Performance difference

Having V8 as the JavaScript engine for the new web view, the JavaScript performance if much better, besides general performance on CSS thanks to hardware acceleration.

The not so good news

The Classic Web View is still alive

Don’t get so excited. We will deal with the old Web View (known as “classic”) for a couple of years. In fact, some devices such as Galaxy Nexus that are today on 4.3 will not get the update. And remember that still today 30% of Android users are on 2.x after 2 years of being replaced by 4.0 so it’s fair to guess that at the beginning of 2016 we will still have around a third of the users on the “classic” WebView that we hate today. The migration on the market will be slow based on Android’s fragmentation.

WebView upgrade

The KitKat WebView is based on Chromium 30 and it won’t be updated. That means you are stuck with it unless to get an upgrade in the future of the whole OS to next version. Even Google has announced OS delta updates without vendors’ intervention, but it seems the WebView will not get that deal yet. Therefore and based on Chrome release cycle, in one year we will have Chrome 40 and the WebView will still be in 30.

In a couple of years we might be complaining about an “old and outdated” webview again

Compatibility issues

Because there are changes between the old WebKit-based rendering engine and the modern Chromium engine, you should test your native webapp on KitKat to make sure it’s still working great. To reduce problems, if our app was packaged before KitKat the WebView will enter a “quirks mode” (any similarity with IE6 is pure coincidence) that will reduce the risk of incompatibilities while still getting the new APIs. In fact, this compatibility mode will get in action if the configuration file of your app has a target SDK lower than 19 (the API number for KitKat). To get more detailed information on migration and compatibility issues you can try the new Guides at Android and Chrome websites:

Looking forward

I’m really looking forward to remove the old WebKit and Android Browser from the market. The Chrome team is doing a great job empowering the mobile web (just remember homescreen webapps from Chrome 31), but sometimes the Android ecosystem is slowing down HTML5 penetration and helping promoting companies to avoid using web technologies. I hope this is the beginning of a change.

We’ve been dealing with webapps on iOS for a couple of years: websites that after Home Screen installation become a full-featured full screen app from a user’s perspective. Finally, Chrome 31 brings that approach to Android devices: HTML5 apps without the need of packaging and a using the store for distribution.

Chrome 31 for Android –available as beta at the time of this writing- brings home-screen web apps to the Android world following Apple’s approach: through <meta> declarations and with user’s intervention adding the website to the Home Screen. Google has named the full-screen ability as “full-screen app mode” and the ability to add the icon to the home screen as “application shortcut”.

While today Chrome supports some of the Apple’s proprietary meta tags for compatibility purposes, Google suggest the usage of the vendor-free versions for future compatibility.

If we mix the full screen app mode with Application Cache, we can provide a full offline app experience without creating a native Android app package. A similar approach was available before on Firefox on Android with Open web apps and on the Kindle Fire series with the recent Amazon Web app platform.

Configuring the shortcut icon

Chrome now has the “Add to homescreen” option in the menu that allow us to add a shortcut to any URL. Even if we don’t want to create a full-screen webapp we should update our website’s icon to match Chrome’s recommendations because the user can add any website to the homescreen, even desktop-optimized content.

Chrome will make use of the apple-touch-icon and apple-touch-icon-precomposed link (Apple’s proprietary declaration for home screen icons) but recommends the usage of the standard “shortcut icon” link with a square size of 196×196 (the recommended size for multiple resolutions). If it’s not defined on that size it will take 128×128 or apple’s icons.

<link rel="shortcut icon" sizes="196x196" href="icon-196x196.png">

If we provide both shortcut icon and apple-touch-icon declarations, Chrome will use the shortcut icon so we can have a multiplatform web app providing both iOS and Android. If you want to check all the available icon sizes on iOS, check Programming the Mobile Web or this blog post.

Remember: we should define the icon even if we don’t want a full-screen webapp because the user can add any website to the home screen. If you have an icon for iOS you may be ok for a while, but you should add the high resolution 196px version if you want to support xxhdpi devices, such as Galaxy SIV.

If you don’t provide a high resolution touch icon, it will use your old favicon inside a paper bigger icon (next figure). It nicely uses the most prominent color of the small favicon to effects on the icon.

IMPORTANT #1: The icon will be available on the Home Screen and not on the Applications menu. This is a restriction from the Android OS itself.

IMPORTANT #2: This mechanism will not work on Chrome on iOS because of OS’ restrictions.

Web app name

The Web app icon will be defined by the user when confirming the icon on the home screen but it will be based on the <title> element on your website. There is no way to define one title for SEO and the browser and a different name for the home screen icon. On iOS, Apple supports an undocumented meta tag (apple-mobile-web-app-title) that is ignored by Chrome at the time of this writing.

Forcing App Mode with Web App Capable

To define that we want to be executed as a full-screen webapp (“app mode”), we should use the unprefixed meta tag:

<meta name="mobile-web-app-capable" content="yes">

For a while, Chrome will also support the Apple-prefixed version:

<meta name="apple-mobile-web-app-capable" content="yes">

Nokia Browsers for Symbian and MeeGo (RIP both) follow a similar approach.

From a web perspective, being web app capable means that our content will work properly when:

There is no URL bar

There is no back or forward buttons on screen (on Android, we will always have the soft/hard back button anyway)

There is no reload button, so everything should be managed by the app. If we change the contents to get the updates the user will need to wait until it’s removed from memory by the OS, to remove the app from the Recent App list or we can provide our own reload button.

Besides orientation change, there will be no viewport changes (such as toolbar appearing/dissapearing)

It’s important to highlight that we can debug webapps using the same remote inspection tools available for Chrome on Android.

In terms of HTML5 APIs, security and cross-domain policies, a full-screen context is exactly the same as running inside Chrome.

Detecting Full-screen

There is no official way to detect if your HTML is being executed in browser mode or app mode (full screen). The iOS navigator.standalone Boolean property is not supported. However, we can use the following quick polyfill to detect whether we are in app mode or not. Please do it before the onload event, so you make sure you are not in browser mode after a page scroll (where the toolbar is also hidden).

This snippet asks about the available viewport height and compares it with the device height to see if the URL bar is on the screen.

The Web app UI

In the Android OS, when we open a Web app it appears in the Recent Apps list as “Web app” (not our page’s title) and it look in a different spot than Chrome. However, the process used by both Web apps and the browser is the same, so if we close the Chrome process it will also close all Web app sessions.

If you open more than one web app, you will see different “Web app” titles in the Recent App list, as in the next figure:

There is no way to define the image to show on the recent app list; Chrome will take a snapshot of the app.

Opening links

When you open a link (through an <a> element or JavaScript), Chrome will load it inside our webapp Activity (window) instead of the browser. If we are loading a file from a different domain it will alert the user of that situation adding a small URL bar at the top:

This is particularly useful for OAuth login mechanism, so we can use Facebook Connect for example to log the user in without leaving our webapp context.

If we want to force a link to open in Chrome, we need to use the standard target=”_blank”.

From a webapp we can communicate with other native apps using standard Android Intent URLs, such as opening Maps or making a call. If you want to know more about this, check Chapter 15 of Programming the Mobile Web.

All the links will have a contextual menu (after a long-press gesture) with a “Open in Chrome” option.

Differences with iOS webapps

Chrome doesn’t support the advanced webapp techniques (poorly documented by Apple), such as:

Additional meta tags for status bar style and title

Additional link for launch image

Navigator.standalone Boolean property

On the other hand, Chrome-based webapps have the ability to go back in history using the back soft/hard key on Android, while on iOS there is no way to do that. Chrome also keeps the current URL (particularly useful for single page webapps) between sessions, so if the user comes back to the webapp a year later it will keep it current state. On iOS every time you re-open the webapp it load the first URL from scratch.

On Chrome webapps, the storage context is the same as in Chrome. Therefore, localStorage, SQL Storage, IndexedDB stores will be shared between the browser and the Web app. On the other hand, on iOS from 6.0 contexts are different so you can’t share data between webapps and websites.

On iOS when you quit a web app and open it again it will always be refreshed; on Chrome it will be up to the operating system resources; so if you re-open the same web app quickly it will just restore the previous app context.

Looking forward

At this point, a HTML5 document running in browser mode with Chrome or in “App mode” has exactly the same permissions and abilities. Because Chrome Packaged apps are available for other platforms, it’s not clear yet if “App mode” apps will have Chrome app API support in the future or if we will need to package them as APKs.

One of the biggest challenges of Web apps is discoverability, so besides asking the user to “install” the app to the home screen on our HTML, a Web app guide or store will be much useful for this problem.

In the future I’d like to see also some UI improvements, such as:

Define launch images (to avoid a white blank screen while loading)

Define the available orientations (so we can lock an HTML5 game in landscape mode for example)

Avoid the installation of the icon if the same URL is already installed in the homescreen

Discover if a full-screen icon is available and launch the full-screen version from Chrome in that case

This is a great step forward web app development and I hope the Chrome team will enhance the abilities and discoverability of web apps in the future.

Apple has rolled out iOS 7 with iPhone 5S and iPhone 5C . As expected, Apple has published just 10% 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 webapp.

In a nutshell

Don’t have time for reading 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.

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 webapp will react.

Toolbars’ tint

Safari will now tint the toolbars (URL bar and bottom toolbar on iPhone) based on: a) the background color when loading the page and b) 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:

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.

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-mode.

The toolbar and full URL bar will appear again when: 1) the user taps on the domain host at the top or 2) 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:

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’s 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 fullscreen 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% of the screen and toolbars never go away.

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 are making things complicate to HTML5 games also. Because this post has started in the Apple Forum while in Beta 1, 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 (update 19/9)

When in fullscreen 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 fullscreen 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 do 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. Therefore, two taps for action a button for example. 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.

Title

The next big change in Safari’s UI on iPhone is the title’s 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 fullscreen mode; the toolbar and title’s bar is always visible.

New Add to Home 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 need 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 to 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; Safari will trigger the back and forward action in the browsing history à la Internet Explorer on 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 (but to be honest, you have the same problem right now with Chrome too).

The problem is even weirder on single page webapps (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 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):

This gesture and the back animation (slide to the right) is also making conflict with some UI frameworks, such as jQuery Mobile or Sencha Touch as 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 webapps or UIWebViews (such as PhoneGap apps)

Icon sizes

The new OS icons are 5% bigger in 7.0 then in previous version, for example 120×120 on Retina iPhone devices instead of the previous 114×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 sizes values.

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

Bookmarks and Favorites

While on bookmarks there are new icons available (see left image below), it seems there is no way to define those icons specifically yet, 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 is not taking the icon for favorites. XXXX

The new devices

In a few days, the iPhone 5S and the iPhone 5C will be available on the market and the good news is that from a web development perspective they are exactly the same as the iPhone 5. Same screen size, same pixel density, same abilities. They may be faster, but nothing to worry about from a coding perspective.

The new Touch ID feature (fingerprint scanner) is not available to web sites yet and the 64-bit CPU will not change anything from a JavaScript developer’s perspective. Having said that, on the iOS Simulator now you have the ability to emulate a 64-bit CPU.

HTML5 markup support

Video tracks

The video HTML5 element now supports the track child for subtitles and/or closed captions. We can support multiple languages and they will appear in a picker inside the video player. The user can change the language and/or disable the captions from the track picker.

For all the possible track types (kind attribute), it supports only captions and subtitles and we have to define the language in the srclang attribute in ISO format (such as en for English). Subtitles are useful when the user can hear the audio but she/he doesn’t understand the language and captions are for when the user can’t hear the audio, so it includes additional information about what is happening (such as ‘background musing playing’).

Defining the label attribute for track is worthless because on iOS it will be ignored and the language name will be used instead for the menu with an optional CC suffix if we are using captions instead of subtitles as the kind value.

Tracks can be accessed through a JavaScript API and we can use it to loop through all the cues on the track file. That might be useful only on iPad where we can truly embed the video in the web canvas instead of a always fullscreen mode on iPhone.

Track elements should follow cross-domain policies, as by default, the video and track origins must be the same. Using JavaScript we can detect if tracks are available using webkitHasClosedCaptions as in

var hasCC = document.querySelector("video").webkitHasClosedCaptions;

We can also change captions visibility using webkitClosedCaptionsVisible boolean property of every video element.

Styling captions

From a CSS perspective, iOS 7 supports the new ::cue pseudo-element but we can only change text-shadow, opacity and outline. All other properties, such as color and font styles are ignored.

Progress and output elements

The <progress> element is now supported, creating a progress bar on the screen based on max and value. There is no indeterminate progress support as in other browsers, so it’s only suitable when we know the determinate value of the activity’s progression.

<progress max="100" value="40">

The <output> element is now supported but I don’t think you will be so excited about it :).

About <meter> it seems to be supported, all the content is ignored but nothing is rendered on the screen, so I think it’s a bug.

REMOVED: Datetime input type

Following Google Chrome, now Safari on iOS doesn’t support the datetime input type anymore and it will fallback to text. This type was deprecated in the standard in favor of datetime-local or using two inputs, date and time for the same purpose. The problem is that datetime was compatible with iOS from version 5.0 to 6.1; if you are using it, be careful!

The week input type is still not available, but now instead of falling back to a text input type, it’s rendered a non-interactive control

If you are using a input type=”datetime” you should act immediately as it is now rendered as a text input type.

Seamless iframe

The new boolean seamless attribute for iframes is now available on iOS 7 that will create a borderless iframe in your website. The iframe will not have scrollbars and, by default, it will get the height of the inner content appearing in the website as using the space of any other block element in the DOM.

Page Visibility is the API -webkit-prefixed on iOS 7- to detect when our tab goes foreground and background. You can try a live demo here. XMLHttpRequest 2.0 spec fully compatible means that now we can request ‘blob’ as a response. The Video tracks API was already covered quickly and it allow us to query and navigate through all the tracks and contents on any media element.

The CSS regions API appears as part of the CSS Regions spec (covered later) and is basically the prefixed webkitGetFlowByName function available on every DOM element.

About the Canvas 2D Drawing API, we have now the globalCompositeOperation attribute on the canvas context that allows us to define the blending mode (such as multiply) when drawing different a layer on top of other. We also have a new Path constructor that we can then draw on the canvas’ context allowing us to store these paths for later usage instead of drawing them directly on the canvas.

AirPlay API

The AirPlay API needs some explanation. AirPlay is the wireless streaming solution from Apple that allows some devices to stream content to different other devices, for now usually an Apple TV. While Safari already supported x-webkit-airplay HTML attribute to define if we want AirPlay or not, we couldn’t customize the experience from HTML5 before.

The API allows us to customize the player and get information and events about streaming through AirPlay. Every video element has the eventswebkitplaybacktargetavailabilitychanged and webkitcurrentplaybacktargetiswirelesschanged. They remind us how terrible is the idea of not using underscores, camel case or other technique for event names convention in JavaScript :S. The first event will fire when there is a new AirPlay target -such as an Apple TV- available or it’s not available anymore; and the second when the playback status on one target has changed.

I think webkitcurrentplaybacktargetiswirelesschanged has won the record: the longest JavaScript event name ever.

If there is a streaming target available, we can then offer the user a button to pick the target calling the video webkitShowPlaybackTargetPicker function.

Background execution

If the user is changing tab (Tab selection screen), your code is still executing but the image is frozen

If the user is changing apps (multitasking mode), your code is still executing and the image is updated

If Safari is in foreground but your website is in a background tab, your code is frozen and Safari has a snapshot of your last execution for UI purposes

If Safari is in background your code is frozen

WebSpeech Synthesis API

UPDATE 19/9: I could make this API work, so it is officially supported and working.

The WebSpeech API allow the website to record and transcript audio, as well as synthesize text to voice using internal voices in the operating system.

Safari on iOS 7 includes just the Synthesis API (text to speech) but not the APIs for listening for audio from the microphone. You can query on all the available voices to speak in different languages and on a real device it is returning 36 voices (sometimes you refresh the page and you get 0, a bug I think) using speechSynthesis.getVoices(). In terms of English, you have female voice using en-US and male voice using en-GB. I’m not an expert in voice recognition but I feel that the voices in this API are not the same as Siri that sounds much natural in iOS 7.

To make JavaScript to speak from your website you can use a shortcut version in the default language or you can define different properties as the following examples:

speechSynthesis.speak(new SpeechSynthesisUtterance("Hello, this is my voice on a webpage"));

WebSQL bug

Using WebSQL API will have big issues (DOMException) while trying to create a database bigger than 5Mb. On previous versions, the limit was 50Mb with user’s permission. Because of a bug, when you try to store more than 5Mb the user will get a permission dialog but just for 5Mb only. Even if the user grants you permission because it’s for 5Mb only, you will get an exception trying to get more. It’s a BIG BUG.

Update 19/9: According to tarobomb from New York Times, if you request less than 5Mb when you first create the database and then you try to store more data (up to 50Mb) the proper confirmation dialog will appear (first 10Mb, then 25Mb and finally 50Mb) and you will finally be able to store more than 5Mb.

Update 22/10: This bug is still there on 7.0.3 update.

CSS Support

In terms of new specs supported (mostly webkit prefixed) we have:

Sticky Position

CSS Regions

CSS Grid Layout (not working)

CSS FlexBox

Dynamic Font types

Sticky position

Sticky position is a new experimental feature that allow us to fix an element to the viewport but only when it’s off the visible area (usually after a scrolling action). It’s like mixing position: static with position: fixed when the static position moves the element outside of the visible viewport. If you have more than one sticky element, they will all accumulate in the same area -defining same position properties- creating a nice effect while scrolling similar to native UITableView sections.

UPDATE 19/9: Some reports indicate that this feature was available on 6.1 as well (but the community didn’t get it so I’ll keep it here).

CSS Regions

With CSS Regions -spec proposed by Adobe- we can create magazine-like designs to flow content through different containers. Because of the nature of the screen size we’ll use this new flow mechanism more on iPad websites and webapps.

Selecting content flowing into different regions is not allowed on iOS. CSS Exclusions, a way to define shapes for regions, usually coming as a Regions companion, is not available yet.

CSS Grid Layout

CSS Grid Layout is other layout new spec from the W3C (proposed by Microsoft and already available in IE10). All the new CSS properties (-webkit-grid-X) are there available but I couldn’t enable using display: grid or display: -webkit-grid. I’m not sure if there is a different way to enable it or is it that it’s not ready yet.

CSS FlexBox

The final spec for CSS FlexBox is finally here and it allow us to stop insulting floats and clear everywhere to layout elements horizontally and/or vertically. To use it we should use display: -webkit-flex to a container and apply different properties available

Dynamic Fonts

Dynamic fonts are a new font type available in iOS 7 that adjusts weight, letter-spacing and leading based on current font size to improve legibility. We can take advantage of this new feature from HTML, using new -apple- prefixed constants (maybe because webkit is not going to use prefixes in the future?). We have a big list of constant, such as -apple-system-headline1, -apple-system-body and -apple-system-caption1.

h1 { font: -apple-system-headline1 }
p { font: -apple-system-body }

Other CSS improvements

There is no good news for media queries as resolution attribute is still not supported. Well, there is something new, such as the ability to query on min-color-index and max-color-index that is completely useless :)

We also have some minor updates, including:

Unprefixed CSS Transitions (and the transitionend event).

CSS Clip Path to clip contents based on shapes, including circle, rectangles and polygons

Kerning and Ligatures on fonts are enabled by default

Background properties now gets more compatibility with different values

box-decoration-break: slice/clone

tab-size style

overflow-wrap: normal/hypernate/break-word

support for the units ch and vmax

mask-type: alpha

new ::cue pseudo-element already covered in the video track section

New -webkit-background-composite property (but I couldn’t make it work)

Home-screen webapps

If you are using Home Screen webapps, I have bad news for you: too many bugs are around this platform in this version.

The only good news is now it seems we don’t have any limits for WebSQL Storage when in full screen; we don’t need user’s permission.

Big issues

There are some big issues on home-screen webapps:

Standard dialogs are not working at all, such as alert, confirm or prompt.Update 22/10: iOS 7.0.3 solves this bug

Webapps can’t open an external URI, such as a website in Safari, make a call, open AppStore, etc. Any URI is just ignored.Update 22/10: iOS 7.0.3 solves this bug

If you install more than 4 apps, the home screen will do strange things, such as replacing one webapp with another one. You will start seeing clones of the same webapp. The same happens when you open different webapps at the same time. Just try it on your device: go to app.ft.com, install the webapp; go to pattern.dk/sun, install the webapp; repeat the operation several times and you will see the mess on your home screen. Restarting the device seems to solve the problem.

When in portrait mode and a text input, a select or a date picker is in focus, media queries will honor orientation: landscape and the resize event will fire. This behavior (bug?) happens on home screen webapps and Web Views, but not on Safari.

UPDATE 19/9: If you are using Application Cache and also managing states through hash or other technique, the history object will not keep your navigation history, therefore history.back() will never work and history.length stays in 1 forever. (Thanks to 10+ people who reported this problem!)

UPDATE 19/9: Cookies are not transferred between your website and your webapp when installing the icon on the home screen (for authentication purposes for example). It was working until 6.1 and now it’s not working anymore. (Thanks Joseph Pearson for reporting this; a test suite here.)

Status bar

If you don’t provide any apple-mobile-web-app-status-bar-style meta tag or if you provide one with the default value, the status bar will become black over black, so… just a black area on the screen (on some devices you will see just the battery icon). The user will not see the clock and all the other icons on the status bar. Update 22/10: iOS 7.0.3 still has this bug

The black value works ok but it’s not in full mode as in iOS 7 new style. Lastly, If you are defining the apple-mobile-web-app-status-bar-style as black-translucent it’s not black-based anymore, it’s just fully transparent following the new iOS full-screen mode for apps (previous image, at the right). Unfortunately it seems there is no way to define if our background is clear or dark so we need to test how the icons and clock look like over our background. UPDATE: The text seems to be always white.

In the next picture you can see the default status bar, the black value and the black-translucent value in action on iOS7.

Launch image and multitasking

For the new multitasking system, when having a home screen webapp, the system is using a white image, not the launch image and not the current status of the app for the preview. The only exception is when the webapp is still the active app where you see the right snapshot. In the next example, we can see the Financial Times webapp with a white snapshot even with a correct Launch image and an active execution.

Luckily we don’t have the iPhone 5 bug for home screen webapps anymore that was letterboxing the app (a year after it was found). We don’t need the viewport hack solution anymore.

Native webapp development

If you are developing hybrid (native webapps), such as Apache Cordova (PhoneGap) apps, there are some news for you. First, no Nitro engine yet.

Paginate mode

When using UIWebView for rich content in native apps or for native webapps (hybrids), we can now use a Paginate feature for an ebook reading experience without vertical scrolling (a la Windows 8 app experience). This feature is perfect if on the app we are showing dynamic content, so we can’t pre-optimize it for pagination. We have different Objective-C properties to configure the pagination process. To enable it, we need to use something like:

These properties will convert any HTML document in the web view in pagination mode (divided horizontally in pages).

Other improvements

For native development -not necessarily using Web View- the iOS SDK now includes a JavaScript runtime: JavaScript Core framework providing wrapper Objective-C for standard JavaScript objects. We can use this framework to evaluate JavaScript code and also parse JSON

With a new property of the Web View, we can now have inline playback mode for HTML5 video instead of the default full screen mode

With a new property of the Web View, we can enable autoplay for video when in a native webapp.

There is also a SafariServices Framework that on iOS 7 is useful to programmatically add URL’s to Safari reading list.

Remote debugging

If you have a MacOS and you are used to remote debugging with your iOS, you must update Safari to version 6.1 and iTunes to version 11.1 to have the ability to communicate with an iOS 7.0 device. At the time of this writing, Safari 6.1 is only available as a Preview.

While the abilites inside the debugger are the same as in the previous version the user interface has changed a lot with a much cleaner design.

Not there yet

While the list is big, in this case I will list features that were announced for Safari 7 for Mac but are not there on Safari on iOS:

Web Speech API (it’s there but it’s not working on iOS)

Push Notifications from websites. This will be a great addition to iOS but it will only be on Mac OS.

Background Blend mode

Grid Layout (it’s there but it’s not working on iOS)

Anything else?

Most of the bugs and problems in this post were posted a few months ago in the private forum and lot of people have sent bug reports and ask desperately on the forum for a solution. I can’t believe that Apple can’t give answers to web developers and they are not event executing some basic test suites to detect some API bugs.

Did you found any other API or support? Any other bug? Feel free to add your comments below using any of the options available.

Android Browser, one of the most important mobile browsers out there is an eternal dying piece of software. Android hasn’t evolved its default browser since 2011 and this is affecting HTML5 developers, including Cordova/PhoneGap apps, while Google Chrome is replacing it slowly.

Today Android 4.3 JellyBean update was released and after some testings I can confirm that the browser is still the same as the one with Android 4.0 launched on October 2011. No new APIs, no new support, same bugs and problems.

Just a quick reminder: Android Browser is the default browser in the OS and has no relationship with Chrome or Chromium (well, it’s using a WebKit engine as the base for current Chrome).

According to different sources, Android Browser is fighting the first place with Safari on iOS in mobile web market share. While numbers can differ depending on the source, it’s clear that it’s still part of the two most important browsers.

For example, Akamai Internet Observatory says that around 40% of the whole mobile browsing is done with Android Browser and only 6% with Google Chrome. On the other hand, StatCounter Global Stats says Android Browser is still 30% while Google Chrome only 3%.

Based on StatCounter and Akamai.IO, Android Browser is one of the most used browsers on mobile devices on July 2013

These stats don’t separate Android by OS version, but according to the official Android Dashboard38% of the Android market share is still on Android 2.x. And the Android Browser on this version is still worst: no SVG, terrible performance and less API support.

What about Google Chrome

Google Chrome for Android is leading the HTML5 ecosystem in terms of developer tools, compatibility, APIs and new CSS support. We are very happy with the Chrome team. However, Chrome is available for download only for Android 4.0+ and even on new devices it’s the default browser only on some specific devices. That’s the reason for not seeing Chrome as the main browser for Android users yet.

We know Android Browser will die eventually in the future, but the agony is taking too long so we need a solution in the meantime

How does a dying mobile browser affect us?

No remote debugging: this is a huge problem today

Some specs are implemented with an older deprecated version, such as Network Information and HTML Media Capture

No support for some APIs affecting the kind of apps/games we can develop for it, compared to Safari/Chrome/FF: Server-Sent events, Web Sockets, Web Workers, Rich HTML5 form controls, FileSystem, IndexedDB, Animation timing

No hopes for advanced APIs for the future, such as WebGL, Web Audio, Web RTC or getUserMedia.

Stuck also for native apps

Having to deal with this dying browser means also that we are stuck in terms of the WebView, the native control to create hybrid apps or show HTML content in a native Android app.Therefore, Apache Cordova (PhoneGap) developers have to use this dying engine even on the most modern Android device.

While the Chrome team has announced twice that Chrome Apps for Androids and a ChromeWebView may be available later, we don’t have a solution out there yet.

Compare it with other browsers

In terms of compatibility, Android Browser is far way at this point. Using HTML5 Test, Android Browser 4.0-4.3 scores 297 while Chrome scores 410 and even IE10 on Windows Phone scores 320.

HTML5Test comparison between Android Browser, Chrome and IE10

Internet Explorer 10 for Windows Phone is better than Android Browser

I think we need a solution while Google Chrome gains market. Just waiting for the long agony doesn’t seem a good idea anymore. It’s talking much more time that we all expected.

Google Glass has included a web browser. That means a new device factor for web development and Responsive Web Design. In this post, I’ll make a review of the browser and the HTML5 compatibility in the first version.

All the Google Glass Explorer Edition devices out there received the XE7 update today that includes a web browser for the first time. You can now add the Glass to the list of web screens, such as desktop, tablets, smartphones, feature phones and smart TVs.

Browsing with Glass

For now, the only way to open the browser is to use the Search app with your voice and click on a search result. That means: “ok glass, google, and your search”. If the search result is not invoking any of the rich snippets (such as Wikipedia, weather, flight status) you will get the first 7 Google search result and now you will be able to browse to those websites (next images).

UPDATE 29/8: XE8 update includes the ability of a card on the Glass to include an action that will trigger the Browser. Therefore, we can push information using Glassware and call a URL from there, without the need of a search.

For a future update, I can think of a URL-based QR code reader and a bookmark feature that we can define at the My Glass website.

Webpages are loaded in full-screen mode and there is no browser chrome UI. Using forward and backward gestures we can scroll down and up inside the webpage’s content.

The Browser on Google Glass has no UI and websites are rendered in full-screen mode

The only interaction we can do is to click. To click we need to touch the panel with two fingers; that action will lock a cursor on the screen. While keeping two fingers, moving our head -yes, the head- we will pan the page until get the fixed cursor over the place where we want to click. And then, we can tap to fire a click event.

The last gesture available is swiping forward and backward with two fingers that will trigger a zoom out/in process, emulating a pinch gesture on a smartphone. To pan we repeat the head movement from the last paragraph.

Only actions available besides clicking is “Go back”.

Is it a mobile browser?

Websites are rendered as a smartphone because of its mobile user agent. I can say that reading news and event seeing videos is a nice experience on most mobile websites. Font-size is automatically adjusted for easy reading without enabling a zoom in experience. If your website is smartphone-optimized, it will look properly on the Glass.

The browser is not Google Chrome and it seems to be a based on Android Browser but there are some code from Chromium. API support is consistent with Android Browser 4.x but a window.chrome object exists as in Chromium.

We don’t know yet if we should provide a different design or layout for Glass or not, basically for navigation purposes. For now, the cursor emulation is the only way to navigate between links and, to be honest it’s not so easy to trigger clicks. For now it seems useful just for searching and reading the resulting page with no interaction more than scrolling.

I think in the future we should be able to attach somehow Actions to our website that the user can browse through the touch panel or the voice. We can do this in the future using a JS API or special Meta Tags.

HTML5 Support

We have full support of HTML, CSS and JavaScript, including CSS Animations and XHR calls. In terms of media, Animated GIF, SVG and WebP are supported properly.

HTML5 audio and video playing working on a Google Glass

HTML5 video and audio are fully supported and working properly. We can get into YouTube and play any video on the home-screen or in Google’s search result. We need to remember that today we can’t interact with the website more than scrolling and clicking, so we can’t make a search inside a website or make a log in.

Talking about forms, only checkboxes, radio buttons and drop down menus (select) are suitable as there is no keyboard (unless we attach a Bluetooth keyboard, but who wants to?). Drop down menus will trigger a default Android dialog that doesn’t look too Glassy, so I think it’s not a recommendation from the Glass team. That UI might change in the future or they will remove support for it.

Basic JavaScript dialogs, such as alert or prompt trigger Android dialogs. Remember, no keyboard or voice typing yet so prompt is totally useless.

HTML5Test.com is exposing a score of 287, compared to 298 on Android Browser and 410 on Google Chrome.

HTML5 Test result on the Google Glass XE7 Browser

Performance

About performance, the page doesn’t seem to show on the screen until it has been loaded fully. That means we will see the loading screen for a while. Animations and Canvas performance is not good right now, it seems there is no hardware acceleration as for a Canvas Animation we get just 1 FPS.

Responsive Web Design

In terms of RWD and CSS, the Glass Browser will act as:

a desktop browser (viewport=960px) if no viewport is defined, or

as a landscape smartphone if the typical viewport meta-tag with width=device-width as a value is used.

Because the mobile user agent, typically the mobile website will be delivered with the glass when you have the option.

In terms of Responsive Web Design and Media Queries, these are the values exposed if we have a mobile viewport

device-width: 640px

device-height: 360px

width: 427px

height: 240px

orientation: landscape

-webkit-device-pixel-ratio: 1.5

There is a weird situation here: device dimensions are expressed in physical pixels and viewport dimensions in CSS pixels, because the exposed Pixel Ratio is 1.5. Therefore, to deliver a different layout for a Glass user, we can use@media screen and (width: 427px) {
/* Glass layout */
}
Position absolute works properly, even when moving and panning with our head.

Advanced Viewport management

Glass Browser is honoring the viewport declaration with target-densitydpi=device-dpi that will give us the physical pixels as the CSS pixels (therefore width will expose 640px).

If we define a user-scalable=no viewport, then the zooming behavior with two fingers will be disabled (BTW, it doesn’t seem a good idea).

JavaScript APIs

Let’s start talking about the no’s: There is no Web Storage API (it’s not there) and no Geolocation (the API is there but it’s not working). We do have support for Touch events that trigger only when using the double finger gesture.

The good news is that Device Motion API is there, and we can read accelerometer and gyroscope raw data to do something. That means we can detect if the user is moving the head and do something and I’m seeing nice ideas behind this API, such as automatic scrolling or games using your head as the control.

The most important events to use in our webapp are: click, scroll, devicemotion and deviceorientation.

There are no Voice or Camera APIs yet so we still need more support for making good augmented reality and webapps totally optimized for Glass.

Conclusion

This is just the beginning. We don’t know yet how Glass will change (or not) user’s behavior but it’s always important to be ready. This is the first version of the browser and I’m sure it will have upgrades before going live to the public.

We need a better way to load and manage URLs and a better way to interact with websites using our voice, adding actions and even sharing websites. What do you think?

DISCLAIMER: This post is based on a prerelease version of the software and the hardware. Be careful, the final product might differ from the information listed here.