Mobile Web Application Best Practices

W3C Working Draft 7 May 6 October 2009

This version:

http://www.w3.org/TR/2009/WD-mwabp-20090507/ http://www.w3.org/TR/2009/WD-mwabp-20091006/

Latest version:

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

Previous version:

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

Editors:

Bryan Sullivan, AT&T

Adam Connors, Google

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

3.1.3 Replicate Local Data To A Server If Necessary

3.1.3.1 What it means

If a client-side storage API is being used, it's important to remember that this used the data in it is not visible to other devices. Whilst this is adequate appropriate for some forms of data (e.g. preferences and state relevant only to a given device), it is often necessary to replicate this data back to a server in order to provide a consistent view across devices and make it possible to recover data if the device is lost or damaged. See 3.5.10 Ensure Consistency Of State Between Devices for further discussion on this topic.

As a rule of thumb, data that needs to be shared with other devices or recovered in the case of a lost or damaged device, should be replicated back to the server as soon as possible.

3.1.3.2 How to do it

The technologies that provide client-side storage APIs should provide facilities to detect the current network connectivity. For example, HTML5 provides a property on the navigator object ( navigator.onLine ) to indicate whether the client is currently online, and dispatches two events on the Window object to indicate a change of network state ( online and offline ).

Mobile Web applications should use However, these events APIs should be used with caution. Even if the browser is reporting an online state, on an intermittant network this is no guarentee that a subsequent connection will succeed. The most effective approach is to control fail gracefully in the flow event of a connection failure, store unsaved data back to the server and to build up in a local queue of changes if the application is offline. uncommitted changes, and set a timer to try again later.

[ Client-Side Storage Icon ] Requires: Local Storage API.

3.2 Security and privacy

Use trusted information, and protect all personally identifiable information.

3.2.1 Do not Execute Unescaped or Untrusted JavaScript JSON data

3.2.1.1 What it means

JSON A common pattern is a very commonly used method to use JSON to transfer data to the client, usually as part of an asynchronous request. However, using a client and then use JavaScript's eval(); eval() function to directly parse it. This is a powerful technique, since on constrained devices eval() can execute more quickly than the incoming alternatives. However, direct execution of a datafeed that contains unescaped user-generated data represents a significant security risk and should be avoided.

Inadvertantly executing malicious JavaScript is particularly dangerous on mobile devices where personal information (current location, contact data, etc) may be exposed.

3.2.1.2 How to do it

Instead Where possible, instead of parsing JSON data by executing it with the browser's eval(); eval() command, function, use a JSON parser (for example: http://www.json.org/json_parse.js ).

In cases where directly evaluating the JSON data If this is desirable impractical (JSON parsers are approximately x10 slower than eval() and may be impractical for reasons of efficiency, large datafeeds) ensure that the data either contains no user-generated content (e.g. the server is responsible for the content of all fields in the datafeed) or that any user-generated content is correctly escaped.

See RFC4627 for details on how to ensure a JSON datafeed is suitably escaped and can be safely passed into JavaScript's eval() function.

3.3 User Awareness and Control

Ensure that the user is aware of otherwise invisible application actions, and offer options to control those actions.

Browsers may have access to information such as:

• Pictures, music, and video clips;
• Contacts, calendar (PIM data);
• Call history;
• System data (battery, coverage, roaming, location);
• Media recording (record audio/video clip, get new picture);
• Device context (e.g. location, connectivity, profile setting).

3.3.1 Inform the User About Automatic Network Access

3.3.1.1 What it means

Network traffic on a mobile device incurs a cost (both in terms of data-charges and battery life) and so it is important to inform the user when this happens. Whenever an application makes asynchronous XHR data requests, whether automatic (on a timer or in response to an external trigger) or secondary to some user action, this should be indicated to the user in an appropriate manner. manner so that the user..

3.3.1.2 How to do it

Applications should disclose how they use network resources. A simple icon indicating background activity is usually sufficient and does not interrupt the flow of the application. If extensive background network activity is required the user should be informed when they first visit the site, when they first sign-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 behavior 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 must should be provided.

3.3.2.2 How to do it

All applications that access the network automatically must provide a means for the user to disable that activity. When automatic network activity is disabled, periodically prompt the user to make network requests.

Consider allowing the user to adjust the polling schedule and to control which activities are allowed to initiate network requests.

3.3.3 Ensure the User is Informed About Use of Personal and Device Information

3.3.3.1 What it means

Ensure that the user is informed if the application 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 whether / how that data will be exchanged with the server.

These notices should be provided when the user first accesses the Web application, on first access to user information, or in help pages. It should provide the user with enough information to reasonably judge whether or not they want to allow the application access to their data.

3.3.3.2 How to do it

In many cases use of APIs that provide access to personal or device information causes a native confirmation dialog to be presented to the user. 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 will lead to the user being presented with repeated native confirmation dialogues.

[ DEVICE DATA icon ] Requires: Device Data APIs.

3.3.4 Enable Automatic Login Sign-in

The Mobile Web Best Practices Working Group 3.3.4.1 What it means

If an application requires user identity it is investigating best practices usual to make login as easy as possible prompt for user credentials (username and password) and provide the option to sign-in automatically on next usage session. This is especially important on a mobile devices with limited device where data input capabilities. Feedback from the community is welcome! (see the Status of This Document section for details more painful than on how a desktop.

3.3.4.2 How to provide feedback) do it

User credentials can be stored in a cookie or in local storage. However, it is important not to store unencrypted password information since this is insecure. Most commonly, a securely hashed token which can be revoked on the server if necessary is stored locally in order to enable automatic sign-in.

3.4 Conservative use of resources

Battery lifetime and cost of network traffic are significant considerations of most users of mobile devices. Since all activities that use either processor or wireless connectivity will incur some cost to battery life or network data costs, applications should consider this factor and be conservative in their use of resources.

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

3.4.1 Use Transfer Compression

3.4.1.1 What it means

Compress content for efficient delivery.

3.4.1.2 How to do it

HTTP 1.1 compression, which uses the gzip and DEFLATE algorithms is widely supported. Web servers should be configured to serve appropriately compressed responses.

Note however, that the cost (in time and battery usage) of decompressing data should be balanced against the gains in transport efficiency. When configuring HTTP 1.1 compression note that:

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

3.4.2 Minimize Application and Data Size

3.4.2.1 What it means

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

3.4.2.2 How to do it

Process HTML, JavaScript and CSS files to remove whitespace and minify before delivery. A number of freely available whitespace strippers and JavaScript / CSS optimizers are available online.

Note that "minification" / "optimization" can take a number of forms from simple removal of whitespace and comments, to the global substitution of tokens (variables, method names, selector names) with shorter alternatives, to alternative binary and compressed representations of the underlying data. alternatives.

In general, minification that parses the source file and makes substitutions based on a lexical / grammatical understanding of that source are less fragile and should be preferred to simple regular-expression based tools.

For a good comparison of JavaScript minification tools try: http://compressorrater.thruhere.net

3.4.4 Optimize Network Requests

3.4.4.1 What it means

Network operations are costly in terms of battery usage, application latency, and potential network traffic expenses, and should not be made unnecessarily. The latency cost of setting up a HTTP request is much higher than the bandwidth limitations on a mobile network and so fewer, larger requests are preferred.

3.4.4.2 How to do it

Consider the following possibilities when designing an application:

Batching requests:

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

Back off during periods of inactivity:

If the application polls for updates, it should monitor user activity and poll less frequently during inactive periods.

Device Context:

If supported by the device, use awareness of current connectivity (e.g. WiFi) to select an appropriate level of interaction.

3.4.5 Minimize External Resources

3.4.5.1 What it means

A Web application typically requires a number of resources (style sheets, scripts, image, etc) each of which may incur an additional HTTP Request. HTTP round trips are particularly expensive on a mobile network and so fewer, larger requests should be favoured over a larger number of smaller requests.

3.4.5.2 How to do it

As far as makes sense after taking into account 3.5.2 Minimize Perceived Latency combine all style sheets into a single resource and all scripts into a single resource. If multiple scripts and style sheets are required as part of the authoring process, then try to arrange that they are merged before the page is served.

3.4.6 Aggregate Static Images ("Sprites") into a Single Composite Resource (Sprites)

3.4.6.1 What it means

Web applications often depend on a number of static images to provide icons, buttons, etc. If served as a separate image each one incurs an additional HTTP round-trip which is detrimental to performance when compared with combining them into a single image for transfer.

3.4.6.2 How to do it

To optimize efficiency:

• For PNG and GIF files, combine images with similar sizes and color palettes;
• Endeavour to sprite JPEGs on 8x8 boundaries in order to minimize the size of the combined JPEG.
• Combine images that do not change often. If one of the component images changes, the entire combination image will need to be downloaded.

To render individual components of a resource use CSS positioning and clipping.

[ ICON: CSS ] Requires: CSS2 Clipping and Positioning Support

3.4.7 Include Background Images Inline in CSS Style Sheets

3.4.7.1 What it means

Background images are often used as gradients to improve the look and feel of an application. These can be included in the CSS as base64 encoded strings in order to avoid an additional HTTP round trip.

Note that base64 encoding adds around 10% to the image size after gzip compression and this additional cost should be weighed against the benefits of less requests.

3.4.7.2 How to do it

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

[ ICON: CSS ] Requires: RCF2397 data uri support.

3.4.8 Use Fingerprinting to Cache Dynamic Resources By Fingerprinting Resource References

3.4.8.1. What it means

Dynamic resources that change occasionally (e.g. a user's avatar) can still be cached by identifying them with a URI that includes a fingerprint Hash of the resource content. Using this technique means that the browser does not 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.8.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.
• Reference the resource using a URI that contains a Hash of the content. If the content changes, this reference will change and the browser will fetch the updated data.

3.4.9 Cache AJAX Data

3.4.9.1 What it means

Data If possible, data designed to be accessed by AJAX requests from the client should be cached in the same way as primary content.

3.4.9.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 data as readily as primary content pages.

3.4.10 Don't Send Cookie Information Unnecessarily

3.4.10.1 What it means

Static resources don't need cookie information and so performance can be improved by serving these from a path or sub-domain for which the application's cookies are out of scope.

3.4.10.2 How to do it

Use a different domain, sub-domain, or path name for static resources to the main application, and restrict the valid path of cookies such that they will not be exchanged when they are not needed.

For example:

Application data served from /myapp will receive cookie information.

Static data served from /static will not receive unneeded cookie information.

3.4.11 Keep DOM Size Reasonable

3.4.11.1 What it means

The permitted size of the Document Object Model (DOM) is more constrained on mobile devices and can be exceeded by large / complex pages. Keep the DOM size below 10MB to avoid browser crashes.

3.4.11.2 How to do it

Clip content and separate content onto separate pages to keep the DOM size manageable.

3.5 User Experience

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

3.5.1 Optimize For Application Start-up Time

3.5.1.1 What it means

User experience is strongly influenced by the initial start-up time of an application.

Offline Web application technologies like HTML5 AppCache bring Web applications into parity with native applications in terms of their start-up time and their ability to be used under intermittent network coverage. The following steps should be considered to minmize the start time of a Web application.

3.5.1.2 How to do it

Consider the following techniques to help minimize application start time:

• Use Offline Technology: Offline Web technologies (for example, AppCache) allow the resources of a Web application (its HTML, JavaScript, and CSS files) to be specified and stored locally so that the application can start without requiring a round-trip to the server.
• Consider Partitioning Large Scripts: In complex Web applications, JavaScript parsing can contribute a significant portion of start time. If some functionality is rarely used it should be moved into separate scripts that can be loaded on demand, lowering the amount of core code that needs to be parsed at start-up.
• Use Local Storage: Where appropriate, store a snapshot of the last application state so it can be displayed immediately on start-up without requiring a server roundtrip.
• Minimize Number of Local Storage Queries: After JavaScript parse time the number of local storage queries required to generate the initial view is the next most significant contribution to start-up latency. Try to minimize the number of local storage queries required before the first view can be displayed.

3.5.2 Minimize Perceived Latency

3.5.2.1 What it means

The Best Practices covered in section 3.4 Conservative use of resources will help to minimize the latency of a Web application, but a number of measures can also be used to further minimize the perceived latency. Lowering perceived latency is an important factor in improving the overall usability of a Web application, improving user's perception of Web site credibility and decreasing bail out rates.

3.5.2.2 How to do it

A number of techniques can be used to improve perceived latency:

• Enable Incremental Rendering :Place JavaScript tags at the bottom of the page (since browsers halt whilst parsing JavaScript) and configure the page such that any useful information that might be available is viewable while the main content of the application is still loading.
• Keep the User Informed of Activity: Spinners and progress bars should be used to keep the user informed during network and device API accesses so that they don't think the application is "stuck".
• Avoid Page Reloads: In dynamic Web applications page reloads should be avoided and the page dynamically updated instead to reflect changes in state. Different views can be switched by dynamically updating the relevant parts of the DOM.
• Preload Probable Next Views: If the flow of a particular Web application means certain paths are more probable, preload the data for these views so they can be displayed immediately when the user requests them.

3.5.3 Design for Multiple Interaction Methods

3.5.1.1 3.5.3.1 What it means

Interaction methods vary across devices. Three main interaction methods should be considered when designing the UI:

• Focus Based: The browser focus "jumps" from link to link;
• Pointer Based: Key-based navigation controls a pointer that can cover any part of the screen;
• Touch Based: Events are related directly to a touch position on the screen with finger or stylus.

The optimum configuration of UI elements varies depending on the interaction method used by the device. Ideally, the UI should be adapted based on a knowledge of the interaction methods supported by the target device. If this is not possible, then the UI should be carefully designed in order to provide a good experience in each of these different interaction methods.

3.5.1.2 3.5.3.2 How to do it

Particularly where navigation of content requires multiple links (ie back/forward in a carousel) the following factors should be considered:

Focus Based:

• Selectable elements (e.g. links) can be widely spaced since the focus area will jump automatically from link to link;
• The current focus of the page is easily determined because that element will be highlighted.

Pointer Based:

• Selectable elements that are associated need to be near each other as scrolling the pointer can be slow;
• Selectable elements need to be large enough to be easily selected -- since the pointer often moves in steps of approximately 5 - 10 pixels;
• Selectable elements should have rollovers to make it clear when the pointer has entered their active area.

Touch Based:

• Selectable elements can be widely spaced as the user can select them directly;
• Selectable elements must be large enough to be easily selected (e.g. list items should have a height of at least 30px).
• 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.5.2 Minimize Perceived Latency 3.5.2.1 What it means The Best Practices covered in section 3.4 Conservative use of resources will help to minimize the actual latency of a Web application, but a number of measures can also be used to further minimize the perceived latency. Lowering perceived latency is an important factor in improving the overall usability of a Web application, improving user's perception of Web site credibility and decreasing bail-out rates [REFS] . 3.5.2.2 How to do it A number of techniques can be used to improve perceived and actual latency: Enable Incremental Rendering : Place JavaScript tags at the bottom of the page (since many browsers halt whilst parsing JavaScript) and configure the page such that any useful information that might be available is viewable while the main content of the application is still loading. Keep the User Informed of Activity: Spinners and progress bars should be used to keep the user informed during network and device API accesses so that they don't think the application is "stuck". Avoid Page Reloads: In dynamic Web applications page reloads should be avoided and the page dynamically updated to reflects changes in state. Different views can be switched by showing and hiding the relevant parts of the DOM. Partition Large Scripts: In complex Web applications, JavaScript parsing can contribute a significant portion of start-up time. If some functionality is rarely used it should be partitioned into separate scripts that can be loaded on demand, lowering the amount of core code that needs to be parsed at start-up. Use Client-Side Storage: Where appropriate, aggressively cache a snapshot of application state so it can be displayed immediately on start-up. In many cases possibly stale data is still more useful no data. 3.5.3 3.5.4 Preserve Focus on Dynamic Page Updates

3.5.3.1 3.5.4.1 What it means

The 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.

3.5.3.2 3.5.4.2 How to do it

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

3.5.4 3.5.5 Use Fragment IDs to Maintain Drive Application History View

3.5.4.1 3.5.5.1 What it means

Web applications can switch between views without a full page reload by showing and hiding sections of content. However, this means that the browser <back> button doesn't work by default, and it is not automatically possible to link directly to specific views within an application. 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.5.4.2 3.5.5.2 How to do it

Each view within an application should have a URI with a distinguishing fragment identifier (e.g. http://myapp.example.org/myapp#view ) and JavaScript used to interrogate the browser location in order to determine which view to display.

For further discussion on this topic see: http://ajaxpatterns.org/Unique_URLs

3.5.5 3.5.6 Make Telephone Numbers "Click-to-Call"

3.5.5.1 3.5.6.1 What it means

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

3.5.5.2 3.5.6.2 How to do it

The most broadly supported scheme is tel: as described in [ RFC3966 ]. Code such as the following can be used to enable "Click-to-Call":

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

3.5.6 Ensure Paragraph Text Flows

3.5.6.1 3.5.7.1 What it means

On small screens it is important that paragraph text flows so that it doesn't require horizontal scrolling and so that it will reflow if the view orientation is changed. See BP1 [MEASURES] for more details.

3.5.6.2 3.5.7.2 How to do it

Use percentage and measures for containers so that text can reflow automatically.

3.5.7 3.5.8 Ensure Consistency Of State Between Devices

3.5.7.1 3.5.8.1 What it means

This recommendation builds on the recommendation in BP1 ( 5.5.1 Thematic Consistency ) and expands it to consider the application preferences , personalization data , and state 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. Data updated on one devices should be viewable consistently 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.7.2 3.5.8.2 How to do it

For any application data that is not exclusively relevant to the current device, favor storing it on the server so it can be shared by other devices. See 3.1 Application Data for more details.

3.6 Handling Device Capability Variation Variations in the Delivery Context

Device capability variation Variations in the delivery context (such as different device capabilities) is a basic characteristic prominent feature of the mobile Web environment. Web. Web applications should adapt their content such that they render as well as possible to known or discoverable properties of the delivery context by adjusting the content, navigation or page flow, with a view to offering a good user experience on as broad a range of target devices as possible.

3.6.1 Use Server-side Capability Prefer Server-Side Detection Where Possible for Static Device Capabilities

3.6.1.1 What it means

For static device capabilities that won't change (e.g. SVG support, screen-dimensions) it is preferable to detect these capabilities Where possible, use the evidence available on the server to determine the properties of the delivery context, and adapt content before it is sent the responses to the client in order to avoid transferring before transmission, thus improving the user experience and avoiding transmission of unnecessary or incompatible data.

3.6.1.2 How to do it

Typically used methods In its most basic form, the minimum evidence from the client device is the HTTP request header. Typically, the following header fields provide evidence of device capabilities detection: capabilities:

• The "User-Agent" header Accept: this list of MIME types can be used aid in the selection or creation of alternative content representations to identify suit the device, requesting device. This field is not always reliable however, and its value often includes "*/*", suggesting that clients can accept every MIME type.
• User-Agent: as a Device Description Repository (DDR) generally unique (albeit opaque) string it can be used as a key into a device descriptions repository (DDR). The set of properties recorded in these repositories varies from implementation to retrieve implementation. The W3C DDR Simple API defines a detailed description common interface and a means of capabilities; expressing the vocabulary of properties for such repositories.
• The "Accept" header can be used X-Wap-Profile: this is a reference to indicate specific MIME types compatible-to/preferred-by the device; The "X-Wap-Profile" header (User User Agent Profile or UAProf) can (UAProf) for the requesting device. In practice, the referenced profile is not always guaranteed to be available, valid or up-to-date, so the value of this field is sometimes used both as device identification and as with a source DDR where corrections to the profiles are stored. Some devices may send an additional field X-Wap-Profile-Diff advertising temporary or permanent variations of detailed device capabilities. a specific terminal with respect to its standard profile.

3.6.2 Use Client-side Client-Side Capability Detection for Dynamic Device State Where Necessary

3.6.2.1 What it means

For dynamic device state that might depend on Where it is not possible to determine certain properties of the configuration or delivery context of from the device (e.g. Is scripting enabled? Is server, this information may be available at the SDCard available? Has permission been granted for PIM access?) detection must client. Once obtained at the client, the information can be done on used directly to adapt the device. presentation, or it can used to request alternative, adapted content from the server.

3.6.2.2 How to do it

Use JavaScript reflection to determine if There are a given API few client-side solutions available to the developer:

JavaScript: this is active and interrogate the most common solution. A script determines the device configuration using appropriate APIs. Two methods / browser properties and manipulates the content and behaviour of the application accordingly. This can then be used to adapt on the client to differing configurations: done in two ways:

1. Encapsulate
2. By encapsulating the different differing behaviours in the control logic of the application. E.g. simply use: application (e.g. if (some_configuration_variable) decision-points in (some_api_exists) { ... ). Typically the code and behave accordingly; delivery context information is gathered at the start of the session, though dynamic information (e.g. current screen orientation) should be refreshed during the session.
3. Use an initial "bootstrap" script
4. By passing the gathered information back to assess device capabilities the server and request requesting alternative content (e.g. either by dynamically adding a new <script> tag to the appropriate application bundle accordingly. DOM or by an XHR request).

CSS Media Types: CSS Media Types allow different stylesheets to implement be associated with different media types (e.g. print, screen, mobile) and is appropriate provided are traditionally used to repurpose content for these destinations. Since the amount list of inactive code downloaded doesn't have a negative impact on performance. Option (2) recognized media types is preferred when the application must change significantly limited, however, and devices are notoriously idiosyncratic in response their interpretation of types, it is in general not a helpful technology in this context. See Media Types [ CSSMT ] for more details.

CSS Media Queries: Media queries are an extension to properties the "media-types" paradigm that can only be determined allow developers to apply specific style rules based on the client. device display characteristics (e.g. screen width, orientation, or resolution). At the time of writing this specification is not fully supported, but can provide a useful way to modify the page layout (for example to reflow sections of text) in a more maintainable, declarative way than is possible with script. See Media Queries [ CSSMQ ] for more details.

3.6.3 Use Device Classification to Simplify Content Adaptation

3.6.3.1 What it means

If a large number of devices are being targeted, or if the application is sensitive to the permutations of a large number of configuration properties, the number of application variants required might quickly become unmanageable.

To combat this, classify target devices into different device classes and build a single application variant for each.

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

3.6.3.2 How to do it

Identify the target devices for the application and assign these to device classes of varying capability. Focus on application variants that work in each class rather than building device-specific exceptions for every variation in device configuration.

Device classes should be defined on an application-specific basis, so that the variants can be tailored accordingly. For example, the following is a possible configuration of application classes:

Class 1: Basic XHTML support, no or very basic scripting. No XHR support. (Even if these kind of devices are not being explicitly supported, it is often advisable to support a non-XHR version in case JavaScript has been disabled on the device).

Class 2: Full AJAX and JavaScript support.

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

3.6.4 Support a non-JavaScript Variant if Appropriate

3.6.4.1 What it means

Scripted and XHR based applications are not supported on all browsers. If broadest reach is a primary concern then consider providing a variant of the application that uses synchronous FORM posts in place of XHR requests. This Best Pratice is related (albeit with a differing focus) to BP 1 [ OBJECTS_OR_SCRIPT] .

3.6.4.2 How to do it

Essentially this BP states that it is favourable to support "Class 1" devices as defined above if appropriate. Doing this will ensure that the application can be used across as broad a range of devices as possible. Furthermore, in some cases a non-JavaScript version can be useful for simple operations in low-bandwidth situations.

In some cases, however, a particular application simply has no non-JavaScript counterpart (e.g. a Web based game, an Instant Messaging client) in which case it should return a 406 Not Acceptable response.

Do this by detecting the device User-Agent and checking its JavaScript support against a DDR or local index.

3.6.5 Offer Users a Choice of Interfaces

3.6.5.1 What it means

Not only is device characteristic detection imperfect, it cannot always account for the differing use-cases of an application. If multiple flavours of the application exist (e.g. to support the various device classifications) it sometimes makes sense to offer the user the choice of which flavour they wish to use.

3.6.5.2 How to do it

Only if it makes sense in the specific context of a given application, allow the user to switch to a different flavour (for example, upgrading their experience if their device is more capable than the server believes, or degrading if connectivity is poor and they wish to accomplish a very simple task that can be done more easily with the minimal UI).

Always attempt to default to the most appropriate UI on first use.

Always remember the user's preference for future visits in a cookie or local data store.

Appendix: Best Practice Dependent Device Properties

The following device properties included in the DDR Core Vocabulary [REF] are of particular value in supporting best practices recommended in this document. They should be available in any DDR supporting the W3C's DDR Core Vocabulary:

• Display Width, Display Height, Display Color Depth
• Input Devices
• Markup Support
• Stylesheet Support
• Image Format Support
• Input Mode Support
• Cookie Support
• Script Support

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 A 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.6.3 Use Device Classification to Simplify Content 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 B References (Non-Normative)

D.1 B.1 MWI References

to be added D.2 Sources MWBP to be added

Mobile Web Best Practices 1.0, Jo Rabin, Editor, W3C Recommendation, 29th July 2008 (see http://www.w3.org/TR/mobile-bp/ )

D.3 B.2 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 B.3 Web, Protocols and Languages

XML

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

XHTML-Basic

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

CSS

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

CSS2

Cascading Style Sheets, level 2 CSS2 Specification, Bert Bos, Håkon Wium Lie, Chris Lilley, Ian Jacobs, Editors, W3C Recommendation, 12 May 1998, revised 11 April 2008 (See <a href="http://www.w3.org/TR/2008/REC-CSS2-20080411/" shape="rec http://www.w3.org/TR/2008/REC-CSS2-20080411/ )

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 )

B.4 Other References

WIDGETS

W3C Widgets Specifications on the W3C Webapps Wiki page ( http://www.w3.org/2008/webapps/wiki/PubStatus#Widgets_Specifications )

HTML5

HTML5, Ian Hickson and David Hyatt, W3C Working Draft (see http://www.w3.org/TR/html5/ )

OFFLINE

Offline Web Applications