Ban layout styling from your components entirely if you can. Make everything headless (eg https://headlessui.dev/, https://www.radix-ui.com/, plain old HTML, etc). Leave the way things look up to the app that uses them.
What if a user needs it ready-to-use? Also imagine you’ve created some styleless form which I need to style according to my Bulma or Bootstrap stylesheet. What if the structure is different than these two are assuming?
I'm not suggesting the layout shouldn't be included at all. There's nothing wrong with including a default for the component - as a stylesheet in "examples" or something. The point is that layout shouldn't be a part of the component itself. The beauty of CSS is that it makes doing that absolutely trivial.
The problem is people treat HTML, CSS, and JavaScript like they are separate languages. They should be treated collectively like bytecode/binary and almost no one should need to know more than they exist, a compiler should be what's writing web output.
Are you saying that content and layout _should_ always remain combined?
I accept that we come to this understanding through our early introduction to language, writing and art. Most people intuitively link structure and presentation when they compose content.
Separating them is incredibly useful. You can see this at a really basic level, in plain text. Lay out a single long paragraph of plain text into lines of max 80 chars, and then insert a word. The layout goes completely wrong and if you don't have tools to help you, you spend ridiculous amounts of time realigning the text. The line-length algorithm you're following (or using) is __totally__ separate from the content. HTML and CSS are this, scaled up to allow fine grained annotation and control of both semantics and presentation, independently.
XSLT is there, chrome supports it, but no progressive rendering, or support of modern XSLT versions.
Basically, Google wants to kill XSLT, and normal web in favour of Javascript, and WASM based web. Why? They don't want people to turn off javascripts, so they can show more ads, and competitors cannot get an easier job making google.com alternative.
"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.
"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.
> 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.