W3C home > Mailing lists > Public > public-bpwg@w3.org > March 2008

RE: ACTION-719 [5.x.y CSS]

From: Rotan Hanrahan <rotan.hanrahan@mobileaware.com>
Date: Thu, 27 Mar 2008 10:05:47 -0400
Message-ID: <D5306DC72D165F488F56A9E43F2045D3018484B0@FTO.mobileaware.com>
To: "Jeff Sonstein" <jeffs@it.rit.edu>, "Mobile Web Best Practices Working Group WG" <public-bpwg@w3.org>

> Detect browser capabilities or user preferences and react accordingly.

This could be one of the easiest approaches, if you are considering this
from a server adaptability point of view. The DDWG's API, soon to be
announced, should help the server to figure out how to adapt to the
device. If you wish, you can adapt the page (and any style therein) at
request time. You could even defer the styling adaptation to the point
where you get a request for the stylesheet. Similar adaptability can be
introduced to the delivery of scripts.

I must admit, however, that the example markup involving SSI might scare
some people away. Better just to mention the technology than show it in
all its gory detail. There are other technologies too, such as JSTL or
W3C's DISelect. (DISelect is not yet in-the-wild to any great extent,
but perhaps this will change when the DDR API is ready.)

You may also need to deal with conflicts between device capabilities and
user preferences, but perhaps that's a level of detail too far.

---Rotan.

-----Original Message-----
From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] On
Behalf Of Jeff Sonstein
Sent: 27 March 2008 13:14
To: Mobile Web Best Practices Working Group WG
Subject: ACTION-719 [5.x.y CSS]


5.x.y Provide for Both Graceful Degradation & Progressive Enhancement  
of CSS
5.x.y.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 device users
will require alternate approaches for browsers that do not support  
positioning
and visibility control. You should provide for both graceful degradation
(in the case of no or minimal CSS support) and progressive enhancement
(in the case of full positioning and visibility control support) of  
CSS by
the client at run-time.

5.x.y.2 How to do it

Detect browser capabilities or user preferences and react accordingly.

  Design targeting purely desktop/laptop audiences (where  
media="screen") tends to be
  structured to degrade gracefully: first if ECMAScript/Javascript is  
not present, and then
  if CSS is not supported. Design targeting a mixed audience of mobile  
(where media="handheld")
  and desktop/laptop users should be structured to also progressively  
enhance CSS.
  Advanced CSS capabilities should be separated from basic CSS, and  
inserted into the
  DOM by the client as appropriate at run-time.

Separate behavior from content and presentation, for graceful  
degradation and
progressive enhancement.

  Designers targeting a mixed audience of mobile and desktop/laptop  
users can build
  Web pages which load (using the <style/> tag in the <head> element)  
CSS for mobile
  audiences and (using the <script/> tag in the <head> element)  
sufficient ECMAScript/Javascript
  to determine device display and interaction capabilities first. This  
allows for progressive
  enhancement, just as good structural design of XHTML allows for  
graceful degradation.

  The following example code illustrates a possible request-time  
payload aimed at a mixed
  mobile and desktop/laptop audience. In this case, if ECMAScript/ 
Javascript is present
  and if the screen-width is determined to exceed a minimum, then the  
display device is
  assumed to be a desktop/laptop (where per-download charges are  
unlikely to apply),
  an additional stylesheet is requested, and ithe new stylesheet is  
inserted into the DOM:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.2//EN"
  "http://www.openmobilealliance.org/tech/DTD/xhtml-mobile12.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
  <meta http-equiv="content-type" content="application/vnd.wap.xhtml 
+xml; charset=utf-8" />
  <meta http-equiv="cache-control" content="no-cache" />
  <title>Example Payload for Progressive Enhancement</title>
  <style type="text/css" media="all">
/*
<![CDATA[ */
                         [put initial CSS here]
/* ]]>
*/
  </style>
  <script type="text/javascript" charset="utf-8">
// <![CDATA[
var triggerWidth = 480;
function appendStylesheet( uriString, mediaTypeTarget ) {
                         [inject stylesheet into DOM here]
}
function getViewportWidth() {
                         [determine viewportWidth here]
}
function adaptToScreen( uriString ) {
  if ( getViewportWidth() >= triggerWidth ) {
    appendStylesheet( uriString, 'screen' );
  }
}
// ]]>
  </script>
</head>
<body onload="adaptToScreen( './stylesheets/bigScreen.css' );">
  [...]

In the above case, the base-CSS for mobile users is delivered along with
ECMAScript/Javascript to determine client capabilities 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.

Good physical design can take advantage of just-in-time technologies
like "server-side includes" to assemble the above payload 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 to insert (as  
above)
site-wide <style/> and <script/> nodes at request-time in the payload  
actually
being delivered at response-time:

[... replace style and script elements with:]
  <style type="text/css" media="all">
/*
<![CDATA[ */
<!--#include virtual="./stylesheets/content.css" -->
<!--#include virtual="./stylesheets/tabNav.css" -->
/* ]]>
*/
  </style>
  <script type="text/javascript" charset="utf-8">
// <![CDATA[
<!--#include virtual="./javascripts/appendStylesheet.js" -->
// ]]>
  </script>
[...]

Separating logical and physical design like this helps reduce
site-wide maintenance costs and site-redesign difficulties
as well as supporting graceful degradation and progressive
enhancement of CSS.
Received on Thursday, 27 March 2008 14:06:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 27 March 2008 14:06:47 GMT