Detailed explanation of the practical use of HTML table layout

Detailed explanation of the practical use of HTML table layout

When is the table used?

Nowadays, tables are generally no longer used for the overall layout of a web page. However, when faced with certain specific designs, such as form input and data presentation, tables may be the most appropriate choice.

The most intuitive impression of a table is that it is an element composed of multiple cells arranged neatly, and you can clearly see the rows and columns. This can be associated with Excel. From Excel's position in data processing and statistics, we can understand the significance of tables on web pages.

Simply put, using a table will make things much easier when you can intuitively feel that multiple elements are arranged in rows and columns. For example, the table is used in caniuse.com:
2015728173924594.png (470×175)

Table layout calculation

Using a table is simple, but sometimes the final state of each grid in the table may not be what you want. For example, if some cells have line breaks, the entire table will look very unsightly because of the line breaks. Especially for tables used for data presentation, width allocation is a very important topic. You may need to carefully calculate the total width of the table based on the data that may be presented in each column.

This is because the table has its own characteristics in layout. It will follow certain principles and determine its actual layout through calculation. Next, this article uses an actual table test example to explore how the table calculates its own layout.
Initial Statement

This article only covers the most common ways to use tables and does not cover all situations. Different browsers interpret some concepts of tables differently, but the layout calculations are basically the same (if there are differences, they will be mentioned separately).

The test tables used below will all look like this (the content is taken from Zero Tracks):
2015728173942365.jpg (535×183)

At the same time, the table will set border-collapse:collapse; and border-spacing:0;. This is also the most common way to apply tables. Normalize.css uses this part as the initialization definition.
Two algorithms

The table-layout CSS property defined on the <table> element determines the algorithm used by the table when calculating layout. It has two values, auto and fixed. In general, the default value auto is used.

The difference between these two algorithms lies in whether the width layout of the table is related to the data content in the table. This article will discuss the layout calculation principles of the table for these two types of values.
Automatic table layout-auto

The characteristic of automatic table layout is that the width layout of the table is related to all the data content in the table. It needs to obtain all the table content before determining the final width layout and then display them together.

It seems that the key point is "content relevance". What happens if the table defines a fixed width (500px here) and all cells do not define a width (only CSS-defined width is discussed)? Let’s look at the results:
2015728174002286.jpg (538×116)

In the table above, the blank parts are filled with spaces. After comparison, we can find the following points:

Columns 2 and 3 are the same width.
The ratio of the width of the first column to the width of any subsequent columns seems to be 2:1.
The combined width of all columns, including borders and padding, equals the width defined by the table.

Each cell has no defined width, so the width layout is completely determined by the specific content data (text information). How to explain such results? You can first intuitively infer the following logic:

Step 1: Select the column with the most text content (under the condition of no line breaks, the width occupied by the text is the widest) from each column as the "representative".
Step 2 compares the width of the "representatives" of each column, and then distributes the total width of the table, including borders and padding, to them according to their width ratio.

Referring to the above logic, let’s look back at the previous table. Doesn’t it make some sense? Note that it said earlier that the width ratio "seems" to be 2:1, what would this be? Let’s look at a version without the padding:
2015728174128545.jpg (558×87)

Use the front-end debugging tool to take a closer look at the width of the cells above. You will find that this table is different from the previous one, and the ratio is very close to 2:1 (yes, there is this little bit because of the border, but without the border, the columns cannot be distinguished).

It can be seen that when analyzing the width ratio, the content width, padding, and border are all taken into account. This also shows that it is not the number of characters that is measured, but the width that the characters can occupy without wrapping (the 2:1 here comes from the fact that Chinese characters are of equal width). The use of padding is of course just to make the table more beautiful :).

What happens when there is a width definition? Here is a table with some cells having widths defined:
2015728174212099.jpg (553×142)

Its corresponding html code is:

XML/HTML CodeCopy content to clipboard
  1. < table   class = "exhibit_table" >   
  2.      < tr >   
  3.          < th > one two </ th >   
  4.          < th   style = "width:200px;" >   </ th >   
  5.          < th >   </ th >   
  6.      </ tr >   
  7.      < tr >   
  8.          < td   style = "width:5px;" >   </ td >   
  9.          < td > </ td >   
  10.          < td >   </ td >   
  11.      </ tr >   
  12.      < tr >   
  13.          < td >   </ td >   
  14.          < td   style = "width:70px;" >   </ td >   
  15.          < td > One, Two, Three, Four </ td >   
  16.      </ tr >   
  17. </ table >   

The following points can be found in the above table:

The actual width of a cell set to 5px is 13px, which is exactly the width of a single Chinese character. The cells with Chinese characters in the same column arrange the text in the form of the minimum cell width (so, the line breaks).
A cell with a width of 200px will actually be rendered with a width of 200px, even though there is a 70px width definition for the same column.
The third column, which does not have an exact width defined, ends up with the remaining width of the table after allocating the first and second columns.

The inference of this is that when there are both columns with and without width definitions:

If the defined width of a cell is smaller than the minimum arrangement width of its content (the width required for the cell when as many rows as possible are arranged in the cell, as opposed to the non-wrapped arrangement), the column where the cell is located will present the content in the minimum arrangement.
If the content width of a cell in the same column (without line breaks, this term is used in the following text) is smaller than the maximum width defined in the column, the actual width of the column is equal to the width defined.
Columns without defined widths will have their widths allocated by the table first, after being allocated to columns with defined widths (again, the ratio between them depends on the content width).

The one at the front that has no width definition can be regarded as case 1. Some columns here have width definitions, while some do not, which can be regarded as case 2. Here is case 3, when all columns have widths defined:
2015728174233994.jpg (549×98)

Corresponding html code:

XML/HTML CodeCopy content to clipboard
  1. < table   class = "exhibit_table exhibit_table_with_no_padding" >   
  2.      < tr >   
  3.          < th   style = "width:50px;" >   </ th >   
  4.          < th   style = "width:50px;" >   </ th >   
  5.          < th   style = "width:100px;" >   </ th >   
  6.      </ tr >   
  7.      < tr >   
  8.          < td >   </ td >   
  9.          < td >   </ td >   
  10.          < td >   </ td >   
  11.      </ tr >   
  12.      < tr >   
  13.          < td >   </ td >   
  14.          < td >   </ td >   
  15.          < td >   </ td >   
  16.      </ tr >   
  17. </ table >   

In the table above, the padding is removed so the values ​​can be clearly defined by the width, resulting in a width ratio of 2:1:1 for the three columns. There is another condition here, that is, the width of the content in the cell does not exceed the defined width value. After testing, IE7 and below behave differently from other browsers when the content exceeds the defined width.

From this table example, we can know that if all columns have width definitions, and the sum of the values ​​of these width definitions is less than the width of the table, the table will continue to allocate the remaining width to them according to their width ratio after allocating the widths corresponding to their width definition values.

The above is an analysis of three situations when the automatic table layout is used and the table itself defines a fixed width. If the table itself does not define a width, there will be more situations, and it will be related to the table's containing block (details). If there is a suitable opportunity in the future, we will discuss it again (the so-called article length is limited...).
Fixed table layout-fixed

The characteristic of fixed table layout is that the width layout of the table is independent of the data content in the table. It only needs to receive the information of the first row of the table to determine the final width layout and start displaying.

Fixed table layout is "content-independent" and it emphasizes the "first row". Take a look at the following table example:
2015728174250768.jpg (551×165)

Corresponding html code:

XML/HTML CodeCopy content to clipboard
  1. < table   class = "exhibit_table exhibit_table_fixed" >   
  2.      < tr >   
  3.          < th   style = "width:50px;" > </ th >   
  4.          < th > one two </ th >   
  5.          < th > one two three four </ th >   
  6.      </ tr >   
  7.      < tr >   
  8.          < td > Estel Bright </ td >   
  9.          < td   width = "1000px;" >   </ td >   
  10.          < td >   </ td >   
  11.      </ tr >   
  12.      < tr >   
  13.          < td   style = "width:5px;" >   </ td >   
  14.          < td >   </ td >   
  15.          < td >   </ td >   
  16.      </ tr >   
  17. </ table >   

The logic of fixed table layout is much simpler and is expressed as follows:

Only take the information of the first row, ignoring the content of all cells after the first row and the width definition
In the first row, if the cells have defined widths, they are allocated their required widths first, and then the remaining widths are evenly distributed to the cells without defined widths.
The width allocation of the cells in the first row will determine the width layout of the table, and the content after the first row will not change the layout.

It is also important to note that when using a fixed table layout, you must define a width for the table element. If its width is not defined (that is, the default value of auto), the browser will use an automatic table layout instead.
Closing statement

In fact, there are other elements related to tables, such as <colgroup>, <thead>, <tfoot>, <caption>, etc., but they are not needed in the most common usage. In fact, they are also taken into account in the table's layout calculations. Add to that the case of cell merging, and you can probably imagine how complicated table layout calculations are.

The W3C document mentions that table layout calculation (automatic table layout) has not yet become a specification. For W3C's description of table layout calculations, see Table width algorithms.
Conclusion

In fact, making such detailed inferences about the calculation principles of table layout is not very practical. It's just that it would be helpful to have this information as a reference when you need to work out the details, although such opportunities are rare.

However, we can draw a more meaningful conclusion based on the content of this article: if the table defines the width and all cells do not define the width, then the automatic layout table will try its best to keep all your data from wrapping. If you encounter a situation where wrapping affects the appearance, it means that you must streamline the data or reduce the margins instead of trying to redo the width allocation yourself.

This time, when doing this kind of actual measurement and inference, I feel that it would be easier to understand if I explain it in detail according to the specific situation rather than presenting it in a systematic and complete manner all at once. Maybe it can be regarded as a language exercise?

<<:  Detailed use cases of MySql escape

>>:  An article explains Tomcat's class loading mechanism

Recommend

Three principles of efficient navigation design that web designers must know

Designing navigation for a website is like laying...

When the interviewer asked the difference between char and varchar in mysql

Table of contents Difference between char and var...

CentOS7.5 installation of MySQL8.0.19 tutorial detailed instructions

1. Introduction This article does not have screen...

Implementation of MySQL Multi-version Concurrency Control MVCC

Table of contents What is MVCC MVCC Implementatio...

How to deploy SpringBoot project using Dockerfile

1. Create a SpringBooot project and package it in...

About front-end JavaScript ES6 details

Table of contents 1. Introduction 1.1 Babel Trans...

Nginx/Httpd reverse proxy tomcat configuration tutorial

In the previous blog, we learned about the usage ...

A brief talk about JavaScript variable promotion

Table of contents Preface 1. What variables are p...

How to install tomcat8 in docker

1. Install tomcat8 with docker 1. Find the tomcat...

JavaScript+HTML to implement student information management system

Table of contents 1. Introduction 2. Rendering 3....

HTML iframe usage summary collection

Detailed Analysis of Iframe Usage <iframe frame...