Re: [css-values] Comments on Serialization of calc

On Thu, Mar 10, 2016 at 11:59 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Wed, Feb 17, 2016 at 7:02 PM, L. David Baron <dbaron@dbaron.org> wrote:
>> Perhaps what should be combined are *identical* units?  Then, for
>> computed values, many units will have been converted to identical
>> units, but for specified values, they won't be.
>
> This doesn't match any implementation.  Chrome combines terms
> aggressively, based on what units are capable of being merged at a
> given time.  Firefox doesn't combine at all - "calc(10px + 10px)" will
> return itself unchanged if you ask for specified value in current
> Firefox or IE.
>
> Chrome also resolves multiplication/division immediately, because it's
> always diving something by a constant value.  I'd not sure what your
> suggestion would tend towards.
>
> Finally there's add/sub/mult/div of *numbers*.  Firefox and Chrome do
> this eagerly - calc(1 + 2) will become calc(3) in specified style,
> calc(2/1) becomes calc(2).  IE keeps it as written.
>
> So our current behaviors for specified-style calc() are:
>
> IE: Always returns what was written.
> Firefox: Returns what was written, except that it resolves any
> subexpressions whose arguments are purely numbers.
> Chrome: Eagerly resolves every subexpression that it can, based on
> specified-value-time data.
>
> Your suggestion is: Return what was written, but resolve any
> subexpressions with identical units.  Right?  (If I state it this way,
> it implies that calc(10px / 2) will stay that way. Is that what you
> intend?)
>
> I'd personally prefer Chrome's behavior, as it matches the behavior
> you get at computed-value and used-value time.  (We can interpret your
> suggestion as also doing this, if we assume that comparable units are
> *only* turned into the "base" unit at computed-value time and above.)
> fantasai apparently prefers either IE's behavior or your suggested
> behavior, based on an IRC convo we're having right now.

At the telcon yesterday, we decided that we *probably* wanted to go with:

1. All expressions with at least one "number" argument are resolved.
(eg "1 + 2" => "3", "10px / 2" => "5px", "2 * (10px + 1em)" => "20px +
2em")
2. Terms with identical units are combined. (eg "10px + 15px" =>
"25px", but "10px + 1in" stays as written)

This guarantees the calc() expression can be stored as a sum of unit'd
values even at specified-value time, while still preserving
author-specified units as much as possible, per usual behavior in
specified values.  (That is, if you type "width: 1in;", we preserve
that in specified value, rather than converting it to the equivalent
"width: 96px;".)

The only dissenter was MS, who wished to review with their
implementors and return with an answer next week.

We'll make a final resolution next week and then I'll edit the spec accordingly.

~TJ

Received on Thursday, 24 March 2016 19:46:21 UTC