Home  >  Article  >  Web Front-end  >  Comparison of the advantages and disadvantages of table and CSS DIV layout modes (translated)_html/css_WEB-ITnose

Comparison of the advantages and disadvantages of table and CSS DIV layout modes (translated)_html/css_WEB-ITnose

WBOY
WBOYOriginal
2016-06-24 12:32:31997browse

As a web designer in late 2008, are you embarrassed to admit that you use Table in your code? If so, you are a courageous person. Web design is a strange industry. You can design your website to look like the classified ads in the evening newspaper, or the unlock ads in the corridor, but never let people know that you use Table. Discovering Table in your source code is like a salesperson being discovered by someone lifting his trousers. It's like wearing white socks.
Table is so ugly and bloated. Even if you only display a simple piece of content, you still need these three basic tags

and a bunch of them in each tag. The messy attributes, unlike
, are simple, neat, and fashionable. They are in perfect harmony with CSS. They form the most perfect Box model. They are like boxes in reality. You put things in them, and then , you can arrange them freely. If you are tired of one layout, it doesn’t matter. Simply change the CSS definition, and a new layout will be born; unlike Table, Table is like a sideboard in a canteen, rows and columns. Column is rustic and greasy, just like our parents, slovenly, they take everything home and pile it haphazardly in the corner. If Div is the petty bourgeoisie, Table is the third generation. They do not belong to this era.

That is to say, in recent years, only three to five years at most, W3C is an organization that everyone thinks is important but everyone dislikes. Their official website is very ugly. I dare say I have never seen it in my life. They have such an ugly website, but their website is one of the few websites that can pass all W3C standard verification, which means that their website is perfect in grammar, structure, and accessibility, although it is still Very ugly. But this is a joke, W3C is very important, otherwise Microsoft will bring all Web development engineers to a point of no return. Fortunately, after the death of Netscape, Nirvana released Firefox, and although Opera did not receive any benefits after the birth of Firefox, at least You have received moral support. Did you see that a big brother finally came out to take care of you? After Jobs came back, Apple returned to its former glory. Only then did people know that there was a browser called Safari in the world. All of this combined made the W3C truly necessary to exist.

W3C said that Table can be used to accommodate text, formatted text, pictures, links, forms, and other Tables... However, Tables should not be used purely as a means to layout document content), the reason is that Table will have problems when the Web is rendered by non-visual devices, which are screen readers and braille browsers. In addition, Table will force users to scroll left and right on large display devices. , therefore, Web designers should use CSS instead of Table. See W3C HTML 4.01 for the definition of Table. When W3C said this, it was December 24, 1999. Although CSS had been born for a long time, not many people used it. The original Web was like an online version of the document and did not become the platform it is now. Too much consideration was given to layout issues. With the formation of the first Internet bubble, a large number of portal websites emerged. Portal websites were the originators of the Table layout, because their homepages were larger than all the pages of a newspaper put together. Complex, Table is very handy in this regard. Combining colspan and rolspan, you can achieve almost any complex layout.

This layout style was still very popular in the early 2000s and into the mid-2000s, especially in China. Under the subconscious mind of the United States, people crammed everything that could be crammed into one page into the homepage. Table Like a housekeeper in the old days, he arranges everything in an orderly manner, although not in perfect order. However, this kind of Web has finally reached the point where people are disgusted. With the emergence of search, RSS subscriptions, and personalized Web represented by blogs, people have more channels to obtain information without having to visit those few websites that are almost necessary. On the homepage of the fainted portal, a fresh, lightweight Web style appeared, using a simpler layout, brighter colors, large icons, large banners, and easier-to-read large fonts. At the same time, in this At that time, CSS was already very mature, and browsers such as Firefox, Opera, and Safari were far better than IE in complying with W3C standards. People finally realized the power of CSS. Because the core of CSS is a Box model in terms of layout, people must find a container object for CSS to attach to.

Div is the lucky one because it is naturally the best prototype of Box. Semantically, Div represents an area of ​​the page. In appearance, it is boxy. More importantly, it is not Like

or have been given special semantics in advance (although they can also be used in the Box model); on the other hand, it is out of people's hatred of Table ruling a bloated era, the end of an era , the successors will work hard to erase the traces of the old era. The fate of those symbols or representatives of the old era is mostly like this. People do not simply forget them, but draw a clear line between them.

This is where all the unfair treatment from Table begins. Why is it unfair? When W3C does not recommend Table layout, it only says that CSS should be used instead. What does this mean? Does Table not support CSS? Of course it is supported, and because Table is an old HTML object and its status was so important, any browser provides the most perfect support for Table, including CSS support. When people embrace Div, they seem to forget that Table is also a Box, and it is a Box with multiple inner cells. Table as a whole has no difference from Div in terms of Box model, and its inner cells, except for Margin , it is still a Box, and the inner box does not contain the concept of Margin, which should be understood. It goes without saying that Div is excellent, but when people say Div CSS, it seems to imply that Table cannot be CSS, which is a huge misunderstanding.

All CSS properties supported by Div are supported by Table. In fact, before Div became popular, those early adopters of Div expressed with little confidence that if Table can do it, Div can do it, and they I also paid the price for my words. People who try to achieve vertical centering in Div understand what I mean. People who try to achieve 100% Div layout in IE6 without CSS Hack understand what I mean even more. 100% Height problem, width adaptive problem between several Divs, I believe anyone who is engaged in Div CSS design will encounter it. The advantage of Table in this regard is not because of how excellent it is, but because it is old and no browser dares to ignore it. It is also because of its original characteristics. People invented tables because they want the data to be displayed neatly. It is as simple as that. But why did Table get so much notoriety? Div advocates accuse Table of nothing more than the following.


The code is bloated: you need to write at least the three tags

before you can start the real content. In addition, there are also various tags in Table Contains complex attribute definitions, while Div only needs a
tag.
Page rendering performance issue: The browser needs to completely read the entire table before it starts rendering.
Bad for SEO: Search engines like content to be separated from decoration.
Poor accessibility: Screen reading software and braille browsers cannot understand the content in the Table well.
Not semantic enough: We need a semantic Web.

Article 1: Bloated code

First of all, the only attributes in Table that cannot be defined with CSS are Cellspacing and Cellpadding. Other attributes can and should use CSS. In this way, the rest , it is the duel between

and
. I believe that for a web page that is often tens of K in size, even if dozens of Tables are used, the extra code can be ignored. , Those who complain that the Table code is bloated should actually check their coding habits. People who can write a Table that is very bloated may not be as concise as writing a Div.

Article 2: Page rendering performance issues

I use a 2004 laptop with a 1.6G CPU and 1G memory. In this configuration, the Table layout and Div cannot be seen. There is any speed difference between layout and page rendering. In fact, even if there is such a difference, the delay relative to the network itself can be ignored.

Article 3: Not conducive to search engine optimization

If you use CSS instead of Table properties as much as possible, as mentioned earlier, the difference between the generated code and Div will not be very big. Will search engines discriminate against the

tag? I have not found the basis for this statement so far.

Article 4: Poor accessibility

This is an inherent flaw of Table, but most Div CSS fans don’t seem to reject Table for this reason.

Article 5: Insufficient semantics

The meaning of the Semantic Web is much more profound. It is not just about Table and Div. Even W3C does not stipulate that Table can only be used for display. For tabular data, many people who are struggling with the semantics of Table may as well wait for HTML 5, which is the real semantics.

The purpose of this article is not to make you abandon Div and join Table. On the contrary, if Div can meet your design needs, Div is still the first choice, but there is no need to avoid Table, otherwise it will go to the other extreme. Many designs that cannot be easily achieved using Div can still be achieved using Table. Of course, no matter what is used, CSS should be used to separate content and decoration. Both Div CSS and Table CSS are legal designs, use whichever is simpler. According to my experience, you should use Div CSS when you can predict the format of your content and have full control over the display format of the content you are about to add; when the content you are about to add is not fixed and you cannot predict its Formatting, if you don't want the page to collapse, using Table CSS is a safe approach.

Table:
Advantages: 1. Good visibility. When users insert a Table, they can see the effect immediately.
2. Simple and convenient, suitable for beginners. You don’t need to know too much about the code to use tables. You only need to insert the table, and then set the length, width, alignment, table attributes, etc.
3. It has good readability. Anyone who knows a little about HTML language can understand it. It is nothing more than "table /table, td /td, tr /tr" and so on.
Disadvantages: 1. Code redundancy, "table tr td /td /tr /table" is the most basic element that constitutes a table (this is a table with one row and one column).
2. It cannot be reused. For example, a table has been used above and the same table as above needs to be used next. It is difficult to call at this time, resulting in too much code and causing the website to open quickly

Slow.

Div css:
Advantages: 1. Streamlined code, div /div" is much simpler than Table code.
2. Reusable, for example, 2- is needed in a web page For 3 Divs, the user only needs to define a style in css, for example, define a style name: abc. When inserting a div, only the form div id="abc /div" is required when inserting a div. You can have more.
3. The website opens quickly. Because the code is streamlined, the server saves a lot of time when reading the code, so the website opens much faster than the table.
Disadvantages: 1. Poor observability. , the user cannot see the editing effect immediately when editing, and needs to preview to see the effect.
2. The readability is poor, the website code is almost all div /div" and this style cannot be seen on the code page. You must enter the css style to see the defined style.
3. The operation is cumbersome. Compared with first-time users and those who don’t know the code very well, the operation is very troublesome.

First, the high reliance on CSS makes web design more complicated. Compared with the table layout (table) in HTML4.0, although CSS DIV is not out of reach, it is at least much more complicated than table positioning. Even for website design experts, it is easy to have problems, let alone beginners. To a certain extent, it has affected the popularization and application of XHTML website design language.

Second, abnormal CSS files will affect the normal browsing of the entire website. The design elements produced by CSS websites are usually placed in several external files. This one or several files may be quite complex or even large. If the CSS file is called abnormally, the entire website will become miserable.

Thirdly, browser compatibility issues with CSS website design are quite prominent. Web design based on HTML4.0 has almost no browser compatibility issues in versions after IE4.0. However, a website designed with CSS DIV may display pages normally in IE but not in Firefox. It’s unrecognizable (which is why Internet marketers are advised to use Firefox). CSS DIV still needs further support from various browser manufacturers.

Fourth, whether CSS DIV is optimized for search engines depends on the professional level of web design rather than CSS DIV itself. CSS DIV web design does not guarantee that the web page will be optimized for search engines. It does not even guarantee that the web page will have a simpler code design than the HTML website. Moreover, the inclusion and sorting of web pages by search engines is obviously not measured by whether tables and CSS positioning are used. This This is the reason why many websites made with traditional table layouts are ranked high in search results, while many web pages made using CSS and web standards are still ranked low. Because for search engines, factors such as website structure, content, and related website links are always the most important indicators for website optimization.

Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn