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

Some additional info on this topic which might be useful: our own dev team
in Dusseldorf has recommended the use of MQ in developing mobile widgets
with fluid UI:

http://www.slideshare.net/danfooo/fluid-layout-techniques-for-vodafone-widge
ts

Dan


On 13/07/2009 18:14, "JOSE MANUEL CANTERA FONSECA" <jmcf@tid.es> wrote:

> Regarding "terminal classification" or device grouping last year the DDWG
> publish a WG Note on this [1]
> 
> This mechanism has been implemented succesfully by our DDR Simple API
> Implementation [2]
> 
> I think this mechanism should be mentioned within the Mobile Web Apps Best
> Practices
> 
> Best Regards
> 
> [1] http://www.w3.org/TR/dd-structures/
> [2] http://forge.morfeo-project.org/frs/?group_id=54
> 
> ________________________________________
> De: public-bpwg-request@w3.org [public-bpwg-request@w3.org] En nombre de
> Eduardo Casais [casays@yahoo.com]
> Enviado el: lunes, 13 de julio de 2009 15:37
> Para: public-bpwg@w3.org
> Asunto: 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
> 
> 
> 
> 
> 
> 
>