W3C home > Mailing lists > Public > www-style@w3.org > April 2012

[css3-values] Three issues with calc()

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 19 Apr 2012 15:32:40 -0700
Message-ID: <CAAWBYDCw802+WcpxKTbN85TutY9naW-hGVWpLLYYSP0CBDyN6w@mail.gmail.com>
To: www-style list <www-style@w3.org>
While editing the V&U on Tuesday, fantasai and I encountered several
interesting issues with calc() (two of which were brought up by Kenny
Lu).  We would appreciate some WG discussion on them to help us come
to a conclusion.

Can you add numbers and dimensions?
================================

Right now, the spec explicitly prevents a number from being added to a
dimension.  In nearly all cases, this is a reasonable restriction,
because properties accept *either* numbers or dimensions, not both.

The one exception (that I know of) is line-height, which accepts a
number that represents a kind of "used-value-time em", so that it has
good inheritance behavior.  This number is basically a length, though,
so its potentially sensical to say "line-height: calc(1 + .5em);"

Are there more exceptions like this?  If not, should we alter the
restrictions on calc() to allow this sort of use, or should we keep
calc() simpler and just write this off as a lone oddity?

Note that if we *do* allow it, we need to define what to do with
properties other than line-height when they receive such a thing.
Currently it's a syntax error, so we can fall back to a more sensible
value.  If this was allowed in the grammar, though, we'd be past the
syntax error stage by the time we realized something was wrong, unless
we violated layering and only allowed it while processing
'line-height'.

Using attr() in calc()
================

Right now, the grammar for calc() explicitly requires NUMBER,
DIMENSION, or PERCENTAGE tokens.  It doesn't allow for other things
that might produce <number>, <percentage>, or dimension values, like
attr().

Can we remove this restriction?  Note that if we do, we can no longer
guarantee that divide-by-0 errors will be caught at parse-time, since
attr() doesn't resolve until computed-value time.  We'll have to
define what happens when we hit these errors.  (I recommend treating
it like an invalid variable, and resetting the property to its initial
value.)

calc() returning integers
===================

Currently, calc() is defined to only return <number> or a dimension.
We'd obviously like to allow calc() to be used on properties that only
accept <integer>.  This sort of check is easy to do (and we already do
this in WebKit, apparently).

Does anyone object to adding some logic that makes calc() explicitly
return an <integer> when appropriate?

(Unlike the other two, this one has no downsides besides
implementation complexity.)

~TJ
Received on Thursday, 19 April 2012 22:33:29 GMT

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