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

推荐订阅源

月光博客
月光博客
人人都是产品经理
人人都是产品经理
C
Check Point Blog
大猫的无限游戏
大猫的无限游戏
小众软件
小众软件
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
博客园 - 聂微东
Help Net Security
Help Net Security
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
L
LINUX DO - 最新话题
Cloudbric
Cloudbric
博客园 - Franky
阮一峰的网络日志
阮一峰的网络日志
O
OpenAI News
V2EX - 技术
V2EX - 技术
H
Hacker News: Front Page
Hacker News: Ask HN
Hacker News: Ask HN
Google DeepMind News
Google DeepMind News
PCI Perspectives
PCI Perspectives
爱范儿
爱范儿
Hacker News - Newest:
Hacker News - Newest: "LLM"
Martin Fowler
Martin Fowler
S
Schneier on Security
Webroot Blog
Webroot Blog
Know Your Adversary
Know Your Adversary
云风的 BLOG
云风的 BLOG
H
Help Net Security
I
InfoQ
Simon Willison's Weblog
Simon Willison's Weblog
雷峰网
雷峰网
J
Java Code Geeks
V
Visual Studio Blog
MyScale Blog
MyScale Blog
C
CXSECURITY Database RSS Feed - CXSecurity.com
C
CERT Recently Published Vulnerability Notes
Google Online Security Blog
Google Online Security Blog
Spread Privacy
Spread Privacy
有赞技术团队
有赞技术团队
The GitHub Blog
The GitHub Blog
Engineering at Meta
Engineering at Meta
V
V2EX
Apple Machine Learning Research
Apple Machine Learning Research
www.infosecurity-magazine.com
www.infosecurity-magazine.com
A
About on SuperTechFans
S
SegmentFault 最新的问题
H
Hackread – Cybersecurity News, Data Breaches, AI and More
TaoSecurity Blog
TaoSecurity Blog
WordPress大学
WordPress大学
S
Securelist
P
Proofpoint News Feed

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
Taming data tables
Harry Roberts · 2013-11-22 · via CSS Wizardry

Written by on CSS Wizardry.

Table of Contents

Independent writing is brought to you via my wonderful Supporters.

  1. The problems
    1. Cell widths
    2. Spanning cells
    3. Knock-on effects
    4. Tables next to tables
    5. Featured case study: NHS
  2. Solution
    1. 24 cells
    2. Equal width columns
  3. Combining the two

tables are a pain to work with, there are no two ways about it; they’re horrible. Tonnes of similar-looking, heavily-nested markup that is completely inflexible. One of the biggest problems I ever encountered was working on Sky Bet, whose content is almost exclusively data tables, and making tables’ cells line up nicely not only with each other, but also with those cells in other tables on the page.

This is a very complex problem to explain, so I have been sure to create a demo.

The problems

There are a lot of headaches we encounter when building tables, and I imagine most of you reading this article will nod along to every point I make; it will be something that will have annoyed us all at some point or another. What this particular (and very specific) problem boils down to is trying to consistently format, size and align complex data layouts across multiple tables. Imagine a financial report; loads of tables of data with differing numbers of cells and columns that—from a purely aesthetic perspective—need to line up in some neat, coherent fashion. Achieving this is made very difficult by a number of different factors…

Cell widths

Tables lay out their cells—by default—in a rather unusual, almost haphazard way. There seems to be no rhyme or reason behind how and why they are rendered at the widths they are, which leads to columns and cells of differing sizes.

Spanning cells

In order to have cells span several columns (and rows, but that doesn’t pose the same problems), we have to use the colspan attribute. To have a cell spanning two columns we would write <t[h|d] colspan="2">. These are often unmanageable, and it can be confusing to remember what all your colspans should add up to.

Knock-on effects

Resizing one cell in one row can, and usually will, affect the layout of the entire table. This is is because all cells’ boundaries have to line up with the boundaries of the rest of the row and column in which it sits. You can’t just change the width of one cell, you have to change them all. This means that, for example, spanning one cell across x columns might mean having to update a whole load more colspans elsewhere in the table.

Tables next to tables

The above problems are further compounded when you begin laying out multiple different tables on any given page. In Sky Bet world, this was pretty much every page. One table’s rendered layout might be vastly different to the tables above and/or below it, creating an unsightly mess of misaligned columns. You might have a table with no colspans above a table with some colspans, above a table with lots of awkward colspans. You might have a table with lots of cells above a table with very few. You might have any combination of amounts of cells and amounts of colspans. It all gets very hairy, very quickly.

Featured case study: NHS

How I helped the NHS rapidly build a brand new product.

Read case study…

Solution

I’ve come up with what I feel is a solid, very pragmatic solution.

There are two parts to solving this problem. Firstly we need to standardise the number of cells in every table, and then we need to force these cells to all be the same width. Think of this as a grid system for tables.

24 cells

Think about page layouts that adhere to a grid system; you might have a 24 column grid, but your page might only have two main columns which span, say, 16 and eight columns respectively. You can’t see the 24 columns, but they’re there. You might then have a large footer broken into three columns of eight (again, adding up to 24).

We need to apply this model to tables; we shall give all tables 24 columns, and then use a generous amount of colspans to knock our cells through into each other, into more useful layouts. Now every table we build will be based on a 24 column grid which will, firstly, make everything more consistent, and, secondly, it will make our maths much simpler. We just need to make sure every row’s colspan values add up to 24 every time.

This does mean that every cell in the table now has to carry a colspan, but as I said, this solution is a pragmatic one.

The reason we pick 24 is because it can take halves, thirds, quarters, sixths, eighths and twelfths; we can make a lot of layouts if we have 24 columns to play with.

Now, we would write this snippet:

...
    <th>Column one</th>
    <th>Column two</th>
    <th>Column three</th>
...

as:

...
    <th colspan="8">Column one</th>
    <th colspan="8">Column two</th>
    <th colspan="8">Column three</th>
...

For all this is more markup, it does mean we can begin to standardise our tables’ layouts so that multiple tables on the same page can share a lowest common multiple and are now able to be aligned to one another.

The short version of this section is basically: we are setting up a grid system for our tables.

Equal width columns

It’s all well and good that all our tables have the same number of columns, but that doesn’t escape the fact that browsers will still render every table differently, and that the size of these cells will always vary. There’s no point having a 24 column table-grid-system if each column is a different width. Thankfully, this is the easiest part of the puzzle to solve and, probably, the most interesting part of this article: table-layout: fixed;.

There is a little known, and even less used, CSS property called table-layout. table-layout basically tells a browser how to render the columns in a table, and is, by default, set to auto. auto means that the browser will automatically render the cells in a table based on their width, which leads to the differently and inconsistently sized columns.

Interestingly, table-layout: fixed; is the backbone of my pure CSS, equal-width tabs.

Setting table-layout to fixed however, tells the browser to render every cell the same width as each other. Equally-sized table cells right out of the box!

Combining the two

By giving our tables a common grid system of 24 columns, and ensuring these columns are all of equal width, we can begin throwing together all manner of layouts.

I would propose that you opt into the table-grid-system via a simple helper class, perhaps .table-grid:

.table-grid {
    table-layout: fixed;
}

Every time we want to build a table to a fixed and consistent layout, we simply invoke the grid and lay it out to that.

Here’s a demo.