---Thanks for the clarification - I'd wondered about that, too.
--- | | How about this: view "font:a/b c d e" as a *macro* (rather than a | shorthand) for | | font-size: a | line-height: b | font-family: c | font-weight: d | font-style: e | | The cascading rules would then be applied *after* the `macro' has been | expanded. (The word `expanded' is just a way of explaining the | meaning, it doesn't say that an implementation should actually do | macro expansion.)---I would suggest that in the description of the font property you replace the existing sentence "Setting the properties individually override the shorthand notation if the weight is otherwise the same." with something like: "This notation is exactly equivalent to including separate lines setting the provided individual font-size, line-height, etc., properties at the same point in the stytlesheet. Properties left out of a font specification are not affected in any way."
I would also re-suggest that we change the syntax to require separators between the components of the font notation (preferably either '-' or ',') and require that all separators be present even if some component properties are omitted.
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