Re: [css3-values] calc(), whitespace, and DIMENSION tokens

This CSS expression stuff has a lot of similarities with XPath 2.0:
* Is used to select / match / process hierarchical DOM
* Allows - within identifiers, and so authors need to use spaces around 
unary and binary - operators.
* Has typed values, I think that each unit defines a different type, 
with types possibly grouped into lengths, angles, frequency, etc.
* Provides conversions and operations between different types, e.g. 
adding lengths in two different units.

I think for consistencies sake that where possible it should use similar 
syntax and behavior as XPath 2.0.

fantasai wrote:
> Paul Duffin wrote:
>> A cleaner alternative is to simply disallow dimensions altogether 
>> within general function syntax and instead provide a special function 
>> notation for specifying the units, which could also be used in 
>> properties as well. That would be slightly more verbose but I believe 
>> would be cleaner.
>>
>> e.g.
>> dim(3cm)-dim(2cm)
>> calc(dim(3em)-max(dim(1em),dim(9px)))
>>
>> That would require a special production for the dim(<DIMENSION>) 
>> function but there is already precedent for that, e.g. not(<selector>).
> 
> Yuk. CSS is hand-authored: nobody wants to write /that/.
> 

In that case how about doing something XPath like and providing length 
constructor functions.
e.g.
cm(3) - cm(2)
calc(em(3) - max(em(1), px(9)))

Not too much more complex than allowing dimensions but makes it much 
easier to specify, implement, and author. IMNSHO having to type a couple 
of extra characters is less onerous than having to remember lots of 
different rules about where white space is necessary and where it is not.

I am concerned that unless the syntax is clearly defined in a recognized 
format, e.g. BNF, then there will be all sorts of ambiguities that will 
be resolved by each implementation in different ways.

>> If a more general yet easier to understand expression based selector 
>> is required then I would suggest something more conventional along the 
>> lines of:
>> :if(p % 2 == 0) instead of :nth-child(2n)
>> :if(p % 2 == 1) instead of :nth-child(2n+1)
>> :if(p <= 4) instead of :nth-child(-n+4)
>> :if(p > 4) instead of :nth-child(n-4)
>> :if(p > 2 && p < 4) instead of :nth-child(n-2):nth-child(-n+3)
>> :if(p == 9) instead of :nth-child(9)
>> :if(p != 9) instead of :not(:nth-child(9))
>>
>> :if() would require more operators than :nth-child() but I think is 
>> more understandable, more flexible and easier to implement.
> 
> Adding :nth-child(n < 5) to Selectors Level 4 I can see, but

In your example you imply that the value of n is the position of the 
element but at least in the current specification of :nth-child it does 
not mean that, it is just a number that solves the equation an+b=p, 
which is why I used p.

> I don't think :if(p % 2 == 0) is easier to understand than
> :nth-child(2n).
> 

It may not be and I am not proposing that you remove nth-child() just 
trying to point out that  somethings are much more easily expressed 
using normal mathematical expressions. If you wanted to you could easily 
add some helper functions, just like you have added helper keywords.

:if(odd(p))
:if(even(p))
:if(nth(4,1)) == :nth-child(4n+1)

Received on Wednesday, 19 March 2008 13:00:37 UTC