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

211–220 of 230 posts

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

#211

Post by smarkov »

au-arms wrote: post #166

Clever, but this smells like a performance anti-pattern. Adopting this means you could, at worst, add 4 spacer divs per component. While most sites may never really feel a sting, for complex apps where reusability is a larger concern you've doubled to quadrupled the size of an already large DOM and you will be hit a death-by-one-thousand-cuts situation. Now you've got more... - html over the wire - html to parse for…

If you're worried about a few additional elements your DOM is already too big and you have bigger issues to worry about.

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

#212

Post by einpoklum »

> Margin breaks component encapsulation. A well-built component should not affect anything outside itself.

I guess I should make all my programs stop printing anything , and creating any files, because I wouldn't want them effecting anything outside themselves.

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

#213

Post by knowfilter »

diordiderot wrote: post #26
speedgoose wrote: post #15

Earlier quoted context omitted.

Let's code all the apparence in the class attribute (instead of the style).

We do, its called tailwindcss lol (and its amazing)

You didn't get the memo? We moved the style attribute inside the class attribute now

https://tailwindcss.com/docs/adding-custom-styles#arbitrary-...

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

#214

Post by bhk »

scns wrote: post #32
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!

One way around this is to only define margins at the end of the container.

Bottom margins can still collapse with those of a parent container.

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

#215

Post by bhk »

jicea wrote: post #49
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!

Agree, collapsing margins are counterintuitive, and only applied to top and bottom margin. It’s really surprising how many people don’t know it’s a thing and fight the box model. If you think you’re constantly fighting layout, try to read the MDN docs [1] with a fresh eye. I was guilty to think I needn’t learn CSS, and reading the MDN really help me. [1] https://developer.mozilla.org/en-US/docs/Web/CSS

What's really surprising is how many people do know that margin collapse is a thing, but haven't fully understood all of the implications, so they still get mystified by some unintended consequence.

I don't think that "go read all the MDN docs" is a very useful suggestion. More useful is something like the following, which I don't think you will find anywhere in MDN:

When an element's top or bottom margin collapses with its parent, this may affect the position of the parent, because the minimum of the child and parent's margin will be used to position the parent. (MDN says the child element's margin will fall "outside the parent", but it is not clear that it will be used during layout to place the parent.)

The bigger problem is that CSS is just so complicated and arbitrary. Consider the rule for collapsing margins with parents, from MDN:

> If there is no border, padding, inline part, block formatting context created, or clearance to separate the margin-top of a block from the margin-top of one or more of its descendant blocks; or no border, padding, inline content, height, or min-height to separate the margin-bottom of a block from the margin-bottom of one or more of its descendant blocks, then those margins collapse.

They list five different factors that prevent collapse, one of which ("block formatting context created") is a link to a page that defines it in terms of 15 different constructs or situations in CSS.

On top of that, it appears that the MDN text is in error, because it lists intervening "height" as something that prevents bottom margin collapse, but not top margin collapse (when in fact it does).

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

#216

Post by jacobp100 »

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!

If you don’t want the margins to collapse, set the container to display: flex.

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

#217

Post by cerved »

necovek wrote: post #87
cerved wrote: post #79

Earlier quoted context omitted.

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,…

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

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

#218

Post by bryanrasmussen »

au-arms wrote: post #193
bryanrasmussen wrote: post #191

Earlier quoted context omitted.

I also think repaints are probably more expensive given this solution.

More expensive with or without the spacer components?

I would think more expensive with spacers, you have more nodes to repaint, furthermore if you have an event that changes a particular spacer size - for example if you have contentnode spacernode contentnode and then change width of spacernode you will be repainting three nodes. Window resizing becomes more expensive seems to me.

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

#219

Post by diordiderot »

knowfilter wrote: post #213
diordiderot wrote: post #26

Earlier quoted context omitted.

We do, its called tailwindcss lol (and its amazing)

You didn't get the memo? We moved the style attribute inside the class attribute now https://tailwindcss.com/docs/adding-custom-styles#arbitrary-...

Dear God

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

#220

Post by necovek »

cerved wrote: post #217
necovek wrote: post #87

Earlier quoted context omitted.

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,…

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 for reflow like HTML + CSS has. TeX itself is also Turing-complete, which makes processing more expensive by definition, and that's mostly the reason for the slow performance, rather than the box model — and it is from 1983, after all. For some things, the reflow model is even used with TeX today (eg. table of contents generation usually requires at least two passes to "reflow" the output).

Post reply on HN