table-layout – CSS-Tricks

Faking Min Width on a Table Column

Anders Pedersen — Tue, 10 Jan 2023 15:11:20 +0000

The good ol’

tag is the most semantic HTML for showing tabular data. But I find it very hard to control how the table is presented, particularly column widths in a dynamic environment where you might not know how much content is going into each table cell. In some cases, one column is super wide while others are scrunched up. Other times, we get equal widths, but at the expense of a column that contains more content and needs more space.

But I found a CSS tricks-y workaround that helps make things a little easier. That’s what I want to show you in this post.

The problem

First we need to understand how layout is handled by the browser. We have the table-layout property in CSS to define how a table should distribute the width for each table column. It takes one of two values:

auto (default)
fixed

Let us start with a table without defining any widths on its columns. In other words, we will let the browser decide how much width to give each column by applying table-layout: auto on it in CSS. As you will notice, the browser does its best with the algorithm it has to divide the full available width between each column.

CodePen Embed Fallback

If we swap out an auto table layout with table-layout: fixed, then the browser will merely divide the full available space by the total number of columns, then apply that value as the width for each column:

CodePen Embed Fallback

But what if we want to control the widths of our columns? We have the

element to help! It consists of individual elements we can use to specify the exact width we need for each column. Let’s see how that works in with table-layout: auto:

CodePen Embed Fallback

I have inlined the styles for the sake of illustration.

The browser is not respecting the inline widths since they exceed the amount of available table space when added up. As a result, the table steals space from the columns so that all of the columns are visible. This is perfectly fine default behavior.

How does

work with table-layout: fixed. Let’s find out:

CodePen Embed Fallback

This doesn’t look good at all. We need the column with a bunch of content in it to flex a little while maintaining a fixed width for the rest of the columns. A fixed table-layout value respects the width — but so much so that it eats up the space of the column that needs the most space… which is a no-go for us.

This could easily be solved if only we could set a min-width on the column instead of a width. That way, the column would say, “I can give all of you some of my width until we reach this minimum value.“ Then the table would simply overflow its container and give the user a horizontal scroll to display the rest of the table. But unfortunately, min-width on table columns are not respected by the

element.

The solution

The solution is to fake a min-width and we need to be a bit creative to do it.

We can add an empty

as the second column for our in the HTML and apply a colspan attribute on the first column so that the first column takes up the space for both columns:

Project name		Amount	Date	Edit

Note that I have added classes in place of the inline styles from the previous example. The same idea still applies: we’re applying widths to each column.

The trick is that relationship between the first and the empty second . If we apply a width to the first (it’s 200px in the snippet above), then the second column will be eaten up when the fixed table layout divides up the available space to distribute to the columns. But the width of the first column (200px) is respected and remains in place.

Voilà! We have a faux min-width set on a table cell. The first cell flexes as the available space changes and the table overflows for horizontal scrolling just as we hoped it would.

CodePen Embed Fallback

(I added a little sticky positioning to the first column there.)

Accessibility

Let’s not totally forget about accessibility here. I ran the table through NVDA on Windows and VoiceOver on macOS and found that all five columns are announced, even if we’re only using four of them. And when the first column is in focus, it announces, “Column one through two”. Not perfectly elegant but also not going to cause someone to get lost. I imagine we could throw an aria-hidden attribute on the unused column, but also know ARIA isn’t a substitute for poor HTML.

I’ll admit, this feels a little, um, hacky. But it does work! Let me know if you have a different approach in the comments… or know of any confusions this “hack” might bring to our users.

Faking Min Width on a Table Column originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

In Defense of Tables and Floats in Modern Day Development

John Macpherson — Fri, 30 Oct 2020 14:44:15 +0000

Twenty-plus years ago, tables were the main way web pages were created in HTML. It gave web builders consistent control of constructing pages with some “design.” No longer did sites only have to be top-to-bottom in a linear manner — they could be set up with columns that align left-to-right and top-to-bottom. Back then, it was seen as a huge breakthrough.

Tables, however, were never designed to lay out pages and, in fact, have all sorts of problems when used that way today. It was a convenient hack, but at the time, a very welcome one, particularly for those trying to achieve a super-specific layout that previous ways couldn’t handle.

Fast-forward to modern days and it’s now obvious that were tons of issues with the table layout approach. Accessibility is a big one.

, and element whose first element has a width of 400px. Notice in this case, toggling table-layout: fixed has no effect.

See the Pen Demo for CSS’s table-layout property by Louis Lazaris (@impressivewebs) on CodePen.

This happens because the default layout algorithm is essentially saying “make the first column 400px wide, and distribute the remaining columns based on their content”. Since the other three columns have the same content as each other, there will be no change. But now let’s add some extra text content to one of the other columns:

See the Pen Demo for CSS’s table-layout property with col width and variable content by Louis Lazaris (@impressivewebs) on CodePen.

Now if you click the toggle button, you’ll see the columns adjust to accommodate a fixed layout, irrespective of content. Once again, the same thing is happening; the first column is set at 400px then the remaining columns are divided equally. But this time, because one of the columns has extra content, the difference is noticeable.

How a fixed layout algorithm determines column widths

The following two demos should help in understanding that the first row of the table is what helps to define the column widths of a table set to table-layout: fixed.

See the Pen Demo for CSS’s table-layout with cell in row 1 given defined width by Louis Lazaris (@impressivewebs) on CodePen.

In the above demo, the first cell in the table’s first row has a width of 350px. Toggling table-layout: fixed adjusts the other columns, but the first one remains the same. Now try the following demo:

See the Pen Demo for CSS’s table-layout with cell in row 2 given defined width by Louis Lazaris (@impressivewebs) on CodePen.

In this case, it’s the second row that has a width attached to its first table cell. Now when the toggle button is clicked, all the column widths are adjusted. Again, this is because the fixed layout algorithm is using the first row to determine the column widths, and the end result is that it distributes the widths equally.

Benefits of a fixed layout algorithm

The aesthetic benefits of using table-layout: fixed should be clear from the demonstrations above. But the other major benefit is performance. The spec refers to the fixed algorithm as a “fast” algorithm, and for good reason. The browser does not need to analyze the entire table’s content before determining the size of the columns; it only needs to analyze the first row. So the result is a faster processing of the table’s layout.

Related Properties

More Information

Fixed Table Layouts
Fixed table layout in CSS2.1 spec
The table-layout property in CSS Table Module Level 3

Browser Support

,
elements aren’t exactly accessible, especially when they’re nested several levels deep. Screen readers — the devices that read web content and serve as a measure of accessibility compliance — struggle to parse them into cohesive blocks of content. That’s not to say tables are bad; they simply were never intended as a layout mechanism. Check out this table layout. Feel free to run it through VoiceOver or whatever screen reading software you have access to. CodePen Embed Fallback Yes, that example looks very much like a typical website layout, but it’s crafted solely with a table. You can see how quickly it becomes bloated and inaccessible the very moment we start using it for anything other than tabular data. So after more than 20 years of being put through the ringer, you might think we should avoid tables altogether. If you’ve never shipped a table-based layout, you’ve undoubtedly heard war stories from those of us who have, and those stories are never kind. It’s like we’ve sort of made tables the “Internet Explorer of HTML elements.” But that’s not totally fair because tables do indeed fill a purpose on the web and they are indeed accessible when they are used correctly. Tables are designed to handle data that is semantically related and is best presented in a linear-like format. So, yes, we can use tables today in the year 2020, and that will likely continue to be true many years from now. Here’s a table being used to display exactly what it’s intended to: tabular data! CodePen Embed Fallback With the push toward web standards in the early 2000s, tables were pushed aside as a layout solution in favor of other approaches, most notably the CSS `float` property. Designers and developers alike rejoiced because, for the first time, we had a true separation of concerns that let markup do the markup-y things it needs to do, and CSS to do the visual stuff it needs to do. That made code both cleaner and way easier to maintain and, as a result, we could actually focus on true standards, like accessibility, and even other practices, like SEO. See (or rather hear) the difference in this example? CodePen Embed Fallback Many of us have worked with floats in the past. They were originally designed to allow content to flow around images that are floated either to the left or right, and still be in the document flow. Now that we’ve gotten newer layout features — again, like grid and flexbox — floats, too, have sort of fallen by the wayside, perhaps either because there are better ways to accomplish what they do, or because they also got the same bad rap as tables after being (ab)used for a long time. But floats are still useful and relevant! In fact, we have to use them for the `shape-outside` property to work. CodePen Embed Fallback A legitimate `float` use case could be for wrapping content around a styled . CodePen Embed Fallback CSS features like grid, flexbox, and multicolumn layouts are among the wonderful tools we have to work with these days. With even more layout possibilities, cleaner and more accessible code, they will remain our go-to layout approaches for many years to come. No hacks or extra code in this flexbox example of the same layout we’ve looked at throughout this article: CodePen Embed Fallback So, next time you find yourself considering tables or floats, reach for them with confidence! Well, when you know the situation aligns with their intended use. It’s not like I’m expecting you to walk away from this with a reinvigorated enthusiasm for tables and floats; only that, when used correctly, they are perfectly valid techniques, and even continue to be indispensable parts of our overall toolset. In Defense of Tables and Floats in Modern Day Development originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter. table-layout Louis Lazaris — Wed, 04 Jan 2017 13:12:01 +0000 The `table-layout` property defines what algorithm the browser should use to lay out table rows, cells, and columns. `table { table-layout: fixed; }` As explained in the CSS2.1 specification, table layout in general is usually a matter of taste and will vary depending on design choices. Browsers will, however, automatically apply certain constraints that will define how tables are laid out. This happens when the `table-layout` property is set to `auto` (the default). But these constraints can be lifted when `table-layout` is set to `fixed`. Values `auto`: the default. The browser’s automatic algorithm is used to define how a table’s rows, cells, and columns are laid out. The resulting table layout is generally dependent on the content of the table. `fixed`: With this value, the table’s layout ignores the content and instead uses the table’s width, any specified width of columns, and border and cell spacing values. The column values used are based on widths defined on columns or cells for the first row of the table. `inherit`: indicates that the value is inherited from the `table-layout` value of its parent In order for a value of `fixed` to have any effect, the table’s width has to be set to something other than `auto` (the default for the `width` property). In the demos below, all the table widths are set to 100%, which assumes we want the table to fill its parent container horizontally. The best way to see the the effects of a fixed table layout algorithm is using a demo. See the Pen Demo for CSS’s table-layout property by Louis Lazaris (@impressivewebs) on CodePen. When you first view the above demo, you’ll notice the layout of the table columns is unbalanced and awkward. At that point, the table is using the browser’s default algorithm to define how to lay out the table, which means the content will dictate the layout. The demo exaggerates this fact by including a long string of text inside one table cell, while all the other table cells use just two words each. As you can see, the browser expands the first column to accommodate the larger bit of content. If you click the “Toggle table-layout: fixed” button, you’ll see what the table layout looks like when the “fixed” algorithm is used. When `table-layout: fixed` is applied, the content no longer dictates the layout, but instead, the browser uses any defined widths from the table’s first row to define column widths. If no widths are present on the first row, the column widths are divided equally across the table, regardless of content inside the cells. Further examples may help make this clearer. In the following demo, the table has a

elements aren’t exactly accessible, especially when they’re nested several levels deep. Screen readers — the devices that read web content and serve as a measure of accessibility compliance — struggle to parse them into cohesive blocks of content. That’s not to say tables are bad; they simply were never intended as a layout mechanism.

Check out this table layout. Feel free to run it through VoiceOver or whatever screen reading software you have access to.

CodePen Embed Fallback

Yes, that example looks very much like a typical website layout, but it’s crafted solely with a table. You can see how quickly it becomes bloated and inaccessible the very moment we start using it for anything other than tabular data.

So after more than 20 years of being put through the ringer, you might think we should avoid tables altogether. If you’ve never shipped a table-based layout, you’ve undoubtedly heard war stories from those of us who have, and those stories are never kind. It’s like we’ve sort of made tables the “Internet Explorer of HTML elements.”

But that’s not totally fair because tables do indeed fill a purpose on the web and they are indeed accessible when they are used correctly.

Tables are designed to handle data that is semantically related and is best presented in a linear-like format. So, yes, we can use tables today in the year 2020, and that will likely continue to be true many years from now.

Here’s a table being used to display exactly what it’s intended to: tabular data!

CodePen Embed Fallback

With the push toward web standards in the early 2000s, tables were pushed aside as a layout solution in favor of other approaches, most notably the CSS float property. Designers and developers alike rejoiced because, for the first time, we had a true separation of concerns that let markup do the markup-y things it needs to do, and CSS to do the visual stuff it needs to do. That made code both cleaner and way easier to maintain and, as a result, we could actually focus on true standards, like accessibility, and even other practices, like SEO.

See (or rather hear) the difference in this example?

CodePen Embed Fallback

Many of us have worked with floats in the past. They were originally designed to allow content to flow around images that are floated either to the left or right, and still be in the document flow. Now that we’ve gotten newer layout features — again, like grid and flexbox — floats, too, have sort of fallen by the wayside, perhaps either because there are better ways to accomplish what they do, or because they also got the same bad rap as tables after being (ab)used for a long time.

But floats are still useful and relevant! In fact, we have to use them for the shape-outside property to work.

CodePen Embed Fallback

A legitimate float use case could be for wrapping content around a styled

.

CodePen Embed Fallback

CSS features like grid, flexbox, and multicolumn layouts are among the wonderful tools we have to work with these days. With even more layout possibilities, cleaner and more accessible code, they will remain our go-to layout approaches for many years to come.

No hacks or extra code in this flexbox example of the same layout we’ve looked at throughout this article:

CodePen Embed Fallback

So, next time you find yourself considering tables or floats, reach for them with confidence! Well, when you know the situation aligns with their intended use. It’s not like I’m expecting you to walk away from this with a reinvigorated enthusiasm for tables and floats; only that, when used correctly, they are perfectly valid techniques, and even continue to be indispensable parts of our overall toolset.

In Defense of Tables and Floats in Modern Day Development originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

table-layout

Louis Lazaris — Wed, 04 Jan 2017 13:12:01 +0000

The table-layout property defines what algorithm the browser should use to lay out table rows, cells, and columns.

table { table-layout: fixed; }

As explained in the CSS2.1 specification, table layout in general is usually a matter of taste and will vary depending on design choices. Browsers will, however, automatically apply certain constraints that will define how tables are laid out. This happens when the table-layout property is set to auto (the default). But these constraints can be lifted when table-layout is set to fixed.

Values

auto: the default. The browser’s automatic algorithm is used to define how a table’s rows, cells, and columns are laid out. The resulting table layout is generally dependent on the content of the table.

fixed: With this value, the table’s layout ignores the content and instead uses the table’s width, any specified width of columns, and border and cell spacing values. The column values used are based on widths defined on columns or cells for the first row of the table.

inherit: indicates that the value is inherited from the table-layout value of its parent

In order for a value of fixed to have any effect, the table’s width has to be set to something other than auto (the default for the width property). In the demos below, all the table widths are set to 100%, which assumes we want the table to fill its parent container horizontally.

The best way to see the the effects of a fixed table layout algorithm is using a demo.

See the Pen Demo for CSS’s table-layout property by Louis Lazaris (@impressivewebs) on CodePen.

When you first view the above demo, you’ll notice the layout of the table columns is unbalanced and awkward. At that point, the table is using the browser’s default algorithm to define how to lay out the table, which means the content will dictate the layout. The demo exaggerates this fact by including a long string of text inside one table cell, while all the other table cells use just two words each. As you can see, the browser expands the first column to accommodate the larger bit of content.

If you click the “Toggle table-layout: fixed” button, you’ll see what the table layout looks like when the “fixed” algorithm is used. When table-layout: fixed is applied, the content no longer dictates the layout, but instead, the browser uses any defined widths from the table’s first row to define column widths. If no widths are present on the first row, the column widths are divided equally across the table, regardless of content inside the cells.

Further examples may help make this clearer. In the following demo, the table has a

Chrome	Safari	Firefox	Opera	IE	Android	iOS
1+	1+	1+	7+	5+	2.1+	3+

table-layout originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.