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

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.

Again, such code doesn't appear to exist.  I cannot find a single
StackOverflow question about this, nor a single Chromium bug, despite
Chrome/WebKit doing an *even stronger* form of simplification for
nearly three years.  If this was actually a problem for a
non-negligible number of authors, we'd have *some* evidence of people
complaining about it, but there doesn't appear to be any.

> If I had some additional values like calc(10px + 50px) and wanted to replace all of the 10px components with 1em, I’d be out of luck with the current Typed OM - I wouldn’t know which calcs had one 10px value and which had two.
>
> Would it really be that hard to represent and work with multiple values of the same unit?

Yes, you need an *entirely different* structure.  As I just said in my
response to Rossen, to preserve ordering/multiplicity, you instead
need a list of {value, unit} objects.  To preserve numeric factors as
well (which is *definitely required* according to the argument you're
making) we actually need a *tree structure* of {value, unit} objects.
Walking a tree in order to determine anything about the structure of
your calc seems greatly overcomplicated for the (apparently vast
majority of) authors that don't care about the structure and just want
to tweak some values.

~TJ

Received on Tuesday, 5 April 2016 18:40:00 UTC