Avoid deriving production rule from function definitions

[cdoublev]

I would like to propose that CSS function definitions are no longer assigned a value derived from an inline definition (without a = sign, here). For example, I would like to avoid the value of fn() being assigned fn(foo) when fn() is defined with <dfn data-dfn-type=function>fn(foo)</dfn >.

I think it should instead be assigned to the prose of fn(). But more importantly, I think assuming it represents the right side of a production rule is problematic.

minmax() is defined inline with minmax(min, max) but min and max are not valid arguments when interpreted as a CSS value definition, regardless of the context that includes it in its value definition.

Until this recent change, minmax(min, max) was defined as a value rather than a function. Since I do not use the values exported by webref, this was not a problem but now I have to specifically ignore it¹ because <minmax()> does not expand to minmax(min, max).

A function can be referenced by Bikeshed autolinks <<fn()>> or <<context/fn()>>, generating <fn()> as their text. In w3c/csswg-drafts#7682 (comment), Tab Atkins says:

Right, the functions should still be marked as functions rather than values, but their context-sensitivity (indicated by the presence of the for value) means they can't be meaningfully used as productions.

I find this confusing and I am not sure why/if I can use <<grid-template-rows/minmax()>>. Perhaps a distinction should be made between a context-sensitive value definition (parsing) and a context-sensitive definition (interpretation by the UA).

But in any case, my proposal seems desirable to me.

^{¹ more concretely, my problem is that minmax() is unnecessarily included in the collection of productions extracted from webref data, whereas there is no property value definition, or higher-order production rule, that includes <minmax()> and requires to resolve its value definition by looking into the productions.}

[tidoust]

Sorry for the late reply.

Are there other cases where this rule creates problematic value properties?
Also, do you know how many definitions would be affected in the CSS extracts if we change that rule?

Most of the time, these scoped values seem directly extracted from the production rule of the parent property that gives birth to them. It seems reasonable to assume that they are production rules when they claim that they define a function.

The value minmax(min, max) is problematic because it seems to be using the usual CSS value syntax, and yet it does not. It should rather be something like minmax(<min>, <max>) with <min> and <max> defined in terms of <inflexible-breadth>, <fixed-breadth, and <track-breadth>. I guess that's another occurrence of prose written to be human-readable more than machine-readable.

I agree with the desired result: the value property should not be minmax(min, max) because that formula is incorrect. If that's an exception to the rule, a patch in Webref might be preferable to fix the problem. If that's more common, the assumption I mentioned would be proven wrong and we should indeed change the rule in Reffy.

[cdoublev]

Are there other cases where this rule creates problematic value properties?

fit-content( <length-percentage> ) is extracted as a function for the grid-template-columns|rows property (actually, for <track-size>, which is used in other properties), whose value definition includes fit-content( <length-percentage [0,∞]> ).

attr() is extracted as a value for the content property, whose value definition includes attr(<identifier>). (Actually, I do not know why Reffy does not use attr(X).)

There are also math functions in CSS Values 4 but Reffy gives precedence to the corresponding production rule over their <dfn> text, thanks to the pureSyntax argument of parseProductionRule().

There are some selectors that are defined with an invalid syntax but here it is the responsibility of the spec authors:

• :nth-of-page(n): <integer>, <number>, or <an+b>, may be expected instead of n
• :nth-child(An+B [of S]?), :nth-last-child(An+B [of S]?): <an+b> [of <selector-list>]? is expected
• :nth-of-type(An+B), :nth-last-of-type(An+B), :nth-col(An+B), :nth-last-col(An+B): <an+b> is expected
• ::cue(selector), ::cue-region(selector): <selector-list> is expected (I think)

Also, do you know how many definitions would be affected in the CSS extracts if we change that rule?

If that's an exception to the rule, a patch in Webref might be preferable to fix the problem. If that's more common, the assumption I mentioned would be proven wrong and we should indeed change the rule in Reffy.

Indeed, a few definitions would be missing...

In my opinion, there should be production rules for them. Spec authors may also use a different syntax that is more human-frienly but they should make sure that they have defined a production rule that would take precedence.

However, there is no production to define for fit-content() and minmax(): they are context-sensitive functions. I do not know how to handle this situation. Maybe a st syntax text attribute in the <dfn> (similarly to lt in anchor links).

attr() is superseded in CSS Values 5, (again) I do not use values, and I handle selectors specifically, therefore I would be fine with a patch for minmax() and fixing fit-content() in the spec! 😌

But I would still have no way to differentiate a function whose syntax is context-sensitive from a function whose syntax is context-insensitive (both may have an interpretation sensitive for a given context).