[css-values] Let B default to 1 in `round(<strategy>?, A, B)`

[Loirooriol]

I get the reasoning for requiring a precision in most cases. However, as I mentioned in #2513 (comment), it seems fine to omit it for numbers.

So if B becomes optional, defaulting to 1, it will be possible to do things like

round(2.3) /* 2 */
round(up, 2.3) /* 3 */

while round(2.3em) will continue being invalid due to the type mismatch between A and B.

[SebastianZ]

while round(2.3em) will continue being invalid due to the type mismatch between A and B.

Does it have to be invalid? Isn't it possible to just assume the same type for B in that case? I.e. round(2.3em) would be equivalent to round(2.3em, 1em).

Sebastian

[Loirooriol]

No, that would be bad. Let's say 1em = 16px, then round(2.3em) should produce the same as round(36.8px). But round(2.3em, 1em) is 2em = 32px, while round(36.8px, 1px) is 37px. Making it unit-dependent is also not clear for round(2.3em + 2.3px).

It could work by saying that step defaults to one canonical unit, but in round(2.3em) authors may get surprised it's 1px instead of 1em, so better require it.

[tabatkins]

Right, that's precisely why it requires a unit right now - we can't have the unit depend on the input (for the reasons given, plus things like round(1em + 10px) that don't have a single unit), and we don't want to default a mystery unit that might violate author expectations.

So if B becomes optional, defaulting to 1

Yes, we could do this. Is there a particular reason to do so, tho?

[Loirooriol]

It just seems strange to require the 1 when working with plain numbers, since it's the obvious choice. Like, in English people just say "round x", not "round x to a multiple of 1".

[SebastianZ]

Let's say 1em = 16px, then round(2.3em) should produce the same as round(36.8px).

Converting the unit before rounding is totally unexpected from an author's standpoint.

we can't have the unit depend on the input (for the reasons given, plus things like round(1em + 10px) that don't have a single unit), and we don't want to default a mystery unit that might violate author expectations.

The point was for rounding when only having a single unit. So, round(1em + 10px) would still be invalid. Only round(2.3em), round(42.8deg), or round(87.39%) would be valid (being equivalent to round(2.3em, 1em), round(42.8deg, 1deg), and round(87.39%, 1%), respectively).

Allowing to omit B for numbers but not dimensions or percentages may cause confusion.

Like, in English people just say "round x", not "round x to a multiple of 1".

Not just spoken languages but also also in many programming languages you can omit the precision - or even don't have a way to define one like in JavaScript.

Sebastian

[jfkthame]

The point was for rounding when only having a single unit. So, round(1em + 10px) would still be invalid.

Would round(3.14159em + 2.71828em) be valid, then? The unit is consistent/clear, but it seems like this could still be tricky/confusing. It looks "obvious" what to do when the units are right there, but what about when you have round(--var(foo) + --var(bar)), where foo and bar are both lengths? Whether the round works (and what it means) then depends on how they were defined in this particular context. I think that's getting too obscure and footgun-ish to be useful.

Making the precision default to 1 (as a number) only, in contrast, is clear and simple, while rounding anything other than a number requires being explicit about the unit of rounding.

[tabatkins]

So, round(1em + 10px) would still be invalid. Only round(2.3em), round(42.8deg), or round(87.39%) would be valid (being equivalent to round(2.3em, 1em), round(42.8deg, 1deg), and round(87.39%, 1%), respectively).

That's pretty fragile, and it means that round(var(--foo)) may or may not be valid, and might round to an unpredictable precision, based on how the value is written somewhere else.

And round(10em / 3)? Either that's invalid too (and the entire feature starts getting super fragile), or we have to rewrite the simplification rules to maintain units as-is when possible.

In-flight edit: lol, @jfkthame makes the exact same points.

---

Anyway, if impls want to change the defaulting rules to allow a default of 1 for B, I'm fine with that. Agenda+ to discuss it.

[Crissov]

I agree with @SebastianZ and @Loirooriol that it would be unintuitive for authors if the rounding base defaulted to 1<canonical unit>, especially for simple terms like 2.3em, but it might still be the most reasonable and useful solution, because you hardly ever round simple terms.
You usually need either the result of a calculation rounded with the resulting unit or a value with a relative unit, e.g. em or %, expressed as an integer amount in an absolute unit like px.

My educated guess is that the most common use case by far will be rounding (calculated) lengths to whole pixels. Since px is the canonical unit there, this would be covered nicely.

Another viable solution I see would be to treat a <number> given as the second parameter not as a module but as the number of decimal places. Then, round(4.32, 1) would compute to 4.3 instead of 4 and likewise round(4.32em, 1) = 4.3em, while round(4.32em, 1em) would yield 4em. The default value would be 0.

Finally, instead of defaulting to 1, 1<resulting unit> or 1<canonical unit>, the second parameter could support keywords:

• round(4.32em, auto) = 4em
• round(4.32em, default) = e.g. 69px
• round(4.32em, none) = e.g. 69.12px

[tabatkins]

I strongly disagree that rounding to "whole pixels" is the most common case for rounding lengths. I think that's actually an extremely rare case; subpixel lengths are usually just fine to work with. Similarly, rounding to the nearest degree doesn't seem particularly useful for most cases. The canonical unit is quite arbitrary, and generally speaking I don't think people will commonly be rounding to 1 of any unit; the rounding precision depends intimately on what one is actually trying to accomplish.

the number of decimal places.

That's just a less powerful version of the current argument, where you're limited to precisions that are a power of 10 of some unit. It also has all the existing problems of a default rounding precision.

keywords

These either continue to have the existing problems of a default rounding precision, or are equivalent to just providing a trivial value.

[SebastianZ]

That's pretty fragile, and it means that round(var(--foo)) may or may not be valid

That's true in any case, as --foo can hold anything.

Though we could also define that the unit of the first operand is used. So round(3.14159em + 2.71828em) = round(3.14159em + 2.71828em, 1em) = 6em, round(1em + 10px) = round(1em + 10px, 1em) = 2em, and round(10px + 1em) = round(10px + 1em, 1px) = 26px (in case 1em = 16px).
That makes it explainable and less fragile.

and might round to an unpredictable precision, based on how the value is written somewhere else.

The precision is not unpredictable, it is unit-based.

Similarly, rounding to the nearest degree doesn't seem particularly useful for most cases. The canonical unit is quite arbitrary, and generally speaking I don't think people will commonly be rounding to 1 of any unit.

The point is to provide a reasonable fallback / default. Authors will still be advised to provide a rounding interval if they want to influence the rounding precision.

Another viable solution I see would be to treat a <number> given as the second parameter not as a module but as the number of decimal places.

Note that Firefox already ships the round() function. So, a change in behavior will break any current usages.

Sebastian

[Loirooriol]

Though we could also define that the unit of the first operand is used

This would violate commutativity. And in fact serialization sorts summation operands alphabetically by their units, so this wouldn't roundtrip. And anyways it's seems very unintuitive to me.

[tabatkins]

Ultimately, trying to infer a rounding precision from the source unit is going to fail in lots of cases, and even when it works, there's zero guarantee that it'll produce a useful value.

The current spec makes it trivial to round to any unit you like (round(..., 1em)) and to any size at all, and doesn't need to do any fragile or unexpected inference at all. It's really unlikely we'd ever change it to be more complicated and fragile, for what is almost certainly a small minority use-case of "people who want to round to 1px/1deg/etc".

[Crissov]

It just occurred to me that with keywords in the second parameter, round() could also be a place to implement truly physical length measurements. #5986 #614

Either round(100mm, physical) or round(100mm, millimeter) would give the best approximation of 1 dm the browser can do with the active output device.

However, authors would probably want arbitrary precision there, which would be crude to support with keywords and always remain incomplete. Treat this as a devil’s advocate proposal then.