to the best of my knowledge the use special characters like !, @, #, $, %, is not allowed in css class names

https://www.w3.org/TR/CSS2/syndata.html#:~:text=In%20CSS%2C%20identifiers%20(including%20element,hyphen%20followed%20by%20a%20digit.

In CSS, identifiers (including element names, classes, and IDs in selectors) can contain only the characters [a-zA-Z0-9] and ISO 10646 characters U+00A0 and higher, plus the hyphen (-) and the underscore (_); they cannot start with a digit, two hyphens, or a hyphen followed by a digit.

This therefore excludes the @ U+0040

That's true for CSS 2 selectors, however if I read the CSS 3 grammer defintion correctly, CSS3 includes a wider range of unicode characters including the @

https://www.w3.org/TR/selectors-3/#grammar

That grammar is very hard to read. I relied on the w3c css tester and it says no

In the CSS file you'll have to escape the @ sign using a backslash:

.uk-hidden\@m {color:blue}

I have tested this item ✅ successfully on 4c51aef

I guess these need updating as well

This will only work as you expect if all fields that ask for a class have validate="CssIdentifier"

scrub that - I guess if they dont have that validation rule at all then this PR makes no difference to that field

My 2c is that this is a bad idea. Allowing a user to add a class in html that they cant use in css without undocumented modification just opens up unnecessary issues

Allowing a user to add a class in html that they cant use in css without undocumented modification just opens up unnecessary issues

On top of that @ is reserved for the @{ident} return ATKEYWORD; ATRULE (eg @media, @container, @Style, etc) which is a special function. Allowing escaped @ inside a class feels like allowing $ inside a PHP variable, which might be fine but common sense probably repels people from these scenarios...

The @ is a reserved sign in CSS, not in HTML attributes - and that's the usecase that we are talking about here.

HTML attributes should allow @ either for the name of the attribute (eg frameworks use @click to shortcut onclick) or for the value. Sorry for the noise

Let’s hope that the email cloaking plugin will not cloak such markup ?

OK So David's right if you add the escape into the CSS (as UIKit does) then it validates as HTML and doesn't directly defy the CSS 3 spec as I read it. I don't love it. But it's nominally valid syntax and used by a major template club. So I think we should just merge it.

Has somebody verified that the email cloak plugin will not cloak markup like e.g.
<span class="something@somewhere.com">bla</span>
?

Has somebody verified that the email cloak plugin will not cloak markup like e.g. <span class="something@somewhere.com">bla</span> ?

Still works - outputs the same