Media Queries – disposition of comments


Comments on draft of 15 October 2008

Last call document:

This document is the disposition of comments on the Media Queries CR sent to the www-style mailing list. The Media Queries CR was first published 8 July 2002, with an editorial revision published 6 June 2007.

The following color coding convention is used for comments after the 6 June 2007 publication:

The table also includes comments that were sent on the editorial revision of 6 June 2007, without colors.

(There were no formal objections.)

Comment from Art Barstow on Tue, 16 Jul 2002; answer on www-style.
1 Given the W3C has already developed a framework (CC/PP) for describing device capabilities (to be used by a server to generate appropriate content), why did the CSS WG ignore this work and develop yet another, competing solution? Media Queries are different in several respects. First, the communication goes the other way and the client (rather than the server) makes the decision on what style sheet to use. The CSS WG thinks there is room for both a client-based and a server-based solution. Second, the work on Media Queries is continued from HTML4 where section 6.13 sketches a solution very close to Media Queries. So, the solution was developed before the work on CC/PP started and should not be interpreted as hostile to CC/PP.

Also, see disposition of comments from Philipp Hoschka in the disposition of comments to the Last Call.

Comment from Susan Lesch on Sat, 8 Feb 2003.

These are minor editorial comments for your Media Queries Candidate Recommendation...

Comment from Arve Bersvendsen 07 Aug 2003.
3The specification does not seem to address exactly how aspect ratios should be queried. The spec seems to assert/dictate that pixel height divided by pixel width provides the correct device aspect ratio. For some devices, one cannot assume that pixel-height/pixel-width provides the correct aspect ratio. Resolved. (See comment 16.)
Comment from Christoph Päper.
4 Regarding CSS 3 Media Queries (CR 2002-07-08), I would like to propose an additional "media feature" to describe whether or what kind of images are supported:
   images (or image)
   Value: none | bitmap | vector | all
   Applies to: visual media types
   Accepts min/max prefixes: no
It is an interesting idea to add queries on what features a UA supports. One could, for example, also add media queries to check whether a UA supports multi-column layout or CSS3 selectors. This may become the topic of a future specification, but the CSS WG do not want to address this big task in a relatively stable draft. Also, it should be pointed out that UAs have a history of falsifying their identity to make sure they receive all content.
Comment from Anne van Kesteren 07 Jul 2005.
5 Where in CSS3 is defined that @page is allowed in @media as in:
@media print{

I couldn't find it anywhere and I guess it should have been defined in CSS 3 media queries which points to CSS 2.1 (or 2.0, actually) which I believe forbids it. However, the CSS 3 paged media module gives some examples of it which make it same like it is allowed. (And it would make sense.)

The expectation is that other modules will define this.
Comment from Anne van Kesteren Sat, 23 Jul 2005.
Comment from Anne van Kesteren Mon, 31 Mar 2008.
6I was wondering why a negative <length> for 'width' (and other media features) is not disallowed ... I hope a further revision of the specification could say that "<length> must be a positive integer when applied to a media feature specified in this specification." (Perhaps adding "or zero" to that for clarity if needed.) With my editor's hat on I went through all the features and clarified what type of "numbers" they could hold and whether those could be negative, zero, or just positive.
Comment from Simon Pieters Fri, 16 Dec 2005.
7 I think that if @media has an empty list of media queries, it should be equivalent to "all". So the following at-rules all have the media query "all":
@media {}
@media all {}
@media "foo" {}
@media all "foo" {}

What should happen when the name is the empty string? I guess it should work the same way as <link rel=stylesheet title=""> in HTML. In Mozilla and Opera, the empty string is equivalent to no name at all (or the other way around, no name is equivalent to the empty string). Thus, I think the following should be equivalent:

@media all {}
@media all "" {}
We agree that a syntax where 'all' is omitted may be handy. The revised CR adds a shorthand syntax for media queries that apply to all media types; the keyword ''all'' can be left out (along with the trailing ''and''). These two media queries are equivalent:
  @media all and (orientation: portrait) { ... }
  @media (orientation: portrait) { ... }
Comment from L. David Baron on Thu, 11 May 2006; answer on www-style.
8 css3-mediaqueries doesn't seem to define the error handling behavior for syntactically incorrect media queries. This needs to be defined so that it is possible to know which of the following rules should make p elements green:
@media all and (min-width: 1px), all and (min-width: more than 1px) {
  p { color: green }

@media all and (min-width: 1px), all and (unknown-feature: 3px) {
  p { color: green }

@media all and (min-width: 1px), all and (min-width: 1unknownunit) {
  p { color: green }

@media all and (min-width: 1px), all and ((< min-width 200px)) {
  p { color: green }

@media all and (min-width: 1px), all and (width at least 200px) {
  p { color: green }

Section 5 does say this:

Since "max-weight" is an unknown media feature, the Media Query is false and the associated style sheet will not be applied.

But it doesn't say how unknown media features are parsed. Is anything unknown within matched parentheses accepted, but considered always false?

This is now clarified in the new error handling section.

Comment from L. David Baron Thu, 11 May 2006.
9Section 4 of has the example:
@media screen and (color), projection and (color)
 { @import url( }
even though @import is not allowed inside @media. (Or is that supposed to be changed in CSS3?)
The example was changed in the editorial revision published 6 June 2007.
10It would also probably be good if some examples in the spec were media lists on @import rules; this is a good candidate. Examples using @import rules were added in the editorial revision published 6 June 2007.
Comment from Christoph Päper on 22 Aug 2006.
11CSS3 Media Queries CR introduces two new units (7.), |dpi| and | dpcm|, solely for its |resolution| media feature (6.9.). Could this be changed or at least be amended to also allow standard CSS absolute length units (e.g. |mm|)? The values using |in| and |cm| would of course be the respective reciprocals of the current ones and described the size of one pointW pixel. If a new unit was needed at all this would be |um|, the ASCII representation of 'µm' for micrometre, approved by ISO (31?). The 'dpi' unit is most commonly used to describe resolution, and 'dpcm' provides a SI-based alternative. Adding even more units to describe resolution seems excessive at this point.
12It might also be a good idea to make this media feature a shorthand for horizontal and vertical resolution for which separate features might be added later. The WG has decided to handle differences in vertical and horizontal resolution as described in comment #3.
Comment from Anne van Kesteren on Mon, 15 Jan 2007.

Parsing media queries

In HTML4 it was pretty clear. You first split on the "," and then remove all characters after the first non ASCII-letter, hyhen or digit. The resulting values are the media specified.

For Media Queries it's not clear what rules you have to follow when the media query given (after splitting on ",") doesn't match the syntax. It's important to know this for the CSSOM MediaList interface for instance.

After reading the reply to comment #8, Anne writes: Ah ok, I guess that sort of solves it. It does mean though that "not all and (foobar)" would apply. Is that desirable? I was thinking that such a media query should perhaps simply be ignored completely so we don't have to worry about how to represent it in the DOM either. That seems also more in line with error handling in CSS.

This is now addressed by the revised syntax section.
Comment from fantasai Mon, 13 Aug 2007.

The poster suggested that it would be more useful to use the media *groups* defined in CSS2.1 [1]. E.g.

   @media paged { ... }
Too late for this version. We should reconsider this for Media Queries Level 4.
Comment from fantasai Tue, 21 Aug 2007.
15 Today we discussed how imprecision in device hardware results in display widths and heights that are not *exactly* in line with the nominal width and height. It was suggested that we should allow some fuzz factor in media query matching for this reason. No change.
Comment from fantasai Tue, 21 Aug 2007.
Proposed changes:

   # In this specification, aspect ratio is defined as the number of
   # horizontal pixels over the number of vertical pixels.

   change to

   | In this specification, aspect ratio is defined as the horizontal
   | length of the device's display divided by its vertical length.

   # The 'resolution' media feature describes the resolution of the
   # output device, i.e. the density of the pixels.


   | When querying devices with non-square pixels, in 'min-resolution'
   | queries the least-dense dimension must be compared to the specified
   | value and in 'max-resolution' queries the most-dense dimensions must
   | be compared instead. A fixed 'resolution' query never matches a device
   | with non-square pixels.

   (Alternatively we could allow two values to query each dimension
   independently, but I don't think this is useful.)
Comment from Stewart Brodie Wed, 22 Aug 2007.
'not' and unknown media types:

Section 3 says: "The presence of the keyword 'not' at the beginning of the
query negates the results."  Section 4 says: "Media queries involving
unknown media types are always false".

When I read that, the word 'always' led me to wonder whether or not unknown
media types trump the section 3 definition of 'not'.  I suggest the
following clarifications:

1) remove the word "always" from the section 4 statement
2) Add an example showing that the following media query is true:

     @media not 3d-glasses { ... }
'not foo' is true and 'foo' is false. (3d-glasses is a parse error.)
Comment from Stewart Brodie Wed, 22 Aug 2007.
18 Does "color-index" have a zero value unless a lookup table is used? If the device does not use a color lookup table, the value is zero.
Comment from Andrew Fedoniouk Tue, 28 Aug 2007.

Is it possible to add in media queries [1] value that will indicate that UA is running with high-contrast-screen settings?

Too late for this version. We should reconsider this for Media Queries Level 4.
Comment from Ian Hickson 6 Nov 2007

it'd be nice if we defined the lack of a media query string to mean "all"

Comment from Henri Sivonen 14 Nov 2007.

Parsing is not well defined in terms of whitespace and error handling.

This is now addressed by the syntax section.
Comment from Henri Sivonen 17 Nov 2007.

If a media feature does not match the media type is that an error?

No. Writing "speech and (width:100px)" is acceptable. The validator may issue a warning though.
Comment from Henri Sivonen 17 Nov 2007.

grid doesn't apply to all media

Fixed, thanks!
Comment from Anne van Kesteren 03 Dec 2007.

I think that the Media Queries draft should either define media types itself or should reference CSS 2.1 for them. Referencing HTML4 and CSS2 for these seems outdated. For instance, "aural" is deprecated in CSS 2.1, but "speech" is not. "speech" is not mentioned in Media Queries and "aural" is used in examples and mentioned several times.

Too late for this version. We should reconsider this for Media Queries Level 4.
Comment from Anne van Kesteren 10 Dec 2007.
25Syntax issues. Addressed. (Syntax is now described in terms of CSS 2.1 eliminating these issues.)
Comment from Anne van Kesteren 12 Dec 2007.
26Using the same syntax rules for HTML and CSS. Addressed by using Bert's syntax proposal.
Comment from Simon Proctor 19 Dec 2007
27 Introducing a 'supports()' querying feature. Too late for this version. We should reconsider this for Media Queries Level 4.
Comment from David Baron 06 Apr 2008
28 What does '(scan)' mean? The draft is clarified to mention that each media feature (including min/max prefixed) "(media-feature)" is equivalent to "(media-feature:x)" for when x is not equal to 0. (If media-feature does not accept 0 x can be any value.)
Comment from David Baron 07 Apr 2008
29 Bad examples for orientation. (Only value was given.) Examples are fixed.
Comment from David Baron 07 Apr 2008
30 Is 'resolution' in terms of CSS or device pixels? Should be device pixels.
Comment from fantasai 24 Apr 2008
31 Definitions of 'height' / 'width' / 'device-height' / 'device-width' need rewording. Reworded as suggested later in the thread.
Comment from Stewart Brodie 6 Jun 2008
32 Does the 'resolution' feature take a float or integer? Defined <resolution> to take an <float> immediately followed by a unit identifier per this e-mail from fantasai.
Comment from fantasai 9 Jun 2008
33 Do we need special wording for display-level transformations, like zooming and N-up printing? We're not going into this level of detail for now.
Comment from David Baron 11 Jun 2008
34 Allow whitespace around '/' for the aspect-ratio and device-aspect-ratio media features. Agreed.
Comment from David Baron 19 Jun 2008
35 says:
  # For a media feature feature, (feature) will evaluate to true if
  # (feature:x) will evaluate to true for a value x other than zero.
Does this mean:
  (a) (width) is always true, even if the viewport width is zero,
  because "0px" is a value other than zero, or:
  (b) (width) is false when the viewport width is zero because "0px"
  and "0" are both not "other than zero"?
I'd also note that because specified widths cannot be negative,
(max-width) currently behaves the same as (width), whereas
(min-width) is always true.  Is that really intended?
Zero is clarified to mean 0px, 0, etc. Min/max prefixed media features without values cannot be used.
Comment from David Baron 19 Jun 2008
After reading it's
not clear to me whether the queries "(grid: -1)" or "(grid: 2)"
should be parse errors or should always be false.  It should be
Clarified they are indeed parse errors.
Comment from Dean Jackson 30 Oct 2008
37The request is changing the syntax of aspect-ratio and device-aspect-ratio to floats and orientation to angles. The WG decided to not make a change here. The WG also decided to keep aspect-ratio and device-aspect-ratio and not drop them as suggested in the follow-up thread.
Comment from Jens Meiert 22 Sep 2008
38Editorial. Fixed.
Comment from Sergiu Dumitriu 23 Oct 2008
39Editorial comments. Also a question whether 'ex' should be described for tty since 'em' is defined. The WG decided to remove the definition of 'em' for tty and leave that definition up to the values & units draft.
Comment from Andrey Mikhalev 25 Feb 2009
40The grammar mixes CSS2 grammar and CSS core grammar productions. Fixed by using expr rather than value.
Comment from Anne van Kesteren 8 Dec 2008
41Media queries has the implied suggestion to violate core grammar error handling. Added a note of a clarification per fantasai's suggestion.

Comments on draft of 23 January 2002

Last call document:

This is the list of comments received on the above draft. No open issues and no objections remain as of 8 July 2002.

Comments from Susan Lesch <> 3 February 2002
# Comment Answer
1 It would help a lot if the title was Media Queries rather than Media queries. In running text, one could think that the title is Media unless the writer added quotation marks. Changed.
2 Also "CSS" or "CSS3" in the title might help readers know what they are about to read. The reason for not using "CSS3" in the title has been that Media Queries are used not only in CSS style sheets, but also in HTML attributes and XML processing instructions. By adding "CSS3", we should restrict the scope of the document unnecessarily. No change.
3 Globally, s/User Agent/user agent/ Changed.
4 In the status section, s/Style activity/Style Activity/ Changed.
5 In 1, add a link to [HTML40] after HTML4, section 6.13 for people who print. Isn't the text "HTML, section 6.13" a sufficient reference for people who print?
6 In 2, the bullet items are sentences and can be capitalized and have ending periods. Changed.
7 In 3.1, s/Media Queries../Media Queries./ Changed.
8 In 3.1, add a link to [CCPP] before the two links to CC/PP and add a reference for people who print. The link to RFC 2534 could link to a reference [RFC2534] not to the RFC. Done.
9 In 3.3, link to a reference [RFC2506]. Done.
10 In 4 and 5, please do not mention Changed.
10 In 4, you could break this long sentence: A media query is true if the media type of the media query matches the media type of the device where the User Agent is running (the User Agent is responsible for knowing which one of the defined media types which most closely resembles the device), and all expressions in the media query are true. maybe like this: A media query is true if the media type of the media query matches the media type of the device where the user agent is running, and all expressions in the media query are true. (The user agent is responsible for knowing which one of the defined media types most closely resembles the device.) Changed.
11 In 5, is this true for XHTML selectors? "CSS style sheets are generally case-insensitive, and this is also the case for media queries." Selectors are the glue between CSS and the document languages. Thus, the case-sensitivity of selectors is the same as the case-sensitivity of the document language. Other parts of CSS, e.g. properties and units, are always case-insensitive. No change.
12 In 5, s/The parenthesis ("()")/The parentheses ("()")/ and s/without the parenthesis/without the parentheses/ Changed.
13 In 5, add a link to [CSS2] after the link to CSS2 for people who print. Are you referring to the link with the text CSS2, section 4.3: Values and Units? If so, isn't the text clear enough as it stands?
14 In 6.6 link to a reference [RFC2531]. Changed.
15 In 6.6, s/provide more specific/provides more specific/ Changed.
16 In 8, s/the W3C Working Group on Cascading Style Sheets and Formatting Properties/the W3C Working Group on Cascading Style Sheets/ (I think.) Changed.
17 In 8, Duerst comes after Diaz. Indeed. The full list of members has now been removed.
18 In 8, make the reference titles the link; (the URI should be plain text). Done.
19 In 8, why make HTML 4.0 a reference rather than HTML 4.01? Changed
Comments from Simon Kissane <> 17 February 2002
# Comment Answer
20 The current CSS3 Media Queries working draft only defines dpi (dots per an inch) as a resolution unit. I strongly suggest that you also provide a metric unit for resolution, such as dots per a centimetre (dpcm) or dots per a milimetre (dpmm). The "dpmm" unit has been added in the new draft.
Comments from Subra PV <> 20 February 2002
# Comment Answer
21 The example under device-aspect-ratio (no mix-max) says how to target a media with an particular device-aspect-ratio.

Question: To support media's with device-aspect-ratio 16:9 or 2.35 (or more) can the query like this is

@media screen and 
  (device-aspect-ratio: 16/9, 2.35)
A comma-separated list cannot be used since commas are used to separate Media Queries. However, you can express your example in the current syntax as:
@media screen and (device-aspect-ratio: 16/9),
       screen and (device-aspect-ratio: 4/3)
22 Also the spec does not seem to address some of the media features define by UAPROF. An example of that can be "Table". An use case for using "table"
   @media screen and (table) {
      div {display: table}
It's an interesting idea to not only make requirements on the hardware of the device, but also on the software. However, there are currently no well-defined descriptions of what "table" or other profiles mean. We believe Media Queries could be extended in this direction in the future.
Comments from Philipp Hoschka <> 20 Feb 2002
# Comment Answer
23 Overall, I have the feeling that there are starting to be too many notations to describe device features, and that some convergence would do no harm. I'm aware of at least CC/PP/UAPROF, IETF conneg, SMIL and SVG test attributes, SDP, and now CSS media queries. We agree in principle that convergence is good, but the WG does not think any of the other specifications mentioned above address our requirements.
24 Please add a reference to RFC2534 in the reference section Done.
25 RFC2533 "A Syntax for Describing Media Feature Sets" provides a syntax for describing media feature sets

In the "related work" section, please explain why you could not reuse this syntax (I think I know the answer to this, but it would be good to have it on record)

We could not use this syntax since it involves '<' and '>' characters that are, in their unescaped form, illegal inside HTML attributes. In their escaped form ('&gt;' and '&lt;') they look ugly. This explanation has been added to the "Related Work" section.
27 Please add a reference to CC/PP in the reference section Done.
28 CC/PP (and UAPROF) provide an RDF-based syntax to describe combinations of device characteristics. Please explain why you did not reuse this syntax by either
  • embedding a CC/PP description in the document
  • referring to an external CC/PP description via a URI
For the first question, see issue #25.

Referring to an external description via a URI was proposed and discussed in the WG. However, an external URL would be expensive to resolve and cache. The proposed syntax builds on, and is compatible with, existing W3C Recommendations. Furthermore, the syntax is very compact and readable.

29 One of the guiding principles of W3C's work on Web architecture is to avoid central registries, and to use URIs to identify objects. See e.g. "in new developments, all significant objects with any form of persistent identity should be "first class objects" for which a URI exists." in the Architecture document or "In HTTP, the format of data is defined by a "MIME type". This formally refers to a central registry kept by IANA. However, architecturally this is an unnecessary central point of control, and there is no reason why the Web itself should not be used as a repository for new types. Indeed, a transition plan, in which unqualified MIME types are taken as relative URIs within a standard reference URI in an online MIME registry, would allow migration of MIME types to become first class objects." in the same document

CC/PP uses URIs for media features, CSS media queries uses a central registry. Using URIs has the additional benefit of providing simpler extensibility and evolvability than a central registry.

Could you address on why you chose to use one central registry, rather than a URI-based solution such as CC/PP?

CSS3 Media Queries are described in a W3C specification, not in a central registry. We intend, however, to register the media features to make it easier for others to reuse them.
30 Please define the media features defined in CSS media query using an RDF schema as described in The CSS WG has started a collaboration with CC/PP WG with the goal of publishing the result as a separate note.
Comments from Roger Gimson <> 20 Feb 2002
# Comment Answer
31 (Comment-1) The document assumes the 'media types' used in CSS2, which were derived from the 'media descriptors' of HTML4: aural, braille, handheld, print, projection, screen, tty, tv, embossed. These types, which in some cases refer to device categories rather than the media they support, have never been very well defined, and are likely to be inadequate for authoring in the future. In particular, it seems to be assumed that the media types are mutually exclusive, in that any particular device can only support one media type. If they are mutually exclusive, this will be a problem for multimodal devices (see Comment-3 for an example). Furthermore, it is likely that distinctions between device types will become more blurred in the future (e.g. watching tv on a handheld). It would be better to encourage authors to select styles according to device capabilities that are important to their application rather than broad categories of device. At some stage, the media types should either be deprecated, or be redefined in terms of assumed device capabilities (e.g. 'screen' implies an interactive visual presentation of a given minimum height and width, 'print' implies a paged, static visual presentation of a given minimum resolution). Indeed, the 'media types' in CSS2 and HTML4 are not strictly defined, but the keywords are commonly used terms. Media Queries have been designed to allow for more device-specific requirements, and this is in line with your comment. Instead of trying to define exactly what each media type constitutes, Media Queries allow style sheet authors to set their own requirements. We believe this is a better strategy since the definition of a media type is likely to change over time.
32 (Comment-2) In Section 4 which defines Media Queries, the following statement is made: "If a media feature does not apply to the device where the UA is running, expressions involving the media feature will be false". Does 'device' mean 'media type', as used in the following example of an 'aural device'? (See also Comment-4) No, 'device' refers to the physical device where the user agent is running.
33 (Comment-3) In the example, the expression "aural and (min-device-width: 800px)" is said to be always false. However, this need not be false for a multimodal device that supports both aural and visual presentations. See issue #54
34 (Comment-4) Maybe I am used to a different pseudo-BNF notation, but it seems that the ? and * are the wrong way round. I expect ? to mean none-or-one and * to mean none-or-many. Indeed, there were two errors in the pseudo-BNF grammar. Fixed.
35 (Comment-5) In the list of media features in Section 6, features are described as being applied to the following 'media types': visual, tactile, aural, bitmapped, tv. Three of these are not valid 'media types' as defined in Section 1, but rather 'media groups' as defined in the CSS2 Specification, section 7.3.1 (although 'bitmap' is used there rather than 'bitmapped'). In fact, media groups are much closer to capturing orthogonal device capabilities than media types, and since they are already the basis for defining which CSS properties may be applicable, would also form a sounder basis for media queries in stylesheets. It's an interesting proposal and the "grid" media query has been added in response to your comment. More media groups could be added in the same way in the future.

The term "bitmapped" has been changed to "bitmap".

36 (Comment-6) The examples used in Section 6 are all specific to CSS since they start with "@media". Previous examples showed media queries in the context of media attributes within xlink elements. Presumably the media_query syntax is defined to allow the same syntax to be used in either situation. The reason for the switch in example style should be explained. One example has been changed to use the HTML syntax and another to use the XML syntax. Also, the text in section 4 has been clarified.
Comments from Steven Pemberton <> 21 Feb 2002
# Comment Answer
37 Stylesheet: Please replace body {font-size: medium} with body {font-size: 100%} The user should decide how big the base font is. Medium is too big for me, and will be too small for others. The final specification will use the normal W3C style sheets.
38 "Screen" and "print" are two of media types that have been defined. => of the media types Changed.
39 (1. Background) First example Doesn't really match the description. Use
@media screen { * {font-family: sans-serif}
or change the description to "For example, a document may use different style sheets for on screen and printing".
Changed. Your wording is used in the latest draft.
40 Media-specific style sheets are supported by several User Agents. The most commonly used feature is, as in the example above, to distinguish between "screen" and "print". => add: and "projection" is beginning to catch on. Changed. Your wording is used in the latest draft.
41 Make it clear that sections 1-3 are informative, and 4-7 are normative. (isn't it weird that RFC2534 uses the American spelling "color" with the English spelling "grey"?) Changed.
42> (everywhere) ( is the website of Vogue) Changed. Also, see issue #10.
43 (6. Media features.) "pretext" means something else. The correct word is "prefix" (replace everywhere) Changed.
44 (6.1 width) The "em" value is based on the font size of the root element. Hmm. And how do you hope to determine that if you haven't loaded any stylesheets yet? I don't see how this can reliably work. Good point. The CSS WG agrees that requireing all stylesheets to be loaded in order to determine their applicability is expensive and will result in circular definitions. This sentence has been added to resolve the issue.

Relative units in media queries are based on the initial value of that property.

This initial value for some properties could, in turn, be based on user settings. For example, the initial value of 'font-size' is the keyword 'medium' which may be what the user specifies.

45 (6.3 and 6.4 device-width/-height) What is the difference between the device-width and the viewport width? You'll need to explain. In CSS terminology, a viewport is "a window or other viewing area on the screen". The description has been changed to:

The "width" media feature describes the width of the rendering surface of the output device. For continous media, this is the width of the viewport (as described by CSS2). For paged media, this is the width of the page box (as described by CSS2).

46 (6.5 device-aspect-ratio) Frankly I would want some slop here. I'd hate to be turned away at the doors of my style-sheet because my number of bits was slightly different. Other questions:
  • Why can I enquire of the device, but not of the viewport?
  • Why can't I just ask if it is landscape or portrait?
  • Why aren't there prefixes for this property? max-device-ratio: 1/1 would give me portrait or square; min-device-ratio: 1/1 would give me landscape or square for instance.
The requirement for a device-aspect-ration comes from the TV industry. A similar requirement for viewport aspect ratio has not been put forward by anyone.

The suggestion to allow prefixes on this media feature is good and this has been added to the latest draft.

47 (6.9. Resolution) Only inches? All the adverts *I* read talk about screen resolution in terms of dot pitch, expressed in mm (which is mm/dot instead of dot/in). For instance 96dpi is about a dot pitch of .26mm "dpcm" has been added to give people a metric alternative to "dpi".
48 I applaud you for using the word "resolution" correctly (which most people seem to think means "number of bits" when talking about screens). Thank you!
49 You should be clearer here and in 6.3, 6.4, 6.5, that you are talking about (as I assume) the resolution that the device is operating at, and not its maximum possible resolution (many people seem to run their 1024x748 monitors at 800x600 in order to get larger fonts, because no one knows how to tell their operating system what the resolution of their screen is; I'm assuming that the enquiries give the 800x600 value and not the finer one). The new draft has been modified to clarify this issue.
50 (6.10 scan) How on earth would you use this to decide on which stylesheet to use? Just interested. 1px horizontal lines will flicker on interlaced screens. Therefore, this style sheet makes sense:
A { border-width: 1px }
@media all and (scan: interlace) { 
  A { border-width: 2px }
51 (7. Units) Same problem as 6.1: how can you determine the value on the root element while you are still trying to determine which stylesheet to load? See issue #44
Comments from Al Gilman <> (on behalf of WAI) 25 Feb 2002
# Comment Answer
52 Recommend changing the name of of the 'width' property to 'viewport-width' to make it parallel with 'device-width' and the same for 'height' change to 'viewport-height.' In CSS2, the term "viewport" is only defined for continous devices. We want the 'width' media feature to be usable for paged media as well. We could extend the definition of the term "viewport", but using the shorter name 'width' seems like a simpler solution.
53 In section "6.1 width" it says The "em" value is based on the font size of the root element. Does this, or does this not require the retrieval and application of the linked stylesheet in order to determine the initial font size that this refers to?

For accessibility, this determination should acquire the base font size from the processor, that is to say incorporate the settings of the user inherited by the document from the operating system and browser. How will that happen under the above definition?

I would think that the logical path for this value would be from the user settings into the browser's effective or default stylesheet and from there into the context of the root element of the document, which would inherit it from there. This implies that if a stylesheet asserts an initial font size that this intervenes in the process and overrides the value from the browser. Is this true?

See issue #44
54 Screen readers interpret a document in multiple media from one rendering. They do not apply a different stylesheet for the tactile or aural presentation from the one that produces the screen presentation. Does this expression syntax for media applicability conditions allow one to indicate that the medium in use is at once both screen and Braille forms? In both Braille and audio? How? Media Queries do not indicate what sort of medium is in use. Media queries describe constraints that must be satisfied in order for the style sheet to be applied. Indeed, multi-modal renderings challenge the definition of media types as being mutually exclusive. However, the same user agent may change the media types in different situations. For example, when displaying a page in print preview mode, the media type is typically switched to 'print'. And, some browsers switch to media type 'projection' when in fullscreen mode. Even when multi-modal presentations happen simultaneously (e.g., when a headline is spoken while being displayed on the screen), the user agent can use different media types for the different presentations. When synthesizing speech, the user agent will apply style sheets associated with the 'aural' media type, and when displaying text on the screen, the 'screen' media type will be applied.

The primary reason for media types being mutually exclusive is to allow authors to write separate style sheets for different media types. For example, a rule tied to the "screen" media type should not influence the presentation on a "handheld" device — even if the handheld device has a screen.

55 Please explain your reasoning which led to not supporting all features duly registerd and listed at both now and in the future by a suitable binding of that namespace to this syntax. As explained in the draft, we do not think the media features listed are suitable for use in Media Queries. However, new and more usable media features could be registered in the future and/or new requirements could make e.g. the CIELAB media features relevant. When that happens, the new media features can easily be used in the Media Queries syntax.

The table below shows the syntax for common logical expressions in RFC 2506 and Media Queries.

RFC2506 CSS3 Media Queries
= :
>= "min-" prefix
<= "max-" prefix
& and
| ,
Further comments from Al Gilman <> 1 Apr 2002
# Comment Answer
56 In terms of mnemonics it is OK for these queries to be called 'media queries' as a colloquial thing, but for accessibility, they need to be 'delivery context' queries and be sensitive to properties outside the domain of expertise of the Style activity and CSS Working Group. The proper scope for properties appearing in selectors is a Device Independence question, not a Style question. And Device Independence and WAI are agreed that the present logical model with disjoint media and properties limited to what is published in the CSS specification is inadequate. The CSS WG believes Media Queries is within the scope of the CSS WG since they describe when a style sheet should be applied. We are sensitive to the fact that other groups also have knowledge in this area and welcome concrete proposals as well as informal discussions on new Media Features. The TV-related Media Features in the current draft result from discussions with representatives from the TV community.
57 In HTML and CSS2 WAI and HTML negotiated that media type names were "some predefined but others legal." The CSS Response to the CSS Media Queries comments is even more restrictive than that. WAI supports the DI contention that disjoint assumption for media types is too restrictive, does not cover what is eventually needed.

Existence-proof Scenario (example of why we care): Blind user with screen reader and speech only -- add 'speak before' etc. generated content is appropriate. BUT Reading-difficulty user with speech augmented reading -- don't introduce anything not on screen. Correct style selection depends on the media combination, not just the medium.

It would have been beneficial to include the CSS WG in previous negotiations on media types as they are part of CSS2. There is consensus in the CSS WG that media types are disjoint and the Media Queries draft does not institute a new interpretation.

We do understand your example and invite you to put forward a proposal for a new media type name describes the second case. This is a simpler solution than introducing formal logic to describe combinations of existing media types.