Mobile Web Development

Mobile devices have quite different hardware characteristics compared with desktop or laptop computers. Their screens are usually smaller, obviously, but they also usually automatically switch the screen orientation between portrait and landscape mode as the user rotates the device. They usually have touch screens for user input. APIs like geolocation or orientation are either not supported on desktops or are much less useful, and these APIs give mobile users new ways to interact with your site.

Responsive Web Design is a term for a set of techniques that enables your website to adapt its layout as its viewing environment — most obviously, the size and orientation of the screen — changes. It includes techniques such as:

• fluid CSS layouts, to make the page adapt smoothly as the browser window size changes
• the use of media queries to conditionally include CSS rules appropriate for the device screen width and height

The viewport meta tag instructs the browser to display your site at the appropriate scale for the user's device.

To use a touch screen you'll need to work with DOM Touch events. You won't be able to use the CSS :hover pseudo-class, and will need to design clickable items like buttons to respect the fact that fingers are fatter than mouse pointers. See this article on designing for touch screens.

You can use the pointer or any-pointer media query to load different CSS on a touch-enabled device.

To help users whose devices have low or expensive bandwidth, you can optimize images by loading images appropriate to the device screen size and resolution. You do this in CSS by querying for screen height, width, and pixel ratio.

You can also make use of CSS properties to implement visual effects like gradients and shadows without images.

Finally, you can take advantage of the new possibilities offered by mobile devices, such as orientation and geolocation.

To create websites that will work acceptably across different mobile browsers:

• Try to avoid using browser-specific features, such as vendor-prefixed CSS properties.
• For browsers that don't support these features, as long as the content is still usable, do not provide a vendor prefixed fallback. Vendor-prefixed property like -webkit-border-radius, harm performance in browsers that are so old they don't support modern standards.
• To use new features with fallbacks that don't harm performance, style to target current browsers, then use the @supports feature query to serve modern CSS to supporting browsers.

See this list of Gecko-specific properties, and this list of WebKit-specific properties, and Peter Beverloo's table of vendor-specific properties.

It's preferable for websites to detect specific device features such as screen size and touch screens using the techniques listed above, and adapt themselves accordingly. But sometimes this is impractical, and websites resort to parsing the browser's user agent string to try to distinguish between desktops, tablets, and phones, to serve different content to each type of device.

If you do this, make sure your algorithm is correct, and you aren't serving the wrong type of content to a device because you don't understand a particular browser's user agent string. See this guide to using the user agent string to determine device type.

Test your website on multiple browsers. This means testing on multiple platforms — at least iOS and Android.

• test mobile Safari on the iPhone using the iOS simulator
• test Opera and Firefox using the Android SDK. See these additional instructions for running Firefox for Android using the Android emulator.