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: Fri, 1 Apr 2016 12:47:38 -0700
Message-ID: <CAAWBYDBfvKRw4pGEdots1KXaujeL--Ck-5ESCZ2G2QPUnnMwMw@mail.gmail.com>
To: 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>
On Thu, Mar 31, 2016 at 8:20 PM, Rossen Atanassov
<Rossen.Atanassov@microsoft.com> wrote:
> On Wed, Mar 30, 2016 at 10:36:26, Tab Atkins Jr. wrote:
>> 1. I trust you that it's not trivial, but I suspect it's not *hard*, either. ^_^  At
>> the bare minimum, you *must* be doing enough parsing to (a) figure out
>> what the resolved type is, so you can validate grammar, and (b) resolve
>> puredss-numeric expressions to see if there's any division by zero.  If you've
>> done that, you have all of the information and data structures necessary to
>> serialize it in the requested way.
>
> It depends on what stage of the computation we're talking about.
>
> When serializing specified values we do quite a bit of work to preserve both user defined values and the order of the expression.  This makes debugging and simply recognizing your calc expressions possible.
>
> Often times calc expressions are based on some user logic - "I know that my left and right margins are 10% and my left padding is 5px etc. thus I need to use calc (10% + 5px + 10%)...". Serializing this back as calc(5px + 20%) loses the meaning.

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).

And, as I argued down below, the object-based OM wants to represent
values in a simple way, to help authors; preserving the math AST,
while matching the input intent, makes the values *much* harder to
manipulate in an API.

> For serializing computed values I'm not as concerned and actually prefer your current proposal.

Computed values are already well-defined and aren't in question at the moment.

>> 2. I don't understand. Really, I have *no clue* what part of this makes you
>> think interop will be troublesome.  The spec is quite explicit about how to
>> serialize, and this proposal is making it more so.  Can you give any example of
>> what you think isn't defined?
>>
>> On the call, you asked about the serialization of "calc(9px + 8em + 5px +
>> 3ex)".  This is why I"m confused - the spec+proposal in completely explicit in
>> how to serialize this.  (The current spec makes the computed/used values
>> completely defined, adding in the proposal makes specified value completely
>> defined.)  As a serialized value, this would be "calc(8em + 3ex + 14px)".  (The
>> unit ordering is defined by the spec as "number, then units in alpha order,
>> then percent". I think current impls just have an arbitrary impl-specific
>> ordering right now.)
>>
>> So is there anything else that still concerns you?
>
> Actually, I missed 8.1.5[2], thus the pushback. Given the required ordering, achieving interoperable solution will be possible, agreed.

This is confusing to me, since if unit order was your concern, that
applies to calc()'s serialization at *all* value stages.  It's
definitely not something that only matters for specified value, so how
was that the only stage that makes this concern you?

>> 3. Yes, it is.  Specifically, this helps us maintain a sane representation in the
>> object-based OM we're designing.  calc() as defined right now can always be
>> represented as a sum of unit'd values, which means we can use a simple
>> struct to represent it as an object.
>> This is very easy to use and manipulate for authors.  Having to preserve and
>> represent an arbitrarily-complex math AST solely for specified-value objects,
>> on the other hand, makes calc()s *way* harder to deal with. (And would
>> mean authors have to write two *totally different codepaths* to handle
>> specified-value calc() vs computed-value calc(), if they want to handle both .)
>
> Again, the concern I expressed applies to specified values.

The thing you are replying to is entirely about specified values.  I
mention computed values only in passing.

>> Can we please resolve on this now?
>
> Sure, if as a group we agree that this is the best path forward ^_^

You are the only person disagreeing with this.  The group agreed on it
last week but deferred the resolution, you objected to it this week
and blocked the resolution.  That's why I'm asking you if we can
resolve on this.

~TJ
Received on Friday, 1 April 2016 19:48:25 UTC

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