- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 19 Apr 2012 15:32:40 -0700
- 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 UTC