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 the source code of these various websites 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 presentation layer classes... There are more and more books on standards nowadays. Except for a few books that advertise "advanced techniques", few people would not emphasize such a sentence in the first few chapters of their books - "separation of structure and expression". However, how many readers of these books have read the first few chapters seriously? Or do you prefer to skip the boring structure explanations and dive into the seemingly advanced layout techniques and Hacks?
In fact, the term div+CSS has misled too many people from the beginning, and the mentality of eager for quick success is the culprit of this phenomenon. The first step for a person who is accustomed to table layout webpage production to come into contact with standards should not be to blindly seek CSS techniques to implement various layouts, but to strive to change his or her way of thinking.
Below I will talk about the way of thinking in compliance with standards based on my personal experience. Many of them 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. "Saving code" is indeed one of the benefits of web page standardization. However, remember that it is only "one of the benefits", not the "only benefit", and it is not the purpose. “Save code” is more often a marketing ploy we use to convince stubborn bosses. The only purpose of web page standardization is "separation of structure and performance", and it is never about saving code for the sake of saving code. I once used a unified class because the sidebar and even the main content of the website have the same presentation form (there are still some books that teach this). This is indeed more code-saving than naming the IDs separately. However, the cost of this is that the code loses its good quality. structure. The consequences of losing a 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 its presentation due to needs, such as the color of a link, etc., we have to modify the page source file and add additional classes. The workload is much greater than just adjusting the id grouping. . 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, which is also a mistake 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, 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 "grasping with both hands, both hands must be strong". 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 your fingertips. 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. Seeing 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 I use <div id="mainnav"><ul> or <ul id="mainnav"> for the main menu? This is a game problem. So far, no one can give a clear answer to this question, not even me. It is true that when <div id="mainnav"> only contains one <ul> element, this div seems a bit redundant, but sometimes in order to match the gorgeous design, one more layer of tags means one more layer. Changes (some people also use span in the a tag). The inherent advantage of div without any original attributes is unmatched by other tags. I just want to illustrate one thing with this proposition, that is, we should realize that in addition to <div id="mainnav"><ul>, there is also <ul id="mainnav"> this way of writing, which also has good structure and semantics and eliminates a layer of nesting. When we don’t need to worry about gorgeous art, can we also make the structure more simple?
This proposition can actually be extended to - "Not all content needs block elements as containers" and "Not all links need other elements as containers", such as "more" that many pages have. Some people write "<div class="more"><a>", while others write <p><a> or <strong><a>. Do they still need to exist when these "containers" only contain an <a> tag? Would writing directly<a class="more">break the structure? Will it lack semantics? Will it affect the layout? If you think differently, you may gain something different.
4. Achieve "separation of structure and performance" at work
Regarding this point, many experts on the Internet suggest this, that is, open the editor first, write out the structure completely, then go to CSS to write the performance, and try not to touch the already written structure.
However, it is difficult for people who use reading books as their main learning method to understand, because most books on standards teach step by step, which means that they must combine structure and expression in a step-by-step manner. Although some books have suggestions in this regard, a few short sentences are far inferior to the subtle effects during the reading process. When the production staff can have a good grasp of the structure, writing structure and performance at the same time will not have much impact on the results. But in my experience, the working method of separating structure and presentation is much more efficient than writing structure and presentation at the same time. At the same time, it is not easy to miss elements on the page.
Of course, the so-called "separation of structure and performance" does not mean that performance is completely ignored. If you want to take performance into consideration, you must ensure that the CSS selector can select as much content as possible without destroying the structure. Where to add classes, or which labels to use to distinguish them, is a matter of opinion. I believe everyone has their own experience. Combining different design drafts, sometimes it is necessary to make corresponding changes. However, these changes should all have the same premise - not destroying the structure and readability of the code.
Furthermore, we must realize that any visual tool is a devil. The effects presented in their visual interfaces are often thousands of miles away from those of real browsers. What we really want to be compatible with is the browser, not the visual interface of the editor.
5. CSS is not a panacea, and it is not impossible to live without CSS.
Compared with the CSS1.0 era, CSS can accomplish more things today. However, demand is always ahead of technology. CSS cannot complete all the presentation layer work of web pages. Sometimes we must combine JS or other languages to achieve some effects. Other times, using JS is much simpler than relying on CSS alone, and the code is more well-structured - the most typical example is the drop-down menu. At these times, we have to convince ourselves, or our bosses and customers, to use simpler and more reasonable methods. Because DOM is also an important component of web page standards, it does not mean that using JS will make our web pages less efficient or no longer standard. On the contrary, this is the biggest misunderstanding of JS. Having said this, I have to mention that in today's era, every profession is required to know more relevant knowledge than ever before. Those who do design must know a little about interaction and production, and those who do production must also understand design and programming, especially With front-end technologies like JS, only in this way can you and your colleagues work better together, and your personal development prospects will be brighter.
No CSS refers to when our website fails to load the CSS file due to various unknown reasons. Don't panic because of this. This is the best time to test the quality of our code. If the web page still maintains good readability without CSS, this achievement is far more worthy of our pride than passing W3C verification.