[css-values] Function notations without parameters should be keywords!?

[Crissov]

The recently introduced tree counting functions sibling-count() and sibling-index() come with a note:

These functions may, in the future, be extended to accept an of <complex-real-selector-list> argument, similar to :nth-child(), to filter on a subset of the children.

Introducing selectors in property value functions would need to respect the resolution of #12590, although it already has been done before in special-needs cases like print-oriented target-…() functions.

Therefore, since 1) this possible future extension is all but certain or sound, 2) the parentheses will always be empty till then, 3) CSS uses keywords alongside functions and 4) there is precedence established by inherit/inherit(), fit-content/fit-content(), snap-block/snap-block() / snap-inline/snap-inline() and somewhat contents / content(),
should these rather be keywords without parentheses instead (for now at least)?

I understand that programmers are trained to think of these as functions and empty parentheses feel normal to them, but that is not how CSS syntax has traditionally been designed – keywords are the default.

If the CSSWG follows my rationale, I further believe that single-word keywords usually work better, especially for global ones. Alas, while siblings could replace sibling-count rather well, index would feel too arbitrary compared to sibling-index.

PS: Since these have started shipping already, a resolution to this issue is urgent, but it is not too late for a change yet.

[SebastianZ]

I generally agree that we should introduce keywords for them.

If the CSSWG follows my rationale, I further believe that single-word keywords usually work better, especially for global ones. Alas, while siblings could replace sibling-count rather well, index would feel too arbitrary compared to sibling-index.

Here I'd contradict, as it's more consistent to have a common prefix for both functions. Though I don't have a strong opinion on that.

PS: Since these have started shipping already, a resolution to this issue is urgent, but it is not too late for a change yet.

It's probably not that urgent, because I'd argue that a function without parameters is equal to its keyword counterpart. So it's not a breaking change that holds up shipping.

Sebastian

[Loirooriol]

Currently counter-increment: foo sibling-index increments the counters foo and sibling-index. But if sibling-index becomes an <integer>, would it instead increment foo by a sibling-index amount? Seems potentially problematic.

[Crissov]

My preference for a single word is not a strong one either.

In some cases, like the counter properties, due to unfortunate value syntax, any or certain new global keyword can indeed be (mis)interpreted as a custom ident. One unsatisfying way to circumvent this, would be to limit the places or contexts such keywords can be used in, e.g. <calc-sum> (like <calc-keyword>) or as the exclusive value of a property (like explicit defaults).