[css-values-5] Should progress functions have a calculation tree as their internal representation?

[cdoublev]

Like math functions. This would help to clarify:

• how to determine their type when they are used in a calculation
• whether the result of progress() can be unwrapped during the simplification of a calculation tree
• whether their resolved value should be clamped to the range allowed in the target context
• whether calc(progress(...)) should serialize as is or with progress(...) as a component of a declared value

[tabatkins]

I've now (in 5afd5de) marked progress() as a math function, so it gets caught by the general terminology about internal representation.

The other two are not math functions, just ordinary functions that resolve to a number, and evaluate their own calculation arguments in a special context. I've added a bit of text to Values 4 (in https://drafts.csswg.org/css-values-4/#calc-type-checking) about how contexts get determined, which hopefully makes this clearer.

[cdoublev]

Thank you, this is useful.

About clarifying how to determine the type of media-progress(), container-progress(), and also tree-counting functions... the specs are actually already clear: they are <number>s.

Anything else is a terminal value, whose type is determined based on its CSS type.

For what is worth, I prefer to not consider them as <number>s, but as resolving to a <number>.

Anyway, I am more interested in the observable output. For exemple, whether calc(media-progress(...)) should serialize with or without calc(), and whether media-progress() matching <integer> should be clamped at computed-value time.

[tabatkins]

Anyway, I am more interested in the observable output. For exemple, whether calc(media-progress(...)) should serialize with or without calc(), and whether media-progress() matching should be clamped at computed-value time.

Neither of these questions are specific to these functions.

• Any single value wrapped in a calc() will discard the calc() at computed-value time.
• Currently, functions returning <number> that aren't math functions don't get any special treatment regarding integers; they're just invalid. However, there's no functions defined as returning <integer> at all. This seems completely reasonable to change, tho - require integers when provided with <number-token>s, but accept <number> otherwise and round to the nearest integer. I'll open a separate issue.

[cdoublev]

Any single value wrapped in a calc() will discard the calc() at computed-value time.

progress() is now a math function therefore it discards calc() in a component of a declared value, but other progress functions can not.

functions returning <number> that aren't math functions don't get any special treatment regarding integers; they're just invalid

So z-index: progress() is rounded to the closest integer, but z-index: container-progress() is not and is either valid or invalid depending on the function output. But you want to change that, right? (I did not understand your reasoning in the rest of your comment.)

there's no functions defined as returning <integer> at all

There is sibling-index() and sibling-count().

[tabatkins]

progress() is now a math function therefore it discards calc() in a component of a declared value, but other progress functions can not.

I'm not sure what you mean. The calc() unwrapping is an aspect of the calc, not an aspect of what it contains. It just needs its contents to be a simple numeric value.

[cdoublev]

The calc() unwrapping can also happen when serializing it as a component of a declared value, when its contents is a single math function.

progress() is a math function so as a component of a declared value, calc(progress(1em from 1px to 20px)) serializes with progress(1em from 1px to 20px). On the other hand, container-progress() and media-progress() (and also sibling-*()) are not so as a component of a declared value, calc(container-progress(width from 1px to 20px)) serializes as is.

To be more explicit about how I see this... defining container-progress() & co as calculations represented with a calculation tree would allow unwraping them from calc(). This would also answer whether font-weight: container-progress(width from 0px to 1px) should be clamped to 1000 (the upper bound of font-weight), consistently with progress(1001 from 0 to 1), or invalid.