Re: Feedback on Media Queries CR

In message <15671.14530.510000.897683@gargle.gargle.HOWL>, Håkon Wium 
Lie <howcome@opera.com> writes
>
>Also sprach Art.Barstow@nokia.com:
> > It's reasonable for the spec to be silent on this but I'm trying
> > to understand the real world usage(s) the WG envisions.
>
>And it's reasonable for you to ask the question. I'll try to sketch a
>few common use cases.

With respect I'm concerned that none of these cases seem likely to be 
useful on the World Wide Web.

>1) When W3C staff give presentations, they use a tool to split a large
>HTML document into smaller ones based on the structure of the
>document. The smaller files each point to a style sheet. Or, rather,
>each file points to three different style sheets. One is called
>"640x480", the other is "800x600", the third is "1024x768" (or
>something). The presenter then has to manually select the proper style
>sheet for the screen resolution in use. With media queries, this can
>now be handled automatically.

This is not a WWW issue, and so why is the W3C trying to solve it?  A 
cascading language isn't required in situations where you know the exact 
output situation; it would surely be better to use a specific language 
or format designed for producing presentations.  If CSS could include 
such features without impacting how it might be used on the Web, fine... 
but I doubt that is the case:

Consider how such a feature might be used in a Web context.  Inevitably 
a design that was suited only to a particular display resolution would 
be a bad design.  If the design is so specific in that respect, it 
likely makes other assumptions about the output device as well, and 
however rich CSS becomes it would surely be impossible for it to express 
all of these nuances (esp. if the author didn't recognise them himself). 
Such a design would be inherently bad for a web page, because the 
designer would have spent time creating a presentation suitable only for 
machines almost exactly like their own.  This is what the W3C should be 
persuading authors to avoid.  Authors neither want nor should have to 
create a new design for every output context.  They should be creating 
flexible design suggestions suitable for a wide range of media.

>2) The introduction of mobile web devices with smaller screens poses a
>presentation problem. The two-dimensional table-based layout of a
>common web page does not scale well onto a smaller screen.

True, but then the two-dimensional table-based layouts seen on many 
corporate and 'portal' sites don't scale well to most PC screens either. 
They may work at an aesthetic level but in terms of conveying 
information they fail horribly.  They always use tiny fixed fonts in 
order to cram the information in to a restricted, totally unsuitable 
design.  The fix for this is to remove those table-based layouts, not 
ask authors to create a new design for every imaginable output 
situation.

> Using Media
>Queries, the style sheet can use a table-based layout on a large
>screen, and a block-based layout on a small screen. The content will
>be the same, but a few lines in the style sheet will be different, and
>the right one will automatically be selected.

Most current mobile devices have such small screens that any attempt at 
CSS presentation will probably make things less readable.  For a 
properly marked-up HTML document there is probably only one way of 
arranging the text on a 3cm x 2cm monochrome LCD display that will be 
any good at all.

>3) Mail-order catalogs have color fidelity concerns on the web. E.g.,
>customers will complain if the garments they order online turn out
>in "different" colors. Media queries will make it possible to show a
>warning message if the color capabilities of the device is too low to
>show colors of acceptable fidelity. (But LCDs will still be poor.)

Such warning messages should *always* appear on the Web, given that 
monitor set-ups vary so greatly.  It would be a case of suppressing the 
message if the media query established that the display device was 
identical to the author's (which would likely be never).

>4) One way to classify video signals is the scan method: progressive
>or interlaced. On interlaced screens one should not use thin (1px)
>horizontal lines since they will flicker. Borders around boxes should
>therefore be 2px or more on interlaced devices, and this can be
>expressed in Media Queries.

It is unreasonable to expect each author creating documents for the Web 
to consider whether their choice of a 1px border is suitable for a 
particular class of output devices.   Instead, browsers running on (in 
this case) interlaced screens should themselves take responsibility for 
ensuring that they do not attempt to render such borders.  This could be 
done internally at some level either with CSS or without it.  A CSS 
solution might be to have a 'min-border-width' property that could 
appear in the user agent's default style sheet.

>I don't think the Media Queries specification (MQ) addresses all
>presentation problems, and it doesn't solve any one problem fully.
>However, it gives authors a way to express presentation preferences
>that are beyond CSS and well into JavaScript-land. Using JavaScript
>and proprietary interfaces, much of the MQ functionality can be
>achieved. So, if MQ appears hostile, JS is the target.

Why would it be an achievement to persuade authors not to use JS for 
such things, only to provide them with an 'approved' method to replicate 
the same (misguided) attempts at pixel-perfect control in CSS?

Best regards
-- 
George Lund

Received on Friday, 19 July 2002 05:51:43 UTC