Working on HTML(5) for mobile sites (Mobilizing websites with responsive design and HTML5 part II)

This blog post is a part of Mobilizing websites with responsive design and HTML5 tutorial. For all posts please see the Introduction post.

There is no separate “mobile HTML”.

Mobile sites are normal HTML sites. Separate WAP protocol has been dead several years now. “XHTML mobile profile” is also dead. Most phones do normal HTML just fine.

Also in developing countries, where the usage of mobile Internet is more prevalent over desktop internet and the device base is geared toward feature phones with less powerful web browsers, thin client browsers like Opera Mini are widely used and support normal HTML just fine.

The major web experience considerations on mobile phones are not technical, in protocol wise. They include

Small screen estate
Lack of physical keyboard
Touch screen instead of mouse as a pointer device

Smartphones like iPhone, Android and Blackberry devices support new HTML5 and CSS3 features and in some cases mobile browsers are more advantaged than their desktop counter-parts. Even if you don’t like Apple as a company per se, they have done a great deal to push HTML5 forward in mobile space and taken the mobile browsing user experience from old, clumsy, WAP era to something you can actually enjoy.

1. There is no HTML5; there is only HTML

There never will be a finalized HTML5 standard and asking the question when HTML5 is ready is pointless. Browser vendors keep adapting evolving HTML features to their browsers continuously and it is up to feature detection and graceful fallbacks to determine whether you can do the trick with the browser or not.

In mobile space HTML5 features provide enhancements making the surfing experience better

Specialized input fields for better text input on non-hardware keyboards
Using CSS3 styles instead of images for layout effects; this reduces HTTP transfer payload making pages load faster
Touch event support
<video> and <audio> multimedia (as oppose to Flash)
etc.

2. Strategies for building a mobile site

There are several options for “mobile strategy” of your site

Responsive layout, as described in this tutorial
Using a stock mobile theme or add-on for open source CMS (Web and Mobile, WPTouch)
A theming HTML proxy, like Diazo, is an option when you cannot touch the front-end template source code at all. A theming proxy reads web HTML, parses it and transforms the result to new mobile HTML output based on (XSLT) rules
A commercial scraper which is a theming proxy with fancy UI e.g. Mobify.me
Client-side transformations with Javascript, like Mobilize.js
Have a separately maintained mobile site, using mobile specific CMS with information duplicated by hand or using a custom integration. Suits for large organizations where the marketing budget is big and internal communications are an issue.

What strategy you should use depends on your IT skill, organization structure and business goals. You need to balance between the wanted user experience level, budget and available competence.

3. Tools for mobile site building

Since mobile sites are normal HTML there is no need to have specific “mobile SDK” or “mobile IDE”.

When you are working on mobile HTML, excluding the device testing phase, a normal web browser fine. Use Firefox + Firebug or Chrome/Safari + developer tools. You usually don’t want to develop on mobile browsers directly, as they lack CSS inspection tools, Javascript debugger or any interaction with the HTML page source.

Note: Opera mobile browsers provide some decent HTML, CSS and Javascript remote debugging capabilities thru their Dragonfly debugging toolbar

4. Spoofing the development browser as mobile

When mobilizing a web site with responsive design, the only trick you usually need to pull is to shortcut the responsive CSS loading so that the development browser loads the mobile stylesheets.

You can do this in your own code level: instead of selectively load mobile.css file force it to be loaded in the desktop browser too by hardcoding mobile.css to be loaded for all browsers.

You could include a server-side conditions which allow you to perform the spoofing using an URL parameter:

http://site.com/?force-mobile=true

On Javascript level touch events might also needs spoofing.

Note: It is not worth of doing mobile development using Internet Explorer as the development browser. Microsoft has recently improved their track record regarding open web standards, but they still have few years catch up to do in order to be able to match the pace of the competition.

5. User agent detection

User agent is a HTTP request header which the web browser uses to tell the web server the software version the web browser is running.

User agent detection is a method of discriminating mobile devices on the server-side and serving them a different HTML payload. I strongly discourage using this old and deprecated method of mobilization in the contemporary world unless you really really have to.

The philosophy of HTML is to let the client device decide how to display the information, not the web server to guess how. Today mobile devices support enough Javascript to make it possible.
User agent detection is fragile, because the user agent strings themselves are a mess and different devices may have the same user agent or the same devices different user agent: false positives ensure
You need to maintain a server-side database of devices and the quality of available databases leaves room for improvement
Different HTML payloads varying by user agents destroy front-end caching performance, as there are thousands of device types and each would create its own front-end caching entry
It seems that widely spread, semi-open, device database project Wurlf is alienating its users

If you need to have different code paths for mobile devices then use something like detectmobile.js which performs the mobile feature detection on the client-side, effectively replacing 5 MB user agent string database with 100 lines of Javascript.

6. Native apps

A native application is nowadays almost synonym for “embedded WebKit” – unless you are doing some really high profile applications. The apps are out of the scope of this tutorial.

If you need to wrap your mobile site for App Store, Android Market, etc. distribution you can use PhoneGap. The user experience is not as great as building expensive 100% native application from the scratch, but the price tag is usually something you can swallow easier.

$\"\"$ Subscribe to RSS feed Follow me on Twitter Follow me on Facebook Follow me Google+

Open Source Hacker

Pushing the boundaries of free technology