CSS selector: Writing an efficient CSS selector

Efficient CSS is not a new topic, nor is it a topic I have to regain, but it is the self in the sky after work, really interested in and always focus on a topic.
Many people either forget, or simply don't realize, that CSS can be efficient and may lead to low energy. However, we may not consider using inefficient CSS when you think you will have too little.
These rules are only really used on highly performance Web sites that require high speed, and any page may contain hundreds of DOM elements. But to practice the truth, whether you're building the next Facebook or developing a local display page, it's always good to learn more ....
CSS Selector
CSS selectors are not new to most of us, and the underlying selectors are types (such as Div), IDs (such as #header), and classes (such as. tweets).
More unusual include the underlying pseudo classes (such as: hover) and more complex CSS3 and ' regular ' (' regex ') selectors, such as: first-childor[class^= "grid-".
The choice of appliances is inherently efficient, and in the words of Steve Souders, the order of more efficient and less efficient CSS selectors is this:
IDs, such as #header
Class, such as. Promo
Type, such as Div
Adjacent sibling, such as H2 + P
Child, such as LI > ul
descendant, such as UL a
Universal, IE *
Attribute, such as [type= "text"]
Pseudo-classes/-elements, such as A:hover
Quote from Steve Souders's even faster website
It's important to know that although one ID is technically faster and better performing, it's rarely used. With Steve Souders's CSS tester, we can see that an ID selector and a class selector differ very little in the rendering speed.
In the Firefox6 on a Windows machine, I got the average rendering data on a simple class selector. The ID selector gives a 12.5 average, so it's actually a bit slower to render than a class.
The speed difference between an ID and a class is almost irrelevant.
The selection test for a type ( ) gives a much slower rendering than a class or ID.
The test for a very much-layered descendant selector gives a value of about 440!
Through this we can find that the difference between ids/classes and types/descendants is very great ... The differences between themselves are subtle.
Note that these values vary greatly in different machines and browsers. I strongly recommend that you run it yourself.
Combination Selector
You can use a single standard selector, such as #nav, to select all elements with a "NAV" id, or you can use a combination selector, such as #nav A, to select any link element within the element id ' nav '.
Now we're going to read this combo tag from left to right. We first find the #nav, and then we find the elements inside. But our browser does not parse this way, it is from right to left to parse these combination selectors.
When we see a #nav inside, and the browser sees a A in #nav里面, these nuances have a significant impact on the browser's performance, and it's valuable for colleagues to learn.
If you want to know why the browser is parsing this way, refer to this discussion on Stack Overflow.
For browsers, starting with the rightmost element (the element it most wants to render) and then going back to the DOM tree is looking down from the top level of the DOM tree, and may not even reach the rightmost selector (the key selector) to be efficient.
This has a significant impact on the performance of CSS selectors ....

key selector " The key selector discussed here is the selector at the very right end of the complex selector and the first selector the browser resolves. Let's go back to where the discussion started, which selector is the most efficient? Which selector as a key selector affects the performance of the selector; when we write CSS code, it is this key selector that affects the efficiency of the selector. A key selector is this: #content. intro{} Inherently efficient selectors such as type selectors can have higher performance? Browsers will look for. All instances of intro (not many), and then look up the DOM tree to determine whether the key selector is inside an element with "content" as its ID. Then, the following selector performance is not very good: #content *{} This selector does the job of looking at each page (each individual page) and then seeing if they have a #content parent element. This is a very efficient selector because its key selector execution overhead is too high. by using this knowledge, we can make better choices in classifying and selecting elements.

 

Let's say we have a very large page, very large and a huge website. On this side, there are hundreds or even thousands of tags. Social media links are only a small part of the link, and are included in ID #social. Suppose these links are, Twitter, Facebook, dribble and Google +. We have four social media links on this page, and hundreds of other links. The following selector is expensive and poorly performing: #social a{} The browser accesses the thousands of links on the scanned page before selecting the four links under the #social node. Our key selector matches a lot of tags that we're not interested in. To eliminate this problem, we can specify a more explicit and explicit selector for each tag contained under social media blocks. Social-link. But that's just the opposite of what we know, and we know that when we use a thin label, try not to use the extra classes.

That's why I think performance is so interesting; there needs to be a balance between Web standard best practices and speed. This is what we usually write: Twitter Facebook Dribbble Google+ Css: #social a{} Now we would instead: Twitter Facebook Dribbble Google+ Corresponding CSS: #social. social-link{} This is a brand new key selector that matches fewer elements, meaning that browsers can find them faster and give them styles. At the same time, in fact, we can further refine the selector, use the. social-link{}, without having to constrain it to a transition, and read the next section for more details. So, to sum up, your key selector is one of the things that determines the browser's workload, so you need to keep an eye on it. Over-decorated selectors Now that we've seen what the key selector is and it's the basis for the follow-up, let's look at how we can further optimize it. With a more specific key selector, you need to avoid overly using the cosmetic selector. The following is an overly decorated selector: 1 HTML body. Wrapper #content a{} This choice is too long-winded, at least three selectors are completely unnecessary. The thin style should be: #content a{} So what? This means that the browser needs to scan all the tags and check if it contains a tag with an ID called "content" so that it is kept in the HTML tab. This can cause the browser to do extra checking and is completely unnecessary to work. Knowing this, we can take a closer look at the actual example below: #nav Li a{} Streamlined to: #nav a{} We know that if tag A is inside the Li tag and the Li tag is inside the #nav, then we can remove Li from the selector. Then, because NAV has an ID, this ID is unique, so it gives the element is completely irrelevant, we can remove the UL. Overly decorated selectors can cause browsers to do more work, remove unnecessary parts from selectors, and make your selectors simpler and more performance-efficient. Is all of this necessary? The short answer is: maybe not. The long answer is: It depends on the site you are creating. If you're doing your next work, go beyond CSS selector performance to find clean code, because you don't really want to focus on it. If you are creating the next version of Amazon, and the page speed of the microsecond changes will indeed be different, it may be necessary, but even that may not. Browsers are only getting better at CSS parsing speed, even in mobile browsers. You'll probably never notice a slow CSS selector in the browser, but ... But It's still happening, no matter how fast the browsers are, they still have to do all the work we're talking about. Even if you don't want to even implement either of these, it's certainly still worth knowing. Remember that selectors can be expensive, and you should avoid using more expensive selectors where possible. That means that if you find yourself writing something like: Div:nth-of-type (3) Ul:last-child li:nth-of-type (odd) *{Font-weight:bold} Then maybe you're not doing it right. Now I am a novice in the world of efficient selectors, so if I miss something, or if you have something to add, please post it in the comments! More about efficient CSS selectors How can I recommend Steve Souders's website and book? That's enough for the extended reading you need. This guy knows a lot!

This article links http://www.cxybl.com/html/wyzz/CSS/20130915/40122.html