CSS class validation too strict

+++ b/core/modules/views/src/Plugin/views/display/DisplayPluginBase.php
@@ -1886,7 +1886,7 @@ public function validateOptionsForm(&$form, FormStateInterface $form_state) {
+        if (preg_match('/[^a-zA-Z0-9-_: ]/', $css_class)) {
           $form_state->setError($form['css_class'], $this->t('CSS classes must be alphanumeric or dashes only.'));

I guess we would need to update the error message then?

But if I'm reading #3050007: CSS identifiers created via `Html::cleanCssIdentifier` shouldn't strip colons correctly, the regex would actually need to become more complex to properly validate this

Taking a stab at getting the regex right.

The regex in #2916377: Html::cleanCssIdentifier Strips Valid Escaped Characters is probably the best to copy.

This takes the regex from #2916377-27: Html::cleanCssIdentifier Strips Valid Escaped Characters and adds the space character. I'm now able to save Tailwind classes for my View.

+++ b/core/modules/views/src/Plugin/views/display/DisplayPluginBase.php
@@ -1886,8 +1886,8 @@ public function validateOptionsForm(&$form, FormStateInterface $form_state) {
+          $form_state->setError($form['css_class'], $this->t('CSS classes must contain valid characters.'));

Can we do an error message that might be a little bit more helpful for users that might not be aware what the 'valid characters' are? Can we point at some documentation somewhere? Or maybe rephrase as 'This value contains characters that are not valid in CSS classes.', might be a little clearer? I don't know.

And still needs a test of course.

Applied patch #7 on 9.2.x and it works fine.Adding screenshots below

Before patch:

After patch:

@mglaman, I just applied #7 on. 9.2.x-dev , but the patch is not doing what is intended here , please review my findings :

The intention of the patch is to allow classes like e.g "sm:text-center md:flex-shrink-0", but after applying the path the classes are getting saved but not coming to html as it is.
Screenshot after applying #7 :

• md:inline-flex is converted to flex md-inline-flex mdinline-flex

I tried to do some changes to the code , and after that the classes are coming as it is.
Screenshot after applying #10:

Adding the test for valid css classes. And made some changes based on #8 comments.

Please review.
Thanks!.

Fixing Cspell issues for comments in #10.

Verified and tested patch#11 for drupal 9.3.x-dev version. Patch applied successfully and looks good to me.Adding screenshot for the reference.thanks @vakulrai .

Rerolled for 9.4.x

Fixing the test case failure issue in #17, please review it.

please ignore this

Just to say I have the same issue but for exclamation marks !

I can happily open up a separate ticket but this seems generally seems to be covered by this ticket too. My motivation is the GovUK Design Guide, exclamation marks seem perfectly legitimate - https://design-system.service.gov.uk/styles/spacing/#overriding-spacing

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

The code seems updated in drupal core 9.5.2 so the patch no longer applies, but css classes like lg:grid-cols-4 are still being rejected when trying to save classes for a view.

"CSS classes must be alphanumeric or dashes only."

Here is a new patch, working with 9.5.3

The current patch still is an arbitrary Drupalism, e.g. it still does not allow ampersand or square brackets (which are used in TailwindCSS for inline selectors like [&_.my-child-container:text-red]).

The CSS class validator should follow official specs, not outdated shortcuts. Given the spec allows basically every symbol to be used as class name, maintaining an self-invented allow list is IMHO conceptionally flawed.

Also inadequate encoding (like e.g. the HTML ampersand or larger-than encoding from [&>.some-div:text-red] to <div class="[&amp;&lt;.some-div:text-red]"> must be avoided: Those symbols are valid symbols inside HTML class names, encoding them to an HTML entity results in an incorrect class name. (And CSS itself does backslash prefixed hex encoding when it needs encoding, but encoding inside CSS files follows different rules than encoding CSS class names inside HTML)

Here is a good link demonstrating unescaped symbols in HTML class names and their represenation inside CSS:

https://mothereff.in/css-escapes

Rerolled against 11.x in the MR.

This is the patch that I'm using, it inherits from #27 , I just updated the regex as
/[^\x{0026}\x{002D}\x{002E}\x{002F}\x{003A}\x{0030}-\x{005A}\x{005F}\x{005B}\x{005D}\x{0061}-\x{007A}\x{00A1}-\x{FFFF}]/u

So I allow these characters
{0026} &
{002D} -
{002E} .
{002F} /
{003A} :
{005F} _
{005B} [
{005D} ]
numbers
letters A-Z a-z

The parts of views.theme.inc that are being modified by the patch were changed by #2977950: Move the bc layer for views UI CSS classes from views to stable9 to remove the @todo. This needs to be rebased.

Although a test was added, the issue has expanded since then. Therefore, the test needs to be expanded to cover the additional special characters too.

Also, the issue summary needs to be updated with info about the additional special characters.

This patch created from Drupal 11.4.5 using the code from 318725-css_class_validation-3187258.patch. Tests are not included.