W3C home > Mailing lists > Public > www-style@w3.org > December 2010

Re: [css3-values] unitless zero lengths inside 'calc()'

From: Brad Kemper <brad.kemper@gmail.com>
Date: Wed, 29 Dec 2010 11:59:45 -0800
Message-Id: <B6FFC098-0F9E-425B-AF4C-AAF0C8AE2377@gmail.com>
Cc: "L. David Baron" <dbaron@dbaron.org>, "www-style@w3.org" <www-style@w3.org>
To: "Tab Atkins Jr." <jackalmage@gmail.com>


On Dec 29, 2010, at 10:48 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

> 2010/12/29 Brad Kemper <brad.kemper@gmail.com>:
>> What is the harm of having unitless zero allowed? The benefit is that authors would not need to remember a special exception to unitless zeros that can be applied everywhere else that lengths are accepted.
> 
> It's ambiguous.  What's calc(0), a number or a length?  

If I had my druthers, it would depend on the property, just like anything else that accepts unitless zeros. If it was 'width: calc(0)' then it would be a length. However, since the spec starts out with saying that it can be used only as a length, then that is how it would end up. 

> Is calc(0 +
> 2em) valid?  

Sure,  

> What about calc(0 + 3)?  

Again, if not for the first sentence of the calc spec, I would say "only if the property accepted '3' as a value; 'width: calc(0 + 3)' would be ignored, but 'z-index: calc(0 + 3)' should be fine." However, because of that sentence, I'd have to say that the result of '3' is not a length, so "no". 

> In calc(2em * 0 + 0), would 0 be
> a number both times, or a number the first time and a length the
> second?

Mathmatically, it should be the same as '2 * em * 0 + 0'.  I would allow it, and also 'calc(2em * 1 + 1)'. 

I guess what I want is for <length-term> to have " | <number>" added to it's definition, or at least " | 0". Then assign the value only if the end result is a length (if that is important, though I don't recall why it is). 

> calc() requires us to do some (very basic, in the current version)
> unit algebra, and the ambiguity makes this trickier (though not
> unsolvable).
> 
> ~TJ
Received on Wednesday, 29 December 2010 20:00:27 GMT

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