Many template parameters have values that are acceptable and not acceptable. I suggest adding a new supported parameter type:
"csscolor": {
...
"description": "Any CSS color specification",
"type": "regex",
"regex": "^#[0-9A-F][0-9A-F][0-9A-F][0-9A-F][0-9A-F][0-9A-F]$"
}Note that this shouldn't be enforced, just documented.
We already have types for number, date, and url (which are sometimes validated in Lua modules using a regex).
T53375 (approved) will provide a way to provide a list of allowed exact values.
I don't think we should implement regex as an actual type since this cannot provide a positive user experience.
While regex patterns make it easy to programmatically determine whether given value is valid or not; it does not allow for an input method that naturally prevents invalid values. E.g. how to you succinctly explain a user hex color codes? How would they translate their desired color to hex? How would they verify that they got it right?
For now I recommend using basic "string" type and use the "description", "default" or "example" fields to describe the desired format.
The other side of the spectrum is a dedicated type. I can see us having a dedicated type for color. This would allow for a visual color picker, for example.
The regex should be used with the description, not instead of it. If the value is well-describable both for humans and with regex, it's worth using both. The description tells the user what to write, and the regex notifies them if there's some error because of misunderstanding (in which case we let them know, and probably they will understand correctly for the second time), or simply because of a typo or copy-pasting some malformed text.
Example: I documented a coordinate template. The arcsecond parameter can be easily described for humans (decimal number not lower than 0 and lower than 60), and also by using regex ([0-5]?[0-9](\.[0-9]+)?). So if the input is malformed (uses decimal comma instead of decimal point, uses non-ASCII number characters etc.), the user can be notified by giving the input field a red border (OOjs UI, which is used in VisualEditor, supports regex field validation). If the user is unsure what's wrong, they can look at the field description, or, if they really don't understand, ask on the template talk page. As there's no validation currently (decimal numbers don't fit in any existing dedicated type), this error simply doesn't get noticed, and either breaks the output, or needs various hacks in the template to get normalized.