@AtmoFX I can't reproduce it

The "issue" here maybe is because the input/money component won't place class where you expect because of daisyUI "label + input" structure. Just use disabled or readonly without any extra classes and you are good to go.

Hey @robsontenorio,

I would like to double down on my analysis though.
If by "the input/money component won't place class where you expect", you mean that the class won't be applied where I want it to, then you are right.

TBH, I don't even see an attempt at reproducing the issues from the PR in your screenshot, since you have not copied my code nor tried to add any class to the inputs you copied from your help page.

Maybe you could try to do that and let me know?
Just to be sure, I don't see a .\!border-solid class inside the stylesheet of https://mary-ui.com/ (the other classes may be missing too), so you'll need to rebuild it for that example.

If you prefer going through the long technical explanation, here it is:

With the snippet you posted, most likely, only 1 of the issues I mentioned will be visible and it won't be so obvious if you don't know what to look for. To see it:

1. Take the disabled money field; change nothing in its code:
   <x-input label="Default money" disabled wire:model="money1" prefix="USD" money />
2. Open the page where you inserted it.
3. Move the cursor over the field slowly. This is what you should see:
   

From what I see disabled is added in 2 places in the rendered HTML and when I edit your own help page to add them in the same place, then I can at least reproduce that with no other alteration (i.e. your site's stylesheet, as it is now, should show you this issue).

What the switch between the default cursor and the forbidden cursor reveals is that the actual input field lies strictly inside the "visual" input field, with margins or padding on all 4 sides: i.e. the screen area covered by the input does not match what the user will interpret as the input.

Now, let us get into the analysis of what is going on. The easiest way to understand is most likely to add a fake CSS class and see where it lands inside the rendered HTML:

<x-input class="where_will_this_appear" label="Default money" wire:model="money1" prefix="USD" money />

becomes (after removing the extra line breaks and <!--[if BLOCK]><![endif]--> comments):

<div>
    <fieldset class="fieldset py-0">
        <legend class="fieldset-legend mb-0.5">
            Default money
        </legend>
        <label class="">
            <div class="w-full">
                <label class="input w-full where_will_this_appear">
                    <span class="label">USD</span>
                            <div class="w-full" x-data="{ amount: $wire.get('money1') }" x-init="$nextTick(() => new Currency($refs.myInput, {&quot;init&quot;:true,&quot;maskOpts&quot;:{&quot;locales&quot;:&quot;en-US&quot;}}))">
                        <input id="maryc7113191edc0aedd815586b97d162450money1" placeholder=" " x-ref="myInput" :value="amount" x-on:input="$nextTick(() => $wire.set('money1', Currency.getUnmasked(), false))" x-on:blur="$nextTick(() => $wire.set('money1', Currency.getUnmasked(), false))" inputmode="numeric" type="text" class="where_will_this_appear">
                    <input type="hidden" wire:model="money1">
                        </div>
                </label>
            </div>
        </label>
    </fieldset>
</div>

The where_will_this_appear appears in the inner <label> as well as in the <input> (scroll all the way to the right).

Armed with the above knowledge, we can infer there will be 2 types of CSS properties in the context of elements that occupy different areas on screen:

• Properties for which children of an element are "contained" into their parent:
  For example, as long as the <input> and its ancestor <label> have e.g. the same background color, nothing will look wrong.
  However, if the <input> and its ancestor have different values for e.g. the cursor, it will certainly look wrong like the above capture from my computer (though less obvious in the case of the cursor).
• Properties for which children of an element may appear distinct from their parent:
  For example, unless forced, there is no guarantee the border of an element will overlap with the border of its parent (or higher-degree ancestor).
  We do not want the values of those properties to be the same for the <input> and its ancestor <label> because something will look wrong if they do.
  And indeed, if no class (default) is added to the x-input, then the <input> will show no border while the inner <label> will show one (+ no ancestor of the <input> other than the inner <label> have a border).

There is also the case of properties that do not matter here, such as text color or font size: since the inner <label> contains no text of its own, there will never be a visual discrepancy.

I am still figuring out how we can address this case, as it is really challenging to cover all the edge cases with customizations.

Yes, you'd need to be more specific if you need my help for that but I know what you mean. It's the same for me with #901.
I would not be surprised whatever you decide will have impact on that issue BTW, so let me know and I'll see how to address that in a similar way as you.

@robsontenorio

If you confirm you dislike my way of keeping the class merge only for the inner label, removing it for the input, maybe the solution would be to apply the same logic here as for the header component.
What I mean is that header supports separate class and icon-classes; how about changing the input to have class and input-class/input-classes?

Additionally and independently from the above, do you think it would be possible to customize the way tailwind classes are merged together? What is done right now would remain as the default but we could for instance set another one in config/mary.php.
Exaxmple of a candidate to override the default merging: gehrisandro/tailwind-merge-php (though apparently not compatible with Tailwind 4 but you get the idea).
That way, all the cases where I had to use !important classes in my code would become regular classes.

The downside to that approach is of course that every component needs to be changed accordingly. Likely not a small endeavour.