The [] encapsulation makes it a little easier to parse; the quotes, in that
example, are unnecessary.
>It would really be simpler if CSS decided what operators were needed and
thus
>defined what tokens it would need, rather than typing in some possible
>notation and then deciding what the bits might mean...
As the CSS1 spec says, this is borrowed from CSS2 in order to facilitate
easy migration to CSS2's addressing system.
>In the third example, . means "a class called" but this does not seem
>to scale well, particularly when CSS is later used for other DTDs which
>might not have a class attribute (or might have one that means something
>else)
Ah, but the class attribute specification is obviously not meant to scale.
As I say at the end of this message, perhaps we should torch the syntax in
favor of [CLASS=foo] addressing.
>Given that, it becomes clear that the third example is correct, or
>at least, most consistent with existing usage.
Granted. Read on...
>So, for generality and a clear upgrade path to CSS 2 how about some
>token to say, here is an attribute, and another token to say, here is
>it's value. Let's use @ and = for these, though the representation
>could be some other token. I just thought @ (at) was memorable for
>"attribute" and = seemed obvious for "has the value"
? I thought there was already a "proposal" for generalized attribute
selection - the [attribute=value], or just [attrib] for existence, format.
That was, I believe, the point of making "[ID=value]" so complex in
comparison (I don't know why we didn't just do "[CLASS=foo]" from the
beginning - perhaps we should?
-Chris