[DX] Form API: Provide a `'type' => 'css_classes'` form element.

[klonos]

This was brought up in #3608

@klonos

In general, these use cases is why I would like us to have a dedicated css_classes field introduced in the Form API. It should have a default description, so that we don't have to be re-inventing things each time we add such a field + this would allow consistency for this description throughout the UI (unless we need to specifically override it in certain cases) + would also allow translating the description only once (instead of having separate translations for each "mutation"). Not to mention validation and things like using underscores vs dashes (#3365 / #3428 / backdrop_clean_css_identifier()).

@jenlampton

Is there an issue for this yet? I like the special validation we'd get, and consistent description text.

The following should be considered when validating CSS IDs/classes:

• Must begin with a letter, and may be followed by any number of letters or digits.
• Only hyphens, underscores, colons, and periods are allowed.
• Cannot start with a digit, two hyphens, or a hyphen followed by a digit.

Even though HTML5 is quite happy for an ID to start with a number, CSS simply doesn’t allow selectors to begin with a number.

...specifically, https://www.w3.org/TR/2003/WD-css3-syntax-20030813/#characters

In CSS3, identifiers (including element names, classes, and IDs in selectors (see [SELECT] [or is this still true])) can contain only the characters [A-Za-z0-9] and ISO 10646 characters 161 and higher, plus the hyphen (-) and the underscore (_); they cannot start with a digit or a hyphen followed by a digit. They can also contain escaped characters and any ISO 10646 character as a numeric code (see next item). For instance, the identifier "B&W?" may be written as "B\&W\?" or "B\26 W\3F". (See [UNICODE310] and [ISO10646].)

[klonos]

...while working on #4052 I tried adding some help/description text and ended up with this:

That is too much help text, but from a UX perspective, I would prefer this, rather than submitting the form and getting validation errors after the fact. #3707 and/or #1414 could help with this.

[olafgrabienski]

That is too much help text, but from a UX perspective, I would prefer this, rather than submitting the form and getting validation errors after the fact.

That's indeed very much text. I'd say, most people know what they do in such a dialog. My suggestion: let's provide less (and friendly) description text and add the details if validation fails.