Hi, I’m Xiaoyu Xiaoyu, dedicated to sharing interesting and practical technical articles. Content is divided into translation and original, if you have any questions, feel free to comment or private letter, I hope to progress with you. Everyone’s support is my motivation to create.

The priority of the selector

As we all know, selectors are weighted, with priority from low to high, as follows:

  • Type selectors (for example, h1) and pseudo-elements (for example, ::before)
  • Class selectors (e.g.,.example), attribute selectors (e.g., [type=”radio”]), and pseudo-classes (e.g., :hover)
  • ID selector (for example, #example)
  • ! Important This declaration overrides any other declaration and is not recommended except in the following situations:
  1. Override inline styles
  2. Override selectors with absolute higher priority

Selector resolution

Although we normally write CSS selectors from left to right:

Root node. Child node. Grandson node {}Copy the code

However, this is just for user writing purposes, and the true parse order is reversed, from the child node to the root node, simply because the number of lookups can greatly affect efficiency. One by one

Since CSS tree is a tree structure, if you start from the root node, then it is similar to depth-first traversal.

If the last child node is still not found, just go back to the previous parent node, continue to look for other child nodes, in fact, there is no problem, let’s compare, see why CSS choose to parse from left to right.

Same graph, in a different analytic direction:

Obvious difference is that our judgment conditions in advance, to determine whether sun node first match, only the match will further, otherwise skip, then it’s more than from multiple line (depth-first traversal) into the problem of more than a single line, somewhat akin to from O (n2) = > O (n), greatly improving the elements matching efficiency.

Parsing from right to left reduces the number and depth of lookup failures compared to parsing from left to right

The other thing is the common style, and for the common style, you have multiple identical styles, exactly the same from the child node to the root node, which is just a line

Write efficient CSS selectors

  • The preference is to avoid using wildcard matches, so that CSS parsing from right to left is useless. It’s the same as going from left to right.
  • The ID selector mentioned earlier has the highest priority, but this is limited to using the ID selector alone. If you mix it with other selectors, you won’t get the unique efficiency of the ID selector. Why is that? Because parsing from right to left, such as # box. text, looks for the class selector first and the ID selector last, the ID selector is less important.
  • Use tags as little as possible, as this will cause the browser to look for many child nodes before determining whether there is a match, such as:.box aIf there is an A tag, it will look it up, but really we just want to style the a on the.box. We could give a more specific class selector:.box .href“, so that fewer elements can be matched
  • There is also the oft-said avoid more than three selectors, such as.div1 .div2 .div3 .p .aI can optimize to zero.div1 .aWhy do we say that? Because there’s a condition in the search that we provide a child node.aAnd in the.div1In fact, it is enough, he will find along a line, know that with nodes, we write so many selectors will only increase the judgment condition, no egg use.
  • Still have namely as far as possible write concrete, can use>Operators and so on
  • Abbreviate the names of the selectors that can be abbreviated. Combine the selectors of the same parent level to reduce CSS size.
  • Use CSS BEM to write specifications
  • Welcome to supplement

The last

This time to share content that is short, ha ha.

After the rollup, I plan to pick up the foundation again. After all, everything is built up from the base a little bit. Only when the base is thick, can it accumulate steadily.