Home > Web Front-end > HTML Tutorial > div css layout_html/css_WEB-ITnose

div css layout_html/css_WEB-ITnose

WBOY
Release: 2016-06-24 12:33:15
Original
902 people have browsed it

The spring breeze of "reconstruction" is blowing all over the country, and the Internet is in a state of turmoil for a while. "div CSS" has become a "fashion". Countless websites have started their own "reconstruction" invariably. However, opening up this variety of The source code of the website often makes people laugh??


We see div layouts with 6 or 7 layers of nesting, tables without tables, pages composed of pure div a, and hundreds of Thousands of presentation layer classes... Nowadays, there are more and more books about standards. Except for a few books that advertise "advanced techniques", there are very few people who will not emphasize such a sentence in the first few chapters of their books..." "Separation of structure and performance". However, how many readers of these books have read the first few chapters seriously? Or more often they just skip the boring structure explanations and dive into the seemingly advanced layout techniques and Hack?


In fact, the term div CSS has misled too many people from the beginning, and the quick success mentality is the culprit of this phenomenon. A web page that is accustomed to table layout. The first step in making contact standards should not be to blindly seek CSS techniques to implement various layouts, but to work hard to change your way of thinking.


I will talk about it based on my personal experience. Comply with the standard way of thinking, many of which are detours I have taken. I hope it will be helpful to XDJMs who have just come into contact with standards:


1. "Saving code" is a marketing tool, not a purpose

"Using div layout can save more code than table layout." I have seen this sentence in many books and websites. This sentence itself is correct, and it can "save code". It is one of the benefits brought by web page standardization. However, remember that it is only "one of the benefits", not the "only benefit", and it is not the purpose of "saving code". It is more often used by us to persuade those who are stubborn. The boss's marketing method. The only purpose of web page standardization is "separation of structure and performance", and it is not to save code for the sake of saving code. I once used a unified class because the presentation form of the website sidebar and even the main content is the same (still do). Some books teach this), which indeed saves code than naming IDs separately. However, the cost of doing so is that the code loses its good structure. The consequences of losing its good structure are: 1. The source code is no longer readable; 2. , the website increases unknown maintenance costs. Just imagine, when a certain piece of content changes in presentation due to needs, such as the color of links, etc., we have to modify the page source file and add additional classes. The workload is compared to Just adjusting the id grouping will make it much bigger. And if things go on like this, the structure will get worse and worse, forming a vicious cycle that is difficult to reverse. There is another situation that occurs in the naming of ids. Mistakes I have made. At that time, in order to "save code", the main menu was named "mm", the secondary menu was named "m2", and the third-level menu was named "m3". As a result, the readability of the web page was seriously reduced, making it difficult for other colleagues to Taking over, trying to save trouble but tiring myself. In the same way, it is not advisable to oversimplify the naming of files and folders. For example, "Website Reconstruction" recommends storing all images in the "i" directory. Personally, I think it is not advisable unless you can write for such a highly abbreviated directory structure. Explain in detail and ensure that everyone involved, including other production staff, developers, and even knowledgeable bosses... can understand and implement it, otherwise it will only add unnecessary trouble to yourself.


2. ID is a sniper rifle, and class is a double-edged sword

If you want to have a good web page structure, both id and class must be mastered proficiently. The so-called "grasp with both hands, grasp with both hands" All must be hard." ID is like a sniper rifle, which can help us accurately locate the elements we want to load styles; and class is the knight's sword, which is lighter and more flexible at hand. The combination of the two can achieve a page with good structure and rich performance. However, there is a wrong view now that id can be completely replaced by class. In fact, this is true for many web page source codes. When you open the entire class, you cannot find an id. There are many reasons for this phenomenon, but the deep-rooted concept of "class=CSS" passed down from the table era is the root cause. It is true that class is more versatile and flexible than id, but it must also be realized that class is far less effective than id in building a good web page structure. The mandatory uniqueness of id makes it easy for us to retrieve any module we need through id, while class does not have this advantage. Although we can define a unique class name for the module, the premise is that only the producer himself can change the web page style. Otherwise, let's find a slightly lazy guy. When he sees that the styles are the same, he will directly apply the previous class. The result is that we find that there are more than a dozen modules in the web page called "gonggao" or "xinwen", so that it is difficult to distinguish them. Without adding a lot of html comments, this result is obviously not what we want. Furthermore, as mentioned earlier, the code saved through universal classes has to be squandered in each individually defined class.

ID is a sniper rifle, and class is a double-edged sword. Together, we both benefit, and apart, we both lose.
3. Not all content requires div as a "container"


Should the main menu use

Popular Tutorials
More>
Latest Downloads
More>
Web Effects
Website Source Code
Website Materials
Front End Template