Mobile browsers may look like desktop browsers, but their behavior sometimes is different and we need to understand them to provide the right user experience. In this post I’ll show you a trick to notify the user about an update while our website is on a background tab.

While on desktop browsers, we can keep multiple running tabs, on most mobile browsers timers (and all JavaScript execution) are paused when the web page left the foreground status.

If you have an iPad, let’s say you have your webmail open in one tab. When you want to browse to another website, you open a new one. That means your email will be frozen for several hours or even days and you will never get updates, until you go back to that tab.

As developers, this raises an important issue: Is there any way to update the content and notify the user while the tab is in the background? As you can see with an iOS device at http://ad.ag/pdtdpw, I’ve found a solution.

UPDATE: The quick explanation on how this hacks works is:
Safari on iOS freezes inactive tabs, but it honors the refresh meta declaration. After a reload, the tab is alive again while it is still in the background. A kind of “background tab resurrection” process.

Updating a background tab on iPad

After making some research and testing, I’ve found a good solution compatible with iPad to notify the user of an update when the tab is in the background: our old friend, the meta refresh.

While it can be an annoying behavior from a user’s perspective when the page is active, the old HTML mechanism allows us to define a meta tag to reload a window automatically every n seconds. Some browsers, such as Safari on iOS, allow us to use this hack to automatically reload inactive tabs and keep them updated:

<!-- Updates the page every 1 minute -->
<meta http-equiv="refresh" content="60">


With this technique, the page will reload on the iPad and the inline scripts and the onload event will be executed in the background tab on every version of iOS. On iOS 5.x no other event or timer will be executed after the onload event until the user goes back to activate the tab. On iOS 6.x timers continue executing even in the background after an automatic refresh.

Refreshing the tab only when in background

The problem is how to remove the reload behavior when the page is the active tab and the user is using our website. Every time we set the content attribute dynamically in the meta tag, the browser starts counting again, so we shift the next reload hit. We can use this idea then to not refresh the page all the time.

To make the trick work on the iPad, we can start a chronometer that will shift the refresh meta tag n seconds on every execution. While the page is still active, our chronometer will be executed and the reload action will be shifted every n seconds. When the page goes onto a background tab, the chronometer will not be fired and the refresh meta tag will trigger, refreshing the page once. From iOS 6.1, after the refresh, the chronometer will continue executing pausing more reloads:

<!-- Updates the page every 1 minute -->
<meta http-equiv="refresh" content="60" id="metarefresh">
<script>
// iPad background tab notification trick
var mr = document.getElementById("metarefresh");
setInterval(function() {
mr.content=mr.content; // Shift the reload operation
}, parseInt(mr.content)/2); // Every 30 seconds in our example
</script>

Creating a background notification

iOS doesn’t support the Web Notifications API as BlackBerry 10, Firefox for Android, Amazon Silk 2.0 and Firefox OS.

Unfortunately, Safari for iPad doesn’t make use of a favicon in the tab UI so our only option is to use the title element to update the UI and capture the user’s attention. Therefore we can change document.title to send information to the user via the tab’s title.

Therefore, if we just execute a chronometer and update the title, it will just work after the background reload. For example:

<script>
var count = 0;
setInterval(function() {
document.title = count;
count++
}, 1000);
</script>

In this example, the counter will start from scratch every time we move the tab to the background as it reloads once. We can use sessionStorage to maintain values between reloads.

Chrome for Android supports background execution directly; therefore these tricks are not necessary. Table 12-1 shows the background execution behavior in different browsers.

What about iPhone?

I’m not sure yet if this is good news or bad news: we can use window.alert from a background tab that was refreshed and it works! And this trick also works on iPhone where there are no tabs but background windows. But be careful, it’s a very intrusive dialog from a background tab or window. If it’s an iPad, changing the title for the tab seems like a better idea.

For iPhone or iPod touch we can then refresh the page and generate an alert dialog if there is something important we want to say. However, there is no way to automatic move the active window to ours; so the alert message should indicate that to see what’s happening the user should move to our window.

Change the title only when in background

In this example, the title is being updated all the time, even when the tab is in foreground. To change that, we need a way to separate foreground from background state after a reload. Without Page Visibility API it seems complicate. I have even tried with Animation Timing API, also known as requestAnimationFrame and even in the background, frames are being fired. At the time of this writing I couldn’t find an easy way to differentiate between foreground state and background after a reload state.

If you find a way, just add a comment in this post.

But it doesn’t work on iOS 6.0 and 5.x!

The previous code works perfect on iPad with iOS 6.1+ but on iOS 6.0 and 5.x it’s a different story. Because timers don’t fire  after the reload, we need a different approach. The approach on iOS <= 6.0 is to just update the title when the page is being loaded and leave the meta refresh make its work every n seconds. In the count example, we can just use sessionStorage.

<script>
var count = sessionStorage.getItem("count")||0;
document.title = count;
count++
sessionStorage.setItem("count", count);
</script>

In this case we don’t have the problem as in iOS 6+ and we can update the title only in the background.

Try it yourself

If you have an iOS device with you, just go to http://ad.ag/pdtdpw

More about tabs

On future posts I’ll continue talking about background tab management for mobile devices, including page visibility detection. If you can’t wait to that time, remember my book Programming the Mobile Web, 2nd edition has +750 pages on the topic :) This is a series of posts I’m publishing based on content extracted from that book.

Google Glass is around the corner it’s time to prepare our services for this new device type. Reading the specs for the first time can be a little overwhelming; therefore I’ll try to make a quick go through the Glass app development process, the mirror API and its HTML5 support.

The new screen

A mobile experience is not a smaller version of a desktop app or website. And a Google Glass app is not a mobile app or website on a transparent background.

If you have a mobile website or a mobile app and you want to support Google Glass, you need to sit down and understand how the device works and what users will expect from an app on it. BTW, a Google Glass app is known as Glassware.

Google Glass is not a mobile replacement; it’s more than a companion. The Glass, not having a cellular connection, needs a phone companion or WiFi to access its heart: the Google cloud. For example, geolocation is provided only if the Glass is paired with an Android 4.x phone.

Important ideas

• Users don’t browse the web on Glass (well, they can ask questions to Google but there is no API for that yet)
• Users don’t install apps, they authorize just Glassware to communicate with the device as we authorize a website/app to access our Facebook/Google+ account
• We need to let the user decide when to access your services and data, we should not force the user to read what we have to say
• Create an specific and optimized architecture for Google Glass
• While everybody thinks on Glass with AR (Augmented Reality), today the device is not offering AR features. We can send contextual information, images and videos to user’s device but we will not augment the reality on user’s vision.
• It’s not a mobile replacement; it’s not a desktop replacement. It’s a new and different kind of device.

Device specs

The first Google Glass device has a high-resolution nHD display 640×360 (one ninth of a full HD) equivalent of a 25″ HD screen from 2.5 meters or 8 feet away. It has a 5MP camera, a bone conduction transducer for audio (that means you don’t need to put earpieces for listening), accelerometer, a touch lateral panel, Bluetooth and WiFi. Check more about technical specs.

No native vs. web discussion

Glassware can be developed only by using RESTful HTTP services. There is no native development or offline apps. Everything on Glass runs over the cloud and if we want to develop Glassware we have to use a server-side platform, such as Java, PHP, Node.JS or Python.

• No Java native development
• No C++ native development
• No HTML5 development (but it supports HTML5 content, later on this)
• No Flash development; just joking here… ;)

A user “installs” a Googleware from our website. Using OAuth 2.0 we will get permission to user’s Glass device that is attached to his/her Google account. Once we have been granted permission, we can now communicate bi-directional with the device through the Google cloud using the Mirror API, an HTTP RESTful-based API. More on how to start using it today, later on this post.

Cards as the main interface

The base of Glass interaction is the card. A card is a piece of content that appears on the Timeline (kind of a Glass’ homepage) when you wake up your Glass using your voice saying ‘ok glass’ or the touch panel. The user can flip between the available cards using the touch panel.

Cards contain information pushed to the device from our servers and this is the most important change from a mobile pushing mechanism: it’s probable that our card will never be seen by the user. And that’s ok. It’s not like a mobile push notification. We push, update and delete cards from our server as many times as we need just for being there with refreshed data if the user thinks it’s time to see the timeline. Therefore, it’s possible that we are pulling a card before the user can really see it because the data became obsolete.

Card will be shown as a timeline (newer to older) but they can be also pinned, so they will always appear on the same place (remember, we can update cards’ content anytime).

Interaction with cards

A card can have menu items attached to a contextual menu tapping on the card so the user can interact with it. Typical system actions include: share, reply, delete, read aloud and pin. These actions have system behavior from the device itself but we can also create our own custom actions. Some actions, such as share, reply or a custom menu item will trigger an HTTP request to our server with the card meta data and the action so we can make things work on our side.

Just to give an example, if we enable the “Reply” menu item action and the user fires it from our card, the user can say something and on our server we will receive an HTTP request from Google’s servers with the original card metadata, the audio file and the transcript text. Cool!

Sharing and suscriptions

Our server can also register on the Glass to be notified of:

• a share action (so users can share other Glassware card with us)
• user’s location (so we can generate or update cards with contextual information)

In terms of sharing we can add a Contact to user’s device, a sharing destination that will appear in users share menu item. We will then receive that share action from any card through the suscription endpoint. It’s a good idea to have a web-based or mobile UI so the user can manage the Contacts that will appear on the device from our Googleware. Remember a contact is not just a person, it can be a group (such as Family) or a generic destination (such as ‘Twitter followers’ or ‘my blog’).

Multilevel cards

Cards can also be bundled in groups, as in a folder in a mobile Home screen menu. In that case, a page curl effect will appear on the front card and the user can “enter” the bundle and then browser all the cards inside. These cards can be inserted, updated and deleted individually.

The other way is to provide one single card with different pages that will also appear similar to a bundle of different cards.

Show me, show me!

To see all these mechanisms working on stage, I suggest you seeing the following YouTube videos:

HTML5 on Glass

A card can be created using:

• Plain text
• Text plus media (image, video or audio)
• HTML5 content

There are several HTML5 templates already available to use that fits perfectly on Glasses’ screens and we can provide our own HTML code.

All the semantic HTML5 elements are supported, including images and tables and it’s not clear yet (I need to wait for a real device here… Google?) what happens with other type of content. Even, the CSS that Glass is using as the default user-agent stylesheet is available.

One nice thing is that apart from using our own images on <img> elements we can access the native maps system using the glass://map URI scheme. This scheme allows us to show a map with optional points and polylines.

<img src="glass://map?w=240&h=360&marker=0;42.369590,-71.107132&marker=1;42.36254,-71.08726" height="360" width="240">

Just remember:

• Follow Glass card UI Guidelines
• The user is not browsing the web, it’s just reading quickly a card
• There is no scrolling: for more details, you can provide a multi-page card or enable a “read aloud” feature that can read more text than the one available on the screen
• Don’t use any JavaScript or interactive HTML element, such as form elements
• Design for a full card of 640×360 with proper margins, using only following font sizes 30px, 34px, 40px, 50px and 70px or a special size for very short messages: 90px;

Glass emulator

While there is no emulator available yet and devices are just being shipped only for Google Glass Explorer (did I say I’m waiting for one? ;)), we can start playing with Glassware with the “Playground“, a card viewer simulator. We can connect Playground with our OAuth client, we can use the HTML5 templates and see how they will look like on the real Glass.

Go and start playing

Google Glass requires to rethink our app or website. Don’t just offer the same services you have on the web and/or on a mobile app. Be smart, simple, accurate and deliver info at the right time without interfering with user’s life.

I can’t wait to get my hands on a real device to feel how useful it might be and to check all we can do with HTML5-based cards.

If you want to start right now playing with the Mirror API, Google is offering APIs for Java, Python, Go, PHP, .NET, Ruby and Dart. Starter Projects are available for Java and Python optimized for being executed on Google App Engine.

And remember, Glassware means just HTTP messages out and in our server-side app, so we can use any platform without using the API helpers from Google.

Official documentation: https://developers.google.com/glass

API and starter projects: https://developers.google.com/glass/downloads

Playground (card simulator): https://developers.google.com/glass/playground

The new BlackBerry Z10 is on sale around the world with a whole new operating system and browser. In this post I’ll go through the important information for web and app developers about one of the most powerful HTML5 platforms available today.

As a BlackBerry Elite developer, I had the opportunity of receiving one of the first public BlackBerry Z10 devices in BBJam Europe in last February. Publishing the second edition of my book Programming the Mobile made me push this post until now. The good news is that if you are a web or an app developer, BB10 is a truly HTML5 first class platform through its completely rewritten web browser and the native web developer platform WebWorks.

First: The platform has nothing to do with previous BlackBerry devices; everything you know about BlackBerry has to be updated. Even the browser doesn’t identify itself as a BlackBerry (more on this later).

In this post, I’ll go through the following topics:

• New devices: BlackBerry Z10 and Q10
• The browser and the native web app platform
• Device detection
• HTML5 support
• WebWorks

New devices

The first device already available on some markets is the BlackBerry Z10, a full touch device that is the first huge evolution in BlackBerry: no physical keyboard.  The second change is the operating system: BB10 is based on QNX and it’s a completely new operating system.

The Z10 includes a multi touch screen with a 1280×768 pixels resolution, touch gestures everywhere and typical modern sensors: accelerometer, gyroscope, magnetometer, lightning and proximity. I’ve made my entire test using a final Z10 device (the developer edition).

The second device -the BlackBerry Q10- was announced. It will be a device with a QWERTY physical keyboard and a square screen of 720×720 pixels. An experimental Alpha Device C is already available to developers emulating the Q10 factor. That’s the other device I’ve used for this post.

If you want to try test your web and apps without a device, BlackBerry offers a free virtual machine that includes the full browsers inside the Z10 and the Q10 (beta). You can download the emulators for free.

The Browser and the native web app platform

The default browser on the BlackBerry 10 platform is a completely new app mostly created form scratch based on the WebKit engine. One of the key features of the browser is that is an HTML5 application. Again, the browser was completely written in HTML5 using HTML, CSS and JavaScript and wrapped as a native app.

The BB10 browser is one of the most advanced default preinstalled browsers on the mobile space, because of its performance and HTML5 compatibility. It’s the first default browser passing the Ringmark Level 1 test. And it even supports half of the Level 2 requirements.

BlackBerry also has brought HTML5 to the front through its native web app platform known as WebWorks. With WebWorks we can package and compile an HTML5 app and distribute it through the store AppWorld. On a WebWorks app we can take advantage of more advanced native-like API to get access and interact with the operating system.

If you create native apps with the Cascades framework (based on Qt) you can also use a Web View to create a hybrid app.

Device detection

I’m not suggesting that we should use device detection. However, it’s important to understand how the browser identifies itself and how can we detect it for some specific situations.

The user agent on the Z10 looks like

Mozilla/5.0 (BB10; Touch) AppleWebKit/537.10+ (KHTML, like Gecko) Version/10.0.9.2372 Mobile Safari/537.10+

Where is the BlackBerry word? Nowhere. The browser’s developers were forced to remove the “BlackBerry” keyword from the user agent because lots of websites -mostly from non-updated old CMSs and “mobilizers”- were just delivering a crappy website or even a WML website when a device identifies itself as “BlackBerry”.

Trying to start from scratch they use just the keyword BB10 to identify the platform. Unfortunately BlackBerry seems to be following Mozilla’s idea of not identifying the device model in the user agent.

Client-side detection can be done looking for the word “Research in Motion, Ltd.” in navigator.platform (even when the company is not called RIM anymore). We can detect the Q10 form factor (square screen) using media queries:
@media (device-aspect-ratio: 1/1) {
/* It's the BlackBerry Q10 */
}

HTML5 support

The BlackBerry 10 browser supports a big list of APIs as we can see in the updated Mobile HTML5 table. It has one of the highest scores in HTML5Test.com (485 points) and lot of un-prefixed CSS abilities, including some features that are still prefixed on other WebKit-based browsers. Besides typical modern HTML5, CSS and JavaScript support on other mobile platforms, BlackBerry 10 Browser includes:

• FullScreen API
• WebGL
• Media and Stream API (also known as getUserMedia) for live camera access (see image below)
• IndexedDB
• Web Notifications API (partially)
• FileSystem and File API
• W3C Touch events
• HTML5 Form input controls (even type=color)
• HTML Media Capture
• Network Information API (latest version, different from Android Browser implementation)
• Vibration API
• Animation Timing API
• Touch icon support through apple-touch-icon link element (150×150 pixels)
• Battery Status API
• Performance Timing API
• WebRTC preliminary support
• Non-standard Extensions, such as text-overflow: -blackberry-fade

Background execution

When the browsers get minimized, every website freezes so our JavaScript code won’t be executing. When the tab is being minimized and the user continues with the browser in foreground, our website continues execution but timer frequencies lower to 1 second. Remember for performance purposes we can use the Page Visibility API and the Animation Timing API. While in a background tab our page can also deliver web notifications (see bug consideration later in this post).

Home Screen

The BB10 Browser supports the apple-touch-icon link element as the icon to use when users add a site to the Home Screen but it seems to ignore the sizes attribute. Standard BB10 icons are 150×150 pixels and PNG is recommended.

<link rel="apple-touch-icon" href="icon150.png">

While the browser is not working full-screen (no support for webapp meta tag) the navigator.standalone boolean value is exposed so it might be possible that a full screen webapp mechanism through a meta tag will be available soon (as in Safari on iOS, MeeGo and Symbian).

Responsive Images and Pixel density

BlackBerry Z10 exposes a device pixel ratio of 2.2437500953674316 and BlackBerry Q10 a value of 2.075000047683716. Therefore BB10 remembers us how important is to query about pixel ratio ranges and not integer values. Lot of websites are just querying about pixel ratio=2 because iOS high-resolution devices are using that value.

If you are using media queries to provide high resolution versions of your bitmap images, you can use for BB10
@media (-webkit-min-device-aspect-ratio: 2) {
/* It includes any device with a pixel ratio >= 2 */
}

Viewport and pixel density

When using the viewport meta tag with width=device-width, BB10 will expose a 320px virtual viewport on all devices, maintaining the iOS standard. It’s important to understand that the BB Q10 has no landscape orientation (and remember, it’s a square screen anyway).

Comparison

Compared to Google Chrome for Android, the BlackBerry 10 browser supports a more HTML5 APIs. Compared to Safari on iOS 6, it supports more APIs and the only missing API is Web Audio that was included in iOS 6.

Debugging

BlackBerry 10 browser includes a full remote web inspector over HTTP (that is, connect your device to the same WiFi network as your desktop computer). Just enable it from the browser’s settings menu and you will get the URL to access it from a desktop browser. Just remember that anyone with that URL will be able to see and interact with your current opened sessions.

Bugs

The Web Notifications API works, we can get user’s permission and deliver notifications. The device will show the notification on the Browser (red star) but there is no way to see the notification’s content or to understand which tab has generated the notification. The Web Notifications don’t appear to communicate with the Hub (the app that manages system notification on BB10).

CSS Regions spec seems to be there in the DOM, but I couldn’t make it work so I believe it’s a bug.

I’m quite confident that BlackBerry will solve these bugs in a future OS update.

WebWorks

Using WebWorks to compile the app as native webapp, we have access to all the HTML5 APIs plus a series of platform specific APIs, as:

• BlackBerry Messenger
• Invoke
• In-app Payments
• Phone and Calls
• PIM
• Push
• User Interface specifics, such as Toast notifications and Cover customization (update the snapshot when the app is minimized)

Once compiled and signed, you can distribute and sell your HTML5 WebWorks app on the store (AppWorld). It’s great to see a platform supporting first-class HTML5 apps from the ground.

Wrapping up

A browser created using web technologies is another great example of what HTML5 can do on today’s smartphones.

BlackBerry 10 Browser is a good example of what developers expect from a good mobile browser: hardware APIs, good performance, easy to use debugging tools, good documentation and a way to create webapps outside of the browser. We will always expect better support but the BlackBerry 10 default browser had an excellent start.

If you want to know more about every HTML5 API listed in this post, check my last book Programming the Mobile Web, 2nd edition.

As you may know, the iPad mini is a new 7.9″ variant of the iPad tablet and one of the biggest questions out there today is how to detect it using server-side or client-side techniques.

I have bad news for you: it seems impossible.

Two days ago, I’ve tweeted about the first detected problem: “It is confirmed that the iPad Mini User Agent is the same as the iPad 2“. I’ve received literally hundreds of answers saying that user agent sniffing is a bad practice, that we should detect features not devices, etc, etc.

Well yes guys, you are right, but it has no direct relationship with the problem. And I need to add the second bad news: there is no client-side technique to make  ”feature detection” neither.

Why do we need to detect the iPad mini in first place

The iPad Mini has no Retina display -the name that Apple gives to high resolution devices- and it’s an iPad 2 clone in terms of resolution: 768×1024 pixels. The biggest difference is that while iPad 2 is 9,7″; the iPad mini is 7,9″.

While it’s true that the difference between iPad 2 and iPad mini (1.8″ or 4.57cm diagonally) is not so big compared to other series (Nexus 7 and Nexus 10 difference is 3″), we need to understand that everything looks 19% smaller on the iPad mini, including text and touch areas. (Update: real demo of this difference)

Ok, you are right; we don’t really need to care about iPad mini vs. iPad 2 in terms of the device itself, but we do need to care about the dpi difference. Designers should want to make some things larger so they can be read properly, or to make touchable areas larger to avoid usability problems.

Second reason is analytics: some companies want to store information about user’s devices to make some decisions and in this case tablet size and factor, or device release date may be something useful. I know this is not a big problem, but it still sounds like an issue for some website and app owners.

How to detect a feature or a device

There are several mechanisms to make feature and device detection and it’s a long story. I have a full chapter on this topic in the second edition of my book Programming the Mobile Web (available today as a prerelease draft version).

We should always prefer feature detection against device detection; but on some specific situations device detection is the only way to go.

When talking about server-side detection, the User Agent and/or device libraries, such as ScientiaMobile’s WURFL is the way to go. The User Agent thing is a mess and there is no simple rule to follow and, when a company like Apple decides to user the same User Agent for all devices, there is no server-side only solution that can help us. In this particular case, all the iPads out there, from the first to fourth generation and the iPad Mini uses the same User Agent. The only difference is the iOS version that they have.

I know many of you are thinking: I don’t care about server-side detection, a good practice following RWD – Responsive Web Design- principles is to use media queries or at least JavaScript to detect features. Well, the big bad news appears: there is no way to detect iPad mini unique features (dpi, screen size in inches/cm). Let’s see why.

Using resolution media queries

CSS3 Media queries includes a resolution attribute that we can query on. The iPad Mini has a 163 dpi resolution screen while iPad 2 has 132 dpi. Great! We have the solution… well, the resolution attribute is not available con WebKit-based browsers, such as Safari on iOS. No way to use it.

Using device pixel ratio

After that, we think on a non-standard media query extension: the device pixel ratio. High-resolution iPads expose a 2 value from both media queries and JavaScript for the device pixel ratio. Well, iPad Mini and also iPad 2 both expose a value of 1; so we can’t rely on this property neither.

Using inches or centimeters units

The other solution about dimensions in in (inches) or cm (centimeters). Well, trying to draw a 10 inches element on the screen, such as in width: 10in; I’ve got same results on both devices (that is, on the iPad mini the div is 19% smaller).

UPDATE: In the CSS3 spec, inches or centimeters units might not match the physical size if the anchor unit is the pixel. Therefore they are useless on these devices.

Both iPad 2 and iPad mini exposes same device-width and device-height in inches and centimeters (it’s matching the pixel values) while we know that is completely false. The following media query is true for all the iPads:

only screen and (min-device-width: 8in)

And the iPad Mini has a device width smaller than 5.3 inches, so the query should be false in a first quick thought.

And with font size and font adjustment, the results are also exactly the same. There is no special text adjustment for the iPad mini and it’s using the same values.

If you want to try the media queries values yourself visit mediaqueriestest.com or m.ad.ag from your mobile device.

Apple… why?

I know some of you will find some obscure reasons, but the official reason is to reduce iOS fragmentation. From a developer and designer perspective we have only two devices: iPhones (including iPod touch) and iPads. That’s all you need to know from an Apple perspective to design and develop a website or an app. While is not a bad idea in a first thought, the iPad mini has a different screen size and that should be honor by the media queries at least.

To make a final conclusion, the problem is not that we can’t detect iPad mini; the problem is that we can’t detect its unique features, such as density and real dimensions that are important for delivering the best possible experience one ach device using responsive web design techniques.

Solutions?

UPDATE: People were asking by Twitter how to deal with this. Well, I can only think on some suggestions:

1. Don’t disable zoom ability in the viewport metatag, such as in user-scalable=no.
2. If you have text offer the user the ability to increase and decrease font size and store the settings in Local Storage or a cookie for next visit. It can be easily implemented using JavaScript and you can change font-size or -webkit-text-size-adjust.

PS: Don’t get me wrong… I’ve tried the iPad mini and I like it; it feels good and the screen is much more useful than other 7″ similar tablets.

October 26^th 2012 is the big day for Microsoft: the launch of Windows 8, Internet Explorer 10 and the Microsoft’s tablet: the Surface. From an OS and an HTML5 point of view, it’s a really big step for Microsoft and for all web developers (even non-mobile) . Let’s review what’s important for us.

I will start with some bad news: you need to go and prepare your websites for the new ecosystem.

Even if you have only a desktop-optimized website, you need to go and prepare it. And if you are thinking: “hey, this will not affect my mobile site because it’s just for tablets” you are wrong.

Part of the content of this post are from my book “Programming the Mobile Web, second edition” to be published soon.

Overview

In this post, we will cover:

• Microsoft Surface tablet
• Internet Explorer 10 modes
• Flash Player
• HTML5 compatibility
• CSS3 compatibility
• Snap mode and the viewport problem
• Server-side identification
• Pinned sites
• Tablet Simulator
• Store app integration
• Windows Store HTML5 Apps

Microsoft Surface tablet

Windows 8 will work on different kind of devices starting in just a few days; it will available as a Windows XP/Vista/7 update for desktop and many new desktop and notebook computers will start shipping with it. However, in this blog, I’m more focused on mobile devices and the Microsoft Surface is probably the first mobile device with this operating system.

Other hardware vendors are also starting to ship Windows 8 tablets but the Microsoft’s one will be like a key device in this environment.

First, it’s important to understand that Windows 8 is available in RT version and in a more classic version. The RT version works only on ARM-based devices, such as most tablets. The other version (available in many editions, such as Pro) is for Intel-compatible devices.

The Surface tablet is available both in RT and Win8 Pro versions, being the latest not available at the time of this writing. Why is this so important? The RT version doesn’t include the full desktop mode and that means, no classic windows, no desktop browsers that can be used. UPDATE: RT version do have a desktop mode but it runs only Microsoft apps, not x64 or x64 apps, such as other browsers.

Desktop users, and Windows 8 Pro tablets users will be able to install any Windows-compatible browser, such as Google Chrome, Firefox or Opera. However, they might not be optimized for touch-enabled browsing.

The Surface is a wide-screen tablet (16:9) with a medium density screen of 1366×768 pixels. The RT version support 5 simultaneous touches and it has typical tablet sensors, such as accelerometer, gyroscope and magnetometer.

On the RT version only apps in the Windows Store can be installed/purchased. Windows Store apps (previously known as Metro apps) can be developed using .NET or HTML5 and must follow store rules. In terms of limitations and feature access, we can say that it’s kind of similar to iPad. It’s not the same, but you are not getting access to anything you want as in classic Windows development.

While Firefox is working on a Windows Store app version of the browser, it’s not clear to me if it’s going to be approved in the store or not. It may be just a touch-enabled mode for non-RT devices (that can install apps without the store).

Internet Explorer 10 modes

On Windows 8 RT including the Surface tablet, the browser can be running in three modes:

1)   Landscape or portrait: IE10 is the only foreground active screen. On portrait the default viewport is 1024px.

2)   Snap mode: it’s sharing the active screen with some other Windows 8 Store app and the browser is snapped (right or left) using just a small portion of the screen (always same size). It only works on landscape mode and when the device has at least 1366px width.

3)   Fill mode: it’s sharing the active screen with some other Windows 8 Store app in snap mode and the browser is talking 3/4 of the screen (filled). It only works on landscape mode and when the device has at least 1366px width.

On desktop mode, you can use a non-touch optimized Internet Explorer 10. That mode is the IE that we are used to. Internet Explorer 10 on desktop mode is available on both RT and non-RT versions of Windows 8.

Flash Player

Flash Player? What is that? :) Jokes apart, you believe you are in a desktop world with IE10 and you are not. Remember, “desktop meets mobile web”. Internet Explorer in desktop mode will support as much plugins as you want including Flash Player.

Most tablets, including the initial Surface, will use Windows 8 Store mode and that means no plugins, no Flash, HTML5 only. Well, that’s not completely true but your life will be much easier if you believe in that. Today, a week before Surface appears on the market, I don’t have any clear answer to know if it will include Flash Player or not.

However what I do know is that, if the device includes a Flash Player, IE10 on Windows 8 store mode (ex-Metro mode) will have it disabled by default. If you are not using a restricted API you can send an e-mail to Microsoft so they can white-list your website so Flash movies will work on your website. As weird as it sounds, you need to send an email to be white-listed. If not, you can add a meta tag or an HTTP Header so Windows 8 store Internet Explorer will suggest you to move to desktop mode. Too complex in my opinion.

HTML5 Compatibility

Some good news! If we compare IE9 and IE10 I believe it’s one of the biggest steps from one version to the next one in the browser history. I know, they’ve taken 19 months to upgrade IE9.

IE10 supports:

• New form input types and validation API (excepting date-related ones and color)
• Application Cache
• Web Sockets
• Web Workers
• History
• Drag and Drop
• XHR 2
• File API
• IndexedDB
• Page Visibility
• DeviceOrientation
• Touch, Pointer and Gesture APIs (non-standard)
• Animation Timing API (aka requestAnimationFrame)

If we compare it with Safari on iOS6, IE10 doesn’t have Web Audio and Web SQL (and it’s not going to add it in the future in favor of IndexedDB).

CSS3 compatibility

In terms of CSS3, IE10 has reached other browsers and in some situation has passed them with the addition of some experimental standards. IE10 is one of the first browsers supporting unprefixed well-known features, such as animations or transitions and it uses -ms- for other experimental styles.

IE10 supports:

• CSS Animations
• CSS Transitions
• CSS 2D and 3D transforms
• CSS Fonts
• CSS Gradients
• CSS Device Adaptation (viewport definition through CSS)
• CSS Exclusions
• CSS Flexible Box (aka FlexBox)
• CSS Grid Layout
• CSS Multi-column layout
• CSS Regions
• CSS Filter Update: it’s just SVG Filter support, CSS Filters are not supported.

Snap mode and the viewport problem

As we saw before, our website can be browser in IE10 snap mode. And as you can see, IE10 maintains a default 1024px viewport if the current browser window is narrower than that width. Therefore every, again, every website today will be zoomed out by default as seen in the picture.

With the snap mode, desktop meets mobile web because every website should now have a similar mobile view for IE10 snap mode, even for desktop devices.

If your website has a responsive design and will automatically work properly on a narrower screen, you can use the following viewport declaration
@-ms-viewport { width: device-width; }

To make our lives even stranger device-width will not be device’s width when in snap mode but the current window width.

If your website is not responsive and you want to provide a snap view mode you can define your own viewport mixed with some media queries as the following example:

@media only screen and (max-width: 400px) {
@-ms-viewport { width: 320px; }
}


Using 320px as a viewport will match most mobile device-width values, such as Safari on iPhone. I have a full explanation of this on my book (too much space to cover it in this post) and you can check Tim Kadlec great post.

Server-side identification

While you can use feature detection for most situations, sometimes server-side detection is necessary. The User Agent will never include hardware details. So we don’t know if we are on a Surface or other vendor’s tablet.

We can search for Windows NT 6.2 to know we are on Windows 8, the Touch keyword will be there on touch devices and the ARM word will be on Windows 8 RT devices.

Pinned sites

We can pin websites to the Start Screen and customize its appearance defining our own tile icon and the background image.

To do so we use the msapplication-TileImage and msapplication-TileColor meta tags:

<meta name="msapplication-TileImage" content="tile.png">
<meta name="msapplication-TileColor" content="#ef0303">


The tile image should be a 144×144 PNG file, with a preferred transparent background and the tile color accepts a CSS color as a value that should be the main color of your logo or visual presence. We can use hexadecimal RGB values (such as #333333), named values (such as red) or using CSS functions, such as rgb. If you don’t provide a color, IE will take it from the most prominent color of your website icon or your tile image. The color and icons are also used in history search and other places inside Internet Explorer.

To combine with other icons, you can use just a white or black small icon over a plan color instead of a big colorful image. IE10 tile size 144×144 is the same as the iPad high-resolution icon size. However, be careful using the same icon for both platform as the idea of how they are being rendered on the screen is really different.

Internet Explorer 10 will use your current title page for the tile. If we want to define a different one, we can use the title meta tag.

<meta name="title" content="Tile title">

Live badge notifications

Of the big advantages of tile icons in Windows is the ability to update a badge number in the Start screen, so it becomes a Live Tile. Internet Explorer will poll for updates for pinned sites if we provide the right details.

First action is to create a badge XML, a really simple XML file that defines current badge number value to show inside the Tile. Of course, we can make a dynamic XML file.

The XML looks like

<?xml version="1.0" encoding="utf-8" ?>
<badge value="5" />

And then, we define using a msapplication-badge meta tag, the badge meta data, including frequency, and badge XML URL.

<meta name="msapplication-badge" content="frequency=1440; polling-uri=http://mysite.com/badge.xml">

Tablet simulator

If you install Windows 8 on a desktop computer, Intel-based tablet or notebook, you can test most of the features of IE10. You can download a preview version for developers at http://windows.microsoft.com/en-US/windows-8/release-preview.

However, for some situations, such as gesture events, orientation changes, etc. tablets and the RT version may be different.

We can install a Windows Simulator that works only on Windows 8 and acts like a generic tablet device. You can download it for free included with Visual Studio Express for Windows 8.

The Simulator allows us to emulate:

• Mouse, pointer or touch events
• Gestures
• Device rotation
• Geolocation
• Different screen resolutions

Store app integration

If you have a Windows Store app (on Windows 8) you can connect your website to it with some meta tags. Internet Explorer will show a menu as shown in next image so the user can quickly get the app from the store if it’s not already installed. If the app is installed then the menu changes to Switch to <name> app.

If you are thinking on the similarities between this feature and Smart App Banners on iOS 6, you are right. However, Microsoft has announced this feature before Apple.

There are five meta tags that can be defined in our website for this connection.

• msApplication-ID: Mandatory. The identification that is defined in the application manifest.
• msApplication-PackageFamilyName. Mandatory. Package family created by Microsoft Visual Studio to identify the app.
• msApplication-Arguments. Optional. String that is going to be passed to your app. If we don’t provide this meta information, Internet Explorer will pass the current URL automatically.
• msApplication-MinVersion. Optional. Enforces a minimum version of your app. Therefore, if your user has an older version when she tries to switch to the app, she will be first sent to the store to update it.
• msApplication-OptOut. Optional. Allow our HTML document to not use the connection on some situations. Possible values are: install that will prevent the installation invitation if it’s not installed, switch that will prevent the switch invitation if the app is installed and both.

The Windows Store App can be created using HTML5, C++, C# or Visual Basic and it must be approved by Microsoft on the store using a Publisher account.

To show you an example Cut the Rope is an addictive game available on many mobile platforms -such as iOS and Android- and they are offering an HTML5 version available -sponsored by Internet Explorer 10- online at http://cuttherope.ie. The game is also available as a Windows Store app so to offer the functionality seen on the figure they are using the following meta tags.

<meta name="msApplication-ID" content="App"/>
<meta name="msApplication-PackageFamilyName"
content="ZeptoLabUKLimited.CutTheRope_sq9zxnwrk84pj"/>

Remember you can find this info and more details on this and other stuff around mobile web on my book.

Windows Store HTML5 Apps

Using HTML5 and Visual Studio we can create native apps that can be distributed through the Store. The HTML5 engine uses all of the IE10 engine and much more. When in HTML5 App, we have other API, other possibilities and styles from CSS and some specifics to native app, as working with native controls using just divs.

Conclusion

IE10 is the biggest step in Microsoft’s web life. Finally, IE meets modern HTML5 and it will make a change in the web world, as desktop or classic web meets mobile. Responsive sites will be more important in a world where users want our content anywhere. Just keep in mind that performance is one of the key issues of responsive sites; just be careful.

What do you think? Anything else that you believe I’ve not added in this list? Comment below.

The new main version of the Apple’s iOS is with us, along with the new iPhone 5 and the iPod Touch fifth generation. As every big change, lot of new stuff is available for HTML5 developers and -as always- no much official information is available.

Quick review

I’m going to divide this post in two parts: iPhone 5 and iOS 6 new stuff.

On iPhone 5:

• New screen size
• New simulator
• What you need to do
• Problems

New features on iOS 6:

• File uploads and camera access with Media Capture and File API
• Web Audio API
• Smart App Banners for native app integration
• CSS 3 Filters
• CSS 3 Cross Fade
• CSS Partial Image support
• Full screen support
• Animation Timing API
• Multi-resolution image support
• Passbook coupons and passes delivery
• Storage APIs and web app changes
• Web View changes for native web apps
• Debugging with Remote Web Inspector
• Faster JavaScript engine and other news

iPhone 5

The new iPhone 5 -along with the iPod Touch 5^th generation- has only one big change in terms of web development: screen resolution. These devices have a wide 4″ screen, WDVGA (Wide Double VGA) 640×1136pixels, 326 DPI -Retina Display as Apple called it. These devices have the same width as iPhone 4/4S but 176 more pixels-height on portrait mode.

New simulator

The new Xcode 4 (available on the Mac AppStore) includes the updated iOS Simulator. The new version has three options for the iPhone simulation:

• iPhone: iPhone 3GS, iPod Touch 1^st-3^rd generation
• iPhone Retina 3.5″: iPhone 4, iPhone 4S, iPod Touch 4^th generation
• iPhone Retina 4″: iPhone 5, iPod Touch 5^th generation

The new simulator also includes the new Maps application replacing Google Maps by default and Passbook.

What you need to do for the new devices

Usually, if your website/app is optimized for vertical scrolling, you should not have any problem. Same viewport, icons and techniques for iPhone 4/4S should work properly.  Remember, when updating the iOS, you are also updating the Web View: that means that all the native web apps -such as PhoneGap/Apache Cordova apps- and pseudo-browsers such as Google Chrome for iOS are also updated. However if your solution is height-dependent, then you may have a problem.Just look at the following example of the Google Maps website on iPhone 4 and iPhone 5. As it is talking the height as a constant, the status bar is not hidden and there is a white bar at the bottom.

If you are using Responsive Web Design you should not have too much trouble as usually, RWD techniques are using the width and not the height for conditionals.

Device detection

At the time of this writing there are no iPhone 5 on the street yet. However, as far as every test I could check, there is no way to detect iPhone 5 server-side. The user agent only specifies an iPhone with iOS 6, and the same exact user agent is being used for iPhone 4S with iOS 6 and iPhone 5.

Mozilla/5.0 (iPhone; CPU iPhone OS 6_0 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10A403 Safari/8536.25

Therefore, the only way to detect the presence of a 4″ iPhone device is to use JavaScript and/or media queries, client-side. If you need to know server-side, you can plant a cookie from client-side for next load. Remember that these devices have 1136 pixels height, but in terms of CSS pixels (independent resolution pixels) we are talking about 568 pixels-heightas these devices have a pixel ratio of 2.

isPhone4inches = (window.screen.height==568);

Using CSS Media Queries and Responsive Web Design techniques,we can detect the iPhone 5 using:

@media (device-height: 568px) and (-webkit-min-device-pixel-ratio: 2) {
/* iPhone 5 or iPod Touch 5th generation */
}


Home Screen webapps

For Home Screen webapps the problem seems important. I’ve reported the problem while in NDA without any answer from Apple yet.

Basically, when you add a website to the Home Screen that supports apple-mobile-web-app-capable meta tag, your webapp works only in iPhone 3.5″ emulation mode (it’s not taking the whole height) as you can see in the following example from the Financial Times webapp.

While it’s a good idea to not add more height to a webapp if the OS is not sure about it’s compatibility on a wider screen, as far as I could test, there is no way to define that our webapp is 4″ compatible. I’ve tried as many combinations as I could think about, and if you provide an apple-touch-startup-image of 640×1096, the iPhone 5 takes your splash screen but it’s being resized to 640×920, at least in the Simulator for the GM compilation (almost the final version).

UPDATE 9/20: Solution found, thanks to some guys that were pointing to some solutions I;ve found the trick. As weird as it sounds, you need to forget about the viewport with width=device-width or width=320. If you don’t provide a viewport, it will work properly. The same if you use other properties than width; if you don’t want your viewport to be the default 980px, the way to do it is:

<meta name="viewport" content="initial-scale=1.0">

Even if you use a viewport for an specific size different than 320 letterbox will not be present.

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

Instead of changing all your viewports right now, the following script will make the trick changing it dynamically:
if (window.screen.height==568) { // iPhone 4"
document.querySelector("meta[name=viewport]").content="width=320.1";
}

The startup image has nothing to do with the letterbox as some developers were reporting. Of course, if you want to provide your launch startup image it has to be 640×1096 and you can use media queries to use different images on different devices. Some reports were saying that you need to name the launch image as in native apps “Default-568h@2x.png” but it’s not true. You can name it however you want. The sizes attribute is completely ignored.

You can use media queries to provide different startup images:

<link href="startup-568h.png" rel="apple-touch-startup-image" media="(device-height: 568px)">
<link href="startup.png" rel="apple-touch-startup-image" sizes="640x920" media="(device-height: 480px)">

If you want to provide an alternative version for low resolution devices then you can use the -webkit-device-pixel-ratio conditional too. If you are wondering why 568px and not 1136px remember that we are using CSS pixels and in these devices the pixel ratio is 2.

The trick is the viewport. Why? I don’t really know. For me, it’s just a bug. But it’s the only solution I’ve found so far.

The other problem is with Home Screen icons that you are already have before buying your new device. iTunes will install the shortcut icon again from your backup and it’s not clear if we are going to have a way to upgrade the compatibility. Even if you change the viewport, if the icon is already installed before the change you will get the letterbox.

iOS 6 and HTML5 development

iOS 6 is available as a free update for every iOS 5 device but not the iPad first generation so we will see this version browsing the web really soon and the iPad market is being fragmented for the first time. The following findings are useful for all iOS devices that are talking the iOS 6 upgrade. As always -and unfortunately- Apple is giving us just partial and incomplete updates on what’s new on Safari and I -as always- enter the hard work of digging into the DOM and other tricks to find new compatibility.

File management

<label>Single file</label>
<input type="file">

We can also request multiple files using the HTML5 new boolean attribute. In this case, the user can’t use the camera as a source.
<label>Multiple files</label>
<input type="file" multiple>

There is no way to force the camera, as using capture=”camcorder”. However, we can specify if we want to capture images or videos only, using the accept attribute.

<input type=file accept="video/*">
<input type=file accept="image/*">


There is no support for other kind of files, such as audio, Pages documents or PDFs. There is no support for getUserMedia for live camera streaming.

What you can do with the image or video after selected?

• Send it using multipart POST form action (old-fashion upload mechanism)
• Use XMLHttpRequest 2 to upload it using AJAX (even with progress support)
• Use the File API that is available on iOS 6 that allows JavaScript to read the bytes directly and manipulate the file client side. There is a good example of this API in action on HTML5Rocks.

Web Audio API

HTML5 game developers should be happy! Web Audio API appears on a mobile browser for the first time. This API allow us to process and synthesize audio on JavaScript. If you have never played with some low level audio, the API may seems a little weird, but after a while is not so hard to understand. Again, HTML5Rocks has a great article to begin with the Audio API.

More information and news on the API on http://www.html5audio.org

Smart App Banners

Website or native app? If we have both, now we can join efforts and connect our website with our native app. With Smart App Banners, Safari can show a banner when the current website has an associated native app. The banner will show a “INSTALL” button if the user doesn’t have the app installed or a “VIEW” button to open it if installed. We can also send arguments from the web to the native app. The case is to open the native app on the same content that the user were seeing on the web site.

To define a Smart App Banner we need to create a meta tag, with name=”apple-itunes-app”. We first need to go and search for the app we have on iTunes Link Maker and take the app ID from there.

<meta name="apple-itunes-app" content="app-id=9999999">

<meta name="apple-itunes-app" content="app-id=9999999, app-argument=xxxxxx">
<meta name="apple-itunes-app" content="app-id=9999999, app-argument=xxxxxx, affiliate-data=partnerId=99&siteID=XXXX">

The banner takes 156 pixels (312 on hi-dpi devices) at the top until the user click on the bottom or on the close button and your website will get the full height for you. It acts like a DOM object at the top of your HTML but it’s not really on the DOM. On iPad -and more on landscape- it seems a little space-wasting.

During some seconds, the banners shows a “loading” animation while the system is verifying that the app suggested is valid to the current user’s device and App Store. If it’s not valid, the banner hides automatically; for example, it’s an iPad-only app and you are browsing with an iPhone or the app is available only on the german App Store and your account is in US.

CSS 3 Filters

CSS 3 Filters a set of image operations (filters) that we can apply using CSS functions, such as grayscale, blur, drop-shadow, brightness and other effects. These functions will be applied before the content is rendered on screen. We can use multiple filters using spaces (similar to transforms).

You can try a nice demo here. A quick example of how it looks like:

-webkit-filter: blur(5px) grayscale (.5) opacity(0.66) hue-rotate(100deg);

CSS 3 Cross-fade

iOS 6 start supporting some of the new CSS Image Values  standard, including the cross-fade function. With this function, we can apply two images on the same place with different levels of opacity and it can even part of a transition or animation.

Quick example:
background-image: -webkit-cross-fade(url("logo1.png"), url("logo2.png"), 50%);

Full screen in Safari

Besides the chrome-less home screen meta tag, now the iPhone and iPod Touch (not the iPad) supports a full-screen mode when in landscape. This is perfect for immersive experiences such as games or multimedia apps. There is no way to force full-screen mode and it needs to be launched by the user (last icon on the toolbar). However, we can invite the user to move to landscape first and press on the full-screen icon to activate our app. If we mix this with some touch event handling we can hide the URL bar and provide a good interface until the user escape from the full-screen.

You will always find two or three overlay buttons at the bottom that your design should be aware of, that’s the back button, the optional forward button and the cancel full-screen.

You can use the onresize event to detect if the user is changing to full-screen while in landscape.

Animation Timing API

Game developers, again, you are lucky. iOS 6 supports Animation Timing API, also known as requestAnimationFrame, a new way to manage JavaScript-based animations. It’s webkit prefixed, and for a nice demo and more detailed explanation check this post from Paul Irish.

CSS Image Set

This is not part of any standard group yet. It’s a new image function, called image-set receiving a group or images with conditions to be applied. The only compatible conditions right now seems to be 1x and 2x for low density devices and high density devices. With this new function we don’t need to use media queries to define different images for different resolutions. The working syntax is:
-webkit-image-set(url(low.png) 1x, url(hi.jpg) 2x)
It’s working on CSS, such as a background-image. I couldn’t make it work on the HTML side, for the src attribute on an img element or the new proposed picture element. With this new syntax we can have more clear multi-resolution image definition, as we don’t need to use media queries and background-size values.

Passbook coupons and passes delivery

Passbook is a new app in iOS that works as a virtual container for all your passes, ticket, discount coupons, loyalty cards and gift cards. As a web developer you may want to serve the user with a discount coupon, a ticket to an event, an e-ticket for your next flight or a loyalty card.

Apple allow websites to deliver this kind of passes from a website without the need of a native app.

To deliver the pass on your website you just need to use the MIME type application/vnd.apple.pkpass or send it through email

Apple provides a tool that you can install on your server to package and sign customized passes on the fly that may include current user information

To pass file is just a JSON meta-data file and a couple of images. We need to package the file and sign it. Unfortunately, to sign the pass we need a signature from Apple and that means that the web developer needs an iOS Developer Program account ($99/year). If you receive the pass already signed, you can just insert it on your own site.

One of the great features of passes is that once installed you can provide some web services on your end and through Push Notification Services, the operating system will call your web services to update the information on the pass.

More information at developer.apple.com/passbook

Storage APIs and webapp updates

No, there is no new storage API available. There is no support for IndexedDB yet. However, there are some changes you should take in consideration:

• Application Cache limit was increased to 25Mb.
• Chromeless webapps (using the apple-mobile-web-app-capable meta tag) now have their own storage sandbox. That means that even if they are served from the same domain, the web app from the Home Screen will have its own persistent Local and SQL Storage. Even if you install the icon many times, every icon will have its own sandbox. While this is good news for apps, it may be also a problem on some apps if you are passing information from the website to the home screen widgets through storage.
  Credits for this finding to George Henne on his post.
• There is a new undocumented meta tag that can be used on any website (having the apple-mobile-web-app-capable meta tag or not) that allow us to define a different title for the Home Screen icon. As you may know, by default Safari takes the document’s title and crop it to 13 characters. Now we can define an alternative title for the Home Screen using:

<meta name="apple-mobile-web-app-title" content="My App Name">

I’ve also found a meta tag called apple-mobile-web-app-orientations accepting the possible values portrait, portrait-upside-down, landscape-right, landscape-left, portrait-any. Unfortunately, I couldn’t make it work. If you have any luck feel free to comment here.

Web View updates

On Web View (pseudobrowsers, PhoneGap/Cordova apps, embedded browsers) JavaScript now runs 3.3x slower (or let’s say that Nitro engine on Safari and Web apps is 3.3x faster). Be careful about the 3.3x, that is just the different of running SunSpider on the same device, on Web View and Safari. However, SunSpider is not covering all possible kind of apps and your total rendering time is not just JavaScript, so this doesn’t mean that your app runs 3.3x slower.

We can find some other good news:

• Remote Web Inspector for webapp debugging
• A new supressesIncrementalRendering Boolean attribute that can eliminate the partial rendering mechanism. I believe this feature is useful to reduce the perception of loading a web page instead of being an app.
• A new WebKitStoreWebDataForBackup info.plist Boolean feature where we can define that we want localStorage and Web SQL databases to be stored in a place to be backed up, such as in iCloud. This problem has appeared in iOS 5.01, now it’s solved
• Changes in the developer agreement: it seems that the restriction of using only the native WebView to parse HTML and JS has gone. It will be good if someone from Apple can confirm this. The only mention to the internal WebKit engine is that it’s the only engine capable of downloading and execute new code, while in the same app expected behavior; that’s the anti-Chrome statement. You can use your own engine but only if you are not downloading the code from the web. This may be opening a door… such as delivering our own engine, for example, with WebGL support.

Remote Debugging

I’m keeping this topic at the end. Because it’s a huge change for web developers. For the first time, Safari on iOS includes an official Remote Web Inspector. Therefore tools, such as iWebInspector or Weinre will become obsolete since this version. The Remote Debugger works with the Simulator and with real devices via USB connection only.

To start a remote inspection session you need to use Safari 6 for desktop. Here comes the bad news: you can only debug your webapp on a Mac desktop computer. It was a silent change, but Safari for Windows is not available anymore, so it’s stuck in 5.x. Therefore, only with a Mac OS computer you can make web debugging session on your iOS devices (at least officially for now).

For security reasons, you need to first enable the Web Inspector from Settings > Safari > Advanced. The new Inspector means that the old JavaScript console is not available anymore.

You can start a debugging session with:

• A safari window on your iOS device or simulator
• A chrome-less webapp installed on your iOS device or simulator
• A native app using a Web View, such as Apache Cordova/PhoneGap apps.

When talking about native apps, you can only inspect apps that were installed in the device by Xcode (your own apps). Therefore, there is no way to inspect Google Chrome on iOS websites for example.

If you are used to the Webkit Inspector -Safari 5 or Chrome-, you are going to see a completely redesign version of the inspector in Safari 6 based on Xcode native development UI. You will be lost for a while understanding the new UI. With the inspector session, you can:

• See and make live changes on your HTML and CSS
• Access your storages: cookies, local storage, session storage and SQL databases
• Profile your webapp, including performance reports for Network requests, Layout & Rendering and JavaScript and events. This is a big step in terms of performance tools.
• Search on your DOM
• See all the warning and errors in one place
• Manage your workers (threads)
• Manage JavaScript breakpoints, and define Uncaught exception breakpoint.
• Access the console and execute JavaScript
• Debug your JavaScript code
• Touch to inspect: There is a little hand icon inside the inspector that allows you to touch on your device and find that DOM element on the inspector.

Well done Apple, we were waiting for this on iOS for long time. Apache Cordova users should be also happy with this feature.

Other smaller updates

• Apple claims to have a faster JavaScript engine. And it seems to be true. On the SunSpider test I’m receiving 20% improvement on JavaScript performance on the same device with iOS 5.1 and iOS 6.
•  Google Maps is not available anymore on iOS 6; Now http://maps.google.com redirects to the Google Maps website and not the native app. there fore there is a new URL scheme, maps, that will open the native new Maps applications. The syntax is maps:?q=<query> and query can be just a search or latitud and longitude separated by comma. To initiate a route navigation, the parameters are: maps:?saddr=<source>&daddr=<destination>.
•  XHR2: Now the XMLHttpRequestProgressEvent is supported
• The autocomplete attribute of the input is officially in the DOM
• Mutation Observers from DOM4 are now implemented. You can catch a change in the DOM using the WebKitMutationObserver constructor
• Safari no longer always creates hardware-accelerated layers for elements with the -webkit-transform: preserve-3d option. We should stop using it for performance techniques.
• Selection API through window.selection
• <keygen> element
• Canvas update: Now the createImageData has one parameter and now there are two new functions that the name suggest to be prepared to provide High Resolution images webkitGetImageDataHD and webkitPutImageDataHD.
• Updates to SVG processor and event constructors
• New CSS viewport related measures: vh (viewport height) vw (viewport width) and vmin (minimum between vw and vh)
• CSS3 Exclusions and CSS Regions were available on beta 1 but they were removed from the final version. It’s a shame although they were too new and not mature enough.
• iCloud tabs. You can synchronize your tabs between all your devices, including Macs, iPhones and iPads. So the same URL will be distributed through all devices. Be careful on your mobile web architecture!

What we are still waiting for

There are a couple of things that we still need to wait for a next version, such as:

• IndexedDB
• FileSystem API
• Performance Timing API
• WebRTC and getUserMedia
• WebGL -still there and still disabled-
• Orientation Lock API for gaming/inmersive apps
• Integration with Facebook and Twitter Accounts native APIs, so we can use current OS user’s credentials automatically instead of forcing the user to log in again.

Final Thoughts

Safari on iOS 6 is a big step for HTML5 developers; debugging tools, new APIs, better JavaScript performance. However, I must say that Apple is still forgetting about documentation updates and properly communication with web developers. There are almost no answers on the discussion forum, no updates on the Safari documentation (some docs are really too old right now).

I believe Apple must do a better job supporting web developers. 

Did you find any other new stuff? other problem or bug? Anything else you were waiting for? Feel free to comment in the section below or contact me by twitter.

I’m attending Google I/O in San Francisco this week and Google has released some news on Chrome: an iOS version that it may not be Chrome, the Android version out of beta, now being the default browser on Android 4.1 and some other stuff. Let’s review the news in the mobile web world.

Android 4.1 Jelly Bean browser

Let’s start with Android 4.1 Jelly Bean. You know I was really happy when Google released Chrome Beta for Android. The default browser (known as Android Browser) is not good enough compared to other modern browsers and Chrome is here to solve this problem.

First news, Google Chrome for Android is out of beta and current version is 18. This version doesn’t support new stuff from the previous beta version but it’s pretty updated in terms of HTML5 compatibility.

The tablet Nexus 7, the first new device with Android 4.1 has Google Chrome by default. That means that the end of the Android Browser era has started. Galaxy Nexus smartphone (at least the version I’ve received in Google I/O) still has Android Browser with Jelly Bean and you need to download Chrome from the Google Play store.

I could confirm with the Chrome team that most new future devices with 4.1 will have Chrome by default and Android Browser is not going to be there.

However, for web views –such as pseudo browser or native apps- the old engine is still there, so there is no Chrome engine from web views yet.

Besides that we are going to see a browser fragmentation in 4.1. New devices sold from now on and 4.0 devices that are going to be upgraded to 4.1. These 4.0 devices will still have the Android Browser as the default browser.

In terms of HTML5 or new compatibility, the default engine on 4.1 (for web views and upgradable devices) is still the non-Chrome one.

Chrome for iOS -iPhone and iPad-

Well… this is big for mobile web development. But it’s not big because of what you are thinking. It’s big because we are going to start big philosophical discussions. That’s is because Chrome for iOS is not Chrome. What?? It has a Chrome-style UI, onmibox, search by voice and it has Chrome synching. However, the rendering and execution engine are not Chrome.

I called them pseudo-browsers and you can see my opinion and a good discussion on the comments area in my previous post. So Chrome for iOS is in fact using the iOS Web View that share most of the code with Safari.

The User Agent that Chrome for iOS is using is the Safari one with one addition: “CriOS” (Chrome for iOS I guess). There is no “Chrome” word inside the User Agent, so if you are doing something special for Chrome, you are safe and it’s not going to be executed on Chrome on iOS.

That means that when using Chrome for iOS you are seeing the web in the same way as in Safari. Since both are based on WebKit it seems it’s not a big deal, but it something that you should aware of. My list of things that you need to care about is:

• HTML5 Compatibility: There are differences between Safari on iOS and Chrome for Android. Chrome for iOS follows Safari on iOS, so you don’t have IndexedDB, file upload and HTML media capture, animation timing API, full screen API, remote debugging and other stuff. While some new stuff may be included in iOS 6 Google is not in control of Chrome on iOS.
• On some APIs –such as Geolocation- it seems there is no permission per site.
• Local Storage: There are some problems on using Local Storage. Chrome is replacing the default UIWebView localstorage but the Incognito mode is called Incognito* mode (with a star) meaning that local storage is not secure.
• JavaScript on Web View are not being accelerated (Nitro engine on iOS) – that means that your code is 2.5x slower than on Safari for iOS. If you are under NDA on Apple you can check the data for iOS 6.
• Full screen apps: There is no way to work with full-screen apps on Chrome on iOS so you need to remove all the invitation messages.
• No default browser: There is no way on iOS to use Chrome as the default browser so every time you click a link on Twitter, Facebook or any other native app on iOS you will be forwarded to Safari. You need to copy and paste the URL in Chrome.
• iOS versions: The same Chrome version will have different support on each iOS version where it’s relying on, such as 4.3, 5.0, 5.1 or 6.0.

I’ve checked into the DOM and nothing new is being implemented. There are a couple of private objects, such as __gChrome that seems to be some JavaScript that Chrome is injecting on the DOM to enhance the web view experience. I’m not sure (neither the Chrome guys here at I/O) when Google is injecting this JavaScript code.

My feelings about Chrome for iOS are strange. I understand why they took the decision but it seems a very different decision that Mozilla took, such as creating Firefox Home app the the Mozilla Junior project, two apps for iOS that because of the limitations of the platform are not being called Firefox.

Chrome for iOS is available for iOS 4.3 and later, it claims to be Chrome 19 and you can download from free from AppStore using this link.

Chrome Apps on Android?

On today’s keynote, an idea was presented: running Chrome HTML5 apps across all the devices, desktop, tablet and smartphones… so I’m waiting for a future version of Chrome for Android supporting Chrome Apps that will make a big step forward mobile HTML5.

The new Chrome Apps platform was presented today and everybody is saying that mobile devices will support these APIs but no information on when or how will they work yet. I’ve asked Google’s guys and the answer is: we are going to get to that point anytime in the future.

In this post I’m analyzing the public information for developers behind Safari on iOS 6 and the research results on Beta 1 version of the next main version of the operating system for iPhone and iPad.

iOS 6 for iPhone, iPod touch and iPad was announced on June 11 2012, and some new Safari features were publicly shown. Apple claims to have 2/3 of the mobile web browsing market (is Opera being considered?) so it’s always important for us when Safari has a new version.

iOS 6 will be available for iPhone 3GS, 4 and 4S, iPod Touch 4^th generation and iPad 2^nd and 3^rd generation.

That means: iPad fragmentation has started.

Public new features for Safari on iOS 6

File uploads

Finally! We can now select an image from the Photo Library or opening the Camera from a web form. The question is about HTML Media Capture being implemented or not (see later for the answer).

Web Audio API

With the Web Audio API we can enhance HTML5 games and multimedia apps with mixing, filtering and processing operations through JavaScript.

CSS Filters

CSS 3 Filters a set of image operations (filters) that we can apply using CSS functions, such as grayscale, blur, drop-shadow, brightness and other effects. These functions will be applied before the content is rendered on screen. We can use multiple filters using spaces (similar to transforms).

Smart App Banners

It’s a way to connect websites to native applications. When you browse a web that has a related native application, Safari can show a banner inviting the user to install or open the native app. The website can also send parameters to the native app. It’s not clear how this is going to be implemented. My guess is through meta tags. The same behavior is available on Internet Explorer 10 for Windows 8.

Full Screen support on landscape

When you orient your device in landscape mode you can then move to a full-screen mode, including hiding the status bar and the Safari toolbar at the bottom. Transparent buttons are replacing the toolbar. A similar behavior is available on Nokia Browser for Symbian.  It’s not clear at this point if we can use the FullScreen API to request the feature (see later for the answer)

Remote Web Inspector

This is a big feature. Announced as a very small feature in the new APIs for developers. In the keynote there was no other information. As you may know, I’ve developed iWebInspector for iOS 5 because of the lack (or the hiding) of a web inspector tool for debugging web apps. It’s not public if this new Remote Web Inspector through LAN (like BlackBerry Remote Web Inspector) or through USB (like Google Chrome for Android)… the answer, later in this post.

Crossfade CSS Function

This feature was published in the keynote with “font-face: 3px” but I’ve seen it. It’s an image function that will create a crossfade between two images (Spec draft), for example:

background-image: -webkit-cross-fade(url("image1.png"),  url("image2.png"), 40%);

Will it work with transitions?

Other announced features and questions

iCloud Tabs

You can synchronize your tabs between all your devices, including Macs, iPhones and iPads. So the same URL will be distributed through all devices. Be careful on your mobile web architecture!

Offline Reading List

when the user adds a page to the reading list it will be also downloaded and precache. Is there any API to know if our page is being executed from the cache?

Maps

Google Maps native app was replaced by a new Maps app (directly from Apple). The question is, is this app still capturing http://maps.google.com URLs? (I hope not) and how to open the native app or driving instructions from a web.

Twitter and Facebook

Both social networks are not integrated in the operating system. It will be good if at some point web apps can also use these credentials.

Questions from the past

WebGL? IndexedDB? getUserMedia (camera access)? Nitro engine on Web Views?

Other news on HTML5 APIs inside the iOS 6 beta 1

I’ve been playing with Safari on iOS 6 Beta 1 for a couple of hours and I’ve found other features and answers to my questions. However, iOS 6 Beta 1 is under NDA (Non Disclosure Agreement) so I can’t talk about it in public. (Apple it’s time to release web-related technologies out of the NDA). I can just say that my findings are at least the double of the information I’m posting here.

If you are enrolled in the iOS Developer Program, you can see the rest of this article under NDA.

Continue this article under NDA >>

Yahoo! has just released the new Axis app for iOS and desktop, promoted on some blogs as a new browser. It’s a good opportunity then to explain how this kind of apps work and why they are NOT browsers. If you are a web developer it’s important for you to know what to expect for this app.

Pseudo-browsers

I know but at some point it’s a matter of semantics. I like to call this apps pseudo-browsers: they pretend to be browsers.

If you have an iOS or Android device and you’ve used Twitter or Facebook you’ve already deal with the idea. When you open a link on those social networks you get an embedded browser and it’s basically using the UIWebView component on iOS and the WebView on Android (image at the right).

You are right. It’s the same component that is the base of native web apps –such as PhoneGap apps-. It’s not 100% the default browser embedded on an app, but it’s quite similar. Basically, both the default browsers (Safari and Android Browser) uses at some point the same code as the web views. However, browsers and web views have also differences in behavior, such as JavaScript execution engines or other HTML5 APIs.

On iOS –that’s for iPhone and iPad-, Yahoo! Axis, iCab Mobile, Skyfire, Dolphin, Mercury Web Browser, and other dozen of apps on the AppStore are not browsers, just apps using the default web view adding different behaviors on the UI, on the search mechanism or sharing features than the default Safari.

For a web developer or designer, it’s the same as the web view. That means that there is no new or removed API than what you can find using the default rendering engine. They are not really adding fragmentation to the mobile web world.

What about Android browsers?

On the Android side we do have different real browsers, such as Firefox or Opera Mobile with real different rendering and execution engines. And we have also some other pseudo-browsers available for download.

Why can’t we find real browsers on the AppStore for iOS?

Because of Apple Review Guidelines saying that any application with web content MUST use the default-rendering engine for HTML, CSS and the default execution engine for JavaScript.

What’s the deal with Opera Mini for iOS?

As you know, Opera has its own rendering engine. Well, Opera Mini, Puffin, iSwifter and other browsers, are cloud-based browsers. That means that your code is not being executed on the device but on a proxy server. There is no rendering or execution engine on the iOS so for Apple, the app is not using a different engine on the device.

Opera Mini had troubles to get accepted at the beginning (look at the joke for Steve Jobs Opera did on Mobile World Congress 2010), but finally Apple flexibilized the rule and accepted it and other cloud-based browsers.

Back again to the problem

Now you understand why there is no Firefox for iOS.

Now you understand why Axis is not a web browser.

Axis may be a tool to browse the web in a different way, but you are browsing the web with a –let me take a break and say- embedded Safari. If your website is being browsed by Axis it’s the same as in the Twitter, Facebook or Flipboard. You can expect mostly all the API support from Safari with an slower JavaScript engine –no Nitro for web view available- and some different behavior on HTML5 APIs.

Some guys were discussing on Twitter that you can say that Google Chrome is not a browser because it’s based on WebKit. Well, wrong! “Based on” doesn’t mean “using”. Chrome is compiling WebKit with additions and removed features, so for developers it’s really a new browser –it has different behavior, and we know that. You can compile your own WebKit flavor on iOS but you will never be accepted on the AppStore -at least with current rules.

The new iPad is here with iOS 5.1. I’ve done the usual research and, mm… there are no much new details to give you. However, the new iPad retina display remembers us some web stuff we should be aware of while creating iPad web experiences.

Safari on iOS 5 and Safari on iOS 5.1 seems to be exactly the same. There is no new APIs, no new stuff supported, same WebKit version; only we have the version change on the User Agent.

However, iOS 5.1 is the first version supporting high resolution iPads. While there is no real devices yet to test on, there are some ideas we need to remember from the iPhone 4 high definition launch and everything goes in the same direction.

Too many pixels

The iPad has a resolution of 2048 x 1536. It’s far away more pixels than we use to have on the web.

Do we need to change our websites for this new resolution? Well, definitely no.

First, remember that more pixels doesn’t mean more visual space to use. Your website will be rendered as in iPad 1 and iPad 2 with the advantage of sharpen text, CSS3 effects and gradients.

We need to remember that since the appearance of iPhone 4 -and also followed by Android- mobile browsers are exposing a virtual resolution to web developers based on the viewport meta tag and/or an attribute called Pixel Ratio. iPad 1 and iPad 2 have a Pixel Ratio of 1. The new iPad has a Pixel Ratio of 2. This value can be accessed though JavaScript using window.webkitPixelRatio or though CSS media queries using -webkit-device-pixel-ratio. 

If we define a div of 500 pixels-wide, it will be really 500 pixels-wide on iPad and 1,000 pixels-wide on the new iPad, unless an special viewport is defined.

High resolution images

Now we know that we will not have problem with text and CSS3 effects. Images is a very different problem. Basically, the new iPad will resize your image. At the end you will not see much difference from iPad 1 or iPad 2. However, if you provide a high resolution alternative the image will become more clear. You can provide alternative images using the Device Pixel Ratio attribute. In case of CSS3, the code should look like:

@media (-webkit-device-pixel-ratio: 2) {
#someContainer {
background-image: url('images-hi/image.png');
}
}


Icons and launch images

Performance

Wait before looking for high resolution versions of your images. If we think about it, we need an image with four times pixels. That’s a huge difference and the image size will be much higher. What does this mean? Your page will be much slower. Ok, there is a 4G version of the new iPad but that doesn’t mean that the difference will be covered.

Think twice about the value added when delivering high resolution images.

Creating effects and gradients using CSS3 will be much faster. However, large backgrounds tends to use lot of memory. Fortunately, the new iPad comes with more memory and CPU power so hopefully this won’t be a problem.

Maybe it’s time to start looking at scalable solution, such as SVG that will take advantage of the high resolution without harming network performance.

In terms of HTML5 games, we need to wait until having the real device but usually if you want to increase your frame rate sometimes it’s better to provide a smaller viewport, so the game will use less memory -like a iPad 2 emulator- and using hardware accelerated CSS3 transforms we can scale it if we need to. It’s just a thought and a trick that is being used in some Android HTML5 games to gain some frames per seconds.