Table of contents
- The basics of tables in HTML
- How should you use tables in HTML?
- What not to do with HTML tables
- Using HTML tables for layout leads to accessibility issues.
- If used for layout, HTML tables tend to produce messy or incorrect HTML.
- Tables can't keep up with the other layout options that we have today.
- What are some HTML table components?
- Header tag (<thead>)
- Body tag (<tbody>)
- Footer tag (<tfoot>)
- Row tag (<tr>)
- Data cell tag (<td>)
- Header cell tag (<th>)
- How Froala, a WYSIWYG editor, makes table handling easy
At some point in their lives, every web developer has used an HTML table to display, create, or edit data. In fact, people encounter HTML tables every day for different purposes, such as pricing tables, feature tables, data tables, and more. It’s a known fact that tables are the go-to HTML component when displaying data. However, there are still a few developers who use tables for other purposes. Is this good, or is this a ticking time bomb in disguise? To help clarify things, we’ve put together a guide that helps explain the use of tables in HTML. And the first thing on our agenda is to go back to HTML table basics.
The basics of tables in HTML
A table is an HTML tag that can display a set of data or other HTML elements in rows and columns. It uses the notation “<table></table>”, and its sub-elements have their own tags. Developers can use HTML tables to display text, images, lists, links, and other HTML elements. The structured display of data in tables shows a connection between each part of a data set. Thus, a table gives more meaning to interrelated data than plain text or other elements.
As long as you have data that looks perfect for spreadsheets, then the HTML table is your best option. This makes mastering table usage and handling in HTML necessary. The following sections will explain the use of tables in HTML and will focus on table components and the role of tables in HTML. Later, I’ll also show you how developers and web users can create tables without coding using an HTML editor. For now, let’s answer this burning question right away: What is the purpose of tables in HTML?
How should you use tables in HTML?
The true purpose of HTML tables is (drum roll, please) organizing data sets to help users read, understand, and analyze them better and faster. And that’s it. Currently, you should use tables only for displaying data (and editing them like in spreadsheets). Whenever you have data that you need to organize, relate, or analyze, use HTML tables. Some popular use cases include emails, bank accounts, student grades or subjects, activities, features, pricing, and song lists.
Tables allow readers to easily and accurately skim through data to make analyses, decisions, or knowledge consumption. Just think about a list of products on e-commerce websites. You can usually see a product’s name, details, prices, website of origin (if any), and pictures in a way that’s easy to read. HTML tables have become a huge part of our lives. For this reason, perfecting HTML tables is a must for developers. And to perfect the use of tables in HTML, we must understand how not to use them as well.
What not to do with HTML tables
Now, let’s talk about the other way you could use HTML tables. You all know what I’m talking about, web development veterans. Since the introduction of tables in HTML, they’ve always had just one purpose, which we’ve discussed earlier. However, some developers back then (and possibly still today) chose to use them in a different way: page layouts.
There was a time when designing page layouts using tables was common (click here for a brief history of CSS page layouts). That’s because, back then, web pages had much simpler layouts that looked more like tables. As the years passed, however, layouts became more complicated (e.g., overlapping elements, fixed navbars and footers, off-page elements, collapsible navbars). Eventually, these complex layout requirements became too much for table tags to handle. Besides, layout isn’t even the intended use for HTML tables. Here are some major reasons why we should no longer use HTML tables for layout:
Using HTML tables for layout leads to accessibility issues.
Nested tables are inevitable when you’re using tables for more complicated layouts (like on most websites nowadays). One of the biggest problems that arises from this is that people who use screen readers will have a difficult time. Screen readers tend to read tables from left to right, top to bottom, and per cell. And when you use tables for layout, they could incorrectly describe the page layout to users. This will lead to severe confusion and exhaustion for your users who use screen readers, greatly decreasing your site’s accessibility.
One could argue that you can avoid the usage of <th>, <caption>, and other table-specific tags when using tables for layout. That way, screen readers could more safely guess that what they’re seeing is a layout table rather than a data table. However, that still doesn’t solve the problems that stem from the reading direction of these readers. For example, you have some content (let’s call it “column”) that spans vertically. The reader might just read “column’s” first element and continue reading horizontally before going back to “column’s” other elements. That’s because of the left-to-right, top-to-bottom text direction of screen readers.
If used for layout, HTML tables tend to produce messy or incorrect HTML.
Tag soup is another problem that comes from complex table layouts and many nested tables. Tag soup refers to HTML code that’s incorrect in terms of either syntax or structure. As web pages get more complicated, you’ll need to nest more and more tables. When this happens, you’ll probably have a higher chance of having both syntactically and structurally incorrect code. But what if it’s no big deal and the site can still perform well? At some point, the developers will have to update or debug their code. And when that time comes, the leftover tag soup will come back to haunt them. Besides, the other ways of doing layout nowadays produce more readable, maintainable, and clean code. This brings me to the last reason.
Tables can’t keep up with the other layout options that we have today.
In modern web development, we usually design page layouts using the flex property, CSS grids, or both. The former allows developers to align content horizontally or vertically. The latter, on the other hand, provides more freedom, representing the page as a grid of rows and columns. Developers can then control where to place content within the grid and even choose the number of rows and columns that content can take up. The best part, however, is that unlike tables, these layout methods are easy to code and maintain.
Another common property of modern websites is that they’re responsive. This means that they give a smooth and consistent appearance and experience, regardless of the device used. A website designed for monitors with a 1920 x 1080 resolution, for example, should still look great on mobile screens. With layouts made from flex or CSS grids, you can have a responsive design right away.
Tables, meanwhile, are not responsive by default. Instead, their default sizes are based on the content within them. As a result, if we use a table for layout, the width of the page content will appear cut on smaller screens.
Nowadays, there are plenty of other CSS- or framework-based ways to create beautiful page layouts. For example, the grid layout combined with flex display produces the best results. Tables are better off doing what they do best: displaying data in an organized and easy-to-read manner. With that in mind, let’s see how we can do so by familiarizing ourselves with HTML table components.
What are some HTML table components?
Header tag (<thead>)
The <thead> tag represents a table’s header. Because of this, it needs to have at least one <tr> (table row) tag inside it. Furthermore, the table header has to be a child of an HTML table. It also needs to come after caption and column group (<colgroup>) elements and precede table body, footer, and row elements. The table header tag is used together with the table body and table footer tags, which we’ll also discuss below.
Body tag (<tbody>)
The <tbody> tag groups together the main content of an HTML table. Like the <thead> tag, it needs to encapsulate at least one <tr> tag. To use a <tbody> tag, you have to place it inside an HTML table and after any caption, column group, and table header elements.
Footer tag (<tfoot>)
The table footer tag groups HTML tables’ footer content together. And yes, you guessed it, it requires one or more <tr> tags. Its place, like its name suggests, is after any caption, column group, table header, and table body elements inside a table.
Row tag (<tr>)
The <tr> tag represents a table row. It needs to have at least one cell inside it and can contain both table data cells and header cells (we’ll get there later). Table rows need to be inside a <table>, <thead>, <tbody>, or <tfoot> element.
Data cell tag (<td>)
The <td> tag refers to a single cell containing some data, which can also be other elements (including nested tables). It, along with header cell tags, is the smallest component of an HTML table. As a result, it should always reside inside a <tr> tag. It also currently has three attributes, namely colspan (the number of columns that a cell should span), headers (at least one header that’s related to the cell), and rowspan (the number of rows that a cell should span).
Header cell tag (<th>)
The header cell tag is the other kind of HTML table cell. Unlike <td> elements that have plain and left-aligned text, <th> elements have bold and centered text. It has the same properties and attributes as <td> tags but has two additional attributes. The first is abbr, which refers to the abbreviated content in a header cell. The other is scope, which determines for which the header cell is a header (e.g., column, row, or group).
Using these tags (and a touch of CSS magic), developers can make modern, sleek, and presentable data tables. But what if you need to make elegant and responsive tables without much coding or effort? Or, what if you want your users to make their own tables when using your app or website (e.g., blogs, CMS, document tools, and the like)? The ideal solution is to use a WYSIWYG (what you see is what you get) editor.
How Froala, a WYSIWYG editor, makes table handling easy
A WYSIWYG HTML editor is a type of HTML editor that allows users to create and edit formatted content without coding. These editors have an interface that displays how content will look in the browser as a user creates the content. It provides efficiency and convenience for both developers and app users, so it’s important to learn about HTML editor properties.
Froala is a leading WYSIWYG editor that’s lightweight, elegant, easy to use, and feature-rich. There are numerous reasons why it’s helpful for developers across every type of app and development tool. For now, though, let’s talk about how it makes everything table-related easy for both you and your users.
- Easy table creation
- Seamless navigation and row insert using the TAB key
- Basic and advanced table operations
- Convenient table handling with the table edit pop-up
- Table and column resizing
- Styling tables and cells
- Over 100 more rich text editing features
When creating and handling tables, it doesn’t get as easy as Froala. It’s an editor that puts user experience and developer friendliness first, letting you or your users create stunning tables quickly. Integrate it into your apps, and you’ll have a powerful tool for creating tables and much more.
And that’s it for this article! This one serves as a guide that helps explain the use of tables in HTML. We talked about the basics and role of tables (remember, don’t use them for layout), table components, and a better, maintenance-free, and future-proof way of handling tables for both developers and users. Before you go, know that web development standards tend to change. So, it’s wise to stay updated with the latest changes and conventions. Remember, using tables for layout was a common, convenient, and acceptable thing back then. Who knows what could happen next, right?
Aaron Dumona former writer for Froala, showcased exceptional talent and dedication during their tenure with the company.