- From: Paul Duffin <pduffin@volantis.com>
- Date: Wed, 19 Mar 2008 12:59:34 +0000
- To: fantasai <fantasai.lists@inkedblade.net>
- CC: paul.duffin@volantis.com, Andrei Polushin <polushin@gmail.com>, www-style@w3.org
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