Re: [css-houdini-drafts] [css-typed-om] Will need to handle min()/max()

The CSS Working Group just discussed CSSNumericValue, and agreed to the following resolutions:

```
RESOLVED: Switch to CSSMathValue-based expression tree with toSum() method for returning dictionary of unit types (as described aboce)
```

<details><summary>The full IRC log of that discussion</summary>

```
<fantasai> Topic: CSSNumericValue
<fantasai> Related to https://docs.google.com/document/d/1NA020gku-tgEHMGK_8xkB6Ksfpd8ieL4z9jFoGchzbA/edit
<fantasai> Related to https://docs.google.com/document/d/1NA020gku-tgEHMGK_8xkB6Ksfpd8ieL4z9jFoGchzbA/edit
<fantasai> ARG WHY WON"T THIS PASTE
<fantasai> Issue #359
<trackbot> Sorry, but no Tracker is associated with this channel.
<dbaron> Github topic: https://github.com/w3c/css-houdini-drafts/issues/359
<fantasai> shane: We came up with a proposal over lunch
<fantasai> shane: Getting rid of previous proposal that we resolved on
<fantasai> shane: and  replacing it with CSSNumericValue which has two subclasses: CSSMathValue and CSSUnitValue
<fantasai> shane: CSMathValue has two members, operator and operands
<fantasai> shane: operator is a string reprsenting a math operator like "*"
<fantasai> shane: *, /, min, max, +
<dbaron> shane: operands are CSSUnitValue
<dbaron> (or presumably also other CSSMathValue??)
<fantasai> shane: operands is a list of CSSUnitValue
<fantasai> s/CSSUnitValue/CSSNumericValue
<fantasai> shane: CSSNumericValue has a method called toSum which returns a map of units to numbers
<fantasai> shane: representing a sum of those dimensions, as previously
<fantasai> shane: If the CSSNumericValue cannot be so reduced, it either returns null or throws, whatever the TAG decides
<fantasai> SimonSapin: If the initial syntax uses unncessary parentheses or calc() inside of calc(), do we want hte tree to preserve that information?
<fantasai> TabAtkins: I would prefer we don't
<TabAtkins> calc(1px + (2px + 3px)) => CSSMath("+", [1px, 2px, 3px])
<fantasai> fantasai: I agree, because people put arens when they want to clarify something, nto just when they have a grouping, e.g. calc(1px + (2*2px))
<fantasai> fantasai: I agree, because people put arens when they want to clarify something, nto just when they have a grouping, e.g. calc(1px + (2*2px))
<fantasai> xidorn: Do we want to distinguish between 3px and calc(3px)?
<fantasai> TabAtkins: Yes, and we'll probably default it to the plus operator
<fantasai> plinss: Going back to unnecessary parens, I think we should preserve that structure.
<fantasai> plinss: If author wants to reduce, can use toSum()
<fantasai> plinss: E.g. 2*3em, they did that for a reason
<fantasai> TabAtkins: Don't have a problem with it, but would mean operator(+,[operator(+, [2px, 3px])])
<fantasai> shane: Any code dealing with this would have to recurse anyway
<TabAtkins> Which would mean calc(1px + (2px + 3px)) => CSSMath("+", [1px, CSSMath("+", [2px, 3px])])
<fantasai> TabAtkins: There's no non-broken code you coudl write that would break on extra parens being grouped
<fantasai> s/grouped/preserved/
<fantasai> plinss: So let's preserve struture
<fantasai> SimonSapin: So no distinction btw nested calc() and nested parens?
<fantasai> TabAtkins: We don't even when serializing, so no
<fantasai> shane: What do you do when animating between calc(5px + (4em + 2%)) and calc(10px + 10em + 10%)
<fantasai> TabAtkins: animations are computed value anyway, and so they're necessarily reduced -- they're produced by the engine, not by the author
<fantasai> TabAtkins: The beginning point can be unit value, endpoint a calc(). What's in between? Engine decides
<fantasai> fantasai: Tab, since you were concerned about typing, could consider CSSMathValue as a listlike type, and .op as the operator member
<fantasai> TabAtkins: No, it's fine.
<fantasai> SimonSapin: Earlier were talking about Proxy for arraylike stuff
<fantasai> SimonSapin: if it's not used here, where is it used in CSSOM?
<fantasai> TabAtkins: TransformValue and UnparsedValue
<fantasai> SimonSapin: Why do we want to do something different here?
<fantasai> TabAtkins: Semantically different -- this is an operator, and arguments to that operator. Those are fundamentally sequences
<fantasai> iank_: So this proposal is completely replacing hte CSSCalcValue stuff we discused earlier?
<fantasai> TabAtkins: yep, throw it away
<fantasai> iank_: So you wouldn't have any of those complex units like em*ch
<fantasai> iank_: Right
<fantasai> TabAtkins: Still want to handle custom units whenever they exist
<fantasai> TabAtkins: also may want to handle case-insensitivity
<fantasai> fantasai: custom idents are case-sensitive
<fantasai> TabAtkins: Note in the spec that we don't have custom units yet, but plan to
<fantasai> Rossen: Sounds like ppl are happy with this?
<fantasai> fantasai: Share Tab's earlier concern about operator and operand being perhaps a bit too long to type, but otherwise seems okay to me
<fantasai> SimonSapin asks how percents represented
<fantasai> TabAtkins: as "percent". Didn't use "%" so that it would be weird to use as a .name
<fantasai> plinss: Unitless zero?
<fantasai> TabAtkins: custom stuff can't use unitless zero, only in CSS syntax.
<fantasai> TabAtkins: also calc() can't have unitless zero
<fantasai> SimonSapin: I have some bugs to file then
<fantasai> RESOLVED: Switch to CSSMathValue-based expression tree with toSum() method for returning dictionary of unit types (as described aboce)
```
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/359#issuecomment-294683166 using your GitHub account

Received on Tuesday, 18 April 2017 05:16:44 UTC