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

221–230 of 230 posts

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

#221

Post by the_other »

Kavelach wrote: post #210
the_other wrote: post #187

Earlier quoted context omitted.

> owl selector is pretty slow when it comes to being processed by browsers I'm sure this hasn't been relevant for about 15 years. CSS rendering is _fast_.

As I mentioned above - one or two clauses like that won't hurt performance, but I have seen situations, when bad CSS (a lot of *'s, too long selectors, a lot of dead and unused clauses) actually had a measurable impact on websites' performance. This especially comes into play, if you deal with a lot of nested HTML elements or when you modify the site's HTML a lot.

That sounds like a different problem from using the owl selector. That sounds like bad coding and app design.

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

#222

Post by the_other »

city41 wrote: post #202
the_other wrote: post #186

Earlier quoted context omitted.

You have the same understanding as the OP. The difference is that the OP is working on a component-based framework. In such a framework, it makes sense to declare the rule defining child margins *in* the parent component's code, not in the child's code.

But why do it with extra elements? The child should accept a class or possibly styles and the parent decides what those are. Child directly styles itself with color, font, internal layout, etc Parent positions child with flex box, grid, margin or absolute positioning. Spacer elements are not needed at all.

I think I see what you’re saying now. You are wondering why have dedicated layout components when you could “simply” get any component to define styles on its children?

You could do it that way too. However, when you reply on your component system to help assemble a UI, the components take on the encapsulation role you’d use rich selectors for in other situations. A layout component performs the same function as a utility css class, but is more idiomatic.

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

#223

Post by the_other »

7sidedmarble wrote: post #159
the_other wrote: post #105

"Banning margin" is excessive and clickbait-y. The Spacer components idea is fine. Using Grid or flex layout in spacers is very sensible. But you could also use margins. ``` .spacer-stack * + * { margin-top: 1em; } ```

That's... what the article said. He's not saying don't use margin for anything, he's saying avoid giving your components margin. The Spacer component is literally just the CSS you posted.

There's something like 5 instances of clear rejection of the use of margins in the article and zero mentions of practical margin-based layout strategies. I stand by my assertion that the article is badly worded.

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

#224

Post by tambourine_man »

spicybright wrote: post #150
tambourine_man wrote: post #130

Earlier quoted context omitted.

>Tendency towards semantic web is unfortunately dead. Not dead, but under severe attack. We can and will fightback

Can you elaborate a bit why? I've don't think I've seen a time where most sites were generally semantic

Search engines, screen readers, ancient browsers, future browsers, etc.

The important concept is that HTML tags should convey the meaning of its content, rather than merely being a target for CSS to define its appearance.

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

#225

Post by city41 »

the_other wrote: post #222
city41 wrote: post #202

Earlier quoted context omitted.

But why do it with extra elements? The child should accept a class or possibly styles and the parent decides what those are. Child directly styles itself with color, font, internal layout, etc Parent positions child with flex box, grid, margin or absolute positioning. Spacer elements are not needed at all.

I think I see what you’re saying now. You are wondering why have dedicated layout components when you could “simply” get any component to define styles on its children? You could do it that way too. However, when you reply on your component system to help assemble a UI, the components take on the encapsulation role you’d use rich selectors for in other situations. A layout component performs the same function as a ut…

The article is about spacer elements. As in an empty div that takes up space so things next to it get moved into place. I'm arguing that isn't necessary, as css has plenty of tools for laying things out. I have no issue with components that focus on layout, that is fine. A div that uses say flex box to layout a set of children is quite common. I'm arguing that parent div does not need spacer elements, you can always accomplish the layout you need with standard css such as flexbox, grid, margin, etc.

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

#226

Post by peterangular »

feupan wrote: post #29
peterangular wrote: post #3

So ban a huge part of the CSS box model. Got it... Margins are valid in many use-cases, specifically many people leverage them for typography. They can even still be valid with component-driven development as well.

> So ban a huge part of the CSS box model. Yes, why not? While eliminating them is hard, the argument here makes perfect sense. We've all been fighting margins one way or another. One could even argue that negative margins are a symptom of the problem. When you use negative margins you're pulling the element out of the box and essentially causing overflow. Does this fix the issue sometimes? Sure. Is it the best optio…

> We've all been fighting margins one way or another.

Nope - not really.

There's always been a huge distaste for the box model and it comes from a place of not understanding it vs. anything else. Margins + features like flexbox are a huge feature of modern web development.

If I were interviewing a developer and they started to go off on "ban margins" it would cause the interview to go short.

---

Since you bring up an edgecase to defend the article: negative margins.

Negative margins are almost considered an edge-case use for my entire career which is as-old as the CSS spec. They would show up in situations where complex layouts were just not achievable (holy grail w/dynamic content width and static sidebars pre-flex/grid). The other place they would show up is simple "off-by-one" issues like placing a child div 1px over it's parent border in dropdowns etc.

I'd say for the last 5-10 years specifically they've not been needed and are an artifact of legacy development before flex showed up. If I came across code using negative margins in a PR I'd ask the submitter to refactor.

Idk - just saying that using an old edgecase as an argument against such a ubiquitous feature of the box model (which is core to FE development) seems off to me.

---

One last thought - margins are still perfectly valid with components. It's just that component developers don't want to think about how their component may lay out with something else on the page. It's microservices fiefdom on the front-end calling to give up core web development features because people don't want to think about components interacting with others.

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

#227

Post by y4mi »

Kavelach wrote: post #209
y4mi wrote: post #125

Earlier quoted context omitted.

Ha, when I first learned about it I remade a pretty interesting navigation menu purely with :not :checked :focused :hover etc, so pure html and css, thinking it would be more performant then my previous JS version. Its performance was not just measurably worse, it was obvious as soon as I opened the revision on my phone. Lesson learned: it's important to think twice before using most pseudo selectors

> I remade a pretty interesting navigation menu purely with :not :checked :focused :hover etc, so pure html and css, thinking it would be more performant then my previous JS version. That sounds so cool! Do you have a version somewhere that I can take a look at? I always like fiddling with clever CSS, even if it is too clever for its own sake, as you managed to find out And keep in mind, that pseudo selectors are not…

Sadly no, I tried for a while until I finally threw in the towel at some point.

I think you're overestimating what I did though, the basic idea is this recreation.

https://codepen.io/wohlben/pen/gOGKejv

it was just a lot more elements in the navigation with subcategories etc, but basically the same methods

(remember to check the mobile view, as thats the one thats using most selectors. Though the desktop view is arguably better)

this recreation is probably very confusing though, as the only hint that there are more links hidden for the category are the missing corners - and there is nothing hinting you have to click the category names to show these hidden options. and i skimped on proper accessibility for this mockup, so the hidden options can't be selected without touch/mouse

The JS just emulates what opening the page would have done. It was SSR

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

#228

Post by cerved »

necovek wrote: post #220
cerved wrote: post #217

Earlier quoted context omitted.

I mostly meant that the rendering problems are radically different. Typesetting is a rendering a static copy a priori. You can expend a lot more time and resources rendering and reflowing the document. Rendering HTML+CSS, which can be dynamic, is a radically different problem. I wouldn't be surprised if these posed very different constraints on the possibilities of the layout model

What I am saying is that that it is not a radically different problem. They are radically different implementations focusing on different goals, but the problem is pretty much the same. TeX's box model is in no way less optimizable than the HTML+CSS (if anything, it's the opposite due to it being much simpler). It has had a stable algorithm and implementation since 1983, and that implementation was never optimized fo…

Håkon Wium Lie, the author of CSS, and fellow implementers were very aware of the TeX box model

>6.6.4 Inspiration from other formatting models In the early design phases of the CSS visual formatting model, other formatting models were frequently consulted for inspiration. In particular, TeX [Knuth 1984] was often brought up in white-board discussions.

As one of its foundations, TeX has a well-defined box model wherein all objects, including individual glyphs, are contained in boxes. The spacing between the boxes can be controlled through TeX commands. In addition to optimal spacing between boxes, TeX also allows maximum and minimum spacing to be expressed. This is referred to as glue (although Knuth suggests that springs is a better term [Knuth&Plass 1981]).

The visual formatting model in CSS is based on a box model, and all elements, both block-level and inline, are turned into boxes. Thus, CSS goes further than most other style sheet languages in creating boxes. For example, DSSSL and P94 do not use boxes for inline elements. However, CSS did not adopt TeX's glue. Although the issue was discussed, it was decided against in order to keep the VFM simple. Glue is very useful when breaking paragraphs into lines, but CSS leaves this problem to implementations. CSS allows, but does not demand, inter-paragraph line-breaking optimizations. Each box in CSS is, however, potentially richer than the boxes found in TeX since it can contain a padding, border and margin bands. CSS also borrows other features from TeX, including the em and ex units.

https://www.wiumlie.no/2006/phd/#ch-css

Håkon also goes into great detail on the historical context and technical requirements surrounding the development of CSS.

I think the reason the CSS box model differs from the TeX box model is because of the different problems they attempt to solve and various contextual difference the technologies developed under. Crucially, it's not because the authors were unaware of the TeX box model or because they thought they could do something better

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

#229

Post by necovek »

cerved wrote: post #228
necovek wrote: post #220

Earlier quoted context omitted.

What I am saying is that that it is not a radically different problem. They are radically different implementations focusing on different goals, but the problem is pretty much the same. TeX's box model is in no way less optimizable than the HTML+CSS (if anything, it's the opposite due to it being much simpler). It has had a stable algorithm and implementation since 1983, and that implementation was never optimized fo…

Håkon Wium Lie, the author of CSS, and fellow implementers were very aware of the TeX box model > 6.6.4 Inspiration from other formatting models In the early design phases of the CSS visual formatting model, other formatting models were frequently consulted for inspiration. In particular, TeX [Knuth 1984] was often brought up in white-board discussions. As one of its foundations, TeX has a well-defined box model wher…

Thanks, that's a nice read! (Note that I never suggested that CSS creators were unaware of the TeX box model, though I had no idea to what extent was it considered early on)

That also supports my claim that reflowing in TeX's box model would be simpler ("CSS is richer").

I simply highlighted a few things where TeX's box model does a great job for what are commonly hard problems with CSS even today (how do you align columns on decimal points?): I imagine most people, even LaTeX users today, are unaware of the internals, and I hope it's valuable for people to learn of them.

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

#230

Post by cerved »

necovek wrote: post #229
cerved wrote: post #228

Earlier quoted context omitted.

Håkon Wium Lie, the author of CSS, and fellow implementers were very aware of the TeX box model > 6.6.4 Inspiration from other formatting models In the early design phases of the CSS visual formatting model, other formatting models were frequently consulted for inspiration. In particular, TeX [Knuth 1984] was often brought up in white-board discussions. As one of its foundations, TeX has a well-defined box model wher…

Thanks, that's a nice read! (Note that I never suggested that CSS creators were unaware of the TeX box model, though I had no idea to what extent was it considered early on) That also supports my claim that reflowing in TeX's box model would be simpler ("CSS is richer"). I simply highlighted a few things where TeX's box model does a great job for what are commonly hard problems with CSS even today (how do you align c…

It's great thesis right?

It was never something I had thought about but I got curious so I did some digging.

It's true that some things are much easier in TeX, like aligning on decimals. HTML tables are used for all sorts of crazy so I'm not surprised it's harder to that kind of stuff

Post reply on HN