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

Paul Duffin wrote:
> 
> 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.

Consistency with XPath 2.0 is so low on CSS's list of design principles
that it pretty much doesn't register. Ease of authoring and consistency
within CSS itself are both far more important.

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

This is totally inconsistent with existing CSS syntax. Requiring whitespace
between tokens is less of a burden than defining a new syntax for lengths.

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

CSS syntax is usually defined in both prose and grammar productions.
The ambiguities usually arise from the grammar not being precise
enough to reflect constraints from the prose.

~fantasai

Received on Wednesday, 19 March 2008 16:14:56 UTC