Should we treat minmax() as a CSS function?

[wbamberg]

This came out of: mdn/content#18780 (comment) and mdn/content#18780 (comment). In those comments we discussed the fact that we don't show formal syntax for minmax() because it's not marked up as a CSS function in the spec, so the syntax isn't included in webref.

I filed w3c/csswg-drafts#7682 to ask about this and the answer seems to be that they're intentionally not marked up as functions because they are context-specific. Instead they are marked up as values (data-dfn-type="value") of track-size and auto-track-size (https://w3c.github.io/csswg-drafts/css-grid-2/#track-sizes).

...compared with, say, data-dfn-type="function" in https://w3c.github.io/csswg-drafts/css-color-4/#funcdef-rgb.

So I'm not sure where this leaves us. We could just remove the ## Formal syntax section from the minmax() page. This is simple but gives us a seemingly random inconsistency, and means we can't make formal syntax mandatory for CSS functions.

Or we could document minmax() inline in the page where it is referenced, as we do for other values, and not give it a separate page.

Or we could treat it like a keyword, which we already do for somewhat similarly-specced things like https://developer.mozilla.org/en-US/docs/web/css/max-content ?

[teoli2003]

It looks to me that this is similar to fit-content(), and in that case, we have chosen the first option. (Remove the formal syntax section) [I found this by looking at the page, not referring to a discussion]

I do think we should be coherent and do the same for fit-content() and minmax(), and keeping a separate page without the formal syntax section is the easiest solution.

Option 2 – To document it on each page – would not bring any advantage to this solution. And option 3 – To document it as a keyword – would be odd as these have no parameter (and no need for a formal syntax).

There is a fourth option, to hardcode a formal syntax, but it won't be automatically updated when the spec changes.

I'd vote for either removing the section (option 1) or hardcoding it (option 4). No strong feelings between the two.

[ydaniv]

I think removing now, and not adding any "dead code" is better, and hopefully a new macro can be added later for values.
Is this something that can also be contributed via PR?

[dipikabh]

This came to my attention via mdn/content#24887.

Reviewing our existing templates, we list templates for CSS property page and CSS selector page.

The sections in the function pages are quite similar to the CSS selector page template, in that the function pages also don't have a "Formal syntax", but a few do have the "Try it" section.

(Is this the only function page with the "Formal syntax" section - https://developer.mozilla.org/en-US/docs/Web/CSS/cross-fade#formal_syntax?)

Would this help:

1. We update the CSS feature reference page section to add a note that function pages will follow the CSS selector page template plus the "Try it" section.

2. Remove the "Formal syntax" section from the function pages (so going with Option 1).