| The main reason (besides personal preference) is to disambiguate the
| scoping when using commas. That is, what exactly does
|
| (A), (B) (C) (D), (E) {...}
|
| mean? I think that at the very least, the spec has to be explicit
| about how these group. With another notation you could say what you
| mean:
|
| A, B::C::D, E {...}
| (A,B)::C::D, E {...}
| (A,B)::C::(D,E) {...}
---I would recommend allowing parentheses, using '+' for the ancestoral relationships, and using '|' for alternatives. So,
L1 | ((L2|L3)+EM) | (EM+B) {font-size: big}
specifies four contexts in which the font-size should be big.
In practice you would want to encourage people to make the specifications meaningful, rather than just combining all the contexts that happen to have the same styling, but sometimes it would make sense to group them so that a future change could be applied to a single meaningful collection of contexts.
I think '+' would be more intuitive for ancestory than either '::' or a blank space - it naturally conveys the dea of combining or layering-on. The '|' for alternatives may be unfamiliar to non-technical authors, but I think it's preferable to comma because comma may be *too* natural and might cause confusion about precedence.
Parentheses are important specifically because they are unambiguous and avoid the issue of precedence. If you don't have parentheses, then you need to define the precedence of the operators. Unambiguity is the most important thing.
It might actually be desirable to use two different characters for "top-level alternatives" and "narrow alternatives", making the above example something like
L1, ((L2|L3)+EM), (EM+B) {font-size: big}
with the comma meaning completely independent top-level alternatives and the '|' meaning alternatives within a context. I could believe that this might make things clearer for less technical authors.
scott
-- scott preece motorola/mcg urbana design center 1101 e. university, urbana, il 61801 phone: 217-384-8589 fax: 217-384-8550 internet mail: preece@urbana.mcd.mot.com