Margins are amazing. I’ve been using margins in CSS for over 20 years and it’s fine. Though I don’t use any fancy frameworks or things where encapsulation, copy/paste, etc will cause problems.
If you code HTML&CSS with W3C standards, you’ll be happier. Maybe I’m an old timer
Are they in container.css, in which case container knows of .reusable-component.
Or does reusableComponent.css know about each and every possible container?
Will there be a containerPlusComponentCombo.css that juggles common rules?
The problem remains even if you prefer grouping css rules in one large file over many small files. You end up tying yourself in to knots as either parent or child requires knowledge of the other.
Sometimes it is perfectly valid. But it is not truly reusable. It doesn’t scale well and requires unnecessary mental overhead.
Instead, why not build a layout container that works for everything?
.container > * + * {
margin-too: var(--sp-md);
}
(Use the new-ish gap rule if you like, but I forgot the details and I’m tired)
It is just as semantic (whatever that means) as in the article and doesn’t needlessly couple things together.
No, because the `container` element uses `margin` and not `padding`. This results in margin behavior, where two adjacent containers with `margin: 10px` will have only 10px between them instead of 20 like with padding.
This approach yields decent readability, fewer elements than if we needed containers wall around, and good flexibility for many contexts and situations.
In a smaller project, styling all buttons might be a fine/good way to do it. But in a larger project, it is inevitable that you will have buttons which you actually don't want to inherit your global styles, and it's a pain and messy to have to override/undo the styles. Like, you bring in a third-party video player, or checkout form, or chat client, and it's busted because your global margin button styles are leaking in.
As to why not scope with .someparent, it can work, but if you already have spacing utility classes ready to go, it's easier to just add the three characters in the class. And as a bonus, when you add another button somewhere else nested way deep under .someparent, it won't accidentally inherit the margin you meant for the first button.
These weird semi-ideological ideas like "don't use margins!" "don't use mocks!" that keep popping up sometimes are leaving me unfazed nowadays. I used to consider them all strongly and weigh the pros and cons but now I feel like I have gained the experience to realize what this is really likely about. I think people come up with this stuff like they come up with political ideas at a bar. They don't actually believe this stuff strongly, it's just some random thing they thought up in the moment and then 5 years later they probably realize that they kept using margins all over their code but no, they didn't bother updating their blog post to do a mea culpa .. of course they didn't.
the title is a bit clickbaty, it should be written as: where to use margins when building web components.
you are just saying that you have to place margin in the container of the component not inside it. that's it!
Anyways, I think the answer is "it depends" and there's no silver bullet when it comes to micro CSS details.
CSS is always controversial when it comes to how structure it and I don't think this type conversations are useful or add anything to front end. it's just a waste of time as the end result only matters.
we can argue for days to both sides on where to place margins and we will never find the "perfect" way.
I am a big believer front end developers will move to low code tools for CSS such as https://intab.io to style their CSS in the near future and focus more on the end result rather than waste time arguing on this micro details. take a way, focus on the end result rather than these trivial things!
18 comments
[ 3.5 ms ] story [ 50.8 ms ] threadIf you code HTML&CSS with W3C standards, you’ll be happier. Maybe I’m an old timer
The only thing that I tend to use is a reset.css, everything else I write on the fly.
Are they in container.css, in which case container knows of .reusable-component.
Or does reusableComponent.css know about each and every possible container?
Will there be a containerPlusComponentCombo.css that juggles common rules?
The problem remains even if you prefer grouping css rules in one large file over many small files. You end up tying yourself in to knots as either parent or child requires knowledge of the other.
Sometimes it is perfectly valid. But it is not truly reusable. It doesn’t scale well and requires unnecessary mental overhead.
Instead, why not build a layout container that works for everything?
(Use the new-ish gap rule if you like, but I forgot the details and I’m tired)It is just as semantic (whatever that means) as in the article and doesn’t needlessly couple things together.
It was last an issue with IE7 and 8 [0], an era we don’t like to talk about.
0 - https://web.archive.org/web/20130508170505/https://developer...
I’m pretty sure you’re wrong there.
Instead of...
Use utility classes in the markup rather than spacing in the reusable definition... This approach yields decent readability, fewer elements than if we needed containers wall around, and good flexibility for many contexts and situations.As to why not scope with .someparent, it can work, but if you already have spacing utility classes ready to go, it's easier to just add the three characters in the class. And as a bonus, when you add another button somewhere else nested way deep under .someparent, it won't accidentally inherit the margin you meant for the first button.
Anyways, I think the answer is "it depends" and there's no silver bullet when it comes to micro CSS details.
CSS is always controversial when it comes to how structure it and I don't think this type conversations are useful or add anything to front end. it's just a waste of time as the end result only matters.
we can argue for days to both sides on where to place margins and we will never find the "perfect" way.
I am a big believer front end developers will move to low code tools for CSS such as https://intab.io to style their CSS in the near future and focus more on the end result rather than waste time arguing on this micro details. take a way, focus on the end result rather than these trivial things!