[css-values-4] <integer> grammar terms and <number>-returning functions

[tabatkins]

Grammars can specify that they take either a <number>, or specifically an <integer>. This behavior is well-defined for literal tokens, but less clear for functions evaluating to these types.

Math functions that resolve to a <number> are defined to be allowed to satisfy an <integer> production; their value is rounded to the nearest integer. Similarly, interpolation between two <integer> terms is defined to round to the nearest integer. But there's not actually anything saying, one way or the other, how to treat other functions that return a <number> but aren't math functions, like sibling-index(). We have never defined a function as returning an <integer>; are these functions simply invalid to be used in z-index and the like?

I propose that we adopt the "round to the nearest integer" behavior for everything that's not a literal <number-token>. (The behavior for <number-token> is probably too entrenched to change.)

Agenda+ as this is a change to a stable spec.

[Loirooriol]

Seems reasonable, but specifically for sibling-index(), I guess it could just be defined as returning an <integer> instead? Not having a precedent doesn't seem a big deal.

[fantasai]

sibling-count() and sibling-index() are already defined to return <integer>.

[fantasai]

I'm not sure about this. I think it's reasonable to require that these functions be explicitly rounded -- it's reasonably likely that the author might want a different rounding behavior, and they can make that explicit with round().

[tabatkins]

sibling-count() and sibling-index() are already defined to return .

Lol indeed, so bad example on my part.

I'm not sure about this. I think it's reasonable to require that these functions be explicitly rounded -- it's reasonably likely that the author might want a different rounding behavior, and they can make that explicit with round().

I don't understand this argument. If the user does want a different rounding behavior, sure, they're allowed to use round() to achieve that. Why does that mean such functions should be invalid (grammar mismatch) when they don't explicitly round? Why does this argument not apply to the existing behavior that auto-rounds math functions?

[cdoublev]

Fwiw, matching the behavior of math functions was my point in #10979:

• rounding to <integer>

Currently, progress() is a math function but container-progress() is not, so z-index: progress(1, 1, 1) is valid but z-index: container-progress(width, 1px, 1px) is not.

• range checking (clamping)

Again, since progress() is a math function, font-weight: progress(1001, 0, 1) is valid and clamped but font-weight: container-progress(...) might be invalid.

• serialization without calc()

calc(progress(...) serializes with progress(...) but calc(container-progress(...)) serializes as is.

[css-meeting-bot]

The CSS Working Group just discussed [css-values-4] `<integer>` grammar terms and `<number>`-returning functions, and agreed to the following:

• RESOLVED: Functions that return a <number> will be rounded to an <integer> when used in <integer> context.

The full IRC log of that discussion

<fantasai> TabAtkins: currently our math functions like calc(), sin() etc.
<fantasai> TabAtkins: If they return a non-integer value, but required to return <integer>, we automatically round to nearest integer
<fantasai> TabAtkins: If you a are a function that returns a number, but not a math function, currently invalid to use in <integer>
<miriam> +1
<kbabbitt> +0.9
<lea> +calc(infinity)
<fantasai> TabAtkins: Let's just call that valid.
<fantasai> TabAtkins: This will not change literal number usage.
<bkardell> +a
<fantasai> TabAtkins: (that's been invalid for 30 years)
<fantasai> TabAtkins: But this allows number-returning function to be used anywhere.
<fantasai> astearns: If you have a custom property that is defined to be <integer> and you set its value with these, that works
<fantasai> lea: yes, that works
<fantasai> astearns: But if you have a custom property not defined as an integer, and set it using one of these math functions, does that get rounded?
<fantasai> astearns: because not defining var()
<fantasai> TabAtkins: var() will do substitution, and then we resolve the math
<fantasai> astearns: We don't expect compat issues here?
<fantasai> TabAtkins: I think only example of non-math function defined to return a <number> is sibling-index() and sibling-count()
<fantasai> fantasai: That's a spec error!
<oriol> The spec is right, they return an <integer> already
<fantasai> TabAtkins: But we could have them in theory. We made some up, but dropped them.
<fantasai> TabAtkins: So we can fix this problem for anything we do in the future.
<fantasai> PROPOSED: Functions that return a <number> will be rounded to an <integer> when used in <integer> context.
<fantasai> oriol: Seems reasonable
<fantasai> RESOLVED: Functions that return a <number> will be rounded to an <integer> when used in <integer> context.