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

(12/04/05 1:21), Tab Atkins Jr. wrote:
> 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?

When I said "valid", Yes.

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

So I assume you more or less share my interpretation before testing
(namely, 1a ~ 1d are invalid)? The problem is that I can see at least
three interpretations of the current text which includes this one and
IE9's and Opera's:

The current property value definition is

  [ <family-name> | <generic-family> ]#

The three interpretations are

1. (1a ~ 1d are invalid) More of less expand the value definition into [
<identifier>+ | <generic-family> ]# (i.e. treat other identifiers as
"component values")

2. (Opera's) Treat a <family-name> as a single and unbreakable component
value and honor the "These keywords cannot be combined with other
component values in same declaration" sentence. (Note that I believe a
normal component value is breakable.)

3. (IE's) Totally ignore "These keywords cannot be combined with other
component values in same declaration" (because there's never a formal
definition of "component value" maybe?) and resolve 'font-family:
inherit;' as matching the global keyword 'inherit' instead of <family-name>.


I don't think mental models matter that much in this example, as it only
affects people who read the spec; performance matters more.
Backward-compatibility matters the least because there's unlikely any
content relying on this as you said. Also, 1. doesn't match any browser,
so I don't think that's the way we want to go. I am probably leaning
towards IE9's interpretation because I don't find that sentence
reliable. Though obviously, no strong opinion.

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

If you read the sentence "These keywords cannot be combined with other
component values in same declaration" very literally in, say, an example
like 'attr(inherit integer)'. 'inherit' is a keyword. 'integer' is a
component value of type <type>, and they are obviously combined in the
same declaration, although implicitly in a function. Why doesn't this
sentence apply?

Admittedly, I don't read this sentence this way but I just want to point
out: without a formal definition of "component value", this sentence is
vague and subject to multiple interpretations. (1. is more of a valid
example)

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

No, "-2" isn't an IDENT.

  # they (identifiers) cannot start with a digit, two hyphens, or a
  # hyphen followed by a digit.

It is a DELIM and a NUMBER like "+2".

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

I doubt we'll be able to make this change from one to another. As I
pointed out in [1], this is testable and are implemented by WebKit and
Opera. But I should say I'll probably avoid submitting test cases like
this because they are "in the realm of useless test cases" and only
harming IE and Firefox for no good reasons.

I suggest we make this a multiple choices in CSS 2.1 (i.e. somehow
undefine it) and spec editors just have to keep this fact in mind when
writing spec sentences.

[1] http://lists.w3.org/Archives/Public/www-style/2012Apr/0082


Cheers,
Kenny

Received on Wednesday, 4 April 2012 20:59:25 UTC