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

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.

>> > ----[2] I have no opinion on the clamping of values at step 2 of the algorithm you want to add. For me it looks fine to drop this step altogether and just serialize "calc(<value>)" whatever <value> is, but I understand some browsers might want to simplify it as soon as possible in order to save memory. This is such an edge case I doubt it is really worth it, though.
>>
>> Yeah, this step is based on browsers' current behavior. I'd prefer to
>> drop it if specifying fresh.
[snip]
> Perhaps what you were observing was part of the calc *computation*
> process rather than the calc *serialization* process?

Ah, yeah, I was only looking at computed value there.  I'm fine with
preserving calc() through specified value, and only discarding it at
computed-value time.  I'll fix this part.

~TJ

Received on Thursday, 10 March 2016 19:59:50 UTC