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.

A year ago, I’ve reviewed the BlackBerry Browser for PlayBook –the tablet from RIM- as the browser with better support on new HTML5 APIs (see 1.0 review). Yesterday, 2.0 version of the operating system was released for free for every user and I’ve just investigated the new APIs available. Let’s see what I’ve found.

While I’m still waiting to get a BlackBerry Smartphone 7.0 on my hands to review it -hey RIM, are you listening? ;) – I’m playing with the PlayBook OS browser. PlayBook Browser is important not just because of its users, but because it will be the same operating system for the next generation of BlackBerry Smartphones (BB10, previously known as BBX).

It was the first one supporting remote web inspector for debugging though your LAN and that’s a great feature. Chrome for Android also supports web debugging but using USB, not through your network.

If you check my PlayBook 1.0 review, you will see that the first version of the browser was already supporting lot of APIs, such as Web Workers, Web Sockets, Device Motion, touch events, form elements and CSS3.

HTML5 Support

The PlayBook 2.0 documentation for web development was not released yet so I was forced –again- to dig into the DOM and search for APIs.

This new version is again surprising me: this is the first tablet –and even mobile device- supporting by default in the native browser:

• WebGL – 3D Drawing API
• Web Notifications API

It also supports some other new HTML5 stuff, such as:

• File API
• Contenteditable attribute
• 3D transformations
• XMLHttpRequest 2
• SVG Fonts
• Browser History API

Now there is a simpler way to add a page to the Home Screen after touching the star icon instead of adding a bookmark. Unfortunately, it’s not taking your apple-touch-icon, it’s just using a screenshot of your page as the icon.

There is no IndexedDB yet but Web SQL is still supported.

Flash Player is available and running really well, being  the only tablet supporting Flash officially right now.

Dangerous 3D

3D is finally here. PlayBook 2.0 supports 3D CSS transforms but it also supports WebGL –aka 3D canvas Drawing API-. This is the first installed by-default mobile browser to support WebGL. The first thing that surprised me on the browser was the idea of giving permission to WebGL to work. It seems a good idea for privacy-related APIs such as Geolocation, contacts or notification but giving permission for WebGL is a little strange. How a normal user understands what WebGL is and why is so dangerous?

I can understand that WebGL may be a battery killer feature, so a message like that is understandable. This is the first time I see a browser warning the user about WebGL security and “your PlayBook may crash”. It seems to me something like: “this is not working properly yet so if your browser crashes it’s not our fault; it’s the developer trying to steal your information”. I know there are some security issues with WebGL but I don’t like the warning. If the user is a typical BlackBerry user –security paranoic- then he will not accept WebGL. Why did RIM add WebGL to the browser if it leads to a real security risk?

Web Notifications

Web Notifications is the ability to show a notification in the operating system from a webpage, even when our page is in the background –at least on some operating systems with real multitasking-. This is a killer feature, because it allows webapps to communicate with the user anytime.  On the mobile side, this API was only available in Firefox for Chrome.

This API is available in PlayBook 2.0 –using the webkit prefix- but it seems to be incomplete. I was able to show a background notification –see image below- but I could only catch the click event when the user closes the notification with the little “x” icon, not when clicking on the message. Even clicking on the notification’s message doesn’t do anything. It doesn’t open the browser again, it doesn’t open the URL I gave when creating the notification and it doesn’t trigger any event. It seems like a bug to me.

Trying to deliver an HTML notification message also leads to a buggy situation. Instead of seeing your message you will see an ugly URL as a notification message.

You will need permission on your domain before sending a notification. The following code works properly:

webkitNotifications.requestPermission(function() {
// Creates a normal notification
var notification = webkitNotifications.createNotification("http://mobilehtml5.org", "HTML5 notification", "Hi from the webpage");
notification.show();
});

It’s that time of the year again when the mobile web ecosystem changes. Google Chrome Beta for Android was released and it appears as the future replacement of Android Browser. I’ve made a deep analysis on the browser HTML5 compatibility and the comparison with Safari on iOS and Android Browser and I’ll show in this post my results.

Quick look

If you have an Android 4.0 device, go to the Market and download it so you can try it yourself. Chrome for Android is a big step for the whole mobile web community and I’m happy for it. It’s still the first beta so there are some things that need some work but in a quick look, it seems stable, fast, nice, and with the latest HTML5 support.

It’s the beginning of the future of some APIs in the mobile world, including Request Animation Frame, FullScreen API, Page Visibility API and IndexedDB. Unfortunately, Chrome is not available yet for Android 2.x and 3.x and WebGL is still out of this version.

I’ve played a couple of hours with the browser and here is my review. I’ll update this post if I find some new information to add or correct. Follow me if you want to get updates.

Why Chrome?

Do we really need a new browser for Android? The answer depends on our point of view. Android is right now the platform with more options in terms of web browsing: the by-default Android Browser, Opera Mobile, Opera Mini, Firefox, UCWeb and now Google Chrome. Chrome appears in the Android world not as a new browser but as a long-term replacement for Android Browser.

The problem was Android Browser. It was always behind Safari on iOS for iPhone and iPad and it was far away behind its desktop cousin Google Chrome; at least, in terms of HTML5 compatibility. Android Browser had problems in the past and the worst problem from my point of view: it doesn’t auto-update. And we know that Android users –because of vendors and carriers- usually upgrade only one version of the operating systems, so millions of users are prisoners of the same Android Browser version until they upgrade their device.

Today, the future of Android browser has begun. Google has released the first beta version of Google Chrome for Android. Starting from the ground from the Chromium Project instead of the original WebKit-based Android browser, Google did a good job aligning the browsing experience and HTML5 compatibility with the present and future standards.

Chrome Beta is a 17Mb free download available on selected countries via Android Market only for Android 4.0 smartphones and tablets. And that is the first bad news: Gingerbread (2.3) and Honeycomb (3.x) users don’t have a Chrome version now and there is no official communication about a version for those platforms in the future. Currently, only 1% of Android users are using 4.0+.

Features

The browser claims to have a faster scrolling experience and I’m not sure yet if SPDY protocol is supported, but I hope so.

One of the most important features for me: it’s an Android app downloaded from the Market. Why this is so important? Because it can be updated in the same way. We will get auto-update feature on Chrome, and that’s the best news we as web developers can receive.

Chrome for Android has a nice UI optimized for tabbed browsing using a new tab browsing experience compared to Android Browser. You can flip/swipe between tabs, as in webOS (if you are creating a touch game, you should avoid use the edges).

It supports Incognito mode (private mode) and a feature called Bandwidth management that preload pages when you are using Wi-Fi. There is no information on how this feature works (rel=preload maybe?) but I believe the search bar is using it. When you search something the first results are being preloaded by default if you are on Wi-Fi.

The user interface includes a fixed URL bar, a tab button and a menu button. The URL bar is always visible and there is no way to hide it, as in Safari for iOS or even Android Browser. The URL bar doesn’t show the page’s title or the page’s icon, just the URL.

I really like the new feature called Link Preview that will make a quick zoom on areas with lots of links in a site without a mobile viewport (see image below). This feature helps the user selecting the right link.

Of course, if you sign in with your Google Account, you will get full synchronization between Chrome for Desktop and Chrome for Android, search suggestions, opened tabs, history and bookmarks.

Detection

To avoid misdetection of Chrome for Android as a desktop, the user agent looks like:

Mozilla/5.0 (Linux; U; Android 4.0.2; en-us; Galaxy Nexus Build/ICL53F) AppleWebKit/535.7 (KHTML, like Gecko) CrMo/16.0.912.75 Mobile Safari/535.7

As you can see, there is no Chrome string there; just CrMo (Chrome Mobile?) and other Android-typical strings.

I’ve made a quick test on some websites, and they are all detecting Chrome as Android Browser.

Remote debugging

For developers, remote debugging and profiling is one of the greatest additions. I’ve received lot of feedback a month ago when I’ve created iWebInspector, a remote debugger helper for iOS Simulator. Now you have the same tool for Android devices.

It allows us to use a full Remote Inspector –the same as in Chrome for Desktop- remotely using USB debugging. Unfortunately, this feature doesn’t work via the network as in BlackBerry Browser for PlayBook and Smartphones 7.0, Weinre or iWebInspector.

You need to use USB debugging mode, meaning that you as a web developer needs the Android SDK tools, the debugging drivers of your phone for Windows users and a couple of command-line tools to deal with. Maybe, it’s time for a iWebInspector for Chrome to help designers with this process :). I believe this process should be easier for web developer but it’s not a big deal when you understand how to do it.

For more information and instructions on how to set this up, visit http://code.google.com/chrome/mobile/docs/debugging.html

Hybrids and PhoneGap

This is a big question. Every developer that had experience with hybrid development in Android, including PhoneGap apps knows that sometimes the embedded WebView on Android gives us lots of problems compared with UIWebView on iOS.

At least today in this first beta, there is no way to use Chrome engine inside your hybrid Android app. However, in the FAQ this feature is mentioned so I believe it’s being under consideration so go now and help me ask for this feature. In the future, PhoneGap or other frameworks can detect if Chrome is available and use ChromeView instead of the original WebView. Let’s dream with that :)

About UI frameworks, just a quick test says that jQuery Mobile and Sencha Touch seems to work properly on Chrome for Android.

HTML5 compatibility

The Chrome team did a good job porting Chromium to Android with the latest HTML5 APIs that we already have in Chrome for Desktop and Chrome OS. First, we have almost every API available in Android Browser 4.0. The only missing API is Network Information API that is on Android Browser since 2.2 and it’s not here on Chrome.

We have the typical HTML5 basic support, such as new elements, video –H.264 and WebM support- & audio tags, Geolocation, hardware accelerated Canvas (2D Drawing), Web Storage, SQL Storage (ok, we can discuss if it’s an HTML5 API), Offline AppCache, and all the CSS3 stuff, such as selectors, effects, media queries, transforms, transitions and animations.

The browser also adds support for mobile-specific stuff such as Touch events, viewport definition, mobile icon support (apple-touch-icon) for bookmarks and orientation change events to the Chrome for Desktop compatibility APIs.

Chrome for Android also supports:

• History API
• SVG and inline SVG
• XMLHttpRequest 2.0
• Device Orientation & Motion API (accelerometer and gyroscope)
• Media Capture API
• Web Workers (not shared)
• Web Timing API (available also on iOS5 and IE9 on Windows Phone 7.5)
• Chrome Performance Timing API (http://ecmanaut.blogspot.com/2010/06/google-bom-feature-ms-since-pageload.html)
• File API (File, FileList, FileReader, Blob types)
• Console API
• Content Editing API (contenteditable attribute and selection API)
• Flex CSS Model (the legacy version, not the latest standard)
• Form validation and new input types including range and date selections (excepting week selector).
• Fixed positioning and scrolling areas (overflow: scroll).

And for new APIs in the mobile world, we can mention compatibility with:

• Page Visibility API
• IndexedDB –the standard replacement for the SQL Storage API- (Firefox already supported this on mobile)
• Request Animation Frame for smoother animations using HTML5
• FullScreen API, but it’s not working properly yet (see below)

Missing features

Looking at the APIs available on other mobile browsers or in Chrome for Desktop that are not there yet in this first beta version for Android:

• WebGL, aka 3D drawing API. The objects seems to be there as in iOS 4 and 5 but there is no way to use it.
• Network Information API
• Full Camera API (for using the camera source in a <video> tag and create augmented reality experiences)
• Notification API, available in Chrome for Desktop and Firefox for Android
• Gesture Events (they are only on Safari for iOS)
• Flash Player support. However, this is a good decision, as Adobe will not support Flash Player in mobile in the future.
• No home screen / applications menu icon support yet.
• Some text-based input types don’t change virtual keyboard, such as email and url while number-based input types do.
• There is still no support for datalist, menu and command. However, almost no browser is supporting these HTML5 elements.
• No Input Speech extension for input types, available on Chrome for Desktop with the x-input-speech.
• No extensions support yet. However, the APIs for extensions are there but disabled, such as window.chrome.app.experimental APIs.
• SearchBox API is there but is not working. This API allow us to communicate with the URL bar (known as Omnibox in the Chrome world) while the user is typing or searching.
• No compass support
• No Web Audio support available on Chrome for Desktop
• Custom Protocol Handler API is there but it’s disabled.

Bugs

This is the first beta version and there are still some bugs to be solved . If you find a bug, you can fill a request.

• The FullScreen API is there and is working buggy. You can enable full-screen, sending in this mode an element and its content. However, it’s not really full-screen (the URL bar is still there) and there is no way to close this mode (by JavaScript or back button).
• SearchBox, Custom Protocol Handler and Add Search Providers API are there but they don’t work

Emulating Chrome for Android

Unfortunately, there is no official way to emulate Chrome for Android. You can say that Chrome for Desktop should be enough but the reality is that it’s not. Mobile has specific design properties that need other kind of testing. While the code is based on Chromium, as far as I know, it’s not exactly 100% the same source code as Google for Desktop, so we still need testing on it.

We have Android Emulator; however there is no official way to install Chrome on it. Android Emulator doesn’t support Market so you can’t install the Chrome package. If you are curious like me then you will find a way to get the Chrome package and install it on the emulator. Yes, I did it (don’t ask me how). However, Chrome is not working fully (it has something to do with some libraries). I could get the Chrome UI but not the ChromeView (the rendering area), so nothing is shown on the screen. I hope the Chrome team can figure out some way to emulate it soon. I know they are reading this post (right? ;) ), so make us happy team.

Conclusion

It’s a great time for the mobile web. This release even put in hold my vacations in the great Tokyo for a couple of hours so I could make this review.

A new first-class browser appears in the mobile web space, joining the list to Firefox, Safari and Internet Explorer. We are going to deal in the next –maybe two- years with Chrome and Android Browser at the same time but for the future, it was a good decision from Google.

I’ll continue my testing over a real device with Android 4.0 and post my results here. I’ll also update Mobile HTML5 in the next few days.

Did you find anything else on Chrome for Android? Do you have any other ideas? Use the comments area below.

Debugging mobile web applications was always a painful process. In this post I’m presenting the free tool iWebInspector I’ve created to enable a full Web Inspector -including JavaScript debugging & profiling- in Safari for iPhone and iPad and in PhoneGap apps.

First of all, full credit of the hack behind the tool to Nathan de Vries. He has discovered some days ago a private API and he has published a post about it. With this solution we can enable a Remote Web Inspector on iOS Simulator included with Xcode 4.2 and iOS 5 SDK using some gdb (debugger) commands.

I’ve started this post as a tutorial on how to enable this option and debug webapps on the iOS Simulator. After writing this post, I’ve realized it was too difficult to use and enable for a typical web developer without Xcode experience.

My next thought was: “it should be great to have a tool making these steps for us“. And my saturday’s afternoon paid for that thought. I’d experience with Objective-C for iOS so it wasn’t difficult to create my first Cocoa Mac application using the same language. After a couple of hours, the first version of iWebInspector was ready to go.

The solution is not working -yet- on real iOS devices, just on the iOS Simulator -available only for Mac OS-. The tool can attach the Web Inspector to any tab opened in Safari for iOS, to a chrome-less webapp (full screen) or to a PhoneGap application -or any native application using UIWebView-.

iWebInspector

I’m pretty sure that Apple will make this tool public in a future version of iOS.

Download iWebInspector

Attaching to PhoneGap and UIWebView

If you are creating a PhoneGap application or a native iOS app with some UIWebView content, it’s easy to enable the Remote Web Inspector with a line of code instead of using iWebInspector. This is a private API so remember to remove this line for the final compilation or you may have an AppStore rejection for private API usage.

Find your application:didFinishLaunchingWithOptions method on your AppDelegate.m file and add this line of code inside:

// Remove me after debugging
[NSClassFromString(@"WebView") _enableRemoteInspector];


That’s all! After that, run your app on the simulator and localhost:9999 will be pointing to the same Remote Web Inspector as in iWebInspector.

Suggestions and Bug Report

iWebInspector was created in a couple of hours, and this is the first version available.  If you find bugs, problems or if you have a suggestion, feel free to contact me or leave a comment here.

Enjoy!

Android 4.0 was announced and the SDK was released. So, I’ve washed my hands, I’ve opened the emulator and I’ve started to dive into the new browser and see what’s in there and what’s not. Unfortunately it’s still Android Browser and not Chrome, but it comes in a better way.

Busy month

October 2011: Busy month for mobile web world.  Just a few days ago, I’ve blogged about Safari on iOS 5; yesterday BlackBerry announced the first mobile browser with WebGL support on the (future) PlayBook platform and a few weeks ago Amazon announced Silk, a new proxy-based browser for tablets.

And now, it’s the Android turn. Android 4.0 was released and while there is no real phone yet to test it on (the Galaxy Nexus will be available soon) I’ve downloaded the emulator and I’ve tested the browser comparing it to Android 2.3 (smartphones) and Android 3.2 (tablet) that I both have on my hands.

Google announced that Google Chrome will be the future of browsing in Android but it was not 4.0 the time for that.

Smartphones meets tablets

This version merges both smartphones and tablets, so smartphones jumps from 2.3 to 4.0 acquiring all the new things on the browser available on 3.x, including:

• SVG
• Motion Sensor API (accelerometer and gyroscope -on compatible devices-)
• 3D Transforms on CSS3
• XHR 2 & CORS
• File API
• HTML Media Capture API for camera/microphone access through file management
• Binary Arrays (Int16Array, Float32Array, etc.)

What’s still missing on Android 4.0

Unfortunately, there are still some missing APIs that are available on Google Chrome and on iOS5 -some of them-, including:

• No Server-sent events (BTW, does anybody use it?)
• No WebSockets
• No WebWorkers
• No IndexedDB
• No Web Notifications (that is a real shame for this platform – Firefox on Android is doing it-)
• No WebGL
• No History Management API
• No rich input controls! I’ve found a huge bug on the range input type (no rendering at all), and no date controls are working. Even it seems that Android 3.x has better support than 4.x (more testing soon)

New stuff

The new stuff for both smartphones and platforms I’ve found:

• Navigation Timing API, same API in IE9 on Windows Phone and in Firefox 7 for Android
• New Console API, but not working properly, for example there is a console.memory.usedJSHeapSize and console.memory.totalJSHeapSize attributes, and some new functions but I could not make them work yet.
• The HTML5 <keygen> new form is available
• Basic MathML seems to work

New things to know

It’s time again for a new version of iOS for iPhone and iPad and a bunch of news about mobile web development. I’ve analyzed every new feature I could found in Safari on iOS5, including what’s the final resolution with expected features as WebGL (3d) on Safari.

Overview of new things

• HTML5 new APIs and feature support, including: Web Workers, Web History, new web form controls, inline SVG, MathML, Compass support, new external script attributes, some new CSS3 improvements and contenteditable
• Fixed zones and scrolling areas support
• New tabbed browsing for iPad but no desktop-like support
• Performance improvements and Nitro engine on home screen webapps

HTML5 news for iOS 5

HTML5 Elements

Safari on iOS still doesn’t render anything special on the new elements progress, meter, detail and summary. If your web content is well and semantically designed, the new reader mode will be activated and your content will be converted into a “article mode” view if the user presses the reader button on the URL bar. There is no API or attributes to manage or customize reader mode. Create a good mobile web experience and your user will never use the reader mode :).

Web Workers

We can use workers to execute code in a different thread than the main UI thread using the HTML5 Web Workers API. This is great to provide good UI experiences when using lot of JavaScript execution.

New Input types support

iOS 5 supports new form rich controls using the input element, supporting range (rendered as a nice touch slider) and most date/time controls using date, time, datetime, month and datetime-local. From the HTML5 standard, color and week selector are still unsupported being rendered as plain text inputs. Datalist is still unsupported.

That is how this simple HTML elements are being rendered on iOS5 (iPhone and iPad):

<input type="date">
<input type="datetime">
<input type="month">
<input type="range" min="0" max="40">

Inline SVG

Now we can embed easily SVG graphics and animations using inline SVG, a new way to embed this kind of files inside an HTML using just a svg element, like que next example:

ClassList API

Now we can use this new API on every DOM node using the classList attribute that provides different methods for class manipulation (a la jQuery) such as add, remove, toggle and contains. For example: menuList.classList.add('touch');

ContentEditable

This new attribute, global to all the HTML5 elements, allows us to convert any HTML element into an editable one. That means that now a user can edit a list (ul element) or even we can create rich editors for iOS using contenteditable and execCommand. On my quick tests most visual rich editors for HTML are working properly on iOS5. Some of them are not optimized for touch, but in functionality, you can change formats and styles without any problem.

Here you have CKEditor working on iPad:

History Management API

Now we can change the URL without refreshing the page (and without using #) with this new API inside HTML5 standard. It exposes some new methods over the history object, such as pushState.

Canvas

Now it is hardware-accelerated as in Internet Explorer 9, so the performance is much more faster. CanvasPattern is now supported.

Geolocation and iOS Simulator

The iOS 5 Simulator for Mac now includes the ability to simulate different locations using latitude/longitude.

MathML

The markup language for math expressions is now available on iOS, so we can use the new math element in HTML and provide a MathML document inside. However, not every math special character is rendering propertly as I could check, such as Sum and big parentheses.

XMLHttpRequest 2

XHR 2 is now supported but to be honest, it’s absolutely useless as file uploads and File API are disabled in Safari on iOS. The great advantage of XHR 2, the progress upload mechanism, is not allowed.

LocalStorage

Now it can be cleaned by the user in Settings > Safari at the same time as cookies. The other new thing to keep in mind is that now a Private Browsing mode exists and we will receive exceptions if we try to use any offline API, such as LocalStorage, inside this mode. Keep in mind that you should catch this exceptions.

When activating Private Browsing Safari changes its whole UI to black:

Error handling

Finally, window.onerror event is exposed so we can catch any JavaScript exception easily.

DeviceMotion API

Compass support is available in the devicemotion event through new attributes: webkitCompassHeading and webkitCompassAccuracy. There is also a new event we can subscribe to: compassneedscalibration. This will work only on iPad 2, iPhone 4, 4S and iPod touch last generation.

Font Design

Some CSS3 features were enhanced, such as support for :first-letter pseudo-element to have a different style for the first letter of a paragraph. Also text-rendering: optimizeLegibility; is now improving handling of kerning pairs and ligatures on typography. Now, WOFF (Web Open Font Format) is supported for CSS3 Web Fonts.

New Gradient Syntax

The new WebKit gradient syntax is supported, including: -webkit-linear-gradient, -webkit-radial-gradient, -webkit-repeating-linear-gradient, -webkit-repeating-radial-gradient

External script files

Async scripts are now available using the async attribute. With asynchronic external script references, the script will be loaded without interfering with other resouces’ downloads.

<script src="external.js" async></script>

It’s also available the defer attribute that allows the browser to defer the script execution until onload executes first.

<script src="external.js" defer></script>

Sandboxed iframes

Now, an iframe can have different security implementations regarding the sandbox attribute as defined in this spec.

Keep Waiting

We still don’t have WebGL (3d canvas) even after demonstrating that WebGL is definitely there. It is deactivated and the rumor says that it’s there only for iAds usage inside a native app. We still don’t have IndexedDB, so Web SQL is the way to continue working with databases. And File Uploads or Camera APIs are also unsupported.

Fixed Zones

Finally, position: fixed is now working. This means that we can now leave those obscure tricks using touch events to emulate fixed toolbars and a lot of JavaScript code (equals CPU usage, equals battery consumption) for emulate momentum animation.

Keep in mind that when using position: fixed and a scalable viewport (or no viewport definition at all), the fixed zone zooms in/out as the viewport and it’s not really fixed as we could expect.

BTW, if you have a desktop website (not mobile-optimized) and fixed zones, you have a big problem! The fixed zones will create useless experiences when the user zooms in.

Scrolling zones

Before iOS 5 any scrolling zone, such as an element with overflow: scroll or an iframe had usability problems. That is because the user needs to use a two-finger scrolling gesture to scroll inside smaller areas in a page.

Now this problem has ended, as now every inner scrolling area will be scrolled using only one finger. And a new CSS extended attribute allows us to define what kinds of scrolling do we want: -webkit-overflow-scrolling that can accept auto (standard “desktop-like” scroll) or touch (with momentum, like native iOS applications or even like the page scroll momentum).

.scrollingWithMomentum {
height: 200px;
overflow: scroll;
-webkit-overflow-scrolling: touch;
}


Tabs in iPad

On iPad with iOS 5 we have now navigation using tabs. But be very careful! Tabs don’t work as in desktop. No tab will work in background or execute any background JavaScript and there is also no favicon support for the tab name. The user can now open a tab in background but your page will be live until onload and it will be frozen and reactivate when the user activate the tab.

If the browsers needs memory can release our page (even being already on an open tab) and when the user activates, the page will be reloaded. We can use sessionStorage to store information for this case.

Performance and Nitro

There is an excellent coverage of performance on iOS5 on Blaze.io blog, so I will not get deeper in this topc. Performance on HTML5 is really improved, as well as some HTTP techniques for loading pages faster. After my testing I can now conclude that Nitro engine is now available on Home Screen apps and it’s still out of UIWebView (PhoneGap-like apps and pseudo-browsers such as SkyFire).

Conclusion

iOS 5 is in the line of HTML5 evolution but it still owe us some new features that are being added in other mobile browsers, such as WebGL, HTML Media Capture API, Device Network Information API and maybe a remote web inspector.

However, Safari on iOS is still the leader in terms of mobile browsers and it’s still the most important browser today to look at when developing mobile web experiences. However, be responsible and don’t create applications and websites that only works on Safari or WebKit.

What do you think? Are you happy with the new changes? Were you expecting more? Did you find anything else new? Feel free to use the comment area!

September 2011 was a busy month for the mobile web space. While we are still waiting for iOS5, Android Ice cream sandwich, new mobile browsers appeared in the ecosystem: Internet Explorer 9 for Windows Phone 7.5, Firefox 7 for Android and the upcoming Amazon Silk to be included in the new Amazon Prime tablet.

While the mobile space changes, there is one problem in the HTML5 world: the web community doesn’t fully understand the mobile world. That is why excellent resources such as Modernizr & Caniuse.com don’t have accurate information about the mobile web space and web developers should not rely on that information.

HTML5 is on everybody’s mouth but web developers have a great challenge: understanding mobile web space and guessing if an HTML5 feature has enough compatibility in the market to start using and testing with it.

That is why, while I was presenting at the great Breaking Development conference in Nashville, I’ve announced a new project: MobileHTML5.org.

Back in 2010 for my book Programming the Mobile Web, I’ve made a lot of testing over dozens of different mobile browsers. And that was the start for this new project.

And now I have a new big impulse for creating this site, a new upcoming book is now official: Mobile HTML5 to be published in early 2012 by O’Reilly Media, co-authored with Estelle Weyl, a great partner for this new project.

So MobileHTML5.org is the result of hours of testing over mobile browsers and I hope everyone can use and contribute to. This is just the start and I’m planning a bunch of new features for the following weeks, including: getting deeper in each API to understand differences between platforms; testing suites and code samples.

On July, 26th I’m doing a workshop at OSCON about jQuery Mobile. If you are there (or not) here you can download the files we are going to use there. It’s algo a very good time to present my new book jQuery Mobile: Up and Running, available un Early Access.

Download workshop files

Velocity is an excellent annual conference organized by O’Reilly about web performance (WPO) and web operations. This was my second Velocity as speaker and I’m really surprised how bigger the show is this year. I did a workshop about mobile web & html5 performance optimization and here you have my presentation.

If you attended my workshop in Santa Clara, California and you have a feedback about it, please use the official workshop page to give it. You can always comment here or send me an e-mail, of course. Thanks again to Steve Souders, the guy behind WPO (Web Performance Optimization) and Velocity co-chair for inviting me again to this great conference.

Full video of my conference will be available later!

As you may already known, iOS 5 beta 1 was released for registered developers and there was a presentation showing some of the new features in Safari. I’ve made the usual investigation to see what’s new and I find a way to show you what’s new in HTML5.