[css-grid] Mark up minmax() and fit-content() as functions in the spec?

[wbamberg]

I've been working on displaying the syntax of CSS features on MDN, via the webref package. We do this using a macro that uses fetches the syntax from webref, then tries to render it nicely, like: https://developer.mozilla.org/en-US/docs/Web/CSS/border#formal_syntax.

There are a few places where this isn't working: two that I have found are minmax() and fit-content(). These look like functions, and the MDN pages are tagged as functions, but in the specs they are not marked up as functions, so they don't appear in webref, and we're not able to show any syntax for them on MDN.

There's more on this here: mdn/content#18780 (comment) :

Finally <minmax()> doesn't seem to have an entry at all although it is listed as a component of some other types. Again, the same applies to some other functions, like <fit-content()>, where we don't see an error because our fit-content() page does not attempt to include formal syntax.

Both minmax() and fit-content() look like CSS functions but they are not defined as CSS functions (the spec defines them with a data-dfn-type="value" and not a data-dfn-type="function"). They are rather defined as "simple" values as auto or inherit. If they were real CSS functions, the definition of <track-size> would not be:

<track-breadth> | minmax( <inflexible-breadth> , <track-breadth> ) | fit-content( <length-percentage> )

... but rather

<track-breadth> | <minmax()> | <fit-content()>

Why is that? I don't know :) You may want to ask the CSS working group why they sometimes decide to create functions and sometimes decide to leave them as pure textual syntax. It may not be intentional.

So I wondered whether there's a reason that these features are not marked up as functions in the specs.

[cdoublev]

You might be interested by #7380 and #2921 (comment).

fit-content() can have different arguments therefore it cannot be defined as a production type, whose value definition must be unique. w3c/webref could extract all values but there would be a lot (ie. all keywords). Maybe they could only extract values that are functions.

[tabatkins]

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.

[cdoublev]

To be clear, taking the current markup.

Name	Markup
fit-content()	data-dfn-type="value" data-dfn-for="grid-template-columns, grid-template-rows"
minmax()	data-dfn-type="value" data-dfn-for="grid-template-columns, grid-template-rows"
rgb()	data-dfn-type="function"

The first two functions have context-sensitive definitions, are marked with data-dfn-type="value", and cannot be annotated with <fit-content()> or <minmax()>.

The third has a unique definition, is marked with data-dfn-type="function", and can be annotated with <repeat()>.

EDIT: repeat() turns out to be a confusing example of a function with a context-free value definition... I replaced it with rgb().

[tabatkins]

Okay, I went ahead and marked up minmax() and fit-content() as functions (and also fixed fit-content() in Sizing, where it had the same issue).

As I said, the context-sensitivity is indicated by the functions have a for value, versus generally usable functions that don't have a for value.

[cdoublev]

As I said, the context-sensitivity is indicated by the functions have a for value, versus generally usable functions that don't have a for value.

Please tell me if I should open new issue(s) and/or PR(s).

If I am not mistaken, all functions below are defined for a single context except rect().

TLDR: I suspect that you think most of them should rather be context-free.

In Filter Effects 1, filter functions (blur(), brightness(), etc) are defined for the filter property, but <filter-function> also expands to <blur()> | <brightness() | etc.

In CSS Transforms 1-2, transform functions (matrix(), rotate(), etc) are defined for the transform property, but they are also annotated between < and > in proses in the spec.

In CSS Shapes 1, shape functions (circle(), ellipse(), etc) are defined for the <basic-shape> type, which is not explicitly expanded (I requested this in #7390).

Among shape functions, the definition of rect() changes in CSS Masking 1, where it is used for the clip property. I suggested to inline its definition in the value definition of clip.

In CSS Values 5, crossorigin(), integrity(), referrerpolicy(), are defined for the <request-url-modifier> type.

In CSS Easing 1-2:

• cubic-bezier() is defined for the <cubic-bezier-easing-function> type
• steps() is defined for the <step-easing-function> type
• linear() is not defined for the <linear-easing-function> type but <linear-easing-function> = linear(<linear-stop-list>) is explicitly defined

In CSS Content 3, leader() is defined for the <content-list> type but it is also annotated between < and > in the value definition of <content-list>.

In CSS Overflow 4, fade() is defined for the text-overflow property but it is also annotated between < and > in the value definition of text-overflow.

In CSS Page Floats 3, snap-block() and snap-inline() are defined for the float property, but they are also annotated between < and > in the value definition of float.

In CSS Images 4, type() is defined for the image-set() function.

---

As a grammar-driven parser implementer, I have to manually define a context-sensitive function definition when it does not appear in the value definition of its context:

const types = {
  // ...
  '<basic-shape>': 'circle(<shape-radius>? [at <position>]?) | ellipse([<shape-radius>{2}]? [at <position>]?) | etc',
  '<transform-function>': 'matrix(<number>#{6}) | translate(<length-percentage> , <length-percentage>?) | etc',
  '<cubic-bezier-easing-function>': 'cubic-bezier(<number [0,1]>, <number>, <number [0,1]>, <number>)',
  '<step-easing-function>': 'steps(<integer>, <step-position>?)',
  // ...
}

[cdoublev]

w3c/reffy now extracts minmax() with minmax(min, max) as its value (definition), which is wrong: min and max keywords are not expected.

Do you think w3c/reffy should only extract (type/function) value definitions from <pre>? I suspect there are many function value definitions annotated in <dfn> instead.

[cdoublev]

There is also a few types defined as value, eg. <family-name> in CSS Speech.