Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Use spacer components instead of CSS margins (2020)

mxstbr.com

Post reply on HN
Print view View original

81–90 of 230 posts

Re: Use spacer components instead of CSS margins (2020)

#81

Post by Xevi »

lelandfe wrote: post #19

Needs (2020) in the title. Original discussion, 123 comments: https://news.ycombinator.com/item?id=22676442 Anyway, considered harmful articles considered harmful . There is a time and place for margins. Being thoughtful with them is a better approach than "banning margin from all components." Should I really ban the use of `margin-left: auto` when positioning my flexed elements? I don't think this article is actuall…

Out of curiosity, why do you need to use "margin-left: auto" when working with flexbox items? What is it that you're trying to do, which can't be solved with "justify-content" and "align-items"?

Re: Use spacer components instead of CSS margins (2020)

#83

Post by onion2k »

wruza wrote: post #65
onion2k wrote: post #47

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.

Re: Use spacer components instead of CSS margins (2020)

#84

Post by wruza »

necovek wrote: post #77
wruza wrote: post #73

Earlier quoted context omitted.

And then you have a container with A, B, margined apart by max(A.mr, B.ml) and want to insert a sizer knob in-between, which makes them (A.mr + B.ml) apart. Or you have to put ABCDE into a sortable wrapping flexbox, and the best practice* says you must -ml the flexbox, but now you don’t know how much because each of ABCDE has its own +ml. It’s all nice until it’s bullshit. * which alone is utter nonsense

Margins make complete sense when you do want to fold them, which is common with textual content (eg. imagine an img tag with bottom margin, and a h2 tag right after it with top margin). The fact that they can be misused does not make them useless.

Web styling is not useless, it’s just fucked up. The article has no hope to change that (neither do we) and tries to find a balance.

In a better world, margins would work in a block context (where paragraphs live) but not in flex/grid ones, which take layout in their hands. Another context could be called “constraints-based”, which would space its children relatively, like A.r + 10px <= B.l; B.r = this.r - 10px. Children would expose their preferred margins, which these layout contexts could take or not take into account.

Re: Use spacer components instead of CSS margins (2020)

#85

Post by AltruisticGapHN »

vore wrote: post #9

I think the main bugbear of margins that the article doesn't mention is margin collapse: I personally don't find the rules super intuitive and I would rather just be explicit with spacing than have the browser collapse things together!

See https://csswizardry.com/2012/06/single-direction-margin-decl...

Re: Use spacer components instead of CSS margins (2020)

#86

Post by onion2k »

ratww wrote: post #68
onion2k wrote: post #47

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.

"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.

Re: Use spacer components instead of CSS margins (2020)

#87

Post by necovek »

cerved wrote: post #79
necovek wrote: post #74

Earlier quoted context omitted.

There are several types of designers, and even on the web itself, several different things you might be designing. Designing a text medium (eg. a blog) should have more focus on semantic tagging compared to a SPA where you probably want an entirely different approach (and where talk of "components" makes more sense). I like TeX's box model over CSS which allows for easier "smart" spacing (look up hglue, vglue, hskip,…

Without taking side to which is superior. Typesetting something to a beforehand known format is radically different problem to a beforehand unknown format.

There is no need to take sides: there are things that are easier in CSS for sure, and I only highlighted a small number of things which are very nice in TeX box model that are somewhat similar to margins in CSS (non-explicit behaviour to help with smarter laying out of text). TeX has a bunch of problems for electronic documents too (box model it uses means that each individual glyph gets positioned as a separate box, which can result in unsearchable PDFs, for instance).

But TeX typesets to a beforehand known format (I assume you mean target document size) as much as HTML+CSS does (a bitmap canvas of x infinity size): it's not optimized to reflow stuff live, but you can definitely change the page size before every run with a single command, and rendering should (mostly) reflow properly (this would be equivalent to resizing the window, or having differently sized/fine target like a cell phone).

It does not solve the problem of multiple page sizes any better than HTML+CSS, it just provides some nicer and more obvious tools for aligning stuff on the page/screen that could be more easily used to achieve such support.

Re: Use spacer components instead of CSS margins (2020)

#88

Post by fleddr »

I fully agree with the solution. Spacer components are a sound concept if you consider that a component should have no awareness of the larger context it is placed in. A next step to make components even more robust is for them to respond to available space in the parent container (container queries).

A spacer component is easy to understand and makes consistent spacing easy. There's nothing dirty or impure about it. You just mark it aria-hidden so that both search engines and screen readers ignore them.

Another tactic is to apply component margin spacing on individual instances of a component, as a utility class. It will work most of the time, but is more fragile.

There is but one issue: the internal padding of a component (which is perfectly normal to have) is visually experienced as a margin when two subsequent components share the same background color. In this scenario you're still theoretically consistent with your margins but visually it is not perceived as such.

Re: Use spacer components instead of CSS margins (2020)

#89

Post by tristanperry »

I do agree generally, but it's funny that the suggested solution (spacers) are basically back to the old 1px transparent gif trick from the 90s/early 00s.

Nothing wrong with the suggestion, but it's just ironic that we seem to be coming full circle again.

Next we'll probably have posts extolling components for layouts ;)

Re: Use spacer components instead of CSS margins (2020)

#90

Post by ratww »

onion2k wrote: post #86
ratww wrote: post #68

Earlier quoted context omitted.

"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'r…

> 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.

Post reply on HN