[cssom] Is round special in CSSOM?

[svgeesus]

Context: moving the serialization of <color> values from CSSOM to CSS Color 4, per CSSWG resolution. I'm just checking that the new Color serialization section has everything needed before sending a PR to replace the corresponding part of CSSOM with a pointer.

Several times in Serializing CSS Values I see the phrase:

rounded to the closest integer (rounding up if two values are equally close)

Looking at the documentation of JavaScript Math.round

If the fractional portion of the argument is greater than 0.5, the argument is rounded to the integer with the next higher absolute value. If it is less than 0.5, the argument is rounded to the integer with the lower absolute value. If the fractional portion is exactly 0.5, the argument is rounded to the next integer in the direction of +∞.

and again for C++

Returns the integral value that is nearest to x, with halfway cases rounded away from zero.

Then, for positive numbers, this seems to be merely a restatement of part of the algorithm. In other words, the next decimal digit after the place to be rounded can take any one of ten values: 0,1,2,3,4,5,6,7,8,9 and of those, half of them (0,1,2,3,4) round down and half (5,6,7,8,9) round up.

Thus, is there utility in retaining this wording? Or is it enough to just say "round". I'm happy either way, just want the Color 4 spec to be complete.

[gibson042]

I would definitely recommend rewording to clarify whether rounding-driven tiebreaking is to be interpreted as towards positive infinity vs. away from zero, either of which is a plausible interpretation of "up". ECMA 402 is currently trying to wrangle this within the JavaScript ecosystem, and have included CSS in the surveys as part of the exercise: tc39/proposal-intl-numberformat-v3#7 (comment)

[css-meeting-bot]

The CSS Working Group just discussed [cssom] Is `round` special in CSSOM?.

The full IRC log of that discussion

<dael> Topic: [cssom] Is `round` special in CSSOM?
<dael> github: https://github.com//issues/5689
<dael> chris: Context was I was going through cssom def os serializing color b/c moving to color 4. Had a special definition of rounding. Seems there is a reason, mainly for negative numbers, that you have to spec
<dael> chris: Do we want this in cssom or copy to color 4, assume rounding is rounding? I wanted guidance before I remove the section
<dael> TabAtkins: Legit question. confusing if round up means toward infinity or away from 0. Ideally shouldn't restate in algos and we should have a statement in OM about how to round
<dael> TabAtkins: Not sure if [missed] has a need
<TabAtkins> s/[missed]/Infra/
<dael> emilio: css values should have something about this b/c came up when dividing numbers
<dael> Rossen_: Had similar discussions around math functions and aligning to a particular language. Discussion around mod operator
<Rossen_> q?
<dael> TabAtkins: I suspect match JS b/c if someone were to impl on their own that's what would happen
<dael> TabAtkins: Apparently c++ and JS differ in default roundin gup
<dael> TabAtkins: Is it better ot match JS, C++, Rust or what?
<dael> emilio: Rust does C++ afaict
<dael> TabAtkins: So away from 0
<dael> fantasai: C++ probably makes more sense for CSS
<dael> Rossen_: Trying to avoid whole discussion about how to align better with math/js/other lang which is the discussion we had before which was heated and we kept coming back to it. I would suggest take this back to the issue and come back with a proposal
<dael> Rossen_: We could spend the next 7 minutes just shifting through languages
<dael> chris: Fine for me
<dael> fantasai: We were just talking values. Values 4 draft is super out of date

[fantasai]

Should probably keep https://drafts.csswg.org/css-values-4/#round-func in sync.

[tabatkins]

Just confirming: CSS and JS both default to "towards positive infinity". C++ and Rust default to "away from zero".

Matching C++ and Rust would be better for implementations, I assume; they don't have to remember to round specially in every serialization function.

But matching JS and CSS would be better for matching the web platform in general.

[fantasai]

The CSS round() function is quite new. If we go with "away from zero" behavior here, we can update round() to match. CSS could then be internally consistent, though inconsistent with JS...

[LeaVerou]

Rounding from a mathematical perspective, might be of interest: https://math.stackexchange.com/questions/3448/rules-for-rounding-positive-and-negative-numbers

[tabatkins]

If we did change CSS, it would suggest that we need to go with the "controls for nearest behavior" that was brought up by dbaron during the f2f; basically being able to pair nearest with another keyword to specify what the rounding behavior should be (so that authors could opt into JS semantics).

That would also mean we'd need to add away-from-zero, which we punted on for lack of demonstrated use-case, if that's the behavior we end up defining for nearest. ^_^

[svgeesus]

I'm happy to see that this is being discussed and that (whichever way we end up with) there will be a single place in CSS which defines this.

I agree that the fairly new round() function should track this.

I see in V&U that combination of <integer> says to round to positive infinity and although combination of <number> is silent on this. That doesn't really cover the case there a number is serialized to finite precision, unless that is thought of as conversion to integer and then conversion to a float-looking string by shifting the decimal point.

For now though CSS Color 4 can point to V&U for rounding, and need not copy over the ambiguous "rounding up" wording from CSSOM.

[tabatkins]

Fantasai and I agree that CSSOM could use some clarity, and that it should match the behavior of JS and the rest of CSS (in calc() rounding, animation rounding, and the default behavior of round()) in rounding X.5 values toward positive infinity. So we added a definition for “round to the nearest integer” to make it easy to reference (and said that it applies “unless otherwise specified” so that anywhere that doesn't mention it gets this behavior by default).

Specs that aren't doing anything special should be able to just refer to V&U: either use an <integer> in the grammar (so you get the correct rounding for free), or ref the new "round to the nearest integer" definition.

[svgeesus]

Thanks!