- From: David Storey <dstorey@opera.com>
- Date: Thu, 6 Aug 2009 10:40:09 +0200
- 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