[csswg-drafts] [css-color-4] Allow invalid `color()` with value definitions (#7136)

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

== [css-color-4] Allow invalid `color()` with value definitions ==
A `<color()>` specified with an unrecognized color space identifier is defined as an [*invalid color*](https://drafts.csswg.org/css-color-4/#invalid-color) that should resolve to opaque black when it is serialized as a component of a used value. And `<color()>` must *forgive* fewer/more arguments than allowed by its value definitions (3), replacing missing arguments by `0` and ignoring extra arguments. 

From a point of view strictly limited to value definitions, eg. `color(unrecognized 0 0 0)` or `color(srgb 1 2 3 4)` must be parse failures, but the grammar defines the above specific rules to replace some of the parse failures. I was wondering if the current value definitions could use some form of *forgiving* value definitions, eg.:

```
<colorspace-params> = [ <predefined-rgb-params> | <xyz-params> | [<ident> [<number> | <percentage> | none ]*]]
<predefined-rgb-params> = <predefined-rgb> [ <number> | <percentage> | none ]*
<xyz-params> = <xyz-space> [ <number> | none ]*
```

Side note: it is defined that `<color()>` must have *one or more `<number>`s or `<percentage>`s providing the parameter values* but I do not see a valid reason to use `{1,}` instead of `*` (zero or more), even if an input like `color(srgb)` would obviously make no sense.

Media Queries use [`<general-enclosed>`](https://drafts.csswg.org/mediaqueries-5/#typedef-general-enclosed) *to allow for future expansion of the grammar in a reasonably compatible way*, as well as Selectors with the value definition of a [functional pseudo class](https://drafts.csswg.org/selectors-4/#typedef-pseudo-class-selector).

I'm asking/suggesting for two reasons:

1. afaik, this is the only CSS type whose grammar *forgives* an input that is not matching the value definition, without using [*parse a comma-separated list acccording to a CSS grammar* from Syntax](https://drafts.csswg.org/css-syntax-3/#parse-comma-list), or using a value definition like the one described above, or a value definition written in prose like the [functional notation of `<url()>`](https://drafts.csswg.org/css-values-4/#functional-notation)
2. from the point of view of an author of a CSS parser implementation, "hooking" the parser to invalidate inputs that was valid according to a specific value definitions, makes more sense than hooking to forgive inputs that are invalid according to this value definition

I searched on Github for related discussions, but there are many issues labelled with `css-color-4` and none were relevants with terms like `invalid` or `color()`. I would be pleased to get a link to those discussions, if any.

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


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

Received on Saturday, 12 March 2022 05:33:52 UTC