- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Thu, 15 Feb 2018 19:00:52 +0000
- To: public-houdini-archive@w3.org
> I don't think wrapping in calc() solves all cases where a serialisation round trip would fail e.g. z-index: calc(4.5) would fail to parse. Ugh, I didn't think of type mismatches in the number/integer confusion. I feel like we should probably just relax this in V&U, so that calc() always matches `<integer>` if it's a number, and you just round if necessary. If `width: calc(-1px)` is fine, there's no reason `z-index: calc(1.5)` shouldn't be. > It's not clear to me why we are avoiding rejecting TypedOM values that don't match what property spec text declares as valid numeric values. Because it seems annoying/bad to force the author to keep track of precisely what numeric type their object is - if assigning a `CSS.px(-1)` to width is invalid, but `new CSSMathSum(CSS.px(-1))` is fine, that's weird. The distinction is reasonable in normal CSS, because you don't have an arbitrary object that may be a plain numeric or may be a calc; you're almost always directly writing the value in, so it's obvious which you have. It's made worse by the fact that the math operations might return a simple type, or not - you can't tell by looking whether `val1.add(val2)` is going to return a CSSUnitValue or a CSSMathSum, as it depends on the types and contents of `val1` and `val2`. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/574#issuecomment-366027613 using your GitHub account
Received on Thursday, 15 February 2018 19:00:54 UTC