惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

AI
AI
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
N
News and Events Feed by Topic
O
OpenAI News
W
WeLiveSecurity
S
Secure Thoughts
www.infosecurity-magazine.com
www.infosecurity-magazine.com
H
Heimdal Security Blog
D
Darknet – Hacking Tools, Hacker News & Cyber Security
Schneier on Security
Schneier on Security
Cloudbric
Cloudbric
T
Threatpost
T
Troy Hunt's Blog
T
Tenable Blog
Hacker News - Newest:
Hacker News - Newest: "LLM"
K
KPMG report finds enterprise disconnect between AI and its ROI | CIO
V
Vulnerabilities – Threatpost
Google Online Security Blog
Google Online Security Blog
Recent Commits to openclaw:main
Recent Commits to openclaw:main
The Hacker News
The Hacker News
Know Your Adversary
Know Your Adversary
Forbes - Security
Forbes - Security
Cyberwarzone
Cyberwarzone
C
CXSECURITY Database RSS Feed - CXSecurity.com
P
Privacy & Cybersecurity Law Blog
L
Lohrmann on Cybersecurity
博客园 - 司徒正美
腾讯CDC
博客园 - 三生石上(FineUI控件)
爱范儿
爱范儿
J
Java Code Geeks
Hugging Face - Blog
Hugging Face - Blog
博客园 - 【当耐特】
M
MIT News - Artificial intelligence
T
The Blog of Author Tim Ferriss
MongoDB | Blog
MongoDB | Blog
酷 壳 – CoolShell
酷 壳 – CoolShell
GbyAI
GbyAI
D
Docker
V
Visual Studio Blog
云风的 BLOG
云风的 BLOG
I
InfoQ
WordPress大学
WordPress大学
人人都是产品经理
人人都是产品经理
A
Arctic Wolf
L
LINUX DO - 热门话题
The Cloudflare Blog
雷峰网
雷峰网
Microsoft Azure Blog
Microsoft Azure Blog
小众软件
小众软件

CSS Wizardry

Front-End’s Missing Metric: The TBT Window Meet Your Users Where They Are with Obs.js Better Browser Caching with No-Vary-Search font-family Doesn’t Fall Back the Way You Think What Is CSS Containment and How Can I Use It? When All You Can Do Is All or Nothing, Do Nothing Obs.js: Context-Aware Web Performance for Everyone Low- and Mid-Tier Mobile for the Real World (2025) The Fastest Site in the Tour de France Making Sense of the Performance Extensibility API Why Do We Have a Cache-Control Request Header? HTML Is Not a Programming Language… Build for the Web, Build on the Web, Build with the Web Licensing Code on CSS Wizardry A Layered Approach to Speculation Rules Designing (and Evolving) a New Web Performance Score Core Web Vitals Colours The Ultimate Contract Templates for Tech Consultants: Protect Your Business and Get Paid Optimising for High Latency Environments Cache Grab: How Much Are You Leaving on the Table? blocking=render: Why would you do that?! Correctly Configure (Pre) Connections The Three Cs: 🤝 Concatenate, 🗜️ Compress, 🗳️ Cache What Is the Maximum max-age? How to Clear Cache and Cookies on a Customer’s Device The Ultimate Low-Quality Image Placeholder Technique Core Web Vitals for Search Engine Optimisation: What Do We Need to Know? The HTTP/1-liness of HTTP/2 In Defence of DOM­Content­Loaded Site-Speed Topography Remapped Why Not document.write()? Speeding Up Async Snippets Critical CSS? Not So Fast! Measure What You Impact, Not What You Influence Optimising Largest Contentful Paint Measuring Web Performance in Mobile Safari Site-Speed Topography Speed Up Google Fonts Real-World Effectiveness of Brotli Performance Budgets, Pragmatically Lazy Pre-Browsing with Prefetch Making Cloud.typography Fast(er) Time to First Byte: What It Is and How to Improve It Self-Host Your Static Assets Tips for Technical Interviews Cache-Control for Civilians Bandwidth or Latency: When to Optimise for Which ITCSS × Skillshare What If? CSS and Network Performance The Three Types of Performance Testing Getting to Know a Legacy Codebase Image Inconsistencies: How and When Browsers Download Images Identifying, Auditing, and Discussing Third Parties My Digital Music Setup Measuring the Hard-to-Measure Finding Dead CSS The Fallacies of Distributed Computing (Applied to Front-End Performance) Ten Years Old Relative Requirements Airplanes and Ashtrays Performance and Resilience: Stress-Testing Third Parties Refactoring Tunnels Little Things I Like to Do with Git Writing Tidy Code Configuring Git and Vim Base64 Encoding & Performance, Part 2: Gathering Data Base64 Encoding & Performance, Part 1: What’s Up with Base64? Code Smells in CSS Revisited Typography for Developers Moving CSS Wizardry onto HTTPS and HTTP/2 Ack for CSS Developers A New Year, a New Focus Preparing Vim for Apple’s Touch Bar Choosing the Correct Average CSS Shorthand Syntax Considered an Anti-Pattern CSS Wizardry Newsletter Nesting Your BEM? Improving Perceived Performance with Multiple Background Images Continue Normalising Your CSS Pure CSS Content Filter Pragmatic, Practical, and Progressive Theming with Custom Properties Refactoring CSS: The Three I’s Speaker’s Checklist: Before and After Your Talk Improving Your CSS with Parker The Importance of !important: Forcing Immutability in CSS Mixins Better for Performance Managing Typography on Large Apps White October Events Workshop Partnership BEMIT: Taking the BEM Naming Convention a Step Further Travelling Like You Want to, When You Have To Contextual Styling: UI Components, Nesting, and Implementation Detail Subtleties with Self-Chained Classes Cyclomatic Complexity: Logic in CSS Immutable CSS Can CSS Be Too Modular? More Transparent UI Code with Namespaces When to use @extend; when to use a mixin The Specificity Graph CSS Wizardry Ltd.: Year 1 in review
Single-direction margin declarations
Harry Roberts · 2012-06-13 · via CSS Wizardry

Written by on CSS Wizardry.

Table of Contents

Independent writing is brought to you via my wonderful Supporters.

  1. Defining vertical rhythm
  2. Confidence in portability
  3. Less to think about
  4. Exceptions
    1. Breaking the rule
  5. Final word

This morning I awoke to find Smashing Magazine had retweeted a tweet I made two months ago about how you should always try and apply margins in one direction only. This, like most rules in web development, is a very general (and breakable) rule. It’s even a rule you can opt not to follow at all, but after receiving a slew of Tweets asking why, I thought I’d write up why it’s a rule I live by, and one I’d recommend to anyone…

I’m not sure how I arrived at this rule, but I’m really glad I did and I would likely never ever change it. The basic premise is that you should try and define all your margins in one direction. This means always use margin-bottom to push items down the page, and margin-left to push them across the page. I’m going to focus mainly on margin-bottom throughout this article as it’s the most obvious to explain, but this can be applied to both directions (top/bottom, right/left).

The benefits are, as I see them:

  • Easier to define vertical rhythm in one fell swoop.
  • More confidence in (re)moving components if you know their margins all push in the same direction.
  • Components and elements don’t have to necessarily live in a certain order if their margins aren’t dependent on adjoining sides.
  • Not being concerned with collapsing margins means one less thing to worry about.

Defining vertical rhythm

This next bit on its own is enough to convince me, this one tip is one of the most valuable ones I have, personally.

Whenever I start a new project I typically want to know two things; my base font-size and my base line-height. Let’s say that I choose a base font-size of 16px and a base line-height of 24px. This gives me (in proper units) this:

html{
    font:1em/1.5 "Comic Sans MS", cursive;
}

That 1.5 is my Magic Number. This is massively important; knowing this number allows me to set up my entire project’s vertical rhythm in one go:

h1,h2,h3,h4,h5,h6,hgroup,
ul,ol,dd,
p,figure,
pre,table,fieldset,hr{
    margin-bottom:1.5rem;
}

Bosh. Done. Now any block level element (I may have missed some) I add anywhere in that page will have a line-height of 24px (if my base font-size is 16px) and will be spaced apart by 24px (again, if my base font-size is 16px).

I can extend that list of selectors as and when I need to and all will remain in order:

h1,h2,h3,h4,h5,h6,hgroup,
ul,ol,dd,
p,figure,
pre,table,fieldset,hr,
.header,.media,.island{
    margin-bottom:1.5rem;
}

For me that is reason enough to stick to just defining my margins in one direction, I can just drop any element anywhere and it will obey the same vertical rhythm as any others.

Confidence in portability

So if I know that all my margins are consistently in the same direction then I can be a lot more confident that if I add, move or remove an element my spacing won’t mess up. This isn’t just about something as pretentious as vertical rhythm, this is about spacing in general. If everything is the same then it doesn’t really matter what is where, it all behaves similarly.

If I had some odd situation where I have a margin-top on element A, a margin-top and margin-bottom on element B and a margin-bottom on element C how can I be sure that removing B won’t break anything? I can’t, because I mixed up my margins!

Less to think about

So if you can be sure things are a lot less likely to break there’s one less thing to worry (as much) about.

One counter argument I got on Twitter today was that I didn’t ‘get’ collapsing margins. This kind of response really annoys (and offends) me. A similar one I get is ‘You just don’t understand specificity!’ whenever I advise against the use of IDs. It’s a developer’s understanding of a subject that allows them to know when to avoid or circumvent something.

Collapsing margins aren’t rocket science but they are one more caveat, one more thing to remember. Look at all that in the spec, all of that to have to consider just as a result of adjoining margins on elements. Don’t mix margin-top and margin-bottom and you won’t even need to think about that.

As a developer gets better they try to be less clever. I know where using IDs can be a pain so I save myself the hassle by not using them, same with collapsing margins; no one gets points for taking the more complex route. I honestly believe that if anything with caveats or potential ‘gotchas’ can be avoided they should be*.

I find I have never had any collapsed margin oddities in any of my projects because I avoid introducing the possibility.

Exceptions

By applying the margin-bottom to all block-level elements that means that most things you put into a page will carry that spacing. Let’s say for example you have a heading in a promotional box that you don’t wish to have a margin-bottom, simply override the rule as you would with any sensibly architected CSS:

h1,h2,h3,h4,h5,h6,hgroup,
...{
    margin-bottom:1.5rem;
}
...
.promo-title{
    padding-bottom:1.5rem;
    border-bottom:1px solid #ccc;
    margin-bottom:0;
}

Using more specific selectors you can undo or alter your spacings with ease.

In working at Sky, there were times when we wanted a larger break between one section and another, let’s say double (3rem) between a carousel and the content below it. Simple:

.carousel{
    ...
    margin-bottom:3rem;
    ...
}

Interestingly, what I actually did was create an abstract class of .landmark which carried that margin-bottom:3rem; to denote any content that was deemed a large, thematic break in the page (signified by larger spacing).

Other times we had a boxed-off bit of content for which I used the Island Object. Some CSS like this…

.island{
    padding:1.5rem;
    -webkit-border-radius:4px;
       -moz-border-radius:4px;
            border-radius:4px;
}

…would often lead to compounding margin-plus-padding issues, thus. The solution here was simply to remove the margin-bottom from the last element, like so.

Breaking the rule

Obviously there will come a time when this rule needs breaking; we can’t even try and kid ourselves–all web development rules get broken. However, before you do go against it, double and triple check that there isn’t a nicer solution. I really cannot remember the last time I broke this rule, but I’m sure I have and will need to in future. I just really, really try not to.

Final word

Everything I’ve written here is nigh on impossible to prove and isn’t quantifiable, but speaking anecdotally and from experience on some huge websites, the method I use works perfectly. More than perfectly. I genuinely cannot remember a time I have had problems with collapsing margins or spacing issues or anything arising from arbitrary margin declarations.

If you think this might be of use then I urge you to try it, it really has worked wonders on every site I’ve ever employed this on. Conversely, if I’ve missed a trick please do tell me!

If you don’t like the idea of it then that’s totally cool; I can’t prove anything and if you’re comfortable as you are then that’s great!

*From the guy who likes unquoted attributes in HTML… I know!