Mobile Web Application Best Practices

W3C Working Draft 29 July 22 December 2008

This version:

http://www.w3.org/TR/2008/WD-mwabp-20080729/ http://www.w3.org/TR/2008/WD-mwabp-20081222/

Latest version:

http://www.w3.org/TR/mwabp/

Previous version:

http://www.w3.org/TR/2008/WD-mwabp-20080729/

Editors:

Bryan Sullivan, AT&T

Adam Connors, Google

Copyright © 2008 W3C ^® ( MIT , ERCIM , Keio ), All Rights Reserved. W3C liability , trademark and document use rules apply.

3.1.2 Use Automated Means for Identifying Automatically Identify the User and Obtaining Personalization Information

3.1.2.1 What it means

Ensure that personalization information is available to the user with minimal effort. effort by using their identity to automatically restore application preferences.

3.1.2.2 How to do it

The A Service Provider (e.g. Mobile Network Operators or Web Portal Providers) or an Identity Management Provider may provide means to access trusted user identities automatically. This has the advantage of removing the need for the user to enter their identity at all and will provide an optimal experience.

Alternatively, the simplest way to do this identify the user is to associate personalization information with a given user identity and obtain their prompt for login credentials directly on first access. access and store a Hashed identity token in a cookie for future accesses. Recommended methods for doing this include:

• HTTP Digest Authentication.
• HTTP Basic Authentication (in which case it must be over a secure HTTPS connection, see 3.2.1 Protect Personal Information Used in Transactions ).
• Web form (delivered over a secure HTTPS connection).

3.2 Security and privacy

Use trusted information, and protect all personally identifiable information.

3.2.1 Use HTTPS when Exchanging User Credentials

3.2.1.1 What it means

Although HTTPS is the most common means to secure personally identifiable information, the overhead of using it can be significant over a mobile network. As such, HTTPS should not be used unnecessarily, and the level of security should be matched to the level of sensitivity of the information being exchanged.

Personally identifiable information (e.g. user identity or information usable as a key to user identity) should only be accepted or sent securely. Less sensitive information that cannot be associated with an individual (e.g. a zip code by itself is not personally identifiable) can be exchanged in the clear does not need to use HTTPS provided the correlating information is secure.

3.2.1.2 How to do it

HTTPS is the most secure way to exchange sensitive information such as user-identity. To avoid the overhead of using HTTPS for all transactions, a related pseudo-identity or secure hash of the actual identity can be exchanged in non-secure transactions.

HTTPS should always be used to exchange the initial user credentials, but subsequent requests need not use HTTPS provided the user identity is exchanged in the form of a Hashed Identity Token.

The Working Group working group is interested in receiving looking for feedback on the validity of this Best Practice. Whilst it is a true reflection of techniques for securing personal data on mobile devices, commonly in use, it risks exposing the Hashed credentials in the network proxies and might pose an unacceptable security risk.

3.2.2 Secure JSON Datafeeds

3.2.2.1 What it means

A common paradigm in Web applications is to provide a datafeed to an JavaScript based Web client in the relative impacts form of an executable JavaScript string (e.g. JSON). This has many advantages in terms of speed of execution and ease of development, but it represents a significant security flaw which can expose user-data to malicious Web sites.

If a JSON datafeed is executable, a malicious Web site can reference it in a <script> element. This will execute the datafeed using HTTPS the cookies associated with the data providing site and other techniques. in most cases generate a JavaScript object model in the client which can be accessed by the malicious site.

3.2.2.2 How to do it

The JavaScript datafeed should be protected by a prefix that will prevent execution directly, but which can be stripped off prior to execution when accessed by an XHR request.

	    { username: "My Name", 
	    
	      contacts: [ 
	      {name: "Contact1", phonenumber: "xx-xxx-xxxx"}, 
	      {name:
	      "Contact2",
	      phonenumber:
	      "xx-xxx-xxxx"}]
	      }
	    
	

	    while(1); { username: "My Name", 

	    
	      contacts: [ 
	      {name: "Contact1", phonenumber: "xx-xxx-xxxx"}, 
	      {name:
	      "Contact2",
	      phonenumber:
	      "xx-xxx-xxxx"}]
	      }
	    
	

3.2.3 Use a Safe EVAL for JSON Datafeeds

3.2.3.1 What it means

If a JSON datafeed is being parsed using the eval(); method it is vulnerable to script attacks. For example, if the feed contains user entered data this data might replicate the JSON syntax in order to compromise the application.

3.2.3.2 How to do it

There are a number of steps which can be used to protect against this kind of attack, use the one most appropriate to the context:

• Ensure that the data comes from a trusted source (e.g. contains no user-generated data).
• Use a "Safe EVAL" method which encodes any unsafe characters in the datafeed before evaluating.

The working group is looking for feedback on an example "Safe EVAL" algorithm that can be shared here, or a publicly available library that can be referenced.

3.3 User awareness and control

Ensure that the user is aware of application behaviors that might affect the overall service experience, application behaviour, and that the user is offered options to control those behaviors.

Many browsers support the ability to make background server requests without requiring a page refresh. server roundtrip. This makes it possible to make server requests that are not automatically reflected in the user-interface and which might surprise the user or lead to unexpected data charges.

Device APIs are being developed in a variety A number of standards activities standard and vendor-specific initiatives proprietary APIs exist to give browsers access to both personal and device information, for example:

• File system access to pictures, music, and video clips
• PIM data (contacts, calendar)
• Call handling
• System data (battery, coverage, roaming, location)
• Media recording (record audio/video clip, get new picture)
• Device context (e.g. location, connectivity, profile setting)

The use Use of such personal information and device functions can expose the user to privacy and security concerns.

The overall goal is that the user is informed of such activities, given effective means to control them, and also the opportunity to opt-out of application/function their use.

3.3.1 Inform the User About Automatic Network Access and Provide Control Over its Use

3.3.1.1 What it means

Whenever an application makes background data requests, whether automatic or user initiated, user-initiated, this should be indicated to the user in an appropriate manner so the user is not surprised by unexpected data-charges, etc. Means should be provided to disable any automatic network activity. manner.

3.3.1.2 How to do it

Applications should disclose, in a clear and useful way, the basic nature of their use of the network. A simple icon indicating background activity is usually sufficient and will not interrupt the main application flow. If extensive background network activity is required this the user should be called out informed when the user they first visits visit the site, when they first log-in, or in associated help pages.

The kinds of detailed information that could be disclosed in associated help pages or terms of service are:

• how often the application will interact with the internet. E.g. every 5 minutes, hourly, daily.
• how long the automatic behaviour will continue.
• how heavy the overall usage is expected to be or the type of service plan recommended.

3.3.2 Provide Sufficient Means to Control Automatic Network Access

3.3.2.1 What it means

If an application makes automatic network requests (e.g. to poll the server for updates or to automatically store an updated client state) a means to control this activity should be provided provided.

3.3.2.2 How to easily disable / re-enable this do it

At a minimum, provide the ability to switch off the automatic network activity. Endeavor to keep the application as functional as possible even if automatic network activity is disabled. disabled by prompting the user before making network requests.

If appropriate, it might be desirable to enable the user to adjust the level of network activity. For example, by adjusting the polling-schedule, or controlling which activities are allowed to initiate network requests.

3.3.2 Inform 3.3.3 Ensure the User is Informed About Use of Personal Information and Degrade Gracefully if Permission is Denied Device Information

3.3.2.1 3.3.3.1 What it means

Ensure that the user is informed when if the application accesses needs to access personal or device information. The user should be informed of the types of information that will be used by the application and how that data will be exchanged with the server. Applications should be defensive and remain as functional as possible if the API request for personal or device information is denied.

3.3.2.2 3.3.3.2 How to do it

In many cases APIs that provide access to personal or device information deliver a native confirmation dialogue to the user before providing access to the data. In this case the application should not force the user to confirm again at the application level, but should make clear in the UI that displayed data has been accessed from the device.

If the user declines a prompt to allow application access to personal or device information, the application must recover gracefully. For example, if a request to a device API fails, do not automatically retry if this might will lead to the user being presented with repeated confirmation dialogues by the underlying API.

3.4 Conservative use of resources

Resources Resources, such as device memory, processor power, and network bandwidth are significantly more limited on mobile devices than on a desktop device. As a result, Web the desktop. The most effective way to ensure that applications should use device run smoothly and network resources conservatively. with low latency is to take steps to ensure minimal use of resources.

3.4.1 Use Transfer Compression for Content

3.4.1.1 What it means

Compress content for efficiency in efficient delivery.

3.4.1.2 How to do it

HTTP 1.1 compression, which typically uses gzip or deflate as algorithms, is a widely (though not universally) supported method of transfer encoding for delivery optimization. To use HTTP compression, compression. In general, Web servers should be configured to serve Web pages using HTTP 1.1 compression (gzip or deflate), compression, according to the coding supported by the device as indicated by the HTTP Accept-Encoding header.

Note however, that the processing processor cost of decompressing data should be balanced against the gains in transport efficiency. As a rule of thumb the following should be considered when configuring HTTP 1.1 compression:

• Most binary data (especially JPEGs) will not benefit from gzip compression.
• For very small files (e.g. <1k) the negative impact of processing may outweigh any small transport gains.

The Working Group is researching the conditions under which compression should 3.4.1.3 Maximizing Compression Efficiency

Gzipping of HTML and CSS files can be recommended made more efficient by ensuring consistency in the code. For example:

• Ensure consistent ordering of attributes in elements (e.g. alphabetize them).
• Use consistent casing (e.g. all lowercase)
• Use consistent quoting (e.g. always use single-quotes)

3.4.2 Minimize Application Size

3.4.2.1 What it means

This section elaborates on mobile devices the Best Practices of BP1 ( MINIMIZE ). Smaller applications will download and execute more quickly and more reliably on constrained devices.

3.4.2.2 How to do it

• Process HTML and CSS files at build time to remove whitespace and minify. A number of Open Source whitespace strippers are available.
• Process script files at build time to remove whitespace and minify the script. Several Open Source javascript compilers are available.

The working group is looking seeking recommendations for feedback on the best / most-commonly used tools to reference in this topic. section.

3.4.3 3.4.4 Minimize Automatically Issued Network Requests

3.4.3.1 3.4.4.1 What it means

Applications that automatically issue network requests should provide value "value" for those requests. The "value" in this case should be determined by the application developer based upon the type of service the application provides, requests so as not to unnecessarily impact battery-life and the resulting direct value application performance. Take care to the user. ensure network requests are as well optimized as possible.

3.4.3.2 3.4.4.2 How to do it

Consider the following issues possibilities when designing an application:

Batching requests:

A single request for more data is much considerably more efficient than several smaller requests. Wherever possible possible, batch up multiple server requests. requests at the application level.

Backoff during periods of inactivity:

If the application polls for updates, it should monitor user-activity and poll less frequently if the user is inactive. Consider contextual factors: during inactive periods.

Device Context:

If possible, supported by the device, use awareness of the current connectivity (e.g. WiFi) and roaming status, to select an appropriate level of interaction. As a fallback, ensure that server requests are visible to the user and controllable. ( See 3.3.1 Inform the User About Automatic Network Access and Provide Control Over its Use )

3.4.4 3.4.5 Use Push Methods to Reduce Pull Traffic

3.4.4.1 3.4.5.1 What it means

Network-initiated content delivery ("push") methods can significantly reduce network traffic overhead, as compared to conventional polling (scheduled "pull") methods.

3.4.4.2 3.4.5.2 How to do it

Push method support may be disclosed through a User Agent Profile document if published by the device vendor, or through other device classification repositories.

If supported by the user agent, options for Push methods include:

• OMA Push: a widely supported enabler providing methods for user-confirmed and automatic content push, directed to mobile browsers and other user-agents user-agents. [ REF ]
• Alternative vendor-specific initiatives.

3.4.5 3.4.6 Minimize Application Size External Resources

3.4.6.1 What it means This section elaborates on the best practices of BP1 [section ref].

Ensure that the A Web application size is optimized in order to minimize the impact typically requires a number of operating resources (stylesheets, scripts, image, etc) each of which may incur an additional HTTP Request. HTTP roundtrips are particularly expensive on a limited bandwidth network. mobile network and so fewer, larger requests should be favoured over a larger number of smaller requests.

3.4.6.2 How to do it Various techniques can be used to minimize application size:

As far as makes sense after taking into account 3.5.8 Separate Rarely Used Functionality combine all stylesheets into a single resource and CSS files at build time to remove whitespace. Several Open Source whitespace strippers are available [REF] ? Process script files at build time to remove whitespace all scripts into a single resource. If multiple scripts and compile stylesheets are required as part of the script. Several Open Source javascript compilers authoring process, then try to arrange that they are available, for example: http://developer.yahoo.com/yui/compressor/ merged before the page is served.

3.4.6 Minimize DOM Manipulation 3.4.7 Consider Inlining Small Stylesheets and Script Resources

3.4.7.1 What it means

On small devices with limited processing capability, In some circumstances performance is improved if the cost of excessive DOM manipulation can significantly impact application performance. JavaScript and CSS stylesheet resources are inlined in the HTML page, since it eliminates the need for two additional HTTP requests required to fetch the external files.

3.4.7.2 How to do it

Only use DOM manipulation Investigate for dynamic parts a given application the optimum configuration. Whether inlined resources make sense or not depends on a number of factors. For example:

• The cache hit rate (e.g. the page. number of times an average user will successfully load script resources from the browser cache).
• The static framework size of the page is best created using HTML markup JavaScript and CSS files.
• The frequency with which can then be connected to the script using the element ID tag. JavaScript and CSS files change.

3.4.7 Minimize External Resources 3.4.8 Sprite Static Images into a Single Resource

3.4.8.1 What it means This section elaborates on the best practices of BP1 [section ref].

Web applications typically require multiple resource (e.g. stylesheets, scripts, images). On often depend on a mobile network, however, the overhead number of making static images to provide icons, buttons, etc. If served as a separate image each one incurs an additional HTTP requests roundtrip which is high and can significantly impact service latency. Steps detrimental to performance. To avoid this, all static images should be taken to minimize the number of requests made by the application. sprited together into a single image.

3.4.8.2 How to do it

The following steps can be taken to reduce network requests: Using manual or automatic means, combine all icons into a single image. To optimize the efficiency of this:

• For small stylesheets or script files it may be more efficient to inline them rather than making a separate request PNG and GIF files, sprite images with similar sizes and colour palettes.
• In general, avoid spites for each one. The downside in this case is that inlined resources can't be cached, JPEGs, but for small files (< XX K) the overhead of the additional request outweighs the potential benefit of caching the resource. if you do use them, sprite on 8x8 boundaries.
• Multiple stylesheets and script should Sprite images that don't change often -- e.g. if a single image in a sprite changes the whole sprite will need to be combined together. downloaded.

To render individual icons from a sprited resource using css positioning and clipping.

3.4.9 Inline Background Images in CSS Stylesheet

3.4.9.1 What it means

Background images are often used as gradients to improve presentation the look and feel of an application. These can be inlined in the css file CSS as base64 encoded strings in order to avoid an additional HTTP roundtrip.

3.4.9.2 How to do it

Background images can be embedded using the url("data:...") construct. data URI scheme: url('data:image/png;base64, [data])

3.4.10 Use Fingerprinting to Cache Dynamic Resources

3.4.10.1. What it means

Dynamic resources that change occasionally (e.g. a user's avatar) can still be cached by identifying them with a URL that includes a fingerprint of the resource content. Using this technique means that the browser doesn't need to check the resource headers in order to validate its cache, instead, any change in the resource will lead naturally to a corresponding change in the resource reference.

3.4.10.2 How to do it

• Set the resource caching policy to never expire by setting the Expires header to a date in the far future.
• If Reference the application resource using a URL that contains multiple icons these should be combined into a single image Hash of the content. If the content changes, this reference will change and then rendered as separate icons in the application using css clipping. browser will fetch the updated data.

3.4.11 Make AJAX Datafeeds Cachable

3.4.11.1 What it means

Datafeeds designed to be accessed by AJAX requests from the client should be cached in the same way as the primary content.

3.4.11.2 How to do it

The standard caching techniques ( Expires header and Cache-Control header), as well as resource fingerprinting can be used on AJAX datafeeds as readily as primary content pages.

3.4.8 3.4.12 Use Power-Efficient Methods

3.4.8.1 3.4.12.1 What it means

As mobile A Web applications become increasingly ubiquitous they are more likely to be required application is not guaranteed to run for long periods of time or be on suspended if it is placed in the background (e.g. an email application or an IM client). and may continue running for a long period. In these circumstances, this case, the application's impact of prolonged JavaScript operations on battery life battery-life should be considered.

3.4.8.2 3.4.12.2 How to do it

• Network activity is the most dominant biggest drain on battery power. If the application requires ongoing network activity (e.g. to poll a server for updates) take steps to inform the user of this activity and minimize its impact on battery-life. See 3.3.1 Inform the User About Automatic Network Access and Provide Control Over its Use
• Excessive DOM manipulation over an extended period of time can also impact device battery life.

The working group is currently investigating the relative impacts of Web application activities on battery life in order to make more concrete recommendations.

3.5.1 Offer A Consistent View Across Multiple Devices 3.4.13 Minimize DOM Manipulation

3.5.1.1 3.4.13.1 What it means

Multiple On small devices may be used to access a Web application with limited processing capability, the same user credentials (e.g. a user may own multiple mobile devices or may access the same cost of excessive DOM manipulation can impact application from both mobile and desktop devices). Application consistency should be maintained across different consuming devices. performance.

3.5.1.2 3.4.13.2 How to do it

Only use DOM manipulation for dynamic parts of the page. The most common cause static framework of failing to offer a consistent application state across multiple consumers the page is best created using HTML markup which can then be connected to store too much information on the device (either script using the element ID attribute.

3.4.14 Reduce Cookie Size

3.4.14.1 What it means

Information stored in cookies or a local device database). To avoid this, use device based storage carefully is exchanged between the server and avoid storing personalization data on the device that would still client for every request, which can negatively impact performance.

3.4.14.2 How to do it

Use cookies sparingly, and consider alternative methods (see 3.1 Personalization ) for anything other than trivial amounts of data.

3.4.15 Don't Send Cookie Information Unnecessarily

3.4.15.1 What it means

Static resources don't need cookie information and so performance can be relevant if improved by serving these from a path or subdomain for which the application were accessed from cookies are out of scope.

3.4.15.2 How to do it

Use a different consumer. See 3.3.1 Inform domain, subdomain, or path name for static resources to the User About Automatic Network Access main application, and Provide Control Over its restrict the valid path of cookies such that they will not be exchanged when they are not needed.

3.4.16 Use JSON in favour of XML for Datafeeds

3.4.16.1 What it means

Asynchronous data can be delivered to the client in response to an XHR request in any form (HTML markup, proprietary format, XML, or JSON object model). Use JSON in favour of XML if possible.

• It is more compact.
• It is quicker to parse since it can be directly parsed using the eval method.

3.4.16.2 How to do it

A JSON datafeed can be built from an object model by hand, or an Open Source JSON builder ( The Working Group REF ). On the client, JSON is investigating readily parsed into a number of additional recommendations for this section javascript object model using the eval method. Note, however, that care should be taken to observe: 3.2.2 Secure JSON Datafeeds and is looking 3.2.3 Use a Safe EVAL for suggestions in this area. JSON Datafeeds .

3.5 User Experience

Given the difficulties and additional complexities of interacting with an application on a mobile device, special consideration should be given to the overall user interface in order to maintain experience. User experience is influenced by a good level number of usability. factors, including: perceived latency, interaction method, and data consistency.

3.6.1 Consider Different Device 3.5.1 Design for Multiple Interaction Methods

3.6.1.1 3.5.1.1 What it means

Interaction methods vary across different devices. Three main interaction methods should be considered:

• Focus Based This is the traditional mobile browser interface and is analogous to navigating with tabs on a desktop browser. As the user navigates through the page using the keypad the Based: The browser focus jumps "jumps" from link to link, in more advanced devices there is 4-way navigation so a user can control the flow more easily. link.
• Pointer based Many of the more recent browsers have implemented a navigation influenced by desktop browsers. Using the Based: Key-based navigation controls a pointer across the screen. Unlike the focus based devices the pointer that can cover all aspects any part of the screen, not just links. Touch based screen.
• Touch based devices allow the user to select links or other page elements Based: Events are related directly with to a touch position on the screen with finger or stylus. There is no concept of a pointer

Devices may implement one or focus. more of these approaches and it is important for an application to remain usable in all cases.

3.6.1.2 3.5.1.2 How to do it

Particularly where content requires multiple links (ie back/forward in carousel) or where the user's interaction with links is designed to give them feedback, the following factors should be considered:

Focus Based:

• Selectable elements can be widely spaced as the user can select them easily by jumping from link to link link.
• The current location of the user can be easily determined using as link elements will be in focus Normally only link elements will be in focus focus.

Pointer Based:

• Selectable elements that are associated need to be near each other as scrolling the pointer can be slow slow.
• The current location of the user can be easily determined using as link elements will be in focus All page elements can be scrolled over and so maybe in focus focus.

Touch Based:

• Selectable elements can be widely space spaced as the user can select them easily easily.
• No elements are in focus until they are selected so extra information cannot be passed to the user (e.g. rollovers will not work).

3.6.2 3.5.2 Use Scripting for User Interface to Improve Perceived Performance

3.6.2.1 3.5.2.1 What it means

Using script for dynamic parts of the page means that the view can be updated without a full page reload. Since re-rendering reloading the entire page can be slow on a device, this can greatly improves improve application usability.

3.6.2.2 3.5.2.2 How to do it

Script on the client can update specified parts of the page, identified either by the ID tag, the css classname, or Use asynchronous (XHR) requests to get additional information from the document structure. The content of these tags can then be updated, and new nodes server in response to user events and update the page DOM can be created and destroyed. to convey this to the user.

3.6.3 Don't Move the 3.5.3 Preserve Focus on Dynamic Page Updates

3.6.3.1 3.5.3.1 What it means

The ECMAScript JavaScript focus method can be used to move the focus to the part of a page that has changed. However, if unexpected, this can confuse or irritate the user, especially if returning to the previous focus is not easy. It can also make an application unusable, if the focus changes prevent the user from using other parts of the application.

3.6.3.2 3.5.3.2 How to do it

Use the ECMAScript JavaScript focus method only if it is essential to the use of the application, and does not inhibit user control/interaction.

3.6.4 3.5.4 Group Closely Coupled Views onto the Same Page

3.6.4.1 3.5.4.1 What it means

Most applications consist of a number of views (e.g. an email application consists of an inbox and the message detail view). User experience is improved if switching between these views does not require a full page reload. server roundtrip.

3.6.4.2 3.5.4.2 How to do it

Each view can be rendered in a DIV element which is hidden using css. Script Client-side script can be used to show and hide the relevant views and their reveal content updated with in response to user events without the need for a background server request. roundtrip.

3.6.5 3.5.5 Use hash URLs to Preserve Browser History and Enable Deep Links Fragment IDs for Application Views

3.6.5.1 3.5.5.1 What it means

Web applications can show multiple views by showing and hiding content. However, this means it is not automatically possible to link directly to these views and the browser <back> button cannot be used to move between previous views. Usability is enhanced by enabling both of these features:

• Enabling deep links (e.g. to the content of a specific email) means the user can still bookmark this view and return to it quickly.
• Enabling the browser history provides a natural method to navigate application views that is natively supported by the browser.

3.6.5.2 3.5.5.2 How to do it

Script can Each view within an application should be identified with a fragmentID (e.g. http://myapp.example.org/myapp#view ) and JavaScript used to update interrogate the browser URL and append a "hash" part location in order to the URL. A hashed section of the URL is a standard mechanism for defining different views within an application. For example, an email application may support and respect URLs of this form: determine which view to display.

3.6.6 Use URI Schemes for Device Functions 3.5.6 Make Telephone Numbers Clickable

3.6.6.1 3.5.6.1 What it means

Standardized URI schemes (link formats) have been defined for some common device functions, e.g. making phone calls and managing phone address books. These URI schemes, if supported, can enable users to easily use these functions from Web applications.

3.6.6.2 3.5.6.2 How to do it

The Wireless Telephony Application Interface Specification (WTAI) most broadly supported scheme is tel: as described in RFC-3966 .Use this as follows to make phone numbers easily diallable from the Web application:

<a href="tel:[PHONE-NUMBER]">[PHONE-NUMBER]</a>

3.5.7 Ensure Paragraph Text Flows defines

3.5.7.1 What it means

On small screens it's important that paragraph text flows to fill all the "wtai:" URI scheme available space. Fixed paragraph widths (even when optimized for accessing a variety of telephone functions. WTAI the device screen) are error prone, make it harder to support may be disclosed through multiple device formats, and will not support multiple orientations (e.g. landscape and portrait mode).

3.5.7.2 How to do it

Specify widths for elements containing paragraph text as a User Agent Profile percentage ( style="width:100%" ) in favour of using an absolute size ( style="width:660px" ).

3.5.8 Separate Rarely Used Functionality document if published

3.5.8.1 What it means

Perceived performance can be improved by separating out JavaScript and CSS styles that are not required by the device vendor. initial page. JavaScript and CSS styles associated with rarely used features should be bundled separately and downloaded only if those features are accessed.

RFC3966 defines 3.5.8.2 How to do it

Consider what functionality is being downloaded in a given script resource and how likely that functionality is to be used in the "tel:" URI scheme majority of requests. If some functionality is rarely used, it may make sense to partition this into a separate script to be loaded on demand. On demand loading can be accomplished by:

• Moving that functionality onto an entirely separate page.
• Creating an embedded frame to load the required additional resources in response to a page event.
• Using <link rel="prefetch">

The working group is seeking feedback on this Best Practice. Whilst it contains value for making phone calls. "tel:" very large / complex applications, the implementation of this technique and its support across even high-end devices is widely supported, since not clear. Specifically, IFRAMEs are known to have significant issues on many devices and so we are looking for validation that their use in this context is a good idea.

3.5.9 Enable Progressive Rendering

3.5.9.1 What it means

Progressive rendering means that the page will be displayed incrementally as it loads. In most cases this results in an improved perceived latency since content is available earlier.

3.5.9.2 How to do it

Place CSS stylesheet ( <style> ) elements in the <head> stanza at the top of the document and JavaScript ( <script> ) elements at the bottom of the document. Browsers will not progressively render a supported attribute page until the stylesheet has been loaded and will block while JavaScript content is parsed.

3.5.10 Ensure Consistency Between Desktop and Mobile

3.5.10.1 What it means

This recommendation builds on the recommendation in UAProf , support BP1 ( 5.5.1 Thematic Consistency ) and expands it to consider the application preferences and personalization data that form part of the overall experience on a mobile Web application.

User credentials valid on one device should be valid on other devices. User preferences captured on one device should be accessible on other devices. The most valuable example of this would be in offering a consistent experience where information entered during a desktop session is accessible in a mobile session and vice-versa.

3.5.10.2 How to do it

For application data to be shared between devices it must be determined from the stored on a server and cannot be stored locally on a device vendor. (e.g. using cookies or a local datastore). For any application data that is not exclusively relevant to the current device, favour storing it on the server so it can be shared by other devices.

3.7 3.6 Handling Device Capability Variation

NOTE: This section is too detailed and requires significant editing. The Working Group is still evaluating the appropriate recommendations for this section and is interested in receiving feedback. Device capability variation is a basic characteristic of the mobile Web environment. Web applications should adapt their content such that they render in an optimum way on as broad a range of target devices as possible.

3.7.1 3.6.1 Use Device Server-side Capability Detection for Static Device Capabilities

3.7.1.1 3.6.1.1 What it means

For some of the best practices included here, support is dependent upon application awareness of related static device capabilities. At the current time, this awareness capabilities that won't change (e.g. SVG support, screen-dimensions) it is limited preferrable to application server use of device detect these capabilities information provided by on the user-agent directly, or obtained from a Device Description Repository (DDR) based upon device identification, e.g. based upon server and adapt content before it is sent to the user-agent header. client in order to avoid transferring unnecessary data.

3.7.1.2 3.6.1.2 How to do it

Typically used methods of device capabilities detection:

• The "user-agent" header can be used to identify the device and/or user-agent, with detailed device capabilities then retrieved from device, and a DDR. Device Description Repository (DDR) can be used to retrieve a detailed description of capabilities.
• The "accept" header can be used to indicate specific MIME types compatible-to/preferred-by the user-agent. device.
• The "x-wap-profile" header (User Agent Profile or UAProf) can be used both as device identification and as a source for detailed device capabilities info.
• Retained information about the current/last used device for the specific user, can be used when preparing content for delivery to the user-agent at a later time. The type of information used will depend upon the way in which the request was received, and the support for the methods, e.g. headers, by specific user-agents. For example: for requests received directly from the user-agent, based upon information from the user-agent directly or forwarded by intermediaries for requests received from other intermediaries, information as available from the intermediary, e.g. for SMS-interworking gateways, the user's phone number

3.7.2 3.6.2 Use Reliable Methods Client-side Capability Detection for Determining Script Support Dynamic Device State

3.7.2.1 3.6.2.1 What it means

It can be tricky to determine For dynamic device state that might depend on the supported script capabilities configuration or context of the device (e.g. Is scripting enabled? Is the SDCard available? Has permission been granted for a PIM access?) detection must be done on the device. Use of reliable methods is recommended.

3.7.2.2 3.6.2.2 How to do it

When it is unknown whether a user-agent supports a given functionality, use Javascript Use JavaScript reflection to check for available functionalities. This avoids determine if a given API is active and interrogate the error-prone approach of trying device configuration using appropriate APIs. Two methods can then be used to parse adapt on the user-agent string client to determine Javascript support. An example differing configurations:

1. Encapsulate the different behaviours in the control logic of how the application. E.g. simply use: if (some_configuration_variable) decision-points in the code and behave accordingly.
2. Use an initial "bootstrap" script to use Javascript reflection: assess device capabilities and request the appropriate application bundle accordingly.

Use Javascript Reflection Option (1) is simpler to implement and if statements + if(window.ActiveXObject) { // Instantiate using new ActiveXObject } else if(window.XMLHttpRequest) { // Instantiate using new XMHttpRequest } is appropriate provided the amount of inactive code downloaded doesn't have a negative impact on performance. Option (2) is preferred when the application must change significantly in response to properties that can only be determined on the client.

3.7.3 3.6.3 Use Device Classification to Simplify Content Selection/Adaptation Adaptation

3.7.3.1 3.6.3.1 What it means

It can be complex If a large number of devices are being targetted, or the application is sensitive to select and adapt content based upon dynamic assessment the permutations of device capabilities. A commonly used alternate approach involves off-line assessment a large number of configuration properties, the number of application variants required might quickly become unmanageable.

To combat this, classify target devices with resulting assignment into "classes", e.g. "good", "better", "best". The definitions of the classes, different "buckets" and build a single application variant for each device assignment to classes, is typically Content Provider specific, i.e. based upon assessments specific to bucket.

This will keep the needs amount of the Content Provider. device-specific code to a minimum without unduly encouraging a "lowest common denominator" solution.

3.7.3.2 3.6.3.2 How to do it

Adapting Web application content and services to mobile devices may be simplified by assigning devices and user-agents (e.g. browsers or other Web applications as identified by Identify the HTTP user-agent header, or other information) to "classes". The "richness" of target devices for the Web application as provided can then be more easily matched and assign these to the broad range "buckets" of capabilities represented by the varying capability. Focus on application variants that work in each bucket rather than building device-specific exceptions for every variation in device class. configuration.

Device classification is partly subjective and partly objective. The aspects buckets should be defined on an application-specific basis, so that affect the classification will vary depending upon the focus of the Web application, and the device/user-agent features it depends upon. Some example classes for web browsers may include: "Good": Serve these devices very basic pages. These devices are typically WAP1 or WML-only handsets with black and white screens. Ringtones are supported, but MIDP applications, wallpapers, and scripted applications are not. "Good" devices also include such color-screen WML phones on which pictures variants can be presented through tailored accordingly. For example, the browser, and javascript applications can be emulated by web servers. Some devices in this category may claim xHTML following is a typical configuration of application buckets:

Bucket 1: Basic XHTML support, but have slow processors, no or the supported xHTML is incomplete. "Better": These devices have solid xHTML support with color screens, and support MIDP, graphics, and ringtones. However they do not support scripted applications. "Best": The "best" device category includes features from the "better" category plus streaming video capabilities, UMTS/HSDPA, and special audio clients. Scripted applications may be supported, but script support likely requires verification before use. very basic scripting. No AJAX support.

Once the device/user-agent is identified, the assigned class can be obtained from the DDR used by the Content Provider, Bucket 2: Full AJAX and content then provided consistent with the assigned class. JavaScript support.

Bucket 3: Advanced device APIs, for example: access to location API, device PIM data, or application cache.

3.7.4 Provide Alternatives to Client-Side Scripting 3.6.4 Support a non-JavaScript Variant if Possible

3.7.4.1 3.6.4.1 What it means

Scripted applications, e.g. using asynchronous I/O methods or ECMAScript/Javascript in general, may and XHR based applications are not be yet well supported by some on many browsers. Pages designed to use scripting will require alternate approaches in browsers that do not support scripting, so you should be prepared for that and If possible, provide similar functionality in case scripting is a variant of the application that does not available. rely on script by using synchronous FORM posts instead.

3.7.4.2 3.6.4.2 How to do it

Detect browser capabilities or user preferences, and react accordingly with graceful degradation or progressive enhancement of Javascript/ECMAScript. Design targeting purely desktop/laptop audiences (where media="screen") tends to be structured to degrade gracefully if ECMAScript/Javascript is not present or if advanced capabilities like asynchronous I/O (and other "AJAX" techniques) are not supported. Design targeting a mixed audience of mobile (where media="handheld") and desktop/laptop users should be structured to both degrade gracefully (if ECMAScript/Javascript Essentially this BP states that it is not present) and likewise to progressively enhance page- and user-behavior capabilities (if ECMAScript/Javascript does turn out to be present). Separate behavior from content and presentation, for graceful degradation and progressive enhancement. Good logical design separates XHTML content (the "data model"), CSS presentation (the "view"), and ECMAScript/Javascript behavior (the "controller"). Designers targeting purely desktop/laptop audiences (where media="screen") tend favourable to duplicate support "Bucket 1" devices as defined above if at all possible. Doing this in will ensure that the physical site structure, placing each in its own file and having pages issue an HTTP request for each separately through use application can be used across as broad a range of the <link/> or <script/> tags. Designers targeting purely mobile (where media="handheld") audiences tend to interleave the three concerns into one physical payload/file delivered to the client devices as possible. Furthermore, in order to reduce per-request charges. Designers targeting some cases a mixed audience of mobile and desktop/laptop users non-JavaScript version can build Web pages which load sufficient ECMAScript/Javascript (in the <head/> element) to determine device display and interaction capabilities when first loaded. This allows for progressive enhancement, just as good structural design of XHTML allows for graceful degradation. Techniques similar to progressive enhancement of CSS (see 5.9.5) may also sometimes be used to inject event-handling Javascript/ECMAScript code into files at request-time and to attach Javascript/ECMAScript behaviors at run-time useful for progressive enhancement. simple operations in low-bandwidth situations.

In some cases, however, the example below, page-scope variables and functions are declared in type of application simply has no non-JavaScript counterpart (e.g. a <script/> element in the <head/> while run-time test code for progressive enhancement is declared Web based game, an IM client) in which case it should return a <script/> element in the <body/> element (to allow the DOM to be loaded before 406 Not Acceptable response.

Do this by detecting the code runs): [NOTE to WG: see http://chw.rit.edu/test/progressiveEnhancement.html for complete code as running example] device User-Agent and checking its JavaScript support against a DDR or local index.

3.7.5 Provide for Both Graceful Degradation & Progressive Enhancement 3.6.5 Offer Users a Choice of CSS Interfaces

3.6.5.1 What it means CSS may be incompletely supported by some browsers. Pages using positioning and visibility control are not supported by some browsers.

Site design to support both desktop/laptop users and mobile Not only is device users will require alternate approaches for browsers that do not support positioning and visibility control. You should provide characteristics detection imperfect, it cannot always account for both graceful degradation (in the case of no or minimal CSS support) and progressive enhancement (in the case differing use-cases of full positioning and visibility control support) an application. If multiple flavours of CSS by the client at run-time. application exist (e.g. to support the various device buckets) it might make sense to offer the user the choice of which flavour they wish to use.

3.6.5.2 How to do it

Detect browser capabilities or Only if it makes sense in the specific context of a given application, allow the user preferences and react accordingly. Design targeting purely desktop/laptop audiences (where media="screen") tends to be structured switch to degrade gracefully: first a different flavour (for example, upgrading their experience if ECMAScript/Javascript their device is not present, and then more capable than the server believes, or degrading if CSS connectivity is not supported. Design targeting a mixed audience of mobile (where media="handheld") poor and desktop/laptop users should be structured they wish to also progressively enhance CSS. Advanced CSS capabilities should accomplish a very simple task that can be separated from basic CSS, and inserted into done more easily with the DOM by minimal UI).

Always attempt to default to the client as most appropriate at run-time. Separate behavior from content and presentation, for graceful degradation and progressive enhancement. UI on first use.

Always remember the <head> element) CSS user's preference for mobile audiences and (using the <script/> tag future visits in the <head> element) sufficient ECMAScript/Javascript to determine device display and interaction capabilities first. a cookie or local datastore.

3.7 SVG

Note: This allows section is still under review. The working group is keen to receive further suggestions for progressive enhancement, just as good structural design best practices specifically related to the use of XHTML allows for graceful degradation. The following example code illustrates a possible request-time payload aimed at a mixed SVG on mobile and desktop/laptop audience. In this case, if ECMAScript/ Javascript is present and if Web sites.

This section covers some specfic Best Practices related to the screen-width use of SVG in mobile Web applications. SVG is determined to exceed a minimum, then vector graphics format designed for use in the display device Web. It is useful when there is assumed to be a desktop/laptop (where per-download charges are unlikely need to apply), an additional stylesheet is requested, and ithe new stylesheet convey large amounts of information.

3.7.1 Use SVG Tiny 1.1 Compatible Content

SVG Tiny 1.1 is inserted into the DOM: most broadly supported.

3.7.2 Minimize Size and Complexity of Content

In Take steps to ensure that the above case, SVG content is not overly complex since constrained devices will have difficulty rendering it. Ensure that the base-CSS for mobile users browser is delivered along with ECMAScript/Javascript configured to determine client capabilities enable GZip compression as a result of the initial request. Subsequent requests for CSS (and possibly other resources) allow for progressive enhancement where determined appropriate by client-side code. per 3.4.1 Use Transfer Compression .

3.7.3 Test on Target Devices

Good physical design can take advantage of just-in-time technologies like "server-side includes" to assemble the above payload Even if SVG Tiny 1.1 is supported on demand, resulting in the <style/> and <script/> nodes being inserted at request-time. The following code in an HTML file would cause the server target devices, it is necessary to insert (as above) site-wide <style/> and <script/> nodes at request-time in the payload actually being delivered at response-time: test on-device since some implementations are not entirely compliant.

3.7.4 Make Use of Language Features to Write Compact Code

Separating logical and physical design like this helps reduce site-wide maintenance costs and site-redesign difficulties as well as supporting graceful degradation Certain features (e.g. defs and progressive enhancement use elements) enable geometric shapes to be re-used. Appropriate use of CSS. these elements is encouraged in order to create compact code.

Appendix: Best Practice Dependent Device Properties

[To include the set of minimum device properties supporting specific best practices.]

Appendix: Examples

TODO: Include more detailed examples on the following BPs... Use Fragment IDs

A Sources (Non-Normative)

The Best Practice statements have been assembled by the BPWG from a number of sources. Primary among those are:

• to be added

While the Best Practice statements have mainly been assembled by secondary research, the sources for that research have in many cases been assembled from primary research. In addition, group members' contributions are to some extent informed by primary research carried out by their company.

B Related Reading (Non-Normative)

Readers interested in the topic of this document will find a variety of other publications of interest. As noted in the Scope paragraph above, topics such as internationalization and accessibility have been addressed separately by the W3C and have not been covered here.

The Character Model for the World Wide Web and other materials prepared by the W3C Internationalization (i18n) Activity cover important interoperability drivers for content prepared for the One Web and the mobile-services arena.

The Web Accessibility Initiative has prepared a variety of Guidelines and Techniques that likewise bear on the preparation and processing of content in and for the Web.

Section 3.7.3 3.6.3 Use Device Classification to Simplify Content Selection/Adaptation Adaptation above introduced the idea of content adaptation. Readers who contemplate implementing server-side adaptation will be interested in the ongoing work of the Device Independence Activity .

C Acknowledgements (Non-Normative)

• to be added

D References (Non-Normative)

D.1 MWI References

to be added

D.2 Sources

to be added

D.3 Device Independence

DIP

Device Independence Principles, R. Gimson, Editor, W3C Working Group Note, 1 September 2003 (See http://www.w3.org/TR/2003/NOTE-di-princ-20030901/ )

DCODI

Delivery Context Overview for Device Independence, , R. Gimson, R. Lewis, S. Sathish, Editors, W3C Working Group Note, 20 March 2006 (See http://www.w3.org/TR/di-dco/ )

DIGLOSS

Glossary of Terms for Device Independence, R. Lewis, Editor, W3C Working Draft (work in progress), 18 January 2005 (See http://www.w3.org/TR/2005/WD-di-gloss-20050118/ )

D.4 Web, Protocols and Languages

XML

Extensible Markup Language (XML) 1.0 (Fourth (Fifth Edition), Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, François Yergeau, Editors, W3C Recommendation, 16 August 2006, edited in place 29 September 2006 26 November 2008 (See http://www.w3.org/TR/2006/REC-xml-20060816/ http://www.w3.org/TR/2008/REC-xml-20081126/ )

XHTML-Basic

XHTML Basic 1.1, Shane McCarron, Masayasu Ishikawa, Editors, W3C Proposed Recommendation, 11 June 29 July 2008 (See http://www.w3.org/TR/2008/PR-xhtml-basic-20080611/ http://www.w3.org/TR/2008/REC-xhtml-basic-20080729/ )

CSS

Cascading Style Sheets (CSS1) Level 1 Specification, Håkon Håkon Wium Lie, Bert Bos, Editors, W3C Recommendation, 11 Jan 1999 January 1999, revised 11 April 2008 (See http://www.w3.org/TR/REC-CSS1 http://www.w3.org/TR/2008/REC-CSS1-20080411/ )

CSS2

Cascading Style Sheets, level 2 CSS2 Specification, Bert Bos, Håkon Håkon Wium Lie, Chris Lilley, Ian Jacobs, Editors, W3C Recommendation, 12 May 1998 (See http://www.w3.org/TR/REC-CSS2/ ) HTTP1.0 Hypertext Transfer Protocol -- HTTP/1.0 Request for Comments: 1945, T. Berners-Lee, R. Fielding, H. Frystyk, May 1996 (See http://www.w3.org/Protocols/rfc1945/rfc1945 ) HTTP1.1 Hypertext Transfer Protocol -- HTTP/1.1 Request for Comments: 2616, R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, June 1999 (See http://www.w3.org/Protocols/rfc2616/rfc2616.html ) D.5 Other References UAPROF Open Mobile Alliance OMA-TS-UAProf-V2_0-20060206-A User Agent Profile Approved Version 2.0 - 06 Feb 2006 1998, revised 11 April 2008 (See http://www.openmobilealliance.org/technical/release_program/docs/UAProf/V2_0-20060206-A/OMA-TS-UAPro