undefined | Better HN

0 pointsazangru1y ago0 comments

> FWIW for a Button, your engineer should just encapsulate all the “ridiculous” styling into a <Button /> element.

Sure thing.

What I don't understand though is why not put a Button.css file next to the Button element file, and describe all the button styles in there. What's so hard about building or maintaining that?

0 comments

0x4571y ago

Soon after, you're going to need slightly adjust that button, you will add some helper classes. Then there will be a case when base style of that button doesn't work with new button style, and now you have 2 bases for a button. You might have semantically named those buttons, but 3 months later that no longer makes sense, and now you're afraid to rename it.

Tailwind lets you style elements in the same file as the element, you don't have to switch between `button.<whatever you use>` and `button.css` to know what is going on.

nah, I love tailwindcss.

azangruOP1y ago

> Soon after, you're going to need slightly adjust that button

The proper thing to do, in my mind, is to gradually set up a collection of such buttons (and other components), and document their properties. A design system, if you will. You shouldn't have that many button variations.

This should also help with the "3 months later" case. Once you've catalogued your buttons, you can reason about them, update their styles, rename them as you please, and so on, while maintaining consistency of buttons across your site.

danenania1y ago

1 - It’s easy for style bugs to get introduced when someone updates the html and forgets the css.

2 - It’s simpler to have styles that depend on js vars/parameters when components handle their own styling.

Encapsulation, in other words.

j / k navigate · click thread line to collapse