Re: [csswg-drafts] [css-values] Allow division of same types in calc()

I agree with @dbaron that "negating" types is confusing wording.

> it's not clear what determines whether the result is `<number>` or `<integer>`, though I suspect that's a pre-existing issue.

Based on the decision in #2337, there is no longer any need to keep track of the distinction between numbers and integers: the calculation can happen as full numbers, and integer clamping happen on the final value.

More comments on @tabatkins' edits:

- Which is likely to go to CR first, Values 4 or CSS Typed OM 1?  Maybe it would be better to move the full type checking definitions here, and then reference/overwrite them from Typed OM.

- Regardless of whether or not you continue to link to Typed OM, it would be helpful if you actually define the type map concept in this spec before using it in the list of rules. Suggested wording:

  > Operators form sub-expressions, which can have complex types created by combining the types of their arguments. These complex types are represented as map of base types to integers representing a power.
  > 
  > [example]
  > The complex type «[ "length" → 1 ]» is a simple length (to the power 1).
  >
  > The complex type «[ "length" → 2 ]» is a length squared (to the power 2), which could represent an area measurement such as cm<sup>2</sup> (although area measurements aren't currently used in CSS).
  >
  > The complex type «[ "length" → 1, "time"→ -1 ]» is length over time (length to the power 1, time to the power negative 1), which could represent speed such as <sup>cm</sup>/<sub>s</sub> (again, not a type currently used in CSS properties, but still valid as an intermediary type in a calculation).
  >
  > The complex type  «[ "length" → 0 ]» is the same as  «[  ]» (an empty type map), and is equivalent to a unitless number.

- The "In previous versions..." sentence should be pulled out as an informative note.

- Then, in the rule list, move the list of simple types up to be the first point in the list, as it provides an understandable example of what this means.

- Since that bullet point already handles converting percentages to their "hint" types, I think it just confuses matters to link to the Houdini "add the types" algorithm for the "+" operator. In this simplified case, the algorithm is:
  
  > At a `+` or `-` sub-expression, determine simplified type maps for both the left and right arguments, by calculating a complex type map for that argument and then removing any types with a power of 0.
  > If the resulting type maps for both arguments are not identical, then the entire math function is invalid.
  > Otherwise, the sub-expression's type map is the result of removing any types with a power of 0 from the complex type map of one of its arguments.

- For multiplication: again, the linked Houdini algorithm includes complications about percent hints which don't apply here.  Notably, with percent hints already resolved to other base types, there is no way for the type checking to fail in a multiplication operation.  After removing percent hints from the algorithm, and converting some of the pseudocode to prose, it would look something like:

  > At a `*` sub-expression, generate a new complex type map, _finalType_, that is a copy of the complex type map for the left-hand argument to the expression.
  > Then, for each base type in the complex type map of the right-hand argument:
  >  - if _finalType_ already has an entry for that base type, increment its power by the amount of the power from the right-hand type map;
  > - otherwise, add a new entry for that base type to _finalType_, with a power equal to the power from the right-hand type map.
  > 
  > The sub-expression’s type is _finalType_.

- For division: 

  > At a `/` sub-expression, invert the type of the right-hand argument by multiplying ever power in the complex type map by -1.
  > The sub-expression's type is the result of multiplying the left-hand argument by this inverted type.

- If the decision is that this spec should stand alone, without reference to Typed OM, then the paragraph about resolving the math expression to a final type also needs to be re-written. But even if you continue to link to Typed OM, there might need to be some clarification here given that percentage types have already been resolved to other base types when possible. (The rules in Typed OM _do not_ define mutually exclusive types, since they allow a `«[ "percent" → 1 ]»` type to match percent, length-percent, angle-percent, etc.)

- Per the decision in https://github.com/w3c/css-houdini-drafts/issues/734#issuecomment-389592303, the "anything else" bullet point will need to be updated (although it might be best to keep that as a separate commit).

- The note about percentages and numbers not being combine-able needs to be updated, so that it doesn't reference division by other types being disallowed.

-- 
GitHub Notification of comment by AmeliaBR
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/545#issuecomment-393266651 using your GitHub account

Received on Wednesday, 30 May 2018 18:22:23 UTC