Re: [css3-values] inaccurate statements about syntax/grammar

On 04/04/2012 06:15 AM, Kang-Hao (Kenny) Lu wrote:
> 2.1. Component value types
>
>    # All CSS properties also accept the keyword values ‘inherit’ and
>    # ‘initial’ as their property value, but for readability these are
>    # not listed explicitly in the property value syntax definitions.
>    # These keywords cannot be combined with other component values in
>    # same declaration; such a declaration is invalid. For example,
>    #‘background: url(corner.png) no-repeat, inherit;’ is invalid.
>
> The latter part starting with "These keywords..." is arguable false in
> the following cases, depending on how "combined" and "component value"
> are interpreted:
>
> 1a. 'font-family: xxx inherit;' is valid in all browsers
> 1b. 'font-family: inherit xx;' is valid in IE9 and Opera12alpha but not
> others
> 1c. 'font-family: xxx, inherit;' is valid in all browsers except
> Opera12alpha
> 1d. 'font-family: inherit, xxx;' is valid in IE9
> 2. 'content: attr(inherit);' is valid (testing on only WebKit and Firefox)
> (Feel free to add more if you know anymore. Even if these exceptions are
> too messy to put in the spec, it's probably not a bad idea if a complete
> list is archived on www-style.)
>
> I should mention that although I think normal people (which include me)
> wouldn't really think 2. is invalid, I did think that 1a ~ 1d are
> invalid after reading this sentence before actually doing the testing.

That was the intent, but apparently the WG was not happy with this,
so 1a and 1b are valid and 1c and 1d aren't. Or something. :/

> So, I think the latter sentence is a bit fragile and I suggest we make
> it non-normative. The idea is that whether a property supports "partial
> 'inherit'" should depend solely on the "Value:" line and that property's
> normative prose but not this fragile sentence. Proposed wording:
>
>    | All CSS properties also accept the keyword values ‘inherit’ and
>    | ‘initial’ as their sole property value. For example, the
>    | "Value:" line of 'counter-increment' becomes '[<identifier>
>    |<integer>? ]+ | none | inherit | initial]' . For readability these
>    | are not listed explicitly in the property value syntax definitions.
>    |
>    | Note: This implies that for most properties these keywords cannot
>    | be combined with other component values in same declaration;such a
>    | declaration is invalid. For example,‘background: url(corner.png)
>    | no-repeat, inherit;’ is invalid.
>
> And we leave 'font-family' to decide whether<family-name>  accepts
> "inherit" and how syntax ambiguity is resolved.

Ok, I've adopted your wording, with some tweaks to the note.
('font-family' is really an outlier in this respect, and I don't want
to imply that such exceptions are reasonably common.)
   http://dev.w3.org/csswg/css3-values/#component-types

> 2.3. Component value multipliers
>
>    # Component values are specified in terms of tokens, as described in
>    # Chapter 4 of [CSS21]. As the grammar allows spaces between tokens
>    # in the components of the value production, spaces may appear
>    # between tokens in property values.
>
> The latter sentence is false at least in the following cases I know of:
>
> 1. Spaces are not allowed in-between the sign and the number. Namely
> "'-'(DELIM) S NUMBER/PERCENTAGE/DIMENSION" are invalid token sequences
> besides special situation like in a calc().
> 2. "'#'(DELIM) IDENT" in element(#id) and its possible generalization to
> arbitrary selectors.
> 3. I would assume<id>  used in nav-* to be in a similar situation to 2.
> although it isn't quite clear.
> (Feel free to add more if you know anymore. Even if these exceptions are
> too messy to put in the spec, it's probably not a bad idea if a complete
> list is archived on www-style.)
>
> I'll note that this is a normative conformance requirement statement
> without which you can't put values in between the component values, and
> the "may" here seems odd. Proposed wording for a replacement for the
> latter sentence:
>
>    | Unless otherwise specified, UAs must ignore S tokens between other
>    | tokens while matching a property value definition.

How about

  | Unless otherwise specified, white space and/or comments may appear before,
  | after, and/or between components in a property value or subcomponents in
  | a functional notation that is defined using these component combinators
  | and multipliers.

?

> Note that
>
> 4. calc()
>
> also falls into the "unless otherwise specified" because spaces are
> required between a plus or minus.

Hmm, I don't think the contents of a functional notation should be
considered component values of a property value. They could be
considered components of a functional notation, though.

> 4.1. Integers: the ‘<integer>’ type
> [...]
> (Note that when you say "integers may be immediately preceded by ‘-’ or
> ‘+’", you seem to be making a difference between /integer/ and
> <integer>, which doesn't seem desirable.)

Indeed. Let me fix that instead by writing
   # The first digit of an integer may be immediately preceded by ''-'' or ''+''
   # to indicate the integer's sign.
since that doesn't depend so closely on the issue mentioned below.
It's probably not perfect enough to make you happy, but it's the best
I can do given the situation, and at least addresses the comment quoted
above.

> I should note that the "immediately followed" here is different from
> others in that this one separates two tokens. Namely, '+/**/1' is a
> valid<integer>  but '1/**/%' is not a valid<percentage>. I am not
> asking for a change here because talking about COMMENT here might make
> the prose unreadable, but I just want to mention this as potential place
> that might confuse people.

We've got an open issue on that:
   https://www.w3.org/Bugs/Public/show_bug.cgi?id=17509

> 8. Functional Notations
>
>    # Some values use a functional notation to type values and to lump
>    # values together. The syntax starts with the name of the function
>    # immediately followed by a left parenthesis followed by optional
>    # whitespace followed by the argument(s) to the notation followed by
>    # optional whitespace followed by a right parenthesis. If a function
>    # takes a list of arguments, the arguments are separated by a comma
>    # (‘,’) with optional whitespace before and after the comma.
>
> This paragraph didn't talk about optional whitespace within a single
> argument (say, the space between wqname and <type>  in attr()). Instead
> of an incomplete description, I'll suggest not talking about whitespaces
> as normative prose here. (It's already covered by the "UAs must ignore S
> tokens between other tokens" or the original "spaces may appear between
> tokens in property values" clause.)

I agree with Tab that it's the responsibility of the arguments to define
where white space is allowed within them. So, no change for this one.

These issues are filed as:
   http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-19
   http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-20
   http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-39
Please let me know if the responses are satisfactory.

~fantasai

Received on Tuesday, 17 July 2012 04:46:34 UTC