Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[cssom] Is round special in CSSOM? #5689

Closed
svgeesus opened this issue Oct 31, 2020 · 10 comments
Closed

[cssom] Is round special in CSSOM? #5689

svgeesus opened this issue Oct 31, 2020 · 10 comments
Labels
Closed as Question Answered Used when the issue is more of a question than a problem, and it's been answered. Commenter Satisfied Commenter has indicated satisfaction with the resolution / edits. css-values-4 Current Work cssom-1 Current Work

Comments

@svgeesus
Copy link
Contributor

svgeesus commented Oct 31, 2020

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.

@svgeesus svgeesus added css-color-4 Current Work cssom-1 Current Work labels Oct 31, 2020
@gibson042
Copy link

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
Copy link
Member

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
Copy link
Collaborator

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

@tabatkins
Copy link
Member

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
Copy link
Collaborator

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
Copy link
Member

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

@tabatkins
Copy link
Member

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. ^_^

@astearns astearns removed the Agenda+ label Nov 11, 2020
@svgeesus
Copy link
Contributor Author

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.

@svgeesus svgeesus added css-values-4 Current Work and removed css-color-4 Current Work labels Nov 13, 2020
tabatkins added a commit that referenced this issue Oct 21, 2021
@tabatkins
Copy link
Member

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 svgeesus added Closed as Question Answered Used when the issue is more of a question than a problem, and it's been answered. Commenter Satisfied Commenter has indicated satisfaction with the resolution / edits. labels Oct 22, 2021
@svgeesus
Copy link
Contributor Author

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Closed as Question Answered Used when the issue is more of a question than a problem, and it's been answered. Commenter Satisfied Commenter has indicated satisfaction with the resolution / edits. css-values-4 Current Work cssom-1 Current Work
Projects
None yet
Development

No branches or pull requests

7 participants