[css-values] Comments on Serialization of calc

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[css-values] Comments on Serialization of calc

Francois Remy-2
Hi Tab, Fantasai,

Here are a few comments regarding the "calc" serialization section I just reviewed:
https://drafts.csswg.org/css-values-3/#calc-serialize


----[0] Thanks for looking into this, you rock, as always!


----[1] I am not confident with the "compatible units" notion, mostly because it isn't defined anywhere (except by example). It is not clear, for instance, what calc(100vw - 20px) resolves to at specified time. Technically, the viewport width does not depend on the element this value is applied on, but at the same time it may vary which would somehow require to keep the values separate to provide the right result over time. It is also not clear to me what happens if we have calc(1cm + 1mm) vs calc(1mm + 1cm). The units are compatible, but which one should we keep? Does order matter?

An alternative approach I would like to see investigated would be the following one:
(a) define a canonical unit per type (length:px,time:s,...) or an ordered list of canonical units if needed
(b) replace step 1 by something like "for each component of the sum, if it would possible to do so permanently, convert it into the canonical unit of the calc expression (specified values cannot be converted in a way that would make the conversion be invalid if the environment changes, computed values can)"

This is a breaking change over your current approach which preserves 0vh for instance, while it would be converted to 0px in this case. We could add some additional condition that says that the validity of conversion is considered independently of the number put in front of the unit, which prevents 0 being an exception).


----[2] I have no opinion on the clamping of values at step 2 of the algorithm you want to add. For me it looks fine to drop this step altogether and just serialize "calc(<value>)" whatever <value> is, but I understand some browsers might want to simplify it as soon as possible in order to save memory. This is such an edge case I doubt it is really worth it, though.


Hope this helps,
Francois

Reply | Threaded
Open this post in threaded view
|

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

Tab Atkins Jr.
On Wed, Feb 17, 2016 at 11:39 AM, Francois Remy <[hidden email]> wrote:

> Hi Tab, Fantasai,
>
> Here are a few comments regarding the "calc" serialization section I just reviewed:
> https://drafts.csswg.org/css-values-3/#calc-serialize
>
>
> ----[0] Thanks for looking into this, you rock, as always!
>
>
> ----[1] I am not confident with the "compatible units" notion, mostly because it isn't defined anywhere (except by example). It is not clear, for instance, what calc(100vw - 20px) resolves to at specified time. Technically, the viewport width does not depend on the element this value is applied on, but at the same time it may vary which would somehow require to keep the values separate to provide the right result over time. It is also not clear to me what happens if we have calc(1cm + 1mm) vs calc(1mm + 1cm). The units are compatible, but which one should we keep? Does order matter?

It probably does need to be expanded on, but it's the same concept of
"absolutization" that transforms em into px at computed-value time.

> An alternative approach I would like to see investigated would be the following one:
> (a) define a canonical unit per type (length:px,time:s,...) or an ordered list of canonical units if needed
> (b) replace step 1 by something like "for each component of the sum, if it would possible to do so permanently, convert it into the canonical unit of the calc expression (specified values cannot be converted in a way that would make the conversion be invalid if the environment changes, computed values can)"
>
> This is a breaking change over your current approach which preserves 0vh for instance, while it would be converted to 0px in this case. We could add some additional condition that says that the validity of conversion is considered independently of the number put in front of the unit, which prevents 0 being an exception).

Agree with this in general.  And yeah, we'd combine based on units
only, not values.

> ----[2] I have no opinion on the clamping of values at step 2 of the algorithm you want to add. For me it looks fine to drop this step altogether and just serialize "calc(<value>)" whatever <value> is, but I understand some browsers might want to simplify it as soon as possible in order to save memory. This is such an edge case I doubt it is really worth it, though.

Yeah, this step is based on browsers' current behavior. I'd prefer to
drop it if specifying fresh.

~TJ

Reply | Threaded
Open this post in threaded view
|

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

L. David Baron
On Wednesday 2016-02-17 15:48 -0800, Tab Atkins Jr. wrote:

> On Wed, Feb 17, 2016 at 11:39 AM, Francois Remy <[hidden email]> wrote:
> > Hi Tab, Fantasai,
> >
> > Here are a few comments regarding the "calc" serialization section I just reviewed:
> > https://drafts.csswg.org/css-values-3/#calc-serialize
> >
> >
> > ----[0] Thanks for looking into this, you rock, as always!
> >
> >
> > ----[1] I am not confident with the "compatible units" notion, mostly because it isn't defined anywhere (except by example). It is not clear, for instance, what calc(100vw - 20px) resolves to at specified time. Technically, the viewport width does not depend on the element this value is applied on, but at the same time it may vary which would somehow require to keep the values separate to provide the right result over time. It is also not clear to me what happens if we have calc(1cm + 1mm) vs calc(1mm + 1cm). The units are compatible, but which one should we keep? Does order matter?
>
> It probably does need to be expanded on, but it's the same concept of
> "absolutization" that transforms em into px at computed-value time.
But it seems wrong to apply a computed-value type of process to a
specified value.

Perhaps what should be combined are *identical* units?  Then, for
computed values, many units will have been converted to identical
units, but for specified values, they won't be.

> > ----[2] I have no opinion on the clamping of values at step 2 of the algorithm you want to add. For me it looks fine to drop this step altogether and just serialize "calc(<value>)" whatever <value> is, but I understand some browsers might want to simplify it as soon as possible in order to save memory. This is such an edge case I doubt it is really worth it, though.
>
> Yeah, this step is based on browsers' current behavior. I'd prefer to
> drop it if specifying fresh.

Gecko and Chromium don't do this.  Testcase:

<!DOCTYPE html>
<p style="margin-left: calc(3px)">
<script>
document.write(document.getElementsByTagName("p")[0].style.marginLeft);
</script>

or
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cp%20style%3D%22margin-left%3A%20calc(3px)%22%3E%3C%2Fp%3E%0A%3Cscript%3E%0Adocument.write(document.getElementsByTagName(%22p%22)%5B0%5D.style.marginLeft)%3B%0A%3C%2Fscript%3E

Perhaps what you were observing was part of the calc *computation*
process rather than the calc *serialization* process?

-David

--
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                          https://www.mozilla.org/   𝄂
             Before I built a wall I'd ask to know
             What I was walling in or walling out,
             And to whom I was like to give offense.
               - Robert Frost, Mending Wall (1914)

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Tab Atkins Jr.
On Wed, Feb 17, 2016 at 7:02 PM, L. David Baron <[hidden email]> wrote:

> On Wednesday 2016-02-17 15:48 -0800, Tab Atkins Jr. wrote:
>> On Wed, Feb 17, 2016 at 11:39 AM, Francois Remy <[hidden email]> wrote:
>> > Hi Tab, Fantasai,
>> >
>> > Here are a few comments regarding the "calc" serialization section I just reviewed:
>> > https://drafts.csswg.org/css-values-3/#calc-serialize
>> >
>> >
>> > ----[0] Thanks for looking into this, you rock, as always!
>> >
>> >
>> > ----[1] I am not confident with the "compatible units" notion, mostly because it isn't defined anywhere (except by example). It is not clear, for instance, what calc(100vw - 20px) resolves to at specified time. Technically, the viewport width does not depend on the element this value is applied on, but at the same time it may vary which would somehow require to keep the values separate to provide the right result over time. It is also not clear to me what happens if we have calc(1cm + 1mm) vs calc(1mm + 1cm). The units are compatible, but which one should we keep? Does order matter?
>>
>> It probably does need to be expanded on, but it's the same concept of
>> "absolutization" that transforms em into px at computed-value time.
>
> But it seems wrong to apply a computed-value type of process to a
> specified value.

I'm not really sure what you mean by "computed-value type of process".
Some units are combinable at specified-value time.  1in is always
exactly equal to 96px, so "1in + 10px" can be losslessly converted to
"106px" right away if you wanted.

> Perhaps what should be combined are *identical* units?  Then, for
> computed values, many units will have been converted to identical
> units, but for specified values, they won't be.

This doesn't match any implementation.  Chrome combines terms
aggressively, based on what units are capable of being merged at a
given time.  Firefox doesn't combine at all - "calc(10px + 10px)" will
return itself unchanged if you ask for specified value in current
Firefox or IE.

Chrome also resolves multiplication/division immediately, because it's
always diving something by a constant value.  I'd not sure what your
suggestion would tend towards.

Finally there's add/sub/mult/div of *numbers*.  Firefox and Chrome do
this eagerly - calc(1 + 2) will become calc(3) in specified style,
calc(2/1) becomes calc(2).  IE keeps it as written.

So our current behaviors for specified-style calc() are:

IE: Always returns what was written.
Firefox: Returns what was written, except that it resolves any
subexpressions whose arguments are purely numbers.
Chrome: Eagerly resolves every subexpression that it can, based on
specified-value-time data.

Your suggestion is: Return what was written, but resolve any
subexpressions with identical units.  Right?  (If I state it this way,
it implies that calc(10px / 2) will stay that way. Is that what you
intend?)

I'd personally prefer Chrome's behavior, as it matches the behavior
you get at computed-value and used-value time.  (We can interpret your
suggestion as also doing this, if we assume that comparable units are
*only* turned into the "base" unit at computed-value time and above.)
fantasai apparently prefers either IE's behavior or your suggested
behavior, based on an IRC convo we're having right now.

>> > ----[2] I have no opinion on the clamping of values at step 2 of the algorithm you want to add. For me it looks fine to drop this step altogether and just serialize "calc(<value>)" whatever <value> is, but I understand some browsers might want to simplify it as soon as possible in order to save memory. This is such an edge case I doubt it is really worth it, though.
>>
>> Yeah, this step is based on browsers' current behavior. I'd prefer to
>> drop it if specifying fresh.
[snip]
> Perhaps what you were observing was part of the calc *computation*
> process rather than the calc *serialization* process?

Ah, yeah, I was only looking at computed value there.  I'm fine with
preserving calc() through specified value, and only discarding it at
computed-value time.  I'll fix this part.

~TJ

Reply | Threaded
Open this post in threaded view
|

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

Tab Atkins Jr.
In reply to this post by Francois Remy-2
On Wed, Feb 17, 2016 at 11:39 AM, Francois Remy <[hidden email]> wrote:
> It is also not clear to me what happens if we have calc(1cm + 1mm) vs calc(1mm + 1cm). The units are compatible, but which one should we keep?

fantasai just pointed out that this is handled by CSSOM.  As far as
calc() is concerned they just combine together into a "<length>
value", and CSSOM describes how to serialize length values (as px).
Same for other units, like calc(1deg + 1rad).

> Does order matter?

Order doesn't matter in combining, but it does in serializing, and
that's well-defined (alphabetical, with numbers first and percentages
last).

~TJ

Reply | Threaded
Open this post in threaded view
|

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

Francois Remy-2
> > It is also not clear to me what happens if we have calc(1cm + 1mm) vs
> calc(1mm + 1cm). The units are compatible, but which one should we keep?
>
> fantasai just pointed out that this is handled by CSSOM.  As far as
> calc() is concerned they just combine together into a "<length> value", and
> CSSOM describes how to serialize length values (as px).
> Same for other units, like calc(1deg + 1rad).

Perfect. I think we should reference that instead of making up a new term here, though.

So, maybe we can say only identical units should be merged, because serialization is already going to take care of the process of converting them to the same unit, right?

 
> > Does order matter?
>
> Order doesn't matter in combining, but it does in serializing, and that's well-
> defined (alphabetical, with numbers first and percentages last).

Makes sense, given your comment above.
Reply | Threaded
Open this post in threaded view
|

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

Tab Atkins Jr.
On Thu, Mar 10, 2016 at 1:42 PM, Francois Remy <[hidden email]> wrote:

>> > It is also not clear to me what happens if we have calc(1cm + 1mm) vs
>> calc(1mm + 1cm). The units are compatible, but which one should we keep?
>>
>> fantasai just pointed out that this is handled by CSSOM.  As far as
>> calc() is concerned they just combine together into a "<length> value", and
>> CSSOM describes how to serialize length values (as px).
>> Same for other units, like calc(1deg + 1rad).
>
> Perfect. I think we should reference that instead of making up a new term here, though.
>
> So, maybe we can say only identical units should be merged, because serialization is already going to take care of the process of converting them to the same unit, right?

No, serialization won't automagically combine things, it just dictates
what unit to use when they *do* get serialized.  See my previous email
to David where I explored what impls do at specified-value time.

~TJ

Reply | Threaded
Open this post in threaded view
|

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

Tab Atkins Jr.
In reply to this post by Tab Atkins Jr.
On Thu, Mar 10, 2016 at 11:59 AM, Tab Atkins Jr. <[hidden email]> wrote:

> On Wed, Feb 17, 2016 at 7:02 PM, L. David Baron <[hidden email]> wrote:
>> On Wednesday 2016-02-17 15:48 -0800, Tab Atkins Jr. wrote:
>>> On Wed, Feb 17, 2016 at 11:39 AM, Francois Remy <[hidden email]> wrote:
>>> > Hi Tab, Fantasai,
>>> >
>>> > Here are a few comments regarding the "calc" serialization section I just reviewed:
>>> > https://drafts.csswg.org/css-values-3/#calc-serialize
>>> >
>>> >
>>> > ----[0] Thanks for looking into this, you rock, as always!
>>> >
>>> >
>>> > ----[1] I am not confident with the "compatible units" notion, mostly because it isn't defined anywhere (except by example). It is not clear, for instance, what calc(100vw - 20px) resolves to at specified time. Technically, the viewport width does not depend on the element this value is applied on, but at the same time it may vary which would somehow require to keep the values separate to provide the right result over time. It is also not clear to me what happens if we have calc(1cm + 1mm) vs calc(1mm + 1cm). The units are compatible, but which one should we keep? Does order matter?
>>>
>>> It probably does need to be expanded on, but it's the same concept of
>>> "absolutization" that transforms em into px at computed-value time.
>>
>> But it seems wrong to apply a computed-value type of process to a
>> specified value.
>
> I'm not really sure what you mean by "computed-value type of process".
> Some units are combinable at specified-value time.  1in is always
> exactly equal to 96px, so "1in + 10px" can be losslessly converted to
> "106px" right away if you wanted.
>
>> Perhaps what should be combined are *identical* units?  Then, for
>> computed values, many units will have been converted to identical
>> units, but for specified values, they won't be.
>
> This doesn't match any implementation.  Chrome combines terms
> aggressively, based on what units are capable of being merged at a
> given time.  Firefox doesn't combine at all - "calc(10px + 10px)" will
> return itself unchanged if you ask for specified value in current
> Firefox or IE.
>
> Chrome also resolves multiplication/division immediately, because it's
> always diving something by a constant value.  I'd not sure what your
> suggestion would tend towards.
>
> Finally there's add/sub/mult/div of *numbers*.  Firefox and Chrome do
> this eagerly - calc(1 + 2) will become calc(3) in specified style,
> calc(2/1) becomes calc(2).  IE keeps it as written.
>
> So our current behaviors for specified-style calc() are:
>
> IE: Always returns what was written.
> Firefox: Returns what was written, except that it resolves any
> subexpressions whose arguments are purely numbers.
> Chrome: Eagerly resolves every subexpression that it can, based on
> specified-value-time data.
>
> Your suggestion is: Return what was written, but resolve any
> subexpressions with identical units.  Right?  (If I state it this way,
> it implies that calc(10px / 2) will stay that way. Is that what you
> intend?)
>
> I'd personally prefer Chrome's behavior, as it matches the behavior
> you get at computed-value and used-value time.  (We can interpret your
> suggestion as also doing this, if we assume that comparable units are
> *only* turned into the "base" unit at computed-value time and above.)
> fantasai apparently prefers either IE's behavior or your suggested
> behavior, based on an IRC convo we're having right now.

Reminder that this is topic #1 at the call tomorrow, so if you haven't
reviewed it and formed your opinion/arguments, we're gonna default to
the standard CSSWG strategy: Tab does whatever he thinks best.

~TJ

Reply | Threaded
Open this post in threaded view
|

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

Tab Atkins Jr.
In reply to this post by Tab Atkins Jr.
On Thu, Mar 10, 2016 at 11:59 AM, Tab Atkins Jr. <[hidden email]> wrote:

> On Wed, Feb 17, 2016 at 7:02 PM, L. David Baron <[hidden email]> wrote:
>> Perhaps what should be combined are *identical* units?  Then, for
>> computed values, many units will have been converted to identical
>> units, but for specified values, they won't be.
>
> This doesn't match any implementation.  Chrome combines terms
> aggressively, based on what units are capable of being merged at a
> given time.  Firefox doesn't combine at all - "calc(10px + 10px)" will
> return itself unchanged if you ask for specified value in current
> Firefox or IE.
>
> Chrome also resolves multiplication/division immediately, because it's
> always diving something by a constant value.  I'd not sure what your
> suggestion would tend towards.
>
> Finally there's add/sub/mult/div of *numbers*.  Firefox and Chrome do
> this eagerly - calc(1 + 2) will become calc(3) in specified style,
> calc(2/1) becomes calc(2).  IE keeps it as written.
>
> So our current behaviors for specified-style calc() are:
>
> IE: Always returns what was written.
> Firefox: Returns what was written, except that it resolves any
> subexpressions whose arguments are purely numbers.
> Chrome: Eagerly resolves every subexpression that it can, based on
> specified-value-time data.
>
> Your suggestion is: Return what was written, but resolve any
> subexpressions with identical units.  Right?  (If I state it this way,
> it implies that calc(10px / 2) will stay that way. Is that what you
> intend?)
>
> I'd personally prefer Chrome's behavior, as it matches the behavior
> you get at computed-value and used-value time.  (We can interpret your
> suggestion as also doing this, if we assume that comparable units are
> *only* turned into the "base" unit at computed-value time and above.)
> fantasai apparently prefers either IE's behavior or your suggested
> behavior, based on an IRC convo we're having right now.

At the telcon yesterday, we decided that we *probably* wanted to go with:

1. All expressions with at least one "number" argument are resolved.
(eg "1 + 2" => "3", "10px / 2" => "5px", "2 * (10px + 1em)" => "20px +
2em")
2. Terms with identical units are combined. (eg "10px + 15px" =>
"25px", but "10px + 1in" stays as written)

This guarantees the calc() expression can be stored as a sum of unit'd
values even at specified-value time, while still preserving
author-specified units as much as possible, per usual behavior in
specified values.  (That is, if you type "width: 1in;", we preserve
that in specified value, rather than converting it to the equivalent
"width: 96px;".)

The only dissenter was MS, who wished to review with their
implementors and return with an answer next week.

We'll make a final resolution next week and then I'll edit the spec accordingly.

~TJ

Reply | Threaded
Open this post in threaded view
|

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

Greg Whitworth
>The only dissenter was MS, who wished to review with their implementors
>and return with an answer next week.

This feels a little strongly worded IMO ;)

I checked with the dev in question and while it won't be as trivial as you made it out to be we're ok with the change in principal.
Thanks,
Greg
Reply | Threaded
Open this post in threaded view
|

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

Tab Atkins Jr.
On Mon, Mar 28, 2016 at 5:57 PM, Greg Whitworth <[hidden email]> wrote:
>>The only dissenter was MS, who wished to review with their implementors
>>and return with an answer next week.
>
> This feels a little strongly worded IMO ;)
>
> I checked with the dev in question and while it won't be as trivial as you made it out to be we're ok with the change in principal.

Apparently you're not, since Rossen just relitigated it on the call. :(((((

Just to reiterate, in case people don't want to look a few messages
upward, the proposal is that, at specified-value time, we:

1. Resolve all numeric expressions, leaving us with a sum of unit'd values.
2. Combine all identical units.

> Rossen_: And I did. I'm the impl in charge of this and I have 3 pushbacks. 1 this won't be a trigger for us to impl 2) interop will be flacky at best and 3) this isn't helping authors. It's going to be hard for tools

Let's run thru these.

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.

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?

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

(We will, eventually, have to deal with unit algebra, and thus have
units of arbitrary complexity that can no longer be represented as a
field in a struct. Shane and I have plans to deal with that, but we'll
cross that bridge when we come to it, and even in that world, the
*vast majority* of calc()s will be "simple" and still
struct-friendly.)

If you're talking solely about *string parsing* of calc()s, (a) we, as
a group, aren't encouraging that, and are creating an API specifically
to make that no longer necessary, and (b) this proposal *simplifies*
string parsing by ensuring all calc()s are a simple sum of unit'd
values.

The only possible code that can be hurt by this change:

* writes out calc()s and then re-parses its own values
* using some extremely naive "parsing" code that requires the
structure be *precisely* the same
* only dealing with specified values ever (because computed/used
simplify in *all* browsers)
* and is IE-only (because everyone else simplifies specified values to
some degree)

So, between both the object-based OM and the string-based, this
proposal simplifies generic handling and is useful for authors.


Nothing I've said here is new; I discussed all of it last week, and it
should be in the minutes.  Again, we all tentatively agreed that the
proposal is good, we were just waiting for MS folk to make sure there
wasn't some "gotcha" that would make it hard for them.  We got that on
Monday, I was just waiting for the official resolution today before
making the edits.

Can we please resolve on this now?

~TJ

Reply | Threaded
Open this post in threaded view
|

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

Rossen Atanassov-3
On Wed, Mar 30, 2016 at 10:36:26, Tab Atkins Jr. wrote:

>
> On Mon, Mar 28, 2016 at 5:57 PM, Greg Whitworth <[hidden email]>
> wrote:
> >>The only dissenter was MS, who wished to review with their
> >>implementors and return with an answer next week.
> >
> > This feels a little strongly worded IMO ;)
> >
> > I checked with the dev in question and while it won't be as trivial as you
> made it out to be we're ok with the change in principal.
>
> Apparently you're not, since Rossen just relitigated it on the call. :(((((
>
> Just to reiterate, in case people don't want to look a few messages upward,
> the proposal is that, at specified-value time, we:
>
> 1. Resolve all numeric expressions, leaving us with a sum of unit'd values.
> 2. Combine all identical units.
>
> > Rossen_: And I did. I'm the impl in charge of this and I have 3
> > pushbacks. 1 this won't be a trigger for us to impl 2) interop will be
> > flacky at best and 3) this isn't helping authors. It's going to be
> > hard for tools

"trigger" should've read "trivial" :)

> Let's run thru these.
>
> 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.

For serializing computed values I'm not as concerned and actually prefer your current proposal.

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

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

> (We will, eventually, have to deal with unit algebra, and thus have units of
> arbitrary complexity that can no longer be represented as a field in a struct.
> Shane and I have plans to deal with that, but we'll cross that bridge when we
> come to it, and even in that world, the *vast majority* of calc()s will be
> "simple" and still
> struct-friendly.)
>
> If you're talking solely about *string parsing* of calc()s, (a) we, as a group,
> aren't encouraging that, and are creating an API specifically to make that no
> longer necessary, and (b) this proposal *simplifies* string parsing by ensuring
> all calc()s are a simple sum of unit'd values.
>
>
> The only possible code that can be hurt by this change:
>
> * writes out calc()s and then re-parses its own values
> * using some extremely naive "parsing" code that requires the structure be
> *precisely* the same
> * only dealing with specified values ever (because computed/used simplify in
> *all* browsers)
> * and is IE-only (because everyone else simplifies specified values to some
> degree)
>
> So, between both the object-based OM and the string-based, this proposal
> simplifies generic handling and is useful for authors.
>
>
> Nothing I've said here is new; I discussed all of it last week, and it should be in
> the minutes.  Again, we all tentatively agreed that the proposal is good, we
> were just waiting for MS folk to make sure there wasn't some "gotcha" that
> would make it hard for them.  We got that on Monday, I was just waiting for
> the official resolution today before making the edits.
>
> Can we please resolve on this now?

Sure, if as a group we agree that this is the best path forward ^_^
Reply | Threaded
Open this post in threaded view
|

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

Tab Atkins Jr.
On Thu, Mar 31, 2016 at 8:20 PM, Rossen Atanassov
<[hidden email]> 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).

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.

> For serializing computed values I'm not as concerned and actually prefer your current proposal.

Computed values are already well-defined and aren't in question at the moment.

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

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

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

~TJ

Reply | Threaded
Open this post in threaded view
|

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

Francois Remy-3
> From: Tab Atkins Jr. [mailto:[hidden email]]
> On Thu, Mar 31, 2016 at 8:20 PM, Rossen Atanassov
> <[hidden email]> 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).
>
> 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.
>
> > For serializing computed values I'm not as concerned and actually prefer
> your current proposal.
>
> Computed values are already well-defined and aren't in question at the
> moment.
>
> >> 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?
>
> >> 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.
>
> >> 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.
>
> ~TJ

Just as a small note: since we all mostly refactor shorthands/longhands, reformat colors, and drop comments+whitespace already, I ("webdev / cssom user" me) am still under the impression that the "preserving what the author wrote" boat sailed a long time ago. That being said, I can understand the argument that choosing this serialization for the specified style reveals details about how css is handled now, which we may never or more difficulty change in the future if we want to. I don't see this as a strong blocker, but I acknowledge the point. I think this is Rossen's main concern, here.

Unrelated: Tab, you might want to take a look at this one, because Chrome is acting weird on that one:
https://jsfiddle.net/09dbr7m6/2/ 

Reply | Threaded
Open this post in threaded view
|

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

Francois Remy-3
In reply to this post by Tab Atkins Jr.
> From: Tab Atkins Jr. [mailto:[hidden email]]
> On Thu, Mar 31, 2016 at 8:20 PM, Rossen Atanassov
> <[hidden email]> 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).
>
> 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.
>
> > For serializing computed values I'm not as concerned and actually prefer
> your current proposal.
>
> Computed values are already well-defined and aren't in question at the
> moment.
>
> >> 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?
>
> >> 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.
>
> >> 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.
>
> ~TJ

Just as a small note: since we all mostly refactor shorthands/longhands, reformat colors, and drop comments+whitespace already, I ("webdev / cssom user" me) am still under the impression that the "preserving what the author wrote" boat sailed a long time ago. That being said, I can understand the argument that choosing this serialization for the specified style reveals details about how css is handled now, which we may never or more difficulty change in the future if we want to. I don't see this as a strong blocker, but I acknowledge the point. I think this is Rossen's main concern, here.

Unrelated: Tab, you might want to take a look at this one, because Chrome is acting weird on that one:
https://jsfiddle.net/09dbr7m6/2/ 

Reply | Threaded
Open this post in threaded view
|

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

fantasai
In reply to this post by Tab Atkins Jr.
On 04/01/2016 03:47 PM, Tab Atkins Jr. wrote:
>
> 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).

This is a very misleading statement. Mozilla only simplifies numerical
factors, so in fact IE and Mozilla's behaviors are very close and
preserve almost everything.
   http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4029

Also, Rossen's concern (which I share) is not just about what authors
are depending on right now (given lack of interop between Blink/Webkit
and IE/FF, it's probably not much), but what would be useful for them
to have going into the future.

And I agree that for computed style we should collapse as much as
possible. (In fact, the Computed Value line is generally represented
as a tuple of percentage and length, which then serializes out as
calc() if it's got non-zero values in both.)

I won't object to collapsing identical units in specified styles,
but I'm not convinced that saves us a whole lot, especially given
we plan to add multiplication and division by units and keywords
into the calc expressions at some point in the future -- which are
not things that can be simplified away so easily.

In any case, as I noted in the minutes of the telecon you're
referencing, I would prefer we got author feedback on this issue.

~fantasai

Reply | Threaded
Open this post in threaded view
|

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

Alan Stearns
On 4/2/16, 9:22 AM, "fantasai" <[hidden email]> wrote:

>On 04/01/2016 03:47 PM, Tab Atkins Jr. wrote:
>>
>> 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).
>
>This is a very misleading statement. Mozilla only simplifies numerical
>factors, so in fact IE and Mozilla's behaviors are very close and
>preserve almost everything.
>   http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4029
>
>Also, Rossen's concern (which I share) is not just about what authors
>are depending on right now (given lack of interop between Blink/Webkit
>and IE/FF, it's probably not much), but what would be useful for them
>to have going into the future.

Given that we’re talking about debugging, lack of browser interop may be a more minor factor than is usual. If one or more browsers have more useful debugging tool behavior, it’s likely that people *do* depend on it if it happens to be the browser they choose to start development in.

Thanks,

Alan
Reply | Threaded
Open this post in threaded view
|

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

Tab Atkins Jr.
In reply to this post by fantasai
On Sat, Apr 2, 2016 at 9:22 AM, fantasai <[hidden email]> wrote:

> On 04/01/2016 03:47 PM, Tab Atkins Jr. wrote:
>> 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).
>
>
> This is a very misleading statement. Mozilla only simplifies numerical
> factors, so in fact IE and Mozilla's behaviors are very close and
> preserve almost everything.
>   http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4029

"Everything" and "almost everything" are *very* different when you're
talking about preserving intent. There's a big difference between "a
third of this 40px margin" and "13.33333333px".

> Also, Rossen's concern (which I share) is not just about what authors
> are depending on right now (given lack of interop between Blink/Webkit
> and IE/FF, it's probably not much), but what would be useful for them
> to have going into the future.

Which I addressed in my further points.

> I won't object to collapsing identical units in specified styles,
> but I'm not convinced that saves us a whole lot, especially given
> we plan to add multiplication and division by units and keywords
> into the calc expressions at some point in the future -- which are
> not things that can be simplified away so easily.

I already addressed this in my earlier message.

~TJ

Reply | Threaded
Open this post in threaded view
|

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

Alan Stearns
On 4/2/16, 8:55 PM, "Tab Atkins Jr." <[hidden email]> wrote:

>On Sat, Apr 2, 2016 at 9:22 AM, fantasai <[hidden email]> wrote:
>
>> I won't object to collapsing identical units in specified styles,
>> but I'm not convinced that saves us a whole lot, especially given
>> we plan to add multiplication and division by units and keywords
>> into the calc expressions at some point in the future -- which are
>> not things that can be simplified away so easily.
>
>I already addressed this in my earlier message.

Could you reiterate or expand on this for my benefit? I read through the thread again and have missed this part.

My current understanding is that since the current simplification proposal is not the most aggressive one, there are current cases that will not be able to be expressed in the simple OM - something like calc(1em + 1ex + 10px). Is that correct? Are there other edge cases that will need a more complicated OM? What’s the fallback plan for things that don’t fit into the simple calc type? (either now if I’m correct that there are edge cases or in the future when we allow more complex calc expressions)

Thanks,

Alan
Reply | Threaded
Open this post in threaded view
|

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

Tab Atkins Jr.
On Sun, Apr 3, 2016 at 10:33 AM, Alan Stearns <[hidden email]> wrote:

> On 4/2/16, 8:55 PM, "Tab Atkins Jr." <[hidden email]> wrote:
>
>>On Sat, Apr 2, 2016 at 9:22 AM, fantasai <[hidden email]> wrote:
>>
>>> I won't object to collapsing identical units in specified styles,
>>> but I'm not convinced that saves us a whole lot, especially given
>>> we plan to add multiplication and division by units and keywords
>>> into the calc expressions at some point in the future -- which are
>>> not things that can be simplified away so easily.
>>
>>I already addressed this in my earlier message.
>
> Could you reiterate or expand on this for my benefit? I read through the thread again and have missed this part.

Me talking about the object-based OM, where a "list of unit'd values"
makes the OM sane and easy to work with, but an AST is not.

> My current understanding is that since the current simplification proposal is not the most aggressive one, there are current cases that will not be able to be expressed in the simple OM - something like calc(1em + 1ex + 10px). Is that correct?

No, that works just fine.  Can you elaborate on why you think that
would be problematic?  It sounds like there's a pretty fundamental
disconnect in what people are thinking about, which might explain the
confusion.

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

> What’s the fallback plan for things that don’t fit into the simple calc type? (either now if I’m correct that there are edge cases or in the future when we allow more complex calc expressions)

Our current plan is to simplify things into three categories:

* a sum of unit'd values, as today
* a sum of values with complex units, to handle mult/division by unit'd values
* a sum of inverses of sums of complex units, to handle division by
sums of unit'd values

As far as I can tell, that's the best we can do; it keeps things as
simple as possible for the common case (everything you can do today),
and makes things as simple as possible for the next most-common case
(dividing a unit by a unit)

Alternately, if having two types of "complex" expressions is too much,
just hang an AST off the object to represent the latter two
categories.  More work for anyone trying to process things, but it's
at only *one* type of work. Unsure if the tradeoffs are better.

~TJ

12