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:
>> On Wednesday 2016-02-17 15:48 -0800, Tab Atkins Jr. wrote:
>>> On Wed, Feb 17, 2016 at 11:39 AM, Francois Remy <frremy@microsoft.com> wrote:
>>> > Hi Tab, Fantasai,
>>> >
>>> > Here are a few comments regarding the "calc" serialization section I just reviewed:
>>> > https://drafts.csswg.org/css-values-3/#calc-serialize
>>> >
>>> >
>>> > ----[0] Thanks for looking into this, you rock, as always!
>>> >
>>> >
>>> > ----[1] I am not confident with the "compatible units" notion, mostly because it isn't defined anywhere (except by example). It is not clear, for instance, what calc(100vw - 20px) resolves to at specified time. Technically, the viewport width does not depend on the element this value is applied on, but at the same time it may vary which would somehow require to keep the values separate to provide the right result over time. It is also not clear to me what happens if we have calc(1cm + 1mm) vs calc(1mm + 1cm). The units are compatible, but which one should we keep? Does order matter?
>>>
>>> It probably does need to be expanded on, but it's the same concept of
>>> "absolutization" that transforms em into px at computed-value time.
>>
>> But it seems wrong to apply a computed-value type of process to a
>> specified value.
>
> I'm not really sure what you mean by "computed-value type of process".
> Some units are combinable at specified-value time.  1in is always
> exactly equal to 96px, so "1in + 10px" can be losslessly converted to
> "106px" right away if you wanted.
>
>> 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.

Reminder that this is topic #1 at the call tomorrow, so if you haven't
reviewed it and formed your opinion/arguments, we're gonna default to
the standard CSSWG strategy: Tab does whatever he thinks best.

~TJ

Received on Wednesday, 23 March 2016 00:40:43 UTC