Re: ACTION-994: Some evidence of CSS MQ in the wild

CSS MQ is generating a very lively debate. Let me try to replace this feature in its
context.

CSS MQ are primarily used to select adequate style sheets for categories of devices.
Originally however, this was the role of CSS media types (CSS MT): by associating a 
tag such as "screen", "tv" or "handheld", the suitable style sheet was supposedly 
delivered to the terminal belonging to the corresponding class.

There were two essential problems with this approach:
a) The categories thus defined are too coarse. We know that even in "handheld" we 
must distinguish among several different types of mobile devices (so called 
"full-web", WAP2, SMS-only for instance).
b) More importantly, the definition of terminal categories, and the assignment of 
different device models to each category, depends fundamentally on the application 
-- not on the fixed conception the terminal vendor has about which categories its
products belong to. In other words, application developer should be in control of
device classification, but CSS MT gave that control to device and browser vendors.

The result became all too painfully apparent recently:
1. Some phones bravely assume they are "handhelds" and only retrieve style sheets
marked as such (or possibly "all"), ignoring other media types.
2. Some ambitious devices, assuming they are equally capable as desktops, ignore 
"handheld" style sheets and only accept those tagged as "screen".
3. Other high-end devices ecumenically gather all style sheets, whether they are 
marked "handheld" or "screen".
4. Others still reject "handheld" style sheets, as they claim to be more than just
middle of the road mobile phones, but ignore "screen" style sheets too, since they
do not consider themselves to be desktops either.

The technical solution to this quandary: CSS MQ. The selection of styling 
characteristics no longer relies upon fixed categories, but on classes defined by
intrinsic device properties. The definition of classes and assignment of devices to
them is controlled by the application developer. CSS MQ is the right way to do things.

Except, of course, that we stumble on further difficulties:
c) If the targets are those high-end devices that implement CSS MQ, then perhaps 80%
of the browsers implement this feature; if the application also target other device
classes, those featuring browsers from OpenWave, NetFront, Obigo or even IEMobile,
then CSS MQ probably do not cover 80% of the market.
d) How much of all media features in the CSS MQ specs are supported by existing 
implementations? Basically, it seems that only a small subset of them are "safe" to
be used, and some of the interesting ones (such as orientation) are rarely, if ever
implemented.

These deficiencies result in further complications, as illustrated by the links I gave
in my previous message: the selection of a style sheet now requires a complicated mix
of CSS MT and MQ, clever sequencing of links to provoke the correct cascading of 
competing style sheets, and special commenting out for browsers that are overburden
with the profusion of possible style sheets to consider. 

Given 
1. the fact that terminal classification depends on the application;
2. that this classification tends to become more complex (not just for technical 
reasons due to CSS MQ/MT implementations);
3. that this classification is based on terminal characteristics that are, for those
actually used, a subset of what can be found in such device capability schemes as
UAProf, WURFL, Volantis, etc;
then why bother implementing a device switcher on the client? If one is using CSS
MQ, then one is highly likely to perform server-side device detection, followed by
content generation or selection based on device properties (whether it is selection
of proper markup, image and multimedia types, generation of presentation elements
such as banners or of executable resources such as Javascript vs. JScript, etc). In
this case, forget about CSS MQ and MT: follow the well-practiced approach of 
server-side device identification, retrieval of properties, and classification before
generating exactly one line of markup with the exact style sheet reference the device
will handle.

If on the other hand, we want to deal with the detection of dynamic device properties
on the device itself, which is the subject of MWABP 3.6.2 "Use Client-side Capability 
Detection for _Dynamic_Device_State_", then why bother with CSS MQ, especially if one 
cannot rely upon it implementing the necessary features? Javascript is more capable, 
provides better event handling than CSS, has interfaces to device facilities to detect
further properties and state information on the mobile phone. 

To make a long story short, I would conclude by stating that CSS MQ appears to have
too many deficiencies and to be redundant with other techniques. Its utilization for
such simple goals as style sheet selection leads to complicated and brittle designs. 
>From the examples in the wild I have seen, the 
current typical utilization of CSS MQ, and the
topic of MWABP 3.6.2, I can honestly not recommend it as a best practice -- although
it is a tool that may be convenient at times.


E.Casais

Received on Monday, 13 July 2009 13:37:57 UTC