W3C home > Mailing lists > Public > www-style@w3.org > April 2016

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 4 Apr 2016 16:27:41 -0700
Message-ID: <CAAWBYDDBQVxe5xkC54ffG9DCjB8Ef-H_9MPW=J8KLgCcZjJRFw@mail.gmail.com>
To: Alan Stearns <stearns@adobe.com>
Cc: fantasai <fantasai.lists@inkedblade.net>, Rossen Atanassov <Rossen.Atanassov@microsoft.com>, Greg Whitworth <gwhit@microsoft.com>, "L. David Baron" <dbaron@dbaron.org>, Francois Remy <frremy@microsoft.com>, CSS WG <www-style@w3.org>
On Sun, Apr 3, 2016 at 10:33 AM, Alan Stearns <stearns@adobe.com> wrote:
> On 4/2/16, 8:55 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>>On Sat, Apr 2, 2016 at 9:22 AM, fantasai <fantasai.lists@inkedblade.net> wrote:
>>> I won't object to collapsing identical units in specified styles,
>>> but I'm not convinced that saves us a whole lot, especially given
>>> we plan to add multiplication and division by units and keywords
>>> into the calc expressions at some point in the future -- which are
>>> not things that can be simplified away so easily.
>>I already addressed this in my earlier message.
> Could you reiterate or expand on this for my benefit? I read through the thread again and have missed this part.

Me talking about the object-based OM, where a "list of unit'd values"
makes the OM sane and easy to work with, but an AST is not.

> My current understanding is that since the current simplification proposal is not the most aggressive one, there are current cases that will not be able to be expressed in the simple OM - something like calc(1em + 1ex + 10px). Is that correct?

No, that works just fine.  Can you elaborate on why you think that
would be problematic?  It sounds like there's a pretty fundamental
disconnect in what people are thinking about, which might explain the

> Are there other edge cases that will need a more complicated OM?

No, Level 3 calc() is 100% representable in the object-based OM,
assuming structural simplifications (that result in equivalent
expressions) are allowed.

> What’s the fallback plan for things that don’t fit into the simple calc type? (either now if I’m correct that there are edge cases or in the future when we allow more complex calc expressions)

Our current plan is to simplify things into three categories:

* a sum of unit'd values, as today
* a sum of values with complex units, to handle mult/division by unit'd values
* a sum of inverses of sums of complex units, to handle division by
sums of unit'd values

As far as I can tell, that's the best we can do; it keeps things as
simple as possible for the common case (everything you can do today),
and makes things as simple as possible for the next most-common case
(dividing a unit by a unit)

Alternately, if having two types of "complex" expressions is too much,
just hang an AST off the object to represent the latter two
categories.  More work for anyone trying to process things, but it's
at only *one* type of work. Unsure if the tradeoffs are better.

Received on Monday, 4 April 2016 23:28:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:02 UTC