Creating web pages and changing your way of thinking

The spring breeze of "restructuring" swept across the north and south of the river, and the Internet was a breeze. "div + CSS" has become a "fashion ", all the websites that are difficult to count have begun their own "reconstruction ". However, opening the source code of these various websites is often dumb-we can see that there are nested 6-layer and 7-layer div ladiv S, tables without tables, and pages composed of pure div +, there are hundreds of class layers ...... Now there are more and more books on standards, except for a few books labeled as "advanced skills, few people will not emphasize this sentence in the first few chapters of their work-"separation of structure and performance ". However, how many readers have carefully read the previous chapters? Or do I skip the tedious structure explanation more directly and get stuck in seemingly advanced layout skills and Hack?

In fact, the div + CSS statement has misled too many people from the very beginning, and the mentality of quick success is the culprit of this phenomenon. One of the first steps for getting used to the standards of table layout web page creation should not be blindly seeking to implement CSS skills for various la S, but trying to change the way of thinking.

Next we will talk about the standard-compliant thinking methods based on my personal experience. Many of them are the detours I have taken and hope to help XDJM who have just come into contact with the standard: 1. "saving code" is a marketing method, not an aim "using div layout can save more code than table layout". I have seen this sentence in many books and websites. This statement is true. "saving code" is indeed one of the benefits of Web page standardization. However, remember that it is only "one benefit", not "the only benefit", but not the purpose. "Saving code" is more about the marketing means we use to persuade stubborn bosses. The only purpose of web page standardization is "separation of structure and performance", rather than saving code to save code. I used a unified class because the content on the sidebar and even the subject is in the same form (so far, some books are taught in this way), which saves more code than naming IDs, however, the cost of doing so is that the code loses a good structure. The consequence of the loss of a good structure is: 1. The source code is not readable; 2. The website adds unknown maintenance costs. Imagine that when a piece of content changes its form as needed, such as the link color, we have to modify the page source file and add additional classes, the workload is much larger than the need to adjust the id group. In the long run, the structure will get worse and worse, forming a vicious circle that is hard to be reversed.

There is also a situation where the id name is also a mistake I have made. At that time, in order to "save code", the main menu was named "mm", the second menu was named "m2", and the third menu was named "m3", which seriously reduced the readability of the webpage, this makes it difficult for other colleagues to take over, but it saves them trouble. Similarly, the naming of files and folders should not be simplified. For example, we suggest storing images in the "I" directory in "website reconstruction". I think it is not advisable, unless you can write a detailed description of this abbreviated directory structure and ensure that every related person includes other producers, developers, or even knowledgeable bosses ...... Can understand and execute, otherwise it will only add unnecessary trouble to yourself.

2. ID is a sniper rifle, and class is a double-edged sword. To make a good web page structure, both id and class must be mastered. The so-called "both hands should be hard ". Like a sniper rifle, ID can help us precisely locate the elements we want to load styles. While class is the swordsman of chivalrous people, it is easier to use it with confidence, the combination of the two can achieve a well-structured and rich page. However, there is a wrong idea that id can be completely replaced by class. In fact, many web page source code is indeed the same. I can open the entire class and cannot find an id. there are many reasons for this phenomenon. However, the deep-rooted concept of "class = CSS" passed down in the table age is the root cause. Indeed, the class is more flexible than the id, but it must be realized that the class is far less effective for building a good web page structure than the id. The forced uniqueness of id makes it easy for us to retrieve any module we need through id, and class does not have this advantage. Although we can define a unique class name for the module, the premise is that only the producer can change the webpage style. Otherwise, the previous class will be applied directly if the style is the same, the result is that more than a dozen modules on the webpage are called "gonggao" or "xinwen", so that a large amount of html comments have to be added to differentiate them, this result is obviously not what we want. Furthermore, as mentioned above, the code saved by the general class has to be squandered in every individually defined class.

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

3. Not all contents require div as a "container"

Does the main menu use <div id = "mainnav"> <ul> or <ul id = "mainnav">? This is a game issue. No one can give a clear answer to this question, even me. It is true that when <div id = "mainnav"> only contains one <ul> element, this div is somewhat redundant, a single layer of tags means a change of one layer (some people also set span in tag ). The inherent advantages of div without any original attributes are incomparable to those of other labels. I just want to explain one thing, that is, we should be aware that there is a <ul id = "mainnav"> <ul> In addition to <div id = "mainnav">, it also has good structure and semantics, and saves a layer of nesting. When we don't need to work hard for the gorgeous artist, can we make the structure more simple?

This proposition can also be extended to "not all content requires Block elements as containers", "not all links require other elements as containers ", for example, many pages have "more ".

<