[css3-values][css3-transforms] relative length in functional notation

The CSS3 V&U spec doesn't explicitly say whether relative units are
calc() are resolved in inheritance time, and this, unfortuately, has
already led to browser inconsistency. In the following test case,

data:text/html,<!DOCTYPE html>
<div style="background-color: blue; font-size: 2em;
            width: calc(1em); height: 1em;
             transform: translateX(1em);">
  <div style="background-color: red; font-size: 0.5em;
              width: inherit; height: 1em; transform: inherit">
  </div>
</div> (unprefixed)

, Firefox14a but not IE9 resolves relative unit *in calc()*. Firefox14a,
Operal12alpha and IE9 but not Chromium18 *don't* resolve relative unit
in translateX(), matching Areyh's observation[1].

(Given that Firefox does this inconsistently, I am interested in how
WebKit implements -webkit-calc(). Unfortunately, I don't have WebKit
nightly at hand.)

If we still want to keep the "as specified, but with relative lengths
converted into absolute lengths" convention, I think CSS3 V&U should say
that loudly, and we might want to ping IE people as soon as possible
becuase calc() is already unprefixed since IE9.


== A Somehow Irrelevant Nitpick on attr() ==

The spec now says

  # The computed value of the ‘attr()’ expression is the value of the
  # attribute with that name on the element, according to the rules
  # given below.

. This seems like a misuse of the term "computed value". For exmple, if
the value of an attribute is an "1em" fed to 'attr(foo length)', it
can't be a computed value because it is relative.

I suggest we just s/computed value/value/ here.

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=15797


Cheers,
Kenny

Received on Wednesday, 11 April 2012 14:04:46 UTC