- From: Adam Connors <adamconnors@google.com>
- Date: Tue, 11 Aug 2009 11:25:04 +0100
- To: Mobile Web Best Practices Working Group WG <public-bpwg@w3.org>
- Message-ID: <393b77970908110325j49d528b8h889fa3ca7ff32b6d@mail.gmail.com>
Hello all, Having lost some momentum with so many weeks without calls I'm just trying to get back up to speed here. Below is the current text for 3.6 in MWABP after modifications based on the resolutions in the last meetings. As agreed, I have removed references to DCCI and OMA DPE and expanded the text around CSS MQ. The text on CSS MQ is a little terse, but hopefully adequate given the context. Comments please. Adam. 3.6 Handling Variations in the Delivery Context Variations in the delivery context (such as different device capabilities) is a prominent feature of the mobile Web. Web applications should adapt to known or discoverable properties of the delivery context by adjusting the content, navigation and/or page flow, with a view to offering a good user experience on as broad a range of devices as possible. 3.6.1 Prefer Server-Side Detection Where Possible3.6.1.1 What it means Where possible, use the evidence available on the server to determine the properties of the delivery context, and adapt the responses to the client before transmission, thus improving the user experience and avoiding transmission of unnecessary or incompatible data. 3.6.1.2 How to do it In its most basic form, the minimum evidence from the client device is the HTTP Accept header. In practice, this evidence is insufficient to determine the key properties that will help to select/adapt the content appropriately, so additional headers or other sources of information should be considered. Typically, the following headers provide evidence of device capabilities: - *Accept header:* this list of MIME types can aid in the selection or creation of alternative content representations to suit the requesting device. This header is not always reliable however, and its value is often set to “*/*”, suggesting that clients can accept every MIME type. - *User-Agent header:* as a 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 will vary from implementation to implementation. The W3C DDR Simple API defines a common interface and a means of expressing the vocabulary of properties for such repositories. - *X-Wap-Profile header:* this is a reference to the User Agent Profile (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 header is sometimes used with a DDR where corrections to the profiles are stored. 3.6.2 Use Client-Side Capability Detection Where Necessary3.6.2.1 What it means Where it is not possible to determine certain properties of the delivery context from the server, this information may be available at the client. Once obtained at the client, the information can be used directly to adapt the presentation, or it can used to request alternative, adapted content from the server. 3.6.2.2 How to do it There are a few client-side solutions available to the developer: *JavaScript:* this is the most common solution. A script determines the device / browser properties and manipulates the content and behaviour of the application accordingly. This can be done in two ways: 1. By encapsulating the differing behaviours in the control logic of the application (e.g. if (some_api_exists) { ...). Typically the delivery context information is gathered at the start of the session, though dynamic information (e.g. current screen orientation) will need to be refreshed during the session. 2. By passing the gathered information back to the server and requesting alternative content (e.g. either by dynamically adding a new <script> tag to the DOM or by an XHR request). *CSS Media Queries:* Media queries are an extension to the "media-types" paradigm that allow developers to apply specific style rules based on the device 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 <#CSSMQ>] for more details.
Received on Tuesday, 11 August 2009 10:25:46 UTC