W3C home > Mailing lists > Public > public-css-archive@w3.org > February 2018

[csswg-drafts] [css-values] calc() should round when it's used as an <integer>

From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
Date: Tue, 20 Feb 2018 21:22:01 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-298753093-1519161721-sysbot+gh@w3.org>
tabatkins has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-values] calc() should round when it's used as an <integer> ==
Right now, calc() carefully tracks whether a numeric expression (no units or %s) is guaranteed to resolve to an integer, or might resolve to a more general number.  This allows it to be used in places like `z-index` safely.

However, it excludes some expressions that would be integral if evaluated - for example, *any* division makes it non-integral, even in an expression like `calc(4 / 2)`.

This restriction also seems somewhat inconsistent with calc()'s treatment of range restrictions - if you specify `width: calc(-1px);`, it's valid (and equivalent to 0px), but if you specify `z-index: calc(4 / 2);`, it's invalid.  It seems like this was accidentally motivated by what can be expressed directly in the grammar (integer vs real) vs what has to be expressed in prose as an additional constraint (range restrictions), but these really shouldn't be treated differently.

In particular, this causes some trouble for TypedOM, which wants to make it so that `CSSUnitValue`s (corresponding to plain numbers and dimensions) get the same protection against being out-of-range that calc() does, but now we've realized that there's no such "should be an integer, is actually a real" protection that we could also apply.

So! I propose that we remove the tracking of `<integer>` vs `<number>` in `calc()` (it's already no longer tracked in the typing algorithms of Typed OM, which will be used in calc(), per WG resolution, when I finally write up the unit-algebra text), and instead say that if a calc() ends up being non-integral when an integer is required, it is automatically rounded to the nearest integer.

(Detail: I provisionally propose we use "toward positive infinity" rounding, same as JS's `Math.round()`. Does CSS already have any rounding we should match instead?)

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2337 using your GitHub account
Received on Tuesday, 20 February 2018 21:22:08 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:24 UTC