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

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

From: fantasai <fantasai.lists@inkedblade.net>
Date: Sat, 2 Apr 2016 12:22:44 -0400
To: "Tab Atkins Jr." <jackalmage@gmail.com>, Rossen Atanassov <Rossen.Atanassov@microsoft.com>
Cc: Greg Whitworth <gwhit@microsoft.com>, "L. David Baron" <dbaron@dbaron.org>, Francois Remy <frremy@microsoft.com>, CSS WG <www-style@w3.org>
Message-ID: <56FFF1D4.7060808@inkedblade.net>
On 04/01/2016 03:47 PM, Tab Atkins Jr. wrote:
> While this may have some theoretical value, there are no authors in
> the wild today depending on this, as IE is the only browser that
> preserves things exactly.  All other browsers simplify at least
> somewhat, so authors already have to deal with the fact that their
> input and output might not be identical (or else they're writing
> really broken code).

This is a very misleading statement. Mozilla only simplifies numerical
factors, so in fact IE and Mozilla's behaviors are very close and
preserve almost everything.

Also, Rossen's concern (which I share) is not just about what authors
are depending on right now (given lack of interop between Blink/Webkit
and IE/FF, it's probably not much), but what would be useful for them
to have going into the future.

And I agree that for computed style we should collapse as much as
possible. (In fact, the Computed Value line is generally represented
as a tuple of percentage and length, which then serializes out as
calc() if it's got non-zero values in both.)

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.

In any case, as I noted in the minutes of the telecon you're
referencing, I would prefer we got author feedback on this issue.

Received on Saturday, 2 April 2016 16:23:13 UTC

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