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

Re: [css3-values] CSSOM for calc()

From: L. David Baron <dbaron@dbaron.org>
Date: Mon, 1 Aug 2011 17:23:37 -0700
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: www-style list <www-style@w3.org>
Message-ID: <20110802002337.GA20683@pickering.dbaron.org>
On Monday 2011-08-01 17:06 -0700, Tab Atkins Jr. wrote:
> One of our engineers is working on calc() right now, and has some
> questions about how the OM for calc() values should work.
> 
> 1. Is it acceptable to collapse redundant subexpressions that can be
> unified at parsetime?  For example, if the passed value was "calc(1px
> + 1px + 1px)", is it okay to simplify it to "calc(3px)" or even just
> "3px"?  Is this okay at parse/computed/used value time?  What about
> units that aren't identical, but are still convertible at parsetime,
> like "calc(1in + 1px)"?

Gecko reduces numbers but not lengths at parse time.  Reducing
numbers is in fact required in order to check for (and reject)
division by zero (although the reduction doesn't need to be stored).

I tend to prefer that specified-value serializations do relatively
little normalization.

> 2. When exactly does calc() collapse to a normal value, in terms of
> what we expose to authors?  I presume that getComputedValue() returns
> a normalized value without any trace of calc(), since that generally
> returns used values.  Is this correct?

Not quite, since inside display:none subtrees getComputedStyle()
returns computed values rather than used, and in those cases calc()
can show up in properties where percentages depend on layout.

-David

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla Corporation               http://www.mozilla.com/   𝄂
Received on Tuesday, 2 August 2011 00:24:01 GMT

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