The syntax for `stroke-dasharray` in the webref/css package does not match the syntax in the specification

[stof]

This package defines the syntax for stroke-dasharray as none | [<length-percentage> | <number>]+#. The spec at https://drafts.fxtf.org/fill-stroke-3/#propdef-stroke-dasharray defines it as none | <length-percentage>+#.

Full definition of the property in the fill-stroke.json file

    {
      "name": "stroke-dasharray",
      "href": "https://drafts.fxtf.org/fill-stroke-3/#propdef-stroke-dasharray",
      "value": "none | [<length-percentage> | <number>]+#",
      "initial": "none",
      "appliesTo": "text and SVG shapes",
      "inherited": "yes",
      "percentages": "relative to the scaled viewport size",
      "computedValue": "as specified",
      "canonicalOrder": "per grammar",
      "animationType": "repeatable list",
      "media": "visual",
      "values": [
        {
          "name": "none",
          "prose": "No dashing: the stroke is drawn continuously.",
          "href": "https://drafts.fxtf.org/fill-stroke-3/#valdef-stroke-dasharray-none",
          "type": "value",
          "value": "none"
        },
        {
          "name": "<length-percentage>+#",
          "prose": "Specifies a dashing pattern to use. Each <length-percentage> value represents the length of the next dash or gap (beginning with the first dash and alternating from there) of the stroke. The pattern repeats over the length of the stroke. (If the number of values is odd, the pattern behaves as if it was duplicated to yield an even number of values.) The dashing pattern is reset and begins anew at the start of each subpath. Negative values are invalid. If all values are zero, it is treated as none.",
          "href": "https://drafts.fxtf.org/fill-stroke-3/#valdef-stroke-dasharray-length-percentage",
          "type": "value",
          "value": "<length-percentage>+#"
        }
      ],
      "styleDeclaration": [
        "stroke-dasharray",
        "strokeDasharray"
      ]
    }

[dontcallmedom]

see https://github.com/w3c/csswg-drafts/issues/3057 as to why we patched the spec extract

[stof]

Hmm, looks like there was a resolution in 2018 but the spec still does not reflect it 😢

And support for <number> in browsers is not fully interoperable. Firefox supports numbers as a parser quirks, not as a fully supported type, so it does not work with calc() returning a number: https://bugzilla.mozilla.org/show_bug.cgi?id=1679465

[dontcallmedom]

I think both the lack of spec progress and the interoperability risk are worth bringing up in https://github.com/w3c/csswg-drafts/issues/3057 if you'd be so inclined