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

On Wed, Apr 4, 2012 at 3:15 AM, Kang-Hao (Kenny) Lu
<kennyluck@csail.mit.edu> 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

I assume that in all of these cases 'inherit' is taken as (part of)
the font family name?

I'd prefer to just file bugs on all the browsers about this.  There's
no good reason to allow it, I highly doubt there's much of any content
relying on it, and it keeps the mental model simpler.


> 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.)

The 'inherit' keyword there isn't a component value - the attr()
function is.  There's no restriction against 'inherit' as a function
argument.


> 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.)

Simon answered 2 and 3.  For 1, I'm confused.  Unless I'm missing
something, this appears to be a major grammar error in 2.1.

>From what I can tell, the only way to parse "-2" is as an IDENT, not a
NUMBER, and the only way to parse "+2" is as a DELIM and a NUMBER.

I'm either quite mistaken (in which case I'd appreciate a
clarification!) or this is a 2.1 error that's needed fixing forever,
and all implementations have just hacked around it.  If the latter,
then once we fix it (presumably to put an optional +/- in the
definition of the NUMBER token), your #1 will be addressed because
it'll be a single token, as will your following comments about signs
in <percentage> (which I've elided for brevity).


> 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.) Proposed wording:
>
>  | 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 the
>  | argument(s) to the notation followed by a right parenthesis. If a
>  | function takes a list of arguments, the arguments are separated by
>  | a comma (‘,’).
>  |
>  | Note that by default spaces may appear between tokens.

The arguments cover that themselves, I would think.  However, it does
seem somewhat unnecessary to talk about whitespace so specifically
here.  fantasai, what do you think?

~TJ

Received on Wednesday, 4 April 2012 17:22:34 UTC