Oct 092008
 

I’ve just completed the documentation for CSS media queries.  This is a very, very nifty capability that lets you select different style sheets based on very precise criteria.  For example, you can use different style sheets on standard versus widescreen displays, or based on the dimensions of the browser window, or whether the screen is 24-bit color or monochrome.

This is very exciting stuff, and hopefully the documentation will be helpful!

 Posted by at 12:06 PM

  8 Responses to “Firefox 3.1 documentation: Media queries”

  1. The “scan” property is listed as accepting a value, but the example uses the value “progressive”. Copy-paste-leftover?

  2. Jens —

    Not sure what you mean; “progressive” is used to query if the device is progressive scan. Is there a particular reason you think that’s incorrect? It’s used as an example in the specification.

  3. bug: ‘media’ is not a media_type, so the example “media and not(color)” is not valid.

    bugs: ‘value:’ field is often incorrectly given value type . For example,
    color and monochrome value types are , not ;
    device-aspect-ratio value type is / , not ;
    resolution value type is , not ;
    scan value type is progressive | interlaced, not .

    bug: does not explain media_type values, nor gives a link to the spec implemented (is it css 2.1§7 ?)

    bug: this page does not specify how Firefox or Gecko (to include Fennec) implements this specification. For example, I assume it uses the ‘screen’ media type for computer screen output, and ‘print’ for printer output.
    Does it ignore all the rest?
    Does Firefox use ‘projection’ or ‘tv’ media type if it is in full screen mode?
    Does Fennec use ‘handheld’ media type in preference to ‘screen’?
    Does Firefox use ‘handheld’ media type on handheld tablets (how can I tell Firefox to do so?)
    For width and height: does Gecko recompute the applicable media styles (width height) if I resize the window or pane?

    specification bug: min is “greater than or equal to” and max is “less than or equal to” so there is no way to specify two exclusive ranges that abut. For example, if a page has

    In this case, a square media device should load both.
    (An unnecessary download. Order in page specifies which prevails.)
    But if instead the page has

    In this case a paperstock card with print area 2500/2400 pixels would fall between and load neither. You can make the gap smaller by using higher numbers like 100/100 and 101/100, but can’t eliminate it.

  4. [try last part again, wordpress elided link element examples above]

    specification bug: min is “greater than or equal to” and max is “less than or equal to” so there is no way to specify two exclusive ranges that abut. For example, if a page has
    <link rel=”stylesheet” media=”(max-device-aspect-ratio: 1/1)” href=”portrait.css”>
    <link rel=”stylesheet” media=”(min-device-aspect-ratio: 1/1)” href=”landscape.css”>
    In this case, a square media device should load both.
    (An unnecessary download. Order in page specifies which prevails.)
    But if instead the page has
    <link rel=”stylesheet” media=”(max-device-aspect-ratio: 10/10)” href=”portrait.css”>
    <link rel=”stylesheet” media=”(min-device-aspect-ratio: 11/10)” href=”landscape.css”>
    In this case a printer containing paperstock card with print area 2500/2400 pixels would fall between and load neither. You can make the gap smaller by using higher numbers like 100/100 and 101/100, but can’t eliminate it.

  5. [try value types bug again using &lt; and &gt;]

    bugs: ‘value:’ field is often incorrectly given value type . For example,
    color and monochrome value types are <integer>, not <length>;
    device-aspect-ratio value type is <integer> / <integer>, not <length>;
    resolution value type is <resolution>, not <length>;
    scan value type is progressive | interlaced, not <length>.

  6. The “scan” property is listed as accepting a [length] value, but that makes no sense. The article should list the allowed values, one of them (judging from the example) being “progressive”.

    (Originally, I wrote “length” with the greater than/less than signs, but the blog ate the “tag”. How about a preview mode so I could have been warned before posting the comment?)

  7. I’ve addressed most of the issues listed in these comments, except for the ones that require engineers to explain how Firefox works internally. I’ll update with that information once I have it. Thanks for the great feedback!

  8. The remaining issues have been address, except the one that requires a note to the working group, which I’ll be taking care of next.