1. CSS Class Naming Principles
Recommend combining camelCase rules and hyphen-separated methods, do not recommend using underscores, because they are not convenient to input
camelCase rules are used to distinguish different words, hyphens are used to indicate subordination relationships, for example:
<ul class="xxList">
<li></li>
<li></li>
<li class="xxList-lastItem"></li>
</ul>
Hyphens are like namespaces, used to limit scope, from this perspective, perhaps can be called modular CSS, object-oriented CSS
2. Low Priority Principle
Avoid abusing child selectors and descendant selectors, will increase priority, and there are conflict risks. To ensure styles are easily overridden, ensure selector priority is as low as possible
Facing style changes, overly high priority is very troublesome, for example:
.info .infoBody .lastItem span {
color: red;
}
At this time, if you want to change a certain span child of lastItem to green, it's very difficult, in order not to affect the target span's span siblings, you can only hang a style on the target span, and add this string of selectors:
.info .infoBody .lastItem span.special {
color: green;
}
Otherwise it will be covered by red due to insufficient priority, in this case it seems there is no way to stop descendant selectors from becoming longer
If using namespace method it will be much better, for example:
.info-infoBody-lastItem span {
color: red;
}
.info-infoBody-lastItem special {
color: green;
}
Keeping selectors at low priority makes them easier to modify, so CSS Lint even doesn't recommend using id selectors, of course id selectors not supporting extension (id is unique) is also an important factor
3. Avoid Class Naming Conflicts
In multi-person collaboration, to maximize avoiding conflicts, can add prefixes to styles, for example:
<!-- by zhangsan -->
<ul class="zs-xxList">
<li></li>
<li></li>
<li class="zs-xxList-lastItem"></li>
</ul>
<!-- by lisi -->
<ul class="ls-xxList">
<li></li>
<li></li>
<li class="ls-xxList-lastItem"></li>
</ul>
4. Readability vs Overly Long Names
Overly long names, such as "zs-dropMenu-lastItem-img", will inevitably increase file size, but the benefits in readability brought by such naming are much more cost-effective than increasing text file size, not to mention text files can be gzip compressed
5. Use More Composition
This kind of problem also exists in CSS: should we hang multiple classes or hang a new class?
There is a principle in object-oriented design: use more composition, less inheritance. This applies here too, although inheritance is out of the question. The advantage of composition is more flexible, easier to extend, for example:
.fl {
float: left;
}
.fr {
float: right;
}
.bdRed {
border: 1px solid red;
}
Generally, using such atomic classes to compose and implement styles is easier to extend (can add bdGreen, w950, etc.), base layer and common layer are organized this way, page layer internal can also be organized this way, the benefit brought is when styles change only need to update class values, rather than going to modify a certain style rule, of course, sometimes must first add new class then apply, and if using only hanging one class, each time have to first find a certain class from style files then modify certain rules
(bdRed naming may be objected by some people, because hope class names can express additional semantics, rather than purely indicating styles, when styles change, bdRed may actually represent black solid border, at this time wanting to keep semantics need to change bdRed to bdBlack and simultaneously modify html. Using composition does not have such problems, because we will add new bdBlack, rather than modifying bdRed)
Note: Like OOP, extensibility needs to be traded off according to specific scenarios, in parts that are unlikely to change using composition has no benefits except increasing CSS code length
6. Hook
This is the most important point, can use class or id as hook, hook is a dangling hook (does not correspond to any styles, also does not appear in selectors), can hang things on it later. Hooks are divided into css hook and js hook, both are very useful.
css hook is used to prevent changes, first add class to an element that may change, no need to apply any styles, fill in style rules when changes occur in the future. Actually this also illustrates another problem: do not omit necessary tags. Fewer tags means harder to extend, for example:
<h2>Secondary Title<span class="btn">Expand/Collapse</span></h2>
If style change requires secondary title to have underline, we have to add wrapping "Secondary Title" with an inline tag, then add styles, and vertical centering etc. may also be affected. If wrapping "Secondary Title" with tags from the beginning won't be caught off guard. Of course, also no need to add a bunch of css hooks, because some places are indeed unlikely to have style changes, so there is a degree between waste and saving
js hook is clues provided for js, convenient for manipulating styles, generally use id as js hook, because native getElementById is most efficient, even if cannot directly find element, can also be used to narrow search scope. Similarly, using class as js hook can also improve element search efficiency, avoid inefficient right-to-left scanning descendant selectors to search elements
References
- "Writing High-Quality Code - The Way of Web Frontend Development Cultivation"
No comments yet. Be the first to share your thoughts.