W3C home > Mailing lists > Public > www-style@w3.org > October 2011

Re: [css3-values] Lengths and calc()

From: fantasai <fantasai.lists@inkedblade.net>
Date: Mon, 10 Oct 2011 17:28:35 -0700
Message-ID: <4E938DB3.5060706@inkedblade.net>
To: Christoph Päper <christoph.paeper@crissov.de>
CC: www-style Mailing List <www-style@w3.org>
On 03/12/2008 05:02 AM, Christoph Päper wrote:
>
> In CSS3 Values and Units sections 3.4.1. and 3.7.4. should be harmonised, i.e. the
> former should use <atomic-length> instead of <length> or explicitely refer to the
> overwrite by 'calc()'.

I don't see a particular reason to split <atomic-length> from <length>.
You might want to take a look at the latest draft, though; it's changed
a lot from the time you made these comments. :)

http://dev.w3.org/csswg/css3-values/

> 3.7.4. The 'calc' function
>
> Is the limitation of 'calc()' to lengths (i.e. no percentages, angles, times, frequencies and probably others) intentional?

Yes.

> I wonder if CSS could include railroad or syntax diagrams for those BNF parts, like JSON.org does.

We've hooked the definitions into the CSS2.1 grammar now. Let me know
if we missed anything.

> PS: How expensive is the addition of more ((absolute) length) units? I know the benefit is severely limited by lack of
> backwards compatibility, but for some (future) applications accuracy might be more important (e.g. for Didot points).

My understanding is, depends on how hard that value is to compute. In
the case of more values pegged to an existing value, probably pretty
easy. But we'd need a good reason to add more features.

~fantasai
Received on Tuesday, 11 October 2011 00:29:11 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:45 GMT