<el-dialog-panel class="mx-auto block max-w-3xl transform overflow-hidden rounded-xl bg-white shadow-2xl ring-1 ring-black/5 transition-all group-data-closed/dialog:scale-95 group-data-closed/dialog:opacity-0 group-data-enter/dialog:duration-300 group-data-enter/dialog:ease-out group-data-leave/dialog:duration-200 group-data-leave/dialog:ease-in">
This is not how custom functional css codebase looks. In custom projects you change the system/configuration to fit the project. You create your own utilities for example you wont have “text-lg sm:text-xl font-semibold tracking-tight” but will have class “font-heading-2”. Similarly you will create button/input classes that have you basic styles.
Generally you start with just simple utility classes inside html and go from there and where it make sense or its too complex you separate to more complex class. You end up with short css file that only has these special components and none of the basic stuff.
For most elemets it ends up like “flex justify-center gap-4”. In BEM i have to invent “nav-secondary__header” put it in correct place and hate myself when i need to change it to “flex justify-beween”.
Tailwind popularised functional css but is also aimed at masses/noobs. Somehow some of those concepts also resonated with some experienced users.
We had css, then SASS/LESS/etc, now Tailwind.
In the days of just CSS people would create variables/functions for their CSS in their server side language & have the server side language create the CSS. SASS/LESS allowed us to do that in stylesheets.
Now we have Tailwind (and of course CSS variables). Tailwind (and the code editor plugin devs) have done an amazing job at making a great workflow to handle CSS, especially in component type UI designs.
* Shout out to Foundation and Bootstrap for also helping us get to where we are today. Foundation is underrated in the history.