W3C home > Mailing lists > Public > www-style@w3.org > October 1996

Re: IDs vs. Classes

From: Scott E. Preece <preece@predator.urbana.mcd.mot.com>
Date: Tue, 8 Oct 1996 08:36:25 -0500
Message-Id: <199610081336.IAA28781@predator.urbana.mcd.mot.com>
To: howcome@w3.org
CC: www-style@w3.org
 From: Hakon Lie <howcome@w3.org>
| 
|  > Also, the spec explicitly states that a simple selector can have only
|  > 1 class (in section 1.4), but I could find no such limit on the number of
|  > IDs per simple selector.
|  > 
|  > Is that a purposeful omission (and simple selectors can have multiple
|  > IDs) or does the same limit apply to IDs (only 1 per simple selector)?
| 
| The specific limitation for class values is there since the Cougar DTD
| [1] suggests that the CLASS attribute value is a comma-separeated list
| of values. CSS1 does not support this, and that's why we needed a
| specific limitation. We're still debating if having more than one
| class value makes sense. Feedback welcome.
---

I have two concerns here:

1) I assume the statement "CSS1 does not support this."  means that CSS1
has no syntax for attaching multiple CLASSes to a selector, not that it
fails to work on HTML elements that have multiple classes specified.
I assume the class part of the simple selector matches whenever *any* of
the classes attached to an element matches the class in the selector.
For example, if there is a rule with the simple selector
	.rationale:	{font-style: italic}
that a paragraph tagged
	<P CLASS=abstract,rationale>
would match that selector.

If CSS1 *did* support multiple class components in a simple selector,
there would be two possible interpretations: that the classes were ANDed
or that the classes were ORed.  That is, a selector containing two
classes could match only when *both* were present or whenever *either*
was present.  Even though, as Bert Bos pointed out in a separate note,
you can get the equivalent of ORed classes by just repeating the rest of
the selector, it would still be a notational convenience to support the
shorthand form.  I would suggest supporting
	.class&class...		to indicate ANDed classes and
	.class|class...		to indicate ORed classes
Having gone that far, you might as well support complete logical
expression syntax, allowing
	.(rational&abstract)|(interface&description&~exception)

2) My more serious concern is that Cougar has mis-specified the CLASS
attribute.  It says it's a comma-separated list of classes, but both the
standards (i18n and tables) that include CLASS say it's a
space-separated list of classes.  This needs to be fixed in Cougar
before people go off and implement it.

---
| 
| For ID, noone have suggested it being more that an single value --
| indeed, such a suggestion would defeat the purpose of ID. A
| selector with more than one ID value would never select anything.
---

Again, there are two possible meanings of having multiple values.  It
would make prefectly good sense to OR together IDs, but, as you note,
not to AND them.

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
Received on Tuesday, 8 October 1996 09:36:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:53:45 GMT