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

On Fri, Apr 01, 2016 at 12:47:38, Tab Atkins Jr. wrote:
> 
> 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).

So you're saying, let's not make things good for authors just because there's only one browser that currently does that? (which is not really the case because Firefox does very little simplification).

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

Even with typed, object-based OM why would the order of values and operands make it *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.

Great.

> >> 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?

Nobody expect to see an EM value type on a computed property and understands that by the time cascade runs such values are already computed as PX, % or AUTO, hence the name *computed*. Specified values are ones the authors *specify*, thus it is a good idea to show them what they specified in the matched rules of an element.

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

Yes and the distinction is important enough so others can understand why one makes a lot more sense than the other.

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

I see at least fantasai sharing this concern.

Cheers,
Rossen

Received on Tuesday, 5 April 2016 01:09:01 UTC