RE: [css-values] calc() serilization

> De : Tab Atkins Jr. [mailto:jackalmage@gmail.com]
> 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.

(maybe we should also add to "1" an ordering for the units so that every browser serializes to "calc(Ax + By)" and not some to that and some to "calc(By + Ax)"; is any such order already defined in css?)

Received on Monday, 22 June 2015 20:52:33 UTC