Add an issue template to suggest CSS syntax patches (#1760)

Goal is to have a formatted structure to gather the information we need. That
structure could perhaps be leveraged later on to automate the creation of a
pull request afterwards (as done for specs in browser-specs).

Author: tidoust

.github/ISSUE_TEMPLATE/css-syntax-patch.yml

@@ -0,0 +1,48 @@
+name: CSS syntax patch
+description: Use this template to suggest a correction to the syntax of a CSS construct
+labels: ["css extracts", "patch"]
+title: "Add CSS syntax patch for: `@@`"
+body:
+  - type: markdown
+    attributes:
+      value: |
+        > [!Important]
+        Please replace `@@` in the title with the name of the CSS at-rule, property, selector, function, type or descriptor to patch. The name should typically appear in a CSS extract in [`ed/css`](https://github.com/w3c/webref/tree/main/ed/css).
+        Function names should end with `()`. Types should be enclosed in `<>`. You may provide additional context if there's some ambiguity, using a `/`-based path.
+        For example: `rgb()`, `<palette-identifier>`, `stop-color`, or `@page/page/<page-size>`
+
+  - type: input
+    id: url
+    attributes:
+      label: Link to the definition in the spec
+      description: |
+        Where is the CSS construct and its syntax defined?
+        This URL should be a link to the relevant version of the spec and include a fragment.
+        For example: `https://drafts.csswg.org/css-fonts-4/#typedef-font-palette-palette-identifier`
+      value: "https://"
+    validations:
+      required: true
+
+  - type: textarea
+    id: syntax
+    attributes:
+      label: Syntax of the CSS construct
+      description: |
+        What should the syntax this CSS construct be?
+        Leave the field blank if you're not sure.
+        Note Webref captures what specs define. The syntax should not contain historical tokens that are no longer in the spec or proprietary extensions.
+      render: code
+    validations:
+      required: false
+
+  - type: textarea
+    id: notes
+    attributes:
+      label: Notes
+      description: |
+        Anything else we should know about the construct and syntax?
+        For example, did it exist in [`mdn/data`](https://github.com/mdn/data) or some other source?
+        Would it be worth making the syntax more explicit in the spec?
+        Is the syntax defined in one spec and extended elsewhere?
+    validations:
+      required: false

ed/csspatches/README.md

@@ -2,7 +2,7 @@
 
 The folder contains two types of patches applied to the CSS extracts scraped from specs during curation to produce the `@webref/css` package:
 
-- The [`syntax-patches.js`](./syntax-patches.js) file contains a list of syntaxes for situations where that syntax cannot be automatically extracted from the underlying spec because it is defined in non-machine-readable prose. These patches are usually permanent in that they cover situations where it is unlikely that the underlying spec will be updated to make the syntax more explicit.
+- The [`syntax-patches.js`](./syntax-patches.js) file contains a list of syntaxes for situations where that syntax cannot be automatically extracted from the underlying spec because it is defined in non-machine-readable prose. These patches are usually permanent in that they cover situations where it is unlikely that the underlying spec will be updated to make the syntax more explicit. To propose a new syntax patch, please use the [dedicated issue template](https://github.com/w3c/webref/issues/new?template=css-syntax-patch.yml).
 - The `*.json.patch` files contains extract file patches applied to CSS extracts. These patches are intended to be temporary while the spec gets fixed, and are typically associated with an issue or pull request raised against the underlying spec. These patches typically break as specs get updated. For details on how to create and update file patches, please see the [Web IDL patches documentation](../idlpatches/README.md).
 
 On top of these patches, note that curation also drops duplicate definitions through the [`tools/drop-css-property-duplicates.js`](../../tools/drop-css-property-duplicates.js) script which handles situations where definitions in one spec override definitions in another spec (for example, definitions in CSS modules overrride definitions in CSS 2).