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

On Mon, Mar 28, 2016 at 5:57 PM, Greg Whitworth <gwhit@microsoft.com> wrote:
>>The only dissenter was MS, who wished to review with their implementors
>>and return with an answer next week.
>
> This feels a little strongly worded IMO ;)
>
> I checked with the dev in question and while it won't be as trivial as you made it out to be we're ok with the change in principal.

Apparently you're not, since Rossen just relitigated it on the call. :(((((

Just to reiterate, in case people don't want to look a few messages
upward, the proposal is that, at specified-value time, we:

1. Resolve all numeric expressions, leaving us with a sum of unit'd values.
2. Combine all identical units.

> Rossen_: And I did. I'm the impl in charge of this and I have 3 pushbacks. 1 this won't be a trigger for us to impl 2) interop will be flacky at best and 3) this isn't helping authors. It's going to be hard for tools

Let's run thru these.

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.

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?

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

(We will, eventually, have to deal with unit algebra, and thus have
units of arbitrary complexity that can no longer be represented as a
field in a struct. Shane and I have plans to deal with that, but we'll
cross that bridge when we come to it, and even in that world, the
*vast majority* of calc()s will be "simple" and still
struct-friendly.)

If you're talking solely about *string parsing* of calc()s, (a) we, as
a group, aren't encouraging that, and are creating an API specifically
to make that no longer necessary, and (b) this proposal *simplifies*
string parsing by ensuring all calc()s are a simple sum of unit'd
values.

The only possible code that can be hurt by this change:

* writes out calc()s and then re-parses its own values
* using some extremely naive "parsing" code that requires the
structure be *precisely* the same
* only dealing with specified values ever (because computed/used
simplify in *all* browsers)
* and is IE-only (because everyone else simplifies specified values to
some degree)

So, between both the object-based OM and the string-based, this
proposal simplifies generic handling and is useful for authors.


Nothing I've said here is new; I discussed all of it last week, and it
should be in the minutes.  Again, we all tentatively agreed that the
proposal is good, we were just waiting for MS folk to make sure there
wasn't some "gotcha" that would make it hard for them.  We got that on
Monday, I was just waiting for the official resolution today before
making the edits.

Can we please resolve on this now?

~TJ

Received on Wednesday, 30 March 2016 17:37:13 UTC