[csswg-drafts] [meta] Context-sensitive function definitions (#13340)

cdoublev has just created a new issue for https://github.com/w3c/csswg-drafts:

== [meta] Context-sensitive function definitions ==
I would like to fix a long-standing problem I have with context-sensitive function definitions.

### The problem

To parse an input against `<fn()>`, a CSS parser must first resolve the value definition of the `<fn()>` production, which is expected to be context-insensitive:

  > [function] context-sensitivity (indicated by the presence of the `for` value) means they can't be meaningfully used as productions.

<details>
<summary>In practice, many context-sensitive functions are used as productions:</summary>
<br>

  - filter functions for [`filter`](https://drafts.csswg.org/filter-effects-1/#propdef-filter) (before f6f0efa, cf. #13309)
  - shape functions for [`<basic-shape>`](https://drafts.csswg.org/css-shapes-1/#typedef-basic-shape)
  - transform functions for [`transform`](https://drafts.csswg.org/css-transforms-1/#propdef-transform)
  - `<calc-size()>` for [`width`](https://drafts.csswg.org/css-sizing-3/#propdef-width), `height`, etc
  - `<fade()>` for [`text-overflow`](https://drafts.csswg.org/css-overflow-4/#propdef-text-overflow)
  - `<leader()>` for [`<content-list>`](https://drafts.csswg.org/css-content-3/#content-values)
  - `<rect()>` for [`clip`](https://drafts.csswg.org/css-masking-1/#propdef-clip)
  - `<snap-*()>` for [`float`](https://drafts.csswg.org/css-page-floats-3/#propdef-float)
  - `<type()>` for [`@function`](https://drafts.csswg.org/css-mixins-1/#function-rule)

</details>

When `fn()` is defined `for` a specific context, this association is reproduced in `webref` data.

This unnecessarily complicates resolving its value definition, as it requires traversing contexts upwards, whereas it could be resolved from a global dictionary. The value definition of a context-sensitive function does not need to be resolved, as it is inlined in the value definition of this context.

### The solutions

To determine if the value definition of a function defined `for` a context is actually sensitive to it, one must determine if it is referenced somewhere as a production, or if its value definition is inlined in the context value definition, which is non-trivial.

<details>
<summary>I would be happy to submit a PR for the above functions, either to remove the associated context or to inline the value definition, as appropriate.</summary>
<br>

I think the context association should be removed for most of them.

`type()` is associated to `@function` and `attr()` with `<syntax>` as its argument value definition, and to `<image-set-option>` with `<string>`. So I would inline its value definition in [`<css-type>`](https://drafts.csswg.org/css-mixins-1/#typedef-css-type).

`rect()` is associated to `<basic-shape>` and `clip`, which is deprecated, so I would inline it in the value definition of `clip`, as suggested in https://github.com/w3c/fxtf-drafts/pull/468#issuecomment-1746066272.

Perhaps `fade()` could be used in other contexts with another value definition, I do not know.

</details>

But I am not sure that is the best solution?

`<fn()>` cannot be used (in `<dfn>`) to define a function, but it can be used in `<fn()> = fn(foo)` and reference a function defined with `fn()`: I do not understand the reasoning behind this restriction. A function defined with a production name would be guaranteed to be context-insensitive.

But it also seems to me that `<foo()>` could both imply a *context-insensitive* value definition and a *context-sensitive* post-parse interpretation.

It also seems worth noting that the number of CSS functions that actually have more than one context-sensitive value definition is very small.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13340 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 13 January 2026 13:41:47 UTC