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

On Wed, Apr 6, 2016 at 4:44 AM Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Mon, Apr 4, 2016 at 6:27 PM, Alan Stearns <stearns@adobe.com> wrote:
> > On 4/4/16, 4:27 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
> >>On Sun, Apr 3, 2016 at 10:33 AM, Alan Stearns <stearns@adobe.com> wrote:
> >>> Are there other edge cases that will need a more complicated OM?
> >>
> >>No, Level 3 calc() is 100% representable in the object-based OM,
> >>assuming structural simplifications (that result in equivalent
> >>expressions) are allowed.
> >
> > So in the current Typed OM proposal there’s *one* px value, which is why
> you’d need to combine (10px + 10px). Without that simplification, you’d
> need to be able to handle arbitrary numbers of px-unit values.
> >
> > But if those two 10px values are actually separate things the author has
> specified, wouldn’t it be better for the Typed OM to retain them as
> separate entities in the specified style? Say I had a number of calc values
> in a pattern like:
> >
> > calc(10px + 300px + 10px)
> > calc(10px + 10% + 10px)
> > calc(10px + 50% + 10px)
> >
> > And I decided that the first 10px component needed to be replaced by
> 1em. I’d prefer an API that let me remove a 10px value and add a 1em value,
> instead of subtracting 10 from the combined px component and adding 1 to
> the combined em component.
>
> You're talking about modifying stylesheets at an editor level.  That's
> more or less out-of-scope.  I don't think there's a similar concern
> for normal scripts altering values.  And as I said in an earlier
> email, for this case to be valid at all, it requires the script in
> question to be the only thing setting values, and depending on the
> specified style to function as a proxy for whatever data-structure
> their code is assuming.
>

Right - the Typed OM is for regularized access to style information. It's
more valuable to be able to treat lengths as a dictionary of units than it
is to exactly preserve the author's string input. For example, the Web
Animations polyfill (github.com/web-animations/web-animations-next) parses
lengths into precisely this sort of structure because it needs to work off
something regular to correctly perform interpolation.

Having said that, I'm not sure that there's a strict requirement that
string serialization matches typed OM behavior - it's just nicer if
everything produces 'the same' sorts of strings at some level (and it means
implementations don't have to carry around extra information solely for the
legacy string serialization).

Cheers,
    -Shane