addClassString conflicts with Tailwind class naming

[Lazerproof]

Short description of the issue

Hi @ryancramerdesign
In this commit, you have introduced the addClassString method which is an overall cool thing. It looks like the initial intention of this method is to add easier customization of forms output on the front end, but it's not possible to use it with Tailwind responsive classes that are using a colon in responsive classes like p-0 md:p-2 lg:p-4. So while it's on the dev branch it would be great to get resolved this issue.

Expected behavior

$inputfield->addClass('bg-red-yellow lg:bg-red-400');

This code should add two classes bg-red-yellow and lg:bg-red-400

Actual behavior

$inputfield->addClass('bg-yellow lg:bg-red-400');

This code adds one class bg-red-yellow

Setup/Environment

• ProcessWire version: 3.0.206

[ivangretsky]

Tailwind is a popular thing right now. I am starting to use it some of my projects, Will need this to customize e.g. Form Builder forms.

[ryancramerdesign]

@Lazerproof The ":" is how you specify what property group the class belongs to with Inputfields, as each Inputfield has several elements that support classes. So if you wanted the class to be part of the wrapping element, you'd do "wrap:myclass" or if you wanted it to be part of the header, you'd do "header:myclass", and so on. However, you can bypass that just by setting the class attribute directly. So for your case you'd want to do this:

$inputfield->class = trim("$inputfield->class bg-red-yellow lg:bg-red-400"); 

or this:

$inputfield->class .= " bg-red-yellow lg:bg-red-400";

To target different elements in the Inputfield, you could use wrapClass, headerClass, contentClass, etc., instead of "class".

[Lazerproof]

Hi @ryancramerdesign You are right, that we have options on how to add Tailwind classes with a colon symbol from the code, but it is still not possible to add them through the 'Custom class attributes field in admin or I'm missing something?

[ivangretsky]

Maybe pipe separator could be a better option? Like wrap|bg-red-yellow lg:bg-red-400
Or the ability to wrap classes in parenthesis? Like wrap:"bg-red-yellow lg:bg-red-400"

[ryancramerdesign]

@Lazerproof @ivangretsky I have updated it so that it will support these Tailwind style classes by assuming the a:b string is indicating an element target with a only if it is one of: wrap, header, content, input, class. Otherwise it'll add it as a class named a:b with the colon in it. Does this provide what you need? Or do any of those keywords (wrap, header, etc.) overlap with Tailwind class names?

[ivangretsky]

This would probably solve 99% of possible problems as mentioned words do not seem to conflict with any of modifier classes here provided out-of-the-box. But in rare cases when someone adds their own custom modifier it could still lead to hard to debug problems. I do not know how should we take this into account? @Lazerproof do you have something to say on this?

[Lazerproof]

@ryancramerdesign Thanks for resolving the issue, but as Ivan said there is still a chance that 'reserved' words could potentially be used as part of the TW class names. Maybe we could have something like !input:bg-red-500 that will treat input not as an input element, but as a class name?

[teppokoivula]

Syntax mentioned above (!input:bg-red-500) is not currently used by Tailwind specifically, but technically it could also become an issue. For an example Tailwind already has the important modifier (!bg-red-500), and there's no guarantee that this won't clash with something else now or in the future.

Just an alternative approach:

CSS spec states that "[k]eywords and property names beginning with -' or '_' are reserved for vendor-specific extensions." Sounds to me like this could be a good alternative: prefix custom modifiers with something like -pw-wrap:. Or whatever modifier makes sense in this context.

Assuming, of course, that Ryan is still open to tweaking things and we don't need to consider things set in stone since some users may be using these :)

[Lazerproof]

@ryancramerdesign I've updated to the 3.0.209 version to test how it works and I assume that I got an infinity loop between these lines 1085 and 1183 with input:lg:bg-red-500 as test string.

@teppokoivula You are right about the important modifier and currently, we have heavy use of it. In the case of a class with an important modifier it could be !!input:bg-red-500 so the first exclamation mark will be trimmed the same as the + and - signs.

[ryancramerdesign]

@ivangretsky @Lazerproof @teppokoivula I don't think that any special modifiers are necessary for that case. If you wanted to add a custom class such as a literal input:bg-red-500 then you can just include the element that you want to add the class for, i.e. input:input:bg-red-500 which adds class input:bg-red-500 to the <input> element. Or if you wanted to add it to the wrapping .Inputfield element then wrap:input:bg-red-500. Just tried that and it works here. Though @Lazerproof identified a different issue (directly above this message) which was preventing any of it from working correctly, so I'm pushing a fix for that now.

[matjazpotocnik]

@Lazerproof, are you ok with the latest update from Ryan?

[matjazpotocnik]

@Lazerproof Ok, I'll close this issue, let me know if you need it re-opening.