Re: Summary of calc serialization discussion

On Wed, Apr 6, 2016 at 9:59 AM Shane Stephens <shans@google.com> wrote:

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

I've been thinking about it more, and having the specified string here
definitely doesn't give editors an API to replace stylesheet parsing of
values. So I think I must misunderstand what you're after?

The reason why is that:
.foo {
  width: 42px;
  width: gobbledygook;
}

*must* throw away the gobbledygook, because the behavior is defined as
falling back on the valid value.

And you can't know (easily) during parse whether there's a fallback in
place or not, so you can't speculatively keep around values that aren't
valid either.

In other words, the only values that one could pass to an editor are those
that parse already as valid - in which case the editor is better off using
the typed representation (I think).

What I'm wondering is whether what you want is an API to replace stylesheet
parsing of *rules*, so you can extract value strings directly. I think that
you could probably use the specified string approach for that but there's a
thorny caveat in that you'd only be able to see the last *valid* value for
each property in each rule, rather than everything that's there. So I think
even here we're better to wait for a proper parser API.

Or am I just totally wrong?

Cheers,
    -Shane


>
> Cheers,
>     -Shane
>
>
>> Thanks,
>>
>> Alan
>>
>