Re: Summary of calc serialization discussion

On Tue, Apr 5, 2016 at 2:19 PM, Alan Stearns <stearns@adobe.com> wrote:
> Hey all,
>
> Here’s my stripped-down analysis of what’s been discussed so far:
>
> A. There is a benefit (for authors and developers) to simplifying the specified value of calc for the Typed OM.
>
> B. There is a benefit (for debuggers and editors) for retaining the actual string in the specified value.
>
> C. Browsers currently do not agree on what to do with specified calc() values. There is a benefit to interoperability, but there has been no evidence presented that authors care about the current differences.
>
> Here are some options I see.
>
> 1. Solving for A and C, we define serialization rules as proposed two weeks ago, and ask browsers to converge in how their tools represent specified values. This makes things worse for B
>
> 2. Solving for B and C, we stick to specified values as the specified strings, and ask browsers to converge on that. This makes things worse for A.
>
> 3. Solving for A alone, we could define that the Typed OM uses computed value simplifications for its representation of specified calc() values, and leave things as they are with C for now.
>
> Given the conversation so far, it seems to me that there would be objections to either 1 or 2. Is 3 an acceptable compromise?

1 makes things no worse *in practice* for B, only worse when compared
to a theoretical world where the serialization is precisely
maintained.  (Note that a few weeks ago we permanently separated from
that world anyway by resolving that nested calc() serializes as
parens.)

2 does make things worse in practice for A.

3 helps nobody.  Firefox *nearly* implements the proposal and is
willing to correct to it, Chrome can do the same.  WebKit's impl is
similar to Chrome's, and shouldn't be hard to switch over either (even
if they don't, their behavior today is the *polar opposite* of IE's).
That's most browsers converging.

~TJ

Received on Tuesday, 5 April 2016 21:35:28 UTC