TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Margin considered harmful

124 点作者 whoisnnamdi大约 5 年前

38 条评论

henriquez大约 5 年前
It&#x27;s funny how we&#x27;ve come full circle from using CSS the way it was intended to be used to that being &quot;considered harmful&quot; and now we have the Javascript framework equivalent of &lt; img src=&quot;spacer.gif&quot; &#x2F;&gt;, an anti-pattern I was using back in 1999.<p>The reality is that frontend is messy, browsers are still inconsistent with respect to how they treat CSS, and creating new layers of abstraction to handle trivial considerations like adding space on a display are just a way of denying that reality by fixing something that isn&#x27;t broken.<p>Creating new, completely useless components to &quot;bring us closer to how designers think&quot; completely flies in the face of separating view from the program layer. And in my experience, &quot;designers think&quot; everyone has a 27&quot; Thunderbolt display, or now increasingly a Pro Display XDR, so I wouldn&#x27;t really put too much stock in what they think. If you disagree, I would propose spacer.gif as a much more succinct and widely accepted alternative to all the harm being done here.
评论 #22677883 未加载
评论 #22677871 未加载
评论 #22678482 未加载
评论 #22678070 未加载
评论 #22679697 未加载
评论 #22677792 未加载
评论 #22677950 未加载
评论 #22677759 未加载
Saaster大约 5 年前
Oh my sweet summer child. As a pro having done this thing for decades, the industry standard in 2020 is to randomly throw margins, negative margins, and paddings on _everything_ (probably in JS&#x2F;JSX) in the vicinity of the thing you&#x27;re trying to position and visually iterate until things looks okay-ish. Probably by a dozen people simultaneously on the project, some of whom may have read an article on CSS once. After a year or two the whole thing is chucked out anyway. And that&#x27;s all right, it gets the job done.
评论 #22677794 未加载
评论 #22677673 未加载
评论 #22677745 未加载
评论 #22677806 未加载
评论 #22677720 未加载
评论 #22677941 未加载
__ryan__大约 5 年前
This article is <i>not</i> advocating using spacer components like so:<p><pre><code> &lt;MyComponent&gt;&lt;&#x2F;MyComponent&gt; &lt;div class=&quot;spacer&quot;&gt;&lt;&#x2F;div&gt; &lt;MyComponent&gt;&lt;&#x2F;MyComponent&gt; </code></pre> They are describing using <i>layout</i> components to define how children should be oriented and spaced.<p>The article&#x27;s example:<p><pre><code> &lt;Stack space={3}&gt; &lt;Item &#x2F;&gt; &lt;Item &#x2F;&gt; &lt;Item &#x2F;&gt; &lt;&#x2F;Stack&gt; </code></pre> Would be basically equivalent to this:<p><pre><code> &lt;style&gt; .layout-space-3 { &gt; * { margin: 6px; &#x2F;&#x2F; Or whatever spacing value to use } } &lt;&#x2F;style&gt; &lt;div class=&quot;layout-space-3&quot;&gt; &lt;Item &#x2F;&gt; &lt;Item &#x2F;&gt; &lt;Item &#x2F;&gt; &lt;&#x2F;div&gt;</code></pre>
评论 #22678524 未加载
评论 #22678510 未加载
评论 #22683017 未加载
评论 #22680251 未加载
keithwhor大约 5 年前
The longer I spend engineering, the more I just want to get the job done and get it over with. I&#x27;ve built, and will continue to build, strongly-opinionated frameworks and platforms based on my experience. But this week&#x27;s silver bullet is next week&#x27;s anti-pattern: mostly because of a misunderstanding of when, how, and where to apply design patterns.<p>Truthfully, it&#x27;s increasingly my opinion that design patterns (and by extension, anti-patterns) only exist in the context of focused, internally consistent systems architected by a small group of individuals and not a committee. Rails, especially early on, is a great example. Actually -- a huge chunk of programming languages are built this way. The web, however, is designed by committee.<p>With this framing, &quot;avoiding margins&quot; works for the way Max builds design systems -- and from what I know, he&#x27;s very talented and the team(s) that work with him should adhere to the systems he constructs. I&#x27;d love to see an implementation of an entire framework &#x2F; design system that avoids margins -- something like Tailwind CSS. I do not, however, really believe this is broadly applicable advice. Most people are just trying to ship something that looks nice, and margins can be overwritten and adjusted easily.<p>NOTE: I have components I&#x27;ve written that have margins I have to overwrite nearly universally, but can&#x27;t remove because of other UIs relying on the margin behavior. So I understand where the argument comes from. It&#x27;s just -- I&#x27;d have a hard time if anybody tried to pick a bone with a software engineer on the team about the use of a margin if the initial intention was good &#x2F; legitimate.
评论 #22678562 未加载
the_other大约 5 年前
I tried something similar to “spacer components” in a recent project. When I wrote them, I felt smug and clever: I had interpreted the suggestions in React about using components; I had separated my presentation concerns from content or functionality etc etc.<p>It turned out to be a mistake. It added a component (with JSX file, an index.js and a folder, and imports and uses in the consuming file. 10s of lines of code across multiple files and folders. After I had made it, I kept seeing the layout pattern it encoded in other parts of my app. I’d reuse the component, break it, refactor it to cover multiple uses, which sometime broke the original. I’d give up and make a new component that was slightly different. In the end I’d have several of these things, all with long names that were hard to interpret and harder to use.<p>And I was the only coder on that project. Imagine if you had several people doing this?<p>This kinda thing is the same as the problems people complain about when working with large CSS codebases.<p>Doing it in CSS is marginally easier, in my view. You probably have fewer files to maintain and fewer lines of code to work with.<p>Ultimately, I think the problem is in neither the CSS or JS. It’s that layout is really hard. It’s as subtle as language. We strive for regularity and consistency, but if we stick it it strictly, we hamper our ability to communicate.
aphextron大约 5 年前
Completely agreed. Margin should only ever be used at the page layout level, where multiple components are being integrated. But spacer components are a terrible idea. Just use CSS.
评论 #22677153 未加载
cousin_it大约 5 年前
I agree that spacers are better than margins (and sometimes better than paddings, when people use paddings as margins). Since whitespace is almost always between A and B, ideally the piece of code defining whitespace would be between the pieces of code that are responsible for A and B.<p>For example, it feels nice to define margin or padding on a &lt;p&gt; element, but what does that mean - distance between two paragraphs? Between paragraph and heading? Between paragraph and bulleted list? Using spacers seems like the only way out of this madness.
评论 #22677630 未加载
评论 #22677682 未加载
评论 #22677602 未加载
tylerchilds大约 5 年前
&lt;br &#x2F;&gt; &lt;br &#x2F;&gt; &lt;br &#x2F;&gt;
评论 #22677306 未加载
评论 #22677933 未加载
评论 #22677333 未加载
jpochtar大约 5 年前
HTML is for styling. JSON is for content.<p>If you&#x27;ve heard &quot;separate content from presentation&quot; all your career, you might autonomically hear it as &quot;separate HTML from CSS&quot;. I used to.<p>In a React app world, your content hasn&#x27;t lived in HTML for a long time. It lives in your DB, and comes to you through JSON.<p>Your React codebase exists to style that JSON. That includes &quot;HTML&quot; (JSX), CSS, and whatever else you&#x27;ve got in there.<p>Since your HTML is for styling, and your CSS if for styling, why separate them? If you do, you&#x27;re not separating content from presentation, you&#x27;re separating presentation from presentation, and that&#x27;s just wasteful.<p>Personally, I&#x27;d prefer to use inline styles for everything, though of course will use CSS for :hover of @media queries where I have to.
williamdclt大约 5 年前
So, the point is that margins on the UI boundaries of a component are a bad idea. Margins are a visual side-effect, which break the idea of keeping components encapsulated.<p>It&#x27;s not anything new really, everybody has experienced pain to try to reuse a component but it&#x27;s badly encapsulated so it&#x27;s painful to fit in a new context. It&#x27;s always worth making it clear and reiterating basic principle under different lights, but this &quot;considered harmful&quot; like you discovered a new law of physics always feels pretentious to me
评论 #22677354 未加载
评论 #22676884 未加载
bpsh大约 5 年前
I was expecting a finance related article.
评论 #22677781 未加载
raphaelrk大约 5 年前
I like the way @wongmjane put it, &quot;Basically margin is like side-effect&quot;<p><a href="https:&#x2F;&#x2F;twitter.com&#x2F;wongmjane&#x2F;status&#x2F;1242370883320049664?s=20" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;wongmjane&#x2F;status&#x2F;1242370883320049664?s=2...</a><p>I remember @jpochtar and @gablg1 had a similar take in &quot;Technical lessons from building a compiler startup for 3 years&quot;. Under &quot;Don’t trust standards&quot;, they wrote &quot;We had no issue w&#x2F; using invisible spacer divs instead of the more “semantic” margins or paddings.&quot;<p><a href="https:&#x2F;&#x2F;medium.com&#x2F;@gabriel_20625&#x2F;technical-lessons-from-building-a-compiler-startup-for-3-years-4473405161cd" rel="nofollow">https:&#x2F;&#x2F;medium.com&#x2F;@gabriel_20625&#x2F;technical-lessons-from-bui...</a>
tengbretson大约 5 年前
I guess we&#x27;re done trying the whole &quot;semantic HTML&quot; thing.
评论 #22677705 未加载
评论 #22677478 未加载
评论 #22677670 未加载
Tade0大约 5 年前
Am I missing something here? Why not just define the margin for those components in that place in the parent component?
austincheney大约 5 年前
I have never understood why developers think in absolutes and then try to force this absurdity on other people. It feels immature to me and makes me feel like I am in a prison or an insane asylum.<p>Just use the correct tool for the given task.
评论 #22677640 未加载
superfrank大约 5 年前
I semi-agree with the point being made, but I don&#x27;t like the solution. Spacer components isn&#x27;t the solution, IMO, separating the reusable styles from one time styles is.<p>so instead of:<p>&lt;div class=&quot;link&quot;&#x2F;&gt;<p>&lt;div class=&quot;spacer&quot;&#x2F;&gt;<p>&lt;div class=&quot;link&quot;&#x2F;&gt;<p>&lt;div class=&quot;spacer&quot;&#x2F;&gt;<p>&lt;div class=&quot;link&quot;&#x2F;&gt;<p>We should be doing:<p>&lt;div class=&quot;link space-right&quot;&#x2F;&gt;<p>&lt;div class=&quot;link space-right&quot;&#x2F;&gt;<p>&lt;div class=&quot;link&quot;&#x2F;&gt;<p>This allows the reusable styles to be reused and the spacing to be one off.<p>P.S. since I&#x27;m more of a react&#x2F;styled-components kind of guy, this is how I would look to do it there<p>const Link = styled.div`<p>&#x2F;&#x2F;... styles<p>` const LinkWithSpacer = styled(Link)`<p>&#x2F;&#x2F;... margin<p>`<p>&lt;LinkWithSpacer &#x2F;&gt;<p>&lt;LinkWithSpacer &#x2F;&gt;<p>&lt;Link &#x2F;&gt;
hjanssen大约 5 年前
Using spacing components makes sense for small applications where there is a predictable set of spacings used everywhere in the app.<p>Once you get to the size of an app which requires a dashboard, and many specific distances, some just a tiny bit smaller or bigger, this gets unwieldy very fast. You end up coding around the spacer component or not using it entirely for some situations which makes the whole approach kinda useless.<p>The approach I take is the &quot;pass your own classname&quot;-approach. Im sure somebody has found a fancy name for it.<p>Having a componenent A:<p><pre><code> const A = ({ className }) =&gt; ( &lt;div className={`${COMPONENT_CLASSNAME} ${className}`}&gt; Hello, World! &lt;&#x2F;div&gt; ) </code></pre> You can then just pass your own classname from the parent into the child component. If your component A does not define any margins, it should be easy to define those and not break anything. As simple as that. I find that to be way more flexible than a spacer component, because most of the time, spacing depends <i>heavily</i> on context. The spacing component therefore either becomes too complex and unwieldy or does not get used at all.<p>The approach from above does have a drawback: if you dont pass a className to your component, the resulting class attribute will contain &quot;COMPONENT_CLASSNAME undefined&quot;. I have not found that to ever be a problem, although if you really want to, you can also write the template string as follows to mitigate this:<p><pre><code> `${COMPONENT_CLASSNAME} ${!!className ? className : &quot;&quot;}` </code></pre> But I do find that to be unnecessarily verbose.
评论 #22678267 未加载
disillusion大约 5 年前
In my experience, margin isn&#x27;t harmful. Using a container to space components relative to each other is harmful.<p>In fact, using margin correctly can prevent an explosion of exceptions on the relative positioning of your components. It also brings you more in line with how a designer thinks.<p>Consider this: one of the things a designer takes into consideration is composition and whitespace. In effect, this means that distances between components might change, depending on what their layout is, and what components are situated around it.<p>When you have a wrapper component, you can set some sensible spacing defaults for its children. But some components visually need more breathing room, while others need less. This depends on the design of the component. It also depends on what components comes before or after, so a simple padding won&#x27;t suffice. Two visually heavy components need more space in between as compared to two that are visually airy. You&#x27;ll eventually end up with a long list of + selectors to precisely tune every single combination. This quickly gets out of hand. With or without a wrapper element, those exceptions must be applied somewhere.<p>However, when using margins, you avoid all that. Since margins collapse, you can be assured that any combination of components has the minimum amount of whitespace between them, determined by who needs the most. Now this isn&#x27;t perfect, but it gets pretty close; any component that needs a bit more breathing room can force a larger distance. This way, you might still have one or two combination exceptions, but these will be rare.<p>So, looking at it like this, margins _are_ a property of the component itself: it&#x27;s the equivalent of a guy stretching his arms out and saying &quot;don&#x27;t come too close, I need my space!&quot;.
neya大约 5 年前
Call me old school if you like, but the cleaner solution in my eyes are to create well-defined CSS classes for such margins and use them in my designs.<p><pre><code> &lt;div class=&quot;margin-10&quot;&gt;..&lt;&#x2F;div&gt; &lt;div class=&quot;margin-20&quot;&gt;..&lt;&#x2F;div&gt; &lt;div class=&quot;margin-30&quot;&gt;..&lt;&#x2F;div&gt; </code></pre> is MUCH cleaner than:<p><pre><code> &lt;div space={3}&gt;..&lt;&#x2F;div&gt; &lt;div space={4}&gt;..&lt;&#x2F;div&gt; </code></pre> The difference being, first of all, I don&#x27;t need to dig into the source to see what `space` does. Next, appearance layer is tied to CSS and the JS takes care of the rest of the structure of the component.
评论 #22677987 未加载
评论 #22678217 未加载
jacobush大约 5 年前
I thought it would be a lean management or economics piece of how low margins are essential to a smooth economy. Or a denouncing thereof. You know, in the days of hospitals being run on just-in-time deliveries.
tcgarvin大约 5 年前
Moving spacing concerns to the parent is an interesting idea, would be fun to try out.<p>That said, I almost didn&#x27;t read the post simply because &quot;Considered Harmful&quot; is the most obnoxious title format I know of.
评论 #22677359 未加载
评论 #22677758 未加载
choward大约 5 年前
I almost didn&#x27;t read the article because of the horrible title. Anyway, I just want to say this is one of the things I like about elm-ui (a ui-library for the elm programming langauge that replaces HTML&#x2F;CSS). It has the concepts of spacing and padding. No such thing as margin. <a href="https:&#x2F;&#x2F;package.elm-lang.org&#x2F;packages&#x2F;mdgriffith&#x2F;elm-ui&#x2F;latest&#x2F;Element#padding-and-spacing" rel="nofollow">https:&#x2F;&#x2F;package.elm-lang.org&#x2F;packages&#x2F;mdgriffith&#x2F;elm-ui&#x2F;late...</a>
naringas大约 5 年前
I hope for a &quot;considered harmful considered harmful&quot; article
评论 #22677634 未加载
评论 #22677704 未加载
graemebenzie大约 5 年前
Adam Wathan &amp; Mark Dalgleish chatting about this <a href="http:&#x2F;&#x2F;www.fullstackradio.com&#x2F;134" rel="nofollow">http:&#x2F;&#x2F;www.fullstackradio.com&#x2F;134</a>
jhpriestley大约 5 年前
Spacer components + flexbox + components defined in JS&#x2F;JSX is basically a copy of how TeX does things (single unified macro language, hspace&#x2F;vspace, boxes and glue algorithm which is pretty much flexbox).<p>Feels like we could have saved a lot of time if we&#x27;d considered at the outset that maybe Knuth, an actual genius who spent years on this problem, had some pretty good ideas?
pastelsky大约 5 年前
If you start thinking as margin as a relationship between two or more blocks instead of property on a block, some of the issues with it are solved.<p>Whenever possible, I try to use the sibling selector for this –<p>.header + .nav { margin: &#x2F;&#x2F; }<p>This way, both header and nav elements remain re-usable and the margin only comes into play if they&#x27;re used in a specific layout, and it is defined in its parent.
doublejosh大约 5 年前
Sorry to be unpleasant... but DUH. This was true long before React. It&#x27;s a core idea in assembled layouts, that is to say all layouts.<p>Margins need to come from the assembling component, rather than the detail item. Spacing requires awareness of multiple elements, which you usually don&#x27;t have internally.
DaniAkash大约 5 年前
I have a blank spacer component for react-native <a href="https:&#x2F;&#x2F;github.com&#x2F;DaniAkash&#x2F;react-native-blank-spacer" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;DaniAkash&#x2F;react-native-blank-spacer</a>. I have been using this to eliminate margins in my existing projects
winrid大约 5 年前
But the parent consuming a component can add margin to the child component without breaking encapsulation.
madjam002大约 5 年前
Been doing this for years! In addition to this I recommend a &lt;Content&gt; component which lays out margins for typography just like you would get in a vanilla HTML document for h1,p,etc, but outside of that everything should use spacing components
quotemstr大约 5 年前
Can&#x27;t you just override margin with an &quot;!important&quot; rule? I disagree with this article&#x27;s exhortation. Cascading style sheets have priorities and override mechanisms for a reason.
the_mitsuhiko大约 5 年前
Every web frontend codebase I have every aged incredibly badly. System A was replaced (inconsistently) with system B after half a year. Ideas and concepts thrown out as well.
campsafari大约 5 年前
Having layout and component design decoupled is the way to go in largescale component driven systems. Not Necessary in your small wordPress theme like site though
rustybolt大约 5 年前
Ha, I thought &#x27;Margin&#x27; would be the name of the latest javascript framework. I&#x27;m not sure if the claim that margin is bad is funnier or less funny.
klodolph大约 5 年前
Fuck it, I’m gonna use SVG for layout in my next web app.
aen大约 5 年前
Design for the sake of shipping, not for the sake of design.
leeoniya大约 5 年前
...and watch your DOM weight at least double in size and JS perf drop substantially due to a ton more components.
msla大约 5 年前
Ironic that this is on a page with grotesquely huge margins.
评论 #22677295 未加载