Re: IDs vs. Classes

Scott E. Preece writes:
 >  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.

Right.

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

Also right.

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

It's not very readable anymore, but I agree that some form of logical
connectors might be useful. Especially the &, since it is not
expressible in any other way. How about

    <P class="abstract,rationale">

    P.abstract.rationale

(for CSS *after* level 1, of course.) This is a simple and readable
notation for the &-case. For the or-case we might be able to find
something with a comma.

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

Actually, I think the comma is better, since it allows spaces in class
names. Cougar should explain that class names are separated by commas
and also `normalized', i.e., trailing whitespace is removed, all
sequences of whitespace are replaced by single spaces, and all letters
are case-insensitive.

Unfortunately, there are a number of these small incompatibilities
between the various specs that describe (part of) HTML. I don't know
exactly what to do about them. The royal way would be to issue new
RFCs, but it's a lot of work for things that are really only of minor
importance in those RFCs.

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

SGML doesn't allow multiple IDs on an element, so, unlike CLASS, there
is no need for logical connectors on IDs.


Bert
-- 
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/pub/WWW/People/Bos/                      INRIA/W3C
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 93 65 77 71                 06902 Sophia Antipolis Cedex, France

Received on Tuesday, 8 October 1996 12:31:07 UTC