- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 18 Apr 2017 05:16:34 +0000
- To: public-houdini-archive@w3.org
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