Table header and Table body
One of the things we didn't do in the basic example above is that the first line is not semantically pointed to the head of the table. We should have done so. The entire first line of the section does not contain data, it is just the title of each column. So we can <thead>
element to do this thing, it will wrap the first <tr>
element (it will wrap all the rows needed for the header information)
When you use an <thead>
element, the <table>
element cannot have a direct <tr>
child element, and all the rows must exist in <thead>
, <tbody>
and <tfoot>
inside. Note that we are going to include all the data rows in it <tbody>
.
End of table
Together <thead>
with <tbody>
the lines that are <tfoot>
used to wrap the table footer. In the <thead>
same way, it only semantically points out the auxiliary information and does not contain any other data.
<tfoot>
The only thing that is unique is its position in the HTML, which is immediately in <thead>
<tbody>
front of it! You might think of it as the table
last element before the end of the tag, but that's not the case. Because the footer may contain necessary information to understand the table, it should be in front of the data in the resource sequence.
Although it first appears in the resource sequence, <tfoot>
it does render at the bottom of the table, making it an unusual HTML element.
For example, it can be used in a very long or high table, <tfoot>
repeating the header information, making it easier for readers to see the header information of the list at the bottom without going back to the head view. But you don't need to use it like that.
<th>
Elements do not have to be placed in <thead>
elements. They simply point to the head information. So they can also be used <tbody>
in the first line of the element.
The interval of a cell
Border-spacing:0.5rem can control the spacing between cells;
Border-collapse:collapse can remove the spacing between cells;
These are both added to the table.
Table line, High: generally not directly write dead WITDH or height, and use padding to make.
Merge cells
There are two important attributes (or) that can be applied in any <td>
cell <th>
: colspan and rowspan. They accept any positive integer greater than or equal to 2. If the colspan value of a TD element is 2 ( <td colspan="2">
), it will still be a separate cell, but it will occupy two cells of space horizontally in a row. RowSpan is the same, but it works in the vertical direction.
Two title axes
As long as the elements of the caption are used <th></th> tags
In this case I may omit the <thead>
label even if the first line is full of table header information. Because the head doesn't seem so important, it <thead>
's a bit strange to put it in a separate branch. So just let all the columns in the first row use labels <th>
and let the first column of the remaining rows use the <th>
label.
When to use a table
Now let's slow down and discuss when to use the table, perhaps you've heard this type of advice: tables are prepared for tabular data (see the first sentence in this article).
What's the right thing to put in a table? Here are a list of some: a schedule/Price list/feature comparison, bowling score, Web-format employee information, financial data, calendar, nutrition ingredient table information version, logic puzzle solver, and more.
You may have heard that tables are non-semantic. This is not true-they point to tabular data semantically, and tables are a good choice when presenting data.
When not to use the table
The table does not apply to layouts. This may seem a little strange. So let's take a look at why tabular features make them seem suitable for layouts: easy to control, logically rigorous, predictable, and not fragile at all.
However, there are some serious problems when using tables to layout. First, the HTML tag means something. As we mentioned earlier, the table element semantically describes the list-type data. It is a violation of semantic responsibility to use them for anything else. While you won't be punished for using it in your email, the benefits of using table in an HTML document aren't that big.
But talking about semantics is sometimes not that simple (related information: 1,2,3,4,5), so let's talk about something that everyone basically agrees with (even if we're not as good as we want to be): the site should be accessible. One part of the accessibility is for screen readers. Screen readers are reading tables from top to bottom, from left to right. Because you have to decide how to present the content of the web based on the structure of the table, it means that the choice of the visual rather than the accessibility.
When it comes to resource order, its impact is greater than accessibility. Imagine a "sidebar on the left" layout, a table will require that the table should first appear in the resource sequence, which is also not conducive to accessibility, may also be detrimental to SEO, which potentially determines that you have to assist the content on your main content.
Can you solve the SEO problem by using the semantic tags in the table? This is possible, but you are now using double HTML. If you really need the layout of the table but want to make it a semantic label, take a look at the next section. If you do not know how to achieve semantics when using the table layout, use ARIA in the table to role="presentation"
indicate its meaning.
When I wrote this post in the second half of 2013, the tables have become less popular and less appealing in the layout scheme. We see a large number of people now using fixed or absolute positioning, which is not possible in the table. We see Flexbox as an excellent choice on the edge of mainstream usability. We saw the grid layout begin to develop. We see Inline-block powerful ways to use it. We see that the floating fragility of the past has faded away.
Now you rarely see modern web sites using tables to lay out, except that HTML messages persist. The scope of rendering the message is very broad. Messages appear anywhere on the internet and on the mobile side of native applications as well as the desktop side of old and new systems. You can do some progressive optimizations for your emails, but it's all agreed that the safest way to do this is to use tables. A strong proof is that the primary mail push server all uses tables to build the template.
To make a semantic element behave like a table
You always need to change the display properties of the elements to get the behavior of the table style, here are their related values:
display:table/*<table>*/Display:table-cell/*<td>*/Display:table-row/*<tr>*/Display:table-column/*<col>*/Display:table-column-group/*<colgroup>*/Display:table-footer-group/*<tfoot>*/Display:table-header-group/*<thead>*/
Inline-table and Inline-block have the same effect.
Other important attributes in the table
Caption: Before <table> <thead>, indicates the title of the table, the General center display
The table after the style is beautified
Odd and even row color, certain, column, mouse hover, see demo
Remember one point: you need to set a fillet on the table itselfborder-collapse: separate;
Form Search
SOURCE See 2014-10-27 Favorites
Fixed table header
SOURCE See Demo
Table element Complete Guide (contains CSS3+HTML5)