Open mplatts opened 2 years ago
One example where the approach above wouldn't work (from https://tailwindcss.com/docs/reusing-styles):
<div>
<div class="flex items-center space-x-2 text-base">
<h4 class="font-semibold text-slate-900">Contributors</h4>
<span class="rounded-full bg-slate-100 px-2 py-1 text-xs font-semibold text-slate-700">204</span>
</div>
<div class="mt-3 flex -space-x-2 overflow-hidden">
<img class="inline-block h-12 w-12 rounded-full ring-2 ring-white" src="https://images.unsplash.com/photo-1491528323818-fdd1faba62cc?ixlib=rb-1.2.1&ixid=eyJhcHBfaWQiOjEyMDd9&auto=format&fit=facearea&facepad=2&w=256&h=256&q=80" alt=""/>
<img class="inline-block h-12 w-12 rounded-full ring-2 ring-white" src="https://images.unsplash.com/photo-1550525811-e5869dd03032?ixlib=rb-1.2.1&auto=format&fit=facearea&facepad=2&w=256&h=256&q=80" alt=""/>
<img class="inline-block h-12 w-12 rounded-full ring-2 ring-white" src="https://images.unsplash.com/photo-1500648767791-00dcc994a43e?ixlib=rb-1.2.1&ixid=eyJhcHBfaWQiOjEyMDd9&auto=format&fit=facearea&facepad=2.25&w=256&h=256&q=80" alt=""/>
<img class="inline-block h-12 w-12 rounded-full ring-2 ring-white" src="https://images.unsplash.com/photo-1472099645785-5658abf4ff4e?ixlib=rb-1.2.1&ixid=eyJhcHBfaWQiOjEyMDd9&auto=format&fit=facearea&facepad=2&w=256&h=256&q=80" alt=""/>
<img class="inline-block h-12 w-12 rounded-full ring-2 ring-white" src="https://images.unsplash.com/photo-1517365830460-955ce3ccd263?ixlib=rb-1.2.1&ixid=eyJhcHBfaWQiOjEyMDd9&auto=format&fit=facearea&facepad=2&w=256&h=256&q=80" alt=""/>
</div>
<div class="mt-3 text-sm font-medium">
<a href="#" class="text-blue-500">+ 198 others</a>
</div>
</div>
ring-2
and ring-white
would override each other.
This could be a good starting point: https://github.com/dcastil/tailwind-merge
I quickly tested the merging of ring-2
and ring-white
and they seem to handle it correctly.
what about taking dasiyui approach i know maybe it is a lot work but writing one class instead of write huge chunks of classes could help to avoid this problem not just that it helps maintain you will have just logic of build the component and one class
Yeah unfortunately that might too much work for a relatively small gain. I haven't had too much of a problem in my projects with overriding styles. Is there any obvious culprits we can try and do a small fix for? Guessing padding/margin/colors is the main thing people want to override?
Rules we should try and support (taken from the tailwind-merge project mentioned above)
twMerge('p-5 p-2 p-4') // → 'p-4'
twMerge('p-3 px-5') // → 'p-3 px-5'
twMerge('inset-x-4 right-4') // → 'inset-x-4 right-4'
twMerge('inset-x-px -inset-1') // → '-inset-1'
twMerge('bottom-auto inset-y-6') // → 'inset-y-6'
twMerge('inline block') // → 'block'
twMerge('p-2 hover:p-4') // → 'p-2 hover:p-4'
twMerge('hover:p-2 hover:p-4') // → 'hover:p-4'
twMerge('hover:focus:p-2 focus:hover:p-4') // → 'focus:hover:p-4'
twMerge('bg-black bg-[color:var(--mystery-var)]') // → 'bg-[color:var(--mystery-var)]'
twMerge('grid-cols-[1fr,auto] grid-cols-2') // → 'grid-cols-2'
twMerge('[mask-type:luminance] [mask-type:alpha]') // → '[mask-type:alpha]'
twMerge('[--scroll-offset:56px] lg:[--scroll-offset:44px]')
// → '[--scroll-offset:56px] lg:[--scroll-offset:44px]'
// Don't do this!
twMerge('[padding:1rem] p-8') // → '[padding:1rem] p-8'
Watch out for mixing arbitrary properties which could be expressed as Tailwind classes. tailwind-merge does not resolve conflicts between arbitrary properties and their matching Tailwind classes to keep the bundle size small.
twMerge('[&:nth-child(3)]:py-0 [&:nth-child(3)]:py-4') // → '[&:nth-child(3)]:py-4'
twMerge('dark:hover:[&:nth-child(3)]:py-0 hover:dark:[&:nth-child(3)]:py-4')
// → 'hover:dark:[&:nth-child(3)]:py-4'
// Don't do this!
twMerge('[&:focus]:ring focus:ring-4') // → '[&:focus]:ring focus:ring-4'
Similarly to arbitrary properties, tailwind-merge does not resolve conflicts between arbitrary variants and their matching predefined modifiers for bundle size reasons.
twMerge('!p-3 !p-4 p-5') // → '!p-4 p-5'
twMerge('!right-2 !-inset-x-1') // → '!-inset-x-1'
twMerge('p-5 p-2 my-non-tailwind-class p-4') // → 'my-non-tailwind-class p-4'
twMerge('text-red text-secret-sauce') // → 'text-secret-sauce'
undefined
, null
and false
valuestwMerge('some-class', undefined, null, false) // → 'some-class'
https://stitches.dev/ could also provide inspiration
How about doing something based on css variables instead of having an interface to manually pass classes? You could use this both for layout-technical customisations as well as aesthetics (colours and such). I'm not sure to want extent Tailwind can then still be used though...
Hmm yeah that might be too fine grained and moving away from the power of Tailwind. Actually thinking @mohammedzeglam-pg might be right in following a daisy approach. eg.
@layer components {
.btn {
@apply inline-block px-5 py-3 rounded-lg focus:outline-none focus:ring focus:ring-offset-2 uppercase tracking-wider font-semibold text-sm sm:text-base;
}
.btn-primary {
@apply bg-indigo-500 text-white hover:bg-indigo-400 focus:ring-indigo-500 focus:ring-opacity-50 active:bg-indigo-600;
}
.btn-secondary {
@apply bg-gray-300 text-gray-800 hover:bg-gray-200 focus:ring-gray-300 focus:ring-opacity-50 active:bg-gray-400;
}
}
Devs will pull in Petal Components CSS into their app.css
... and hopefully can override them if need be (yet to test this).
From this video it seems you can then add classes like px-10 inline and it will override what's in the @apply
collection.
https://www.youtube.com/watch?v=TrftauE2Vyk&ab_channel=TailwindLabs
This way you can do inline modifications, or if you want to drastically change a component for the whole application, you redefine the @apply
block for that component in your app.css
.
https://www.youtube.com/watch?v=TrftauE2Vyk&ab_channel=TailwindLabs
i think now before this major update maybe add this to default config in docs will be better solution than manual, and your idea it will be making petal component fit to any design could thing about it. i was thinking about file that just imported like tailwind to app.css. https://tailwindcss.com/docs/configuration#important
awesome job already done by @zachdaniel in his new project https://github.com/zachdaniel/tails
It's definitely not "done" but it's a work in progress :) contributions welcome!
It's definitely not "done" but it's a work in progress :) contributions welcome!
Nice! Seems like a great start and I think the majority of cases are just padding/margin/color merges.
I'd also eventually like to add stuff there to turn at least some of the simpler classes into in-line styles so that you can write an email template in tailwind. Not sure how well that will work, but would be pretty useful IMO.
My first naive approach would be something like this:
Since the class order is not important, we can split the classnames by whitespace and then put them into a map, identified by their class prefix (everything before the last
-
, e.g."p-5 place-items-start" => %{"p" => "p-5", "place-items" => "place-items-start"}
).Then we just merge the overrides map over the defaults map and get the remaining values.
I am not 100% sure if this would always work with tailwindcss and the naming scheme used there.
This also would override class names like
table
withtable-auto
during merging, because they share the same prefix, which could also be undesirable._Originally posted by @moogle19 in https://github.com/petalframework/petal_components/issues/34#issuecomment-1112892876_