Invalid per the CSS spec is pretty self explanatory. There is a common CSS spec used by the JS engine and web browser. When the class used does not comply to that defined standard, the class is invalid.
You can see this when trying to trying to use querySelector with responsive:property-[arbitrary] classes (I think, or it might be a different pattern of which I'd have to go back and check) and other cases where the JS engine will throw an error for trying to use a class Tailwind encourages you to write.
No. As of 2022[1], the CSS spec defines a class-name (in a .css rule's selector) as "." + ident, and the lexical scanner rules for ident specifially allow any character outside of 0x00-0x7F in a class name after an initial [_A-Za-z] character.
> Invalid per the CSS spec is pretty self explanatory.
It is, but in the same way “I received an error” is not an incorrect error report it just lacks specificity.
I think what CSSer was asking (though the question itself was not worded as precisely as it could be) is: can you give examples of the invalid identifiers that it encourages?
Perhaps because that would be wasteful if what you want to select already has a class that identifies all the elements you want and only the elements you want? Adding an extra class for your JS might mean adding it in several places around your work too, not just in a single template. Why define .things-to-select-when-I-look-for-red-things when .red-things already exists and could do the job?
There is also the matter of separation of concerns, not wanting to add classes specifically for particular bits of code where possible to avoid it, but given the sea of classes generated by frameworks these days I'm not sure that is an ideal which is much followed ATM.
It’s a fair thought, and it’s interesting you mention that. I do think of it as separating concerns. I think of CSS for styles and JS for dynamism that can’t be achieved out of the box. Classes are only attributes, after all. Hypothetically, if you remove the JS-dependent class it doesn’t break any styles (unless of course, you’re using JS to apply styles, which is another conversation). That being said, if someone still felt strongly I’d concede this is subjective and only relevant to developer experience.
I think you touched on an objective subject, however, if you were alluding to performance. Classes are generally free and cheap. I’d be very interested in evidence to the contrary if anyone could share.
My last, somewhat random, thought is that it does indeed seem that who likes TW and who doesn’t does seem to depend a lot on the stack they’re thinking of when they mull over its (de)merits.
It isn't as much about performance (the small amount of extra network transfer is likely to be brought close to zero if compression is used, the extra CPU load might be measurable on low-spec devices but on top of all the junk already in sites using heavy frameworks this is not going to make/break anything) as maintainability. You have something extra to make sure is set everywhere it needs to be.