[css-mixins-1] <type()> conflicts with a previous definition in css-images-4

[romainmenke]

css-images-4 defines: https://drafts.csswg.org/css-images-4/#funcdef-image-set-type

<image-set()> = image-set( <image-set-option># )
<image-set-option> = [ <image> | <string> ]
                     [ <resolution> || type(<string>) ]?

css-mixins-1 defines: https://drafts.csswg.org/css-mixins-1/#function-rule

<@function> = @function <function-name> [ ( <function-parameter-list> ) ]?
  [ using ( <function-dependency-list> ) ]?
  [ returns <css-type> ]?
{
  <declaration-rule-list>
}

<function-name> = <dashed-ident>
<function-parameter-list> = <function-parameter>#
<function-dependency-list> = <function-parameter>#
<function-parameter> = <custom-property-name> <css-type>? [ : <declaration-value> ]?
<css-type> = <syntax-component> | <type()>
<type()> = type( <syntax> )

These are different and do not overlap in practice because one is only valid in declaration values and the other only in @function preludes.

But the conflicting definition makes it harder to extract syntax information from specs.

It is also apparent in the specs itself because <type()> in css-mixins-1 actually links to the definition in css-images-4.

[cdoublev]

They do not overlap mainly because one is a function and the other is a type.

You might be interested by speced/bikeshed#2906.

[romainmenke]

🤔 then maybe this is an issue in csstree or @webref/css?

css-images-4 as exposed through @webref/css:

  values: [
    // ...
    {
      "name": "image-set()",
      "prose": "Delivering the most appropriate image resolution for a user’s device can be a difficult task. Ideally, images should be in the same resolution as the device they’re being viewed in, which can vary between users. However, other factors can factor into the decision of which image to send; for example, if the user is on a slow mobile connection, they may prefer to receive lower-res images rather than waiting for a large proper-res image to load. The image-set() function allows an author to ignore most of these issues, simply providing multiple resolutions of an image and letting the UA decide which is most appropriate in a given situation.",
      "href": "https://drafts.csswg.org/css-images-4/#funcdef-image-set",
      "type": "function",
      "value": "image-set( <image-set-option># )",
      "values": [
        {
          "name": "type()",
          "value": "type( <string> )",
          "href": "https://drafts.csswg.org/css-images-4/#funcdef-image-set-type",
          "type": "function"
        }
      ]
    },

css-mixins-1 as exposed through @webref/css:

  values: [
    // ...
    {
      "name": "<type()>",
      "href": "https://drafts.csswg.org/css-mixins-1/#typedef-type",
      "type": "type",
      "value": "type( <syntax> )"
    },

---

csstree doesn't make the distinction between a type <foo()> and a function foo().
But I am also unsure how it could.

When referenced both look the same:

<bar> = <foo()> | something

That the specs incorrectly link (css-mixins-1 links to css-images-4) seems to "prove" that this type is ambiguous.

[cdoublev]

I created the issue on the Bikeshed repo because I think it should not generate a link from <type()> to <dfn>type()</dfn>, which is documented...

<<foo()>> is an autolink to the function named "foo"

... but is incompatible with:

The processor will attempt to infer your definition type from the context and text content of the definition:

• [...]
• Is it surrounded by <>? Then it’s a type.
• Does it end with ()? Then it’s a function.

In my opinion, webref/reffy do the right thing.

csstree doesn't make the distinction between a type <foo()> and a function foo().

Not all functions are context-insensitive (eg. minmax()) and cannot be defined with a production rule like a type.

[romainmenke]

Got it, thank you.

I am going to try and get away with ignoring entries like

        {
          "name": "type()",
          "value": "type( <string> )",
          "href": "https://drafts.csswg.org/css-images-4/#funcdef-image-set-type",
          "type": "function"
        }

as found in:

  values: [
    // ...
    {
      "name": "image-set()",
      "prose": "Delivering the most appropriate image resolution for a user’s device can be a difficult task. Ideally, images should be in the same resolution as the device they’re being viewed in, which can vary between users. However, other factors can factor into the decision of which image to send; for example, if the user is on a slow mobile connection, they may prefer to receive lower-res images rather than waiting for a large proper-res image to load. The image-set() function allows an author to ignore most of these issues, simply providing multiple resolutions of an image and letting the UA decide which is most appropriate in a given situation.",
      "href": "https://drafts.csswg.org/css-images-4/#funcdef-image-set",
      "type": "function",
      "value": "image-set( <image-set-option># )",
      "values": [
        {
          "name": "type()",
          "value": "type( <string> )",
          "href": "https://drafts.csswg.org/css-images-4/#funcdef-image-set-type",
          "type": "function"
        }
      ]
    },

I think this should be fine for my purposes.

Thank you for the explanation and context 🙇