Re: [csswg-drafts] [css-conditional-5] Fix autolinks to `<supports-env-fn>` (#13735)

> The goal here was to (eventually) have `css-env-1` point to the `env()` from this spec for feature detection. I am not 100% familiar with all the details of Bikeshed, but won’t this proposed change prevent that from being possible?

Creating a function definition for `env()` scoped to `@supports` so that it can be pointed to by `css-env-1` is doable. Now, you cannot have a single definition for the type definition *and* the function definition as that confuses tools, including Bikeshed. For example, the link to `<supports-env-fn>` in the syntax of [`<supports-feature>`](https://drafts.csswg.org/css-conditional-5/#typedef-supports-feature) is currently broken, because Bikeshed is looking for a type and can no longer find it. Same thing for the missing link below the syntax that describes `<supports-env-fn>`.

This PR fixes the problem by getting back to a proper type definition (and then you may add a scoped function definition as needed). Alternatively, you could drop the type definition altogether and only have a scoped function definition, through:

```
<dfn>&lt;supports-feature></dfn> = ... | <<@supports/env()>> | ...
<dfn for="@supports">env()</dfn> = env( <<ident>> )
```

Happy to update this PR to do that. Feel free to also close the PR and do things differently, the PR is just meant to be a heads-up that there are broken links along with a possible solution to fix them ;)

-- 
GitHub Notification of comment by tidoust
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/13735#issuecomment-4143105433 using your GitHub account


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

Received on Friday, 27 March 2026 14:40:45 UTC