RE: [your feeback needed] :nth-child() argument

There is nothing strange at the tokenizer level about a version of the spec that allows space anywhere. There are obvious places where space would not be allowed, like between digits, since that would create multiple tokens that don't make sense (number number dimension, or number number ident, as examples).

Let's take David's invalid samples:

3 n = (number ident), I can easily process that by normalizing it to (n-dimension)
+ 2n = (plus dimension), again, can easily be folded
+ 2 = (plus number)...

I'm not really seeing the problem of allowing spaces. All values still fall into "term" in CSS 2.1 and only the semantics of how to fold down is in question. There is a canonical form which would be shown by not having any spaces and the expanded form with spaces which would create dramatically different token streams but could still be folded down into the canonical form.

I see the concern around impacting general calculation at some later date. Do we plan on allowing that calculation to occur in nth-child? If not then I'd be in favor of allowing space. The reasoning is that treating space as significant is sometimes now easy. Space currently is only significant when it is required for separating two tokens, "hello world" == (ident ident)... Otherwise we ignore it (technically speaking we request the NextNonSpaceToken from the tokenizer). There are very few places where it IS important so I'm against adding more places where I have to fall back to the more general NextToken and am forced to treat space as significant.

That said, internal discussion points to the only strange thing being 3{space}n versus 3n. We discussed how this would impact a generalized math module and we can't think see how there would be any difference unless we supplied that there was a different calculation semantic due to the space. We could not have the space restriction at all, but state that (number ident) is not a valid token sequence if people are passionate about disallowing 3{space}n. I'm not passionate enough to write the grammar to restrict it though and would rather just leave it open.

Justin Rogers [MSFT]

-----Original Message-----
From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of Jens Meiert
Sent: Tuesday, March 11, 2008 12:05 PM
To: daniel.glazman@disruptive-innovations.com
Cc: www-style@w3.org
Subject: Re: [your feeback needed] :nth-child() argument


> We then propose to restrict whitespaces in the nth-child()'s argument
> to ONLY after the '(' and before the ')'. Since this is not the common
> practice in CSS - whitespace is usually allowed everywhere - we would
> like the web designers community to let us know if they think it's an
> acceptable compromise or if you think for instance that web authors
> will make a lot of mistakes putting invalid whitespaces inside the
> expression.

This looks like an acceptable solution since a) it does not affect all “:nth-child()” use cases (like “tr:nth-child(odd)”) and b) will be less of a problem anyway assuming that less experienced web developers will be less likely to use this pseudo-class at all.

(Hapless inconsistency though.)

--
Jens Meiert
http://meiert.com/en/

Received on Tuesday, 11 March 2008 23:25:36 UTC