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

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

From: Rossen Atanassov <Rossen.Atanassov@microsoft.com>
Date: Fri, 1 Apr 2016 03:20:54 +0000
To: Tab Atkins Jr. <jackalmage@gmail.com>, Greg Whitworth <gwhit@microsoft.com>
CC: "L. David Baron" <dbaron@dbaron.org>, Francois Remy <frremy@microsoft.com>, CSS WG <www-style@w3.org>
Message-ID: <BLUPR03MB181EA58ACD07A2CD76F7C309B9A0@BLUPR03MB181.namprd03.prod.outlook.com>
On Wed, Mar 30, 2016 at 10:36:26, Tab Atkins Jr. wrote:
> 
> 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

"trigger" should've read "trivial" :)

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

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.

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

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

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

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

Sure, if as a group we agree that this is the best path forward ^_^
Received on Friday, 1 April 2016 03:21:27 UTC

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