Re: [css-values] calc() serilization

On Wed, Nov 5, 2014 at 10:01 AM, Bem Jones-Bey <bjonesbe@adobe.com> wrote:
> In working on some tests for the CSS Shapes test suite, I discovered that Blink and WebKIt disagree about the serialization of some calc() expressions. For example:
>
> Expression: calc(10/100)
> WebKit: calc(0.1)
> Blink: 0.1
>
> Expression: calc(10/100 + 30/100)
> WebKit: calc(0.4)
> Blink: 0.4
>
> I've noticed that the CSS Values and Units doesn't mention anything about serialization for calc(), so I'd guess that there are probably other divergences.

Yay accidentally dropping emails on the floor!  (Thanks for reviving
it, fantasai!)

Agree that we should define serialization here.

1. calc() should serialize as a sum of unique uncombinable non-zero
united values (where "uncombinable" is defined by whatever stage of
computation the value is from: as a specified value you can only
combine absolute units, numbers, etc; as a computed value you can
combine em+px, etc.).  Multiplication and division never show up in
the serialized value; they exist solely to make some numbers easier to
express.

2. I'm torn on whether a fully combined value should serialize as a
calc() or as the value itself.  There's no meaningful difference
between the two; they do exactly the same thing (modulo bugs).  In an
object-based CSSOM, I'd have calcs stay as calcs no matter what you do
to them, for API predictability.  That isn't as necessary for
serialization purposes, so I'm not sure which I prefer.  Requiring it
to stay as calc() means disallowing browser optimizations where they
shift down to a plain value (rather than a calc() struct) when
possible.

~TJ

Received on Monday, 22 June 2015 20:02:31 UTC