[ratww]

"Component" doesn't necessarily means "third party library".

The headless components need to be styled in the end, and the guideline present in the article still applies to those cases: outer margins in components causes some headaches.

[onion2k]

"Component" doesn't necessarily means "third party library"

I didn't suggest it did. It does mean "block that could be reused somewhere" though. Devs should consider that carefully when they're making components. If your block can't be lifted and reused because it relies on the parent structure or it expects something global that's not passed in as a param/prop/whatever then you need to think some more, because you're making something that's not reusable.

One day, someone, somewhere will want to use your component in a way that you didn't plan for. If you've created a hard link to a particular part of your app such as an expectation that the parent HTML structure will look a specific way, then you've made their job harder when you didn't have to.

[ratww]

> Devs should consider that carefully when they're making components. If your block can't be lifted and reused because it relies on the parent structure [...] then you need to think some more.

Yes, that's what the article is talking about.

Even with headless components you need to have CSS somewhere else in the end. I don't know how you're "[leaving] the way things look up to the app that uses them" to headless components, but most people do it with (surprise) other components that belong to the "app" itself. Or with CSS-components.

So, the advice in the article could still apply to them. If you apply a style that contains an outer margin, you might run into the problems discussed by the articles.