W3C home > Mailing lists > Public > public-bpwg@w3.org > August 2009

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

From: David Storey <dstorey@opera.com>
Date: Thu, 6 Aug 2009 10:40:09 +0200
Message-Id: <3A92801F-52AF-48A7-B153-7442E4E44A52@opera.com>
To: Public MWBP <public-bpwg@w3.org>

On 5 Aug 2009, at 23:29, Eduardo Casais wrote:

>
> A few remarks about this example from Dan:
>
>> 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-widgets
>
> a) It is an interesting example for the utilization of CSS MQ.  
> Nevertheless, since device capability repositorie (e.g. WURFL) often  
> include detailed information about display properties -- including  
> pixels counts and physical dimensions -- this confirms the general  
> approach of performing media selection or adaptation on the server  
> if at all possible, relying upon media queries as a second choice.

One issue we often see internally with device repositories like WUFL,  
is that even though they are good, if they get things wrong they cause  
mayhem.  They need to be kept up to date for every new model and if we  
are on some new device sites that use such repositories often break as  
the content is squashed into one corner of the screen as the db  
doesn't know about the device. We then have to go and beg someone to  
update the database (which we cant' always do as projects can be  
confidential).  With MQs there is no external dependancies - things  
will just work no matter what new devices comes out.

>
> b) The example addresses an issue that is being raised more and more  
> often in the community of mobile developers -- and which had also  
> been highlighted some time ago (by whom?) in the BPWG. See for  
> instance:
>
> bryanrieger.com/issues/mobile-screens-and-pixel-sizes/
> www.littlespringsdesign.com/blog/blog/2009/07/22/how-big-is-your- 
> image/
>
> c) An issue (nr. 293) had been dispatched as requiring no specific  
> formulation, referring back to BP1 5.4.8. However, the suggested  
> practices in BP1 might not be sufficient:
> 1. Specifying fonts only with relative measures (e.g. "larger") may  
> not be enough -- one may really have to force the default font to at  
> least "large" or "x-large" so as to have legible text.
> 2. Various versions of small "decoration" bitmaps (e.g. icons,  
> bullets, etc) may have to be explicitly constructed to occupy more  
> pixels so as to be recognizable on screens with higher pixel  
> density. This aspect is not really tackled in BP1 5.4.8.
> 3. Content-rich pictures may not take advantage of the higher pixel  
> count. Let us consider (street/geographical topographic) maps. If  
> the pixel count increases while the density remains about the same,  
> it is possible to enlarge the area represented on the display  
> without a loss of legibility. At the other extreme, if the pixel  
> count and the pixel density increase at the same rate, it is not  
> really possible to enlarge the area represented on the screen that  
> much without a marked loss of legibility (map features become  
> minuscule).
>
> I do not know whether there is enough material for a best practice,  
> but the issue has decidedly gained much relevance recently.
>
> E.Casais
>
>
>
>

David Storey

Chief Web Opener / Product Manager, Opera Dragonfly
W3C WG:  Mobile Web Best Practices / SVG Interest Group

Opera Software ASA, Oslo, Norway
Mobile: +47 94 22 02 32
Received on Thursday, 6 August 2009 08:40:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:09:01 UTC