I was working on a form in a project using Mary UI, and one of the fields needed to be readonly. As soon as I added the attribute, the input's border changed from solid to dashed.
That's not a bug. It's a deliberate choice in Mary UI, and every form component in the library gets the same treatment when it's readonly.
I get the appeal. The text stays at full contrast, so it's easier to read than the washed-out gray treatment most apps give non-editable fields. If the whole point of a readonly field is showing the user a value, readability matters.
But does a dashed border actually say "you can't edit this" to a user? Users have decades of training that a grayed-out field means it's readonly, whereas a dashed border doesn't carry that meaning.
In plenty of interfaces it marks a drop zone or a spot to add something, which is almost the opposite message. A user might click into the field, try to type, and wonder why nothing happened.
In our case, we decided to keep the convention users already know.
All it took was a few lines of CSS in our app.css file.
input[readonly] {
border-style: solid !important;
@apply bg-base-200/50;
}
This puts the solid border back and adds a subtle gray background.
And since this file is processed by Tailwind, we can use @apply with one of the theme's own color tokens, keeping everything consistent.
I'm not saying Mary UI got it wrong. The maintainers made a reasonable trade-off in favor of readability, and for many apps it works fine.
This is just one specific example for one specific UI toolkit. The main point of this tip is that it's worth asking whether a UI toolkit's default works for your users, or whether you'd rather keep the convention they already understand.
Adopting a UI toolkit's design system doesn't mean you stop making design decisions. The defaults are a starting point someone else picked for their context. Keep the ones that serve your users, and change the ones that don't.
Here to help,
Joel
P.S. Judgment calls like this are easier with a second opinion. In our community, you can ask a question like this and hear how other Laravel devs would handle it.
