Re: Summary of calc serialization discussion

On Wed, Apr 6, 2016 at 9:53 AM Alan Stearns <stearns@adobe.com> wrote:

> On 4/5/16, 4:51 PM, "Shane Stephens" <shans@google.com> wrote:
>
> >
> >
> >On Wed, Apr 6, 2016 at 9:49 AM Alan Stearns <stearns@adobe.com> wrote:
> >
> >
> >On 4/5/16, 2:50 PM, "Alan Stearns" <stearns@adobe.com> wrote:
> >
> >>On 4/5/16, 2:40 PM, "Shane Stephens" <shans@google.com> wrote:
> >>>
> >>> On Wed, Apr 6, 2016 at 7:24 AM 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.
> >>>
> >>>
> >>> By "computed value simplifications" you mean expression
> simplifications?
> >>> Merging of values with like units, simplification of constants, etc?
> >>
> >>Yes – as far as I can tell, no one disagrees with having the proposed
> simplifications defined for the computed value. So we’d converge on a
> interoperable computed value that works for the Typed OM, and define that
> the Typed OM also uses those simplifications
> > for the specified value.
> >>
> >>It would also be good if we could solve C outside of the Typed OM, but I
> think it’s a separate question we can set aside (for now) in favor of
> agreeing on a solution for A.
> >
> >Hmm - reading the current PositionValue [1] section in Typed OM, I see
> that there’s a bit of A and B in the Typed OM already. For specified values
> there the cssText attribute contains the specified string - no
> serialization is invoked. I think that makes perfect
> > sense for all specified values. Could we extend that such that when you
> access cssText through CSSStyleRule.styleMap you always get the string from
> the stylesheet?
> >
> >
> >
> >
> >That section should probably say that you get the serialized string,
> though.
>
> Why? What’s the use case? If it’s the actual specified string then editors
> would have an API to replace the stylesheet parsing they have to do now.
>

I'm not sure I follow. At any rate, my comment wasn't use case driven as
much as I don't want to build a spec that requires implementors to start
holding onto strings that are currently discarded.

Cheers,
    -Shane


> Thanks,
>
> Alan
>