W3C home > Mailing lists > Public > www-style@w3.org > June 2015

Re: [css-values] calc() serilization

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 22 Jun 2015 14:17:09 -0700
Message-ID: <CAAWBYDC7GpQbsb4heJc4=GfUsrGz2f8zJxL9xMqwtEBY=03_CQ@mail.gmail.com>
To: Fran├žois REMY <francois.remy.dev@outlook.com>
Cc: Bem Jones-Bey <bjonesbe@adobe.com>, www-style list <www-style@w3.org>
On Mon, Jun 22, 2015 at 1:52 PM, Fran├žois REMY
<francois.remy.dev@outlook.com> wrote:
> Tab Atkins Jr. said:
>> 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?)

There is no such ordering; I agree that there should be.  For lack of
anything better, and since the ordering has no behavioral
significance, I suggest case-insensitive alphabetical order by unit,
with % last.

~TJ
Received on Monday, 22 June 2015 21:17:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:55 UTC