3 ms·

It is completely possible to do that with Tailwind and components, I do it all the time. I'll create a Button component that takes parameters like `mode=primary

by MrJohz 3y ago

It is completely possible to do that with Tailwind and components, I do it all the time. I'll create a Button component that takes parameters like `mode=primary`. The Button component contains a `button` element with some common classes that apply to all buttons (padding, borders, shadows, etc). Then depending on the parameters, I'll append other specialised classes (usually colours). The only thing you have in CSS that is harder when working with Tailwind is overrides - e.g. "this component is normally blue, but it's green if this class/parameter/attribute is set". That said, even when I'm using CSS, I tend to find overriding, except in the simplest of cases, usually causes problems, because now I need to make assumptions about the order of declarations that are difficult to make in a codebase maintained by multiple people over several years. For that reason, in the button case, I would typically make it so that the different modifiers (.button-primary etc) are mandatory when using the .button class.

snowcode 3y ago
I'm not a CSS guru, and as a result I've had to do things in a very very simple way. Currently the simplest solution for me, involving no additional server side frameworks is to just "compose" the static html on the server or at build time. So a "base" class of re-usable styling could easily be a static string. I wouldn't start by thinking about inheritance, I'd only consider it if and when I actually hit that problem. It's often just a single edge case. So my code is generated server side, using something Jam-stacky like Hugo or Cloudflare pages, (with a cloudflare worker that dynamically replaces or modifies a button ...in that very one specific edge case.) Your existing example needs to be made more complex though because I'd just use standard CSS for that, for example button.submit { color:blue) button.submit.critical { color:red } i.e. all my buttons are blue, except that one special case where I have a "critical button" and we "override" the color to "red". I simply flag it with the extra semantic attribute and style it accordingly.The button will clearly be red because the css for red has a higher specificity, but it also "reads" easily as such if the css is properly crafted. Of course it's possible to write Semantic CSS that no-one can follow; and the same goes for Tailwind. The problem with CSS though, is unfortunately the most common approach is to add a new DIV, and slap on a CSS definition that ignores all inherited styling. So, unless you're going to re-write everything a big corporate ball of mud is made up of, Tailwind works better here, since it's PURPOSE is overriding and ignoring everything. He says ..ducking!

by MrJohz 3y ago

snowcode 3y ago

I'm not a CSS guru, and as a result I've had to do things in a very very simple way. Currently the simplest solution for me, involving no additional server side frameworks is to just "compose" the static html on the server or at build time. So a "base" class of re-usable styling could easily be a static string. I wouldn't start by thinking about inheritance, I'd only consider it if and when I actually hit that problem. It's often just a single edge case. So my code is generated server side, using something Jam-stacky like Hugo or Cloudflare pages, (with a cloudflare worker that dynamically replaces or modifies a button ...in that very one specific edge case.) Your existing example needs to be made more complex though because I'd just use standard CSS for that, for example button.submit { color:blue) button.submit.critical { color:red } i.e. all my buttons are blue, except that one special case where I have a "critical button" and we "override" the color to "red". I simply flag it with the extra semantic attribute and style it accordingly.The button will clearly be red because the css for red has a higher specificity, but it also "reads" easily as such if the css is properly crafted. Of course it's possible to write Semantic CSS that no-one can follow; and the same goes for Tailwind. The problem with CSS though, is unfortunately the most common approach is to add a new DIV, and slap on a CSS definition that ignores all inherited styling. So, unless you're going to re-write everything a big corporate ball of mud is made up of, Tailwind works better here, since it's PURPOSE is overriding and ignoring everything. He says ..ducking!