Back in time over a decade ago, web development was still living
through its infancy. Developers would commonly build website layouts
constructed with HTML4 tables, and this was standard practice most of
the time. When CSS finally grew into popularity precedents began to
change. It was now easier for developers to use div elements and
position everything with CSS stylesheets.
But even following modern practices of HTML5/CSS3 we can still find a use for tables. The specifications haven’t changed much since HTML4 and with good reasoning. In this article I’d like to share a few techniques and ideas for when you should be using tables in your webpages. We can also look into where tables will be going in the future of content on the Internet.
Fluid-width layouts were very popular since design aesthetics have not always been as influential. As CSS became more prevalent it didn’t make sense to style webpages using table attributes anymore. Each row of data had to be split by
But this formatting has continued to this day with modern HTML5 tables. You can read a bit more about the HTML table element from W3Schools excellent resources page. There is also a list of related tags and optional attributes correlated with formatting tables.
HTML tables are great for data listings, catalogs, image galleries, products, or anything with a similar block-style layout. You’ll be able to create these pages using CSS but it’s going to require a litany of additional properties. So why even go with that route if it requires additional work?
Tables can naturally be split into core sections with a header, body, and footer. This schematic follows any traditional layout where you’ll have some header rows to define the datatypes, followed by a long list of data rows. Adding a footer is completely optional but it can be used for some type of legend or table key index.
To scale this out even further you can add a whole descriptive block of text defining your table output. The newer HTML5 tags for details and summary are ultimately optional but very useful. I can think of various corporate environments where you need to describe various bits of data and share it onto a public webpage.
This extra content is beneficial not just for the end user, but also for search engine crawlers. Captions are considered much like table headers and the summary description is a good way to load up related keywords. Again these are completely optional tags, but they can exert a large effort towards keeping your webpage organized.
One of my favorite scripts is named Tablecloth which is a completely dynamic open source solution based on JavaScript. By including a copy of the CSS/JS files you can add hover functionality to any table element in your webpage. As you mouse over table cells you’ll see a highlighted row and column effect matching your current position.
The extensibility of these scripts only adds to the growing collection of open source solutions perfectly formatted to be used by more advanced frontend web developers.
Tabular data can be found in almost every website so it’s not cheating to use divs or other markup instead. Tables are beneficial to developers who understand why they’re using that markup and how you can format rows & columns together. Tabular layouts are perfect for galleries with smaller thumbnails linking to full images, videos, whatever.
I would argue the largest reason to not use tables is when formatting your overall website layout. The newer HTML5 header, footer, nav, and section elements fit the roles much better. But understand there is no “wrong” area to use tables in your content. It ultimately boils down to personal preferences and what you feel comfortable designing into your markup.
I hope this article can provide some deeper insight for newer web developers. It’s true that almost nobody suggests building an entire website with tables anymore. But it’s also true that nobody is ruling out tables as a deprecated element. There is a purpose for every bit of website markup and following these standards will get you more experience as a skilled web developer.
But even following modern practices of HTML5/CSS3 we can still find a use for tables. The specifications haven’t changed much since HTML4 and with good reasoning. In this article I’d like to share a few techniques and ideas for when you should be using tables in your webpages. We can also look into where tables will be going in the future of content on the Internet.
Historical Origins
Tables were originally the best solution for website layouts because of their flexibility. Developers wanted to support all screen resolutions and tables could handle these additional attributes. These include the width attr which was specified in a percentage value. This means your table rows would adjust naturally based on a percentage of the browser window.Fluid-width layouts were very popular since design aesthetics have not always been as influential. As CSS became more prevalent it didn’t make sense to style webpages using table attributes anymore. Each row of data had to be split by
<tr>
tags which would eventually feel bulky and abnormal.But this formatting has continued to this day with modern HTML5 tables. You can read a bit more about the HTML table element from W3Schools excellent resources page. There is also a list of related tags and optional attributes correlated with formatting tables.
How To Display Tabular Data
By far the most common useage of modern tables is when formatting tabular data. This may seem like a no-brainer but I have run into countless developers who simply loathe tables. It’s like an all-or-nothing relationship where you either use them or you don’t. This is a horrible attitude since you’re fighting against the natural order!HTML tables are great for data listings, catalogs, image galleries, products, or anything with a similar block-style layout. You’ll be able to create these pages using CSS but it’s going to require a litany of additional properties. So why even go with that route if it requires additional work?
Tables can naturally be split into core sections with a header, body, and footer. This schematic follows any traditional layout where you’ll have some header rows to define the datatypes, followed by a long list of data rows. Adding a footer is completely optional but it can be used for some type of legend or table key index.
Formatted Table Captions
Another newer addition with HTML5 are table captions which hover towards the top of the page. These fields are often inside the table element yet right before you open any new content rows. It’s almost like a header to define the content found inside your table listing.To scale this out even further you can add a whole descriptive block of text defining your table output. The newer HTML5 tags for details and summary are ultimately optional but very useful. I can think of various corporate environments where you need to describe various bits of data and share it onto a public webpage.
This extra content is beneficial not just for the end user, but also for search engine crawlers. Captions are considered much like table headers and the summary description is a good way to load up related keywords. Again these are completely optional tags, but they can exert a large effort towards keeping your webpage organized.
Dynamic JS Effects
Tables can be even cooler if you pair JavaScript libraries into your layout. It’s possible to allow users functionality such as drag-and-drop, inline editing, and so much more. Think of all the different pricing tables or member lists you’ve ever seen. All those layouts can be created custom from scratch and even optimized using tables.One of my favorite scripts is named Tablecloth which is a completely dynamic open source solution based on JavaScript. By including a copy of the CSS/JS files you can add hover functionality to any table element in your webpage. As you mouse over table cells you’ll see a highlighted row and column effect matching your current position.
The extensibility of these scripts only adds to the growing collection of open source solutions perfectly formatted to be used by more advanced frontend web developers.
How to Determine Proper Situations?
It can be difficult figuring out which situations require a table in your layout. I very rarely use them except for content which is often formatted into rows. One reason this works well is because you don’t need to adjust floating divs and create “artificial” rows in your markup.Tabular data can be found in almost every website so it’s not cheating to use divs or other markup instead. Tables are beneficial to developers who understand why they’re using that markup and how you can format rows & columns together. Tabular layouts are perfect for galleries with smaller thumbnails linking to full images, videos, whatever.
I would argue the largest reason to not use tables is when formatting your overall website layout. The newer HTML5 header, footer, nav, and section elements fit the roles much better. But understand there is no “wrong” area to use tables in your content. It ultimately boils down to personal preferences and what you feel comfortable designing into your markup.
Conclusion
Tables are still just as relevant in web design today as they have ever been over the years. Developers have evolved and found better tools for creating entire website layouts. But this has also guided new semantics which follow content as the primary motivator in web development.I hope this article can provide some deeper insight for newer web developers. It’s true that almost nobody suggests building an entire website with tables anymore. But it’s also true that nobody is ruling out tables as a deprecated element. There is a purpose for every bit of website markup and following these standards will get you more experience as a skilled web developer.
Your blogs are totally worth giving time and energy. wp themes
ReplyDeleteThanks for the guide!
ReplyDeleteThat was really useful
Melbourne Web Developer
ReplyDeleteInformative Blog.
UI Development Training
UI Development Training in Hyderabad
UI Development Online Training
Damien Grant
ReplyDeleteDamien Grant
Damien Grant
Damien Grant
Damien Grant
Damien Grant
Damien Grant
Damien Grant
Damien Grant
ReplyDeleteDamien Grant
Damien Grant
Damien Grant
Damien Grant
Damien Grant
Damien Grant
Damien Grant