[madmod]

Margin is generally more desirable than padding imo. Component/element knows the content it contains and uses margins to require a minimum amount of spacing. It avoids the need to make decisions on the spacing between every combination of components.

Padding only works if you know everywhere your component might be used or don't mind remaking spacing decisions every time you use it. In my experience minimizing code needed for each use of a component leads to more coherently styled interfaces, particularly on larger or faster moving teams.

[x3ro]

The author is arguing exactly that: remake spacing decisions every time you use a component, because that’s what many designers (most?) do. This is also true in my experience.

[necovek]

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, vskip, and eg. care for orphans when typesetting etc.) and smarter column alignment (trivial alignment on decimal point in tables).

While I'd never call myself a designer, I've done plenty of TeX (print and PDF) publications that people have commended for usability and appearance.

[cerved]

Without taking side to which is superior.

Typesetting something to a beforehand known format is radically different problem to a beforehand unknown format.

[necovek]

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

[cerved]

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

[necovek]

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

[HelloNurse]

I want CSS to make spacing decisions so that I don't have to, and a system where graphical elements look good by default because they come with appropriate margins and containers adapt to what I want them to contain (e.g. by shrinkwrapping the content or by switching between different numbers of columns or rows) is more useful than a non-system that looks bad unless I keep many tedious ad-hoc specifications consistent.

Moreover,

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

Definitely not, margins are an essential part of a component, like a garden around a house, and they make components "usable in any context or layout" (unless the context or layout is stupidly overcomplicated).

[wruza]

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

[necovek]

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.

[wruza]

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.

[HelloNurse]

The "block context" for which setting margins is a good layout abstraction is not the technical "block", "inline-block" etc. of CSS, but the general situation of measuring the empty space between homogeneous rectangular blocks.

If you want to place a slider between two text paragraphs, the slider isn't a good match for them (even if rectangular, it's far smaller) and you'll have to give it small or even negative margins under the assumption of the text paragraphs having normal, big enough margins.

And this highlights the issue with the idea that "children would expose their preferred margins, which these layout contexts could take or not take into account": a reusable and modular layout should be bottom-up, with components knowing what CSS rules make them look good and containers respecting them. Since the slider is small it can have smaller margins than the text paragraphs, but a container that knows that its middle child is a slider is a complicated and ad-hoc container.

[ui4jd73bdj]

Exactly. Slapping some components together for a simple feature shouldn't require a designers input at all. Whether the defaults are margins or paddings I don't really care, but if the component looks bad without styling, it's a bad component.

[eyelidlessness]

> remake spacing decisions every time you use a component

I’ve worked with several awesome designers and they all appreciated when I told them this is untenable.

[diordiderot]

The word padding isn't in the article...

He reccomends spacing at the parent