W3C home > Mailing lists > Public > www-style@w3.org > February 2016

Re: [mediaqueries] Editorial

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 10 Feb 2016 14:33:25 -0800
Message-ID: <CAAWBYDCCkU-7dA7wx6bmB39RZzrs+vqAuT_cRWN4D_qKJ6tcJg@mail.gmail.com>
To: fantasai <fantasai.lists@inkedblade.net>
Cc: "www-style@w3.org" <www-style@w3.org>
On Fri, Feb 5, 2016 at 11:08 AM, fantasai <fantasai.lists@inkedblade.net> wrote:
> 1. Note in the range syntax that it is new to L4, and thus less
> widely-supported
>    than the min-/max- prefixed syntax.


> 2. This sentence is weird:
>  # In addition to conforming to the syntax, each media query needs to use
> media
>  # types and media features according to their respective specification in
> order
>  # to be considered conforming.
> If you're trying to say that such a syntax would be invalid, maybe

I really don't understand what that paragraph is trying to say either.
Removed, as it doesn't add anything.  (In particular, using an invalid
media type doesn't make anything invalid, which is the usual result of
using unknown values in CSS, so I don't want to try and imply

> 3. Start a new section "Evaluating Media Queries" or somesuch, starting
> here:
>  # Each of the major terms of <media-condition> or
> <media-condition-without-or>
>  # is associated with a boolean result, as follows: (...)
> Put this section after 3.1 Error Handling.


> 4. Use curly quotes instead of straight quotes in prose (not code).

Done. (Carefully, one-by-one, so I didn't accidentally change a proper
double quote. ^_^)

> 5. "the style sheet is usable on printed output" -> s/usable/used/
>    likewise for subsequent examples


> 6. “A specified <length> cannot be negative.” ->
>    “Negative <length> values are invalid.”

Done (and same with the various <integer> ones).

> 7. We generally don't define types in the "Values" section in the
> introduction:
>    that section is just saying where to find definitions for types not
> defined
>    in this specification. (It is defining module interactions.) If you're
>    defining a type in a spec, put it somewhere more appropriate to the main
>    content of the spec.

Done, moved them down to the first MQ using them.

> 8. “<resolution> does not refer to the number of device pixels per physical
>    length unit, but the number of device pixels per css pixels.”
>    a) s/css pixels/css unit/


>    b) Move this note to the bottom of the section. It is not interesting
>      to authors.


> 9. The example for 'inverted' has inconsistent indentation.


> 10. The table of pointer devices in the 'pointer' section should
>    a) Move up to the top of the section, since it summarizes the information
>       of all the subsections, not just this one.


>    b) Use class="data" instead of using your own styling. You might also
>       need to use 'scope' attributes on the row headings.

Done, and I simplified the table a bit.  The data styling wasn't
*quite* smart enough to figure it out, and it was laid out kinda weird

>    Also,
>    c) Put some examples inline into the definitions of each value.


> 11. “the 3 levels” s/3/three/g


> Overall, this is a very readable spec, so good job!


Received on Wednesday, 10 February 2016 22:34:14 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:56 UTC