"computationally idempotent" is a bad term

[dbaron]

The definition of registerProperty() partially defines the term "computationally idempotent".

This term doesn't make sense because computation of all values of all CSS properties is idempotent. Idempotence means that f(x) equals f(f(x)). In this case we're talking about f() being the function compute() that produces a computed value from a specified value. Pretending for a moment that both the input and output of this function is strings (rather than a data type that we can convert to strings): compute("1em") might well be "16px", but compute("16px") sure better be "16px". Likewise, compute("inherit") may well be "rgb(0, 0, 255)" (depending on the property and the inherited value, of course), but compute("rgb(0, 0, 255)") sure better be "rgb(0, 0, 255)". (Gecko has tests to test this for a very large set of properties and values that we add to whenever we add support for new CSS values.)

[shans]

It is a terrible term but we couldn't think of anything better. Got any ideas?

[dbaron]

computationally independent? (i.e., it's independent of the inherited values and values of other properties)

[shans]

I think we want that x = f(x). In other words you can use "16px" because compute("16px") == "16px" but you can't use "1em" because compute("1em") != "1em". Basically we want the fixed points of the compute function.

I'm not sure that independent captures that completely, but it's better than idempotent.

[dbaron]

That's a little too strict, since "12pt" is ok, because compute("12pt") is always "16px".

(I came up with independent because in Gecko we have a concept of recording dependencies.)

[shans]

I think you can still count that as a fixed point with an appropriate form of equality. However, I think Chrome's initial values mechanism actually stores the values as computed, so we can't represent 12pt directly anyway.

[tabatkins]

"independent" works for me - the clarified definition I'm using is much closer to that.