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

> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com]
> 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

Just as a small note: since we all mostly refactor shorthands/longhands, reformat colors, and drop comments+whitespace already, I ("webdev / cssom user" me) am still under the impression that the "preserving what the author wrote" boat sailed a long time ago. That being said, I can understand the argument that choosing this serialization for the specified style reveals details about how css is handled now, which we may never or more difficulty change in the future if we want to. I don't see this as a strong blocker, but I acknowledge the point. I think this is Rossen's main concern, here.

Unrelated: Tab, you might want to take a look at this one, because Chrome is acting weird on that one:
https://jsfiddle.net/09dbr7m6/2/

Received on Monday, 4 April 2016 15:24:09 UTC