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

On Mon, Apr 4, 2016 at 6:08 PM, Rossen Atanassov
<Rossen.Atanassov@microsoft.com> wrote:
> On Fri, Apr 01, 2016 at 12:47:38, Tab Atkins Jr. wrote:
>> On Thu, Mar 31, 2016 at 8:20 PM, Rossen Atanassov
>> <Rossen.Atanassov@microsoft.com> wrote:
>> > On Wed, Mar 30, 2016 at 10:36:26, Tab Atkins Jr. wrote:
>> >> 1. I trust you that it's not trivial, but I suspect it's not *hard*,
>> >> either. ^_^  At the bare minimum, you *must* be doing enough parsing
>> >> to (a) figure out what the resolved type is, so you can validate
>> >> grammar, and (b) resolve puredss-numeric expressions to see if
>> >> there's any division by zero.  If you've done that, you have all of
>> >> the information and data structures necessary to serialize it in the
>> requested way.
>> >
>> > It depends on what stage of the computation we're talking about.
>> >
>> > When serializing specified values we do quite a bit of work to preserve
>> both user defined values and the order of the expression.  This makes
>> debugging and simply recognizing your calc expressions possible.
>> >
>> > Often times calc expressions are based on some user logic - "I know that
>> my left and right margins are 10% and my left padding is 5px etc. thus I need
>> to use calc (10% + 5px + 10%)...". Serializing this back as calc(5px + 20%) loses
>> the meaning.
>>
>> While this may have some theoretical value, there are no authors in the wild
>> today depending on this, as IE is the only browser that preserves things
>> exactly.  All other browsers simplify at least somewhat, so authors already
>> have to deal with the fact that their input and output might not be identical
>> (or else they're writing really broken code).
>
> So you're saying, let's not make things good for authors just because there's only one browser that currently does that? (which is not really the case because Firefox does very little simplification).

This is a dishonest gloss, and I don't appreciate it.

I did a quick survey of Stack Overflow, and there appear to be *zero*
questions about this, despite the fact that Chrome/WebKit do
relatively substantial simplification (and have been doing so for
nearly three years
<https://bugs.chromium.org/p/chromium/issues/detail?id=243610>).  I
can't find a single bug in the Chromium bug tracker about this,
either.  So to a first approximation, it appears that authors don't
care about this.

I already described the set of circumstances that have to be met in
order for the ordering to matter; they're extremely hard to meet.
Absent that one super-corner-case (which is *extremely fragile* anyway
and shouldn't be encouraged), whether to simplify/reorder or not
appears to be solely an aesthetic/theoretical-purity preference.
Since authors don't seem to care, this narrows even further, to solely
an aesthetic/theoretical-purity preference *from implementors*.  Per
the priority of constituencies, that sort of preference is *very easy*
to override with even a small benefit to authors, and the better
behavior of the object-based OM is precisely such a benefit.

>> And, as I argued down below, the object-based OM wants to represent
>> values in a simple way, to help authors; preserving the math AST, while
>> matching the input intent, makes the values *much* harder to manipulate in
>> an API.
>
> Even with typed, object-based OM why would the order of values and operands make it *much* harder to manipulate in an API?

I explained why - the object-based OM is shaped like
<https://drafts.css-houdini.org/css-typed-om/#calclength>, which does
not preserve ordering, multiplicity of identical units, or numeric
factors.  This shape is *really easy* to work with, however - you can
trivially read, write, and manipulate it in script.  It's easier than
a list of {value, unit} pairs (which preserve ordering/multiplicity),
and *much* easier than a *tree structure* of {value, unit} pairs
(which preserve numeric factors as well).

>> >> 2. I don't understand. Really, I have *no clue* what part of this
>> >> makes you think interop will be troublesome.  The spec is quite
>> >> explicit about how to serialize, and this proposal is making it more
>> >> so.  Can you give any example of what you think isn't defined?
>> >>
>> >> On the call, you asked about the serialization of "calc(9px + 8em +
>> >> 5px + 3ex)".  This is why I"m confused - the spec+proposal in
>> >> completely explicit in how to serialize this.  (The current spec
>> >> makes the computed/used values completely defined, adding in the
>> >> proposal makes specified value completely
>> >> defined.)  As a serialized value, this would be "calc(8em + 3ex +
>> >> 14px)".  (The unit ordering is defined by the spec as "number, then
>> >> units in alpha order, then percent". I think current impls just have
>> >> an arbitrary impl-specific ordering right now.)
>> >>
>> >> So is there anything else that still concerns you?
>> >
>> > Actually, I missed 8.1.5[2], thus the pushback. Given the required ordering,
>> achieving interoperable solution will be possible, agreed.
>>
>> This is confusing to me, since if unit order was your concern, that applies to
>> calc()'s serialization at *all* value stages.  It's definitely not something that
>> only matters for specified value, so how was that the only stage that makes
>> this concern you?
>
> Nobody expect to see an EM value type on a computed property and understands that by the time cascade runs such values are already computed as PX, % or AUTO, hence the name *computed*. Specified values are ones the authors *specify*, thus it is a good idea to show them what they specified in the matched rules of an element.

This appears to be a non-sequitur?  I was wondering why your concern
was about interoperability of specified-value unit ordering, given
that the other value stages *also* have unit-ordering concerns.  It
doesn't really matter, as you appear to be happy about this, I was
just confused.

>> >> 3. Yes, it is.  Specifically, this helps us maintain a sane
>> >> representation in the object-based OM we're designing.  calc() as
>> >> defined right now can always be represented as a sum of unit'd
>> >> values, which means we can use a simple struct to represent it as an
>> object.
>> >> This is very easy to use and manipulate for authors.  Having to
>> >> preserve and represent an arbitrarily-complex math AST solely for
>> >> specified-value objects, on the other hand, makes calc()s *way*
>> >> harder to deal with. (And would mean authors have to write two
>> >> *totally different codepaths* to handle specified-value calc() vs
>> >> computed-value calc(), if they want to handle both .)
>> >
>> > Again, the concern I expressed applies to specified values.
>>
>> The thing you are replying to is entirely about specified values.  I mention
>> computed values only in passing.
>
> Yes and the distinction is important enough so others can understand why one makes a lot more sense than the other.

What I mean is, the section quoted above that I originally wrote was
providing justification for this specified-values proposal.  Your
response ignored that and just responded to the mention of computed
values.  It didn't even respond to the content of that mention, which
was about how presenting a different OM for specified values and
computed values was bad for authors.

>> >> Can we please resolve on this now?
>> >
>> > Sure, if as a group we agree that this is the best path forward ^_^
>>
>> You are the only person disagreeing with this.  The group agreed on it last
>> week but deferred the resolution, you objected to it this week and blocked
>> the resolution.  That's why I'm asking you if we can resolve on this.
>
> I see at least fantasai sharing this concern.

Her objection also ignored my previous arguments. :/

~TJ

Received on Tuesday, 5 April 2016 18:30:36 UTC