As a front-end, can you say you know CSS and confidently say you know CSS? CSS is easy to write, but the initial structure design and later maintenance is a very mental affair.
Here, throw out two nouns: ooCSS and BEM.
What is OOCSS?
For those of you who haven’t, see this article OOCSS vs. OOSCSS. Bootstrap is a typical object-oriented CSS, also known as OOCSS.
Object-oriented CSS is a CSS rule that is easy to reuse. The key point here is how to identify, create, and modularize reusable objects in a page, reuse them wherever they are needed, and extend their additional functionality. So my understanding is that OOCSS is a reusable, decouple, poorly coupled CSS.
Disadvantages:
- OOCSS is suitable for truly large web sites because large web sites use a lot of reusable components that might not work in small projects. So using OOCSS or not should depend on your project.
- If not used wisely, creating components can be a mess, a mess, an unexpected maintenance disaster, or a maintenance nightmare.
- It is best to write a documentation for each component to facilitate invocation and maintenance
- Thousands of lines of CSS are created, but there is a chance that they will never be used. Such as Twitter Bootstrap
- Style (CSS) and structure (HTML) are too tightly coupled
Advantages:
- Emphasize reuse and reduce CSS code
- Selector conciseness
- Extensible classes
- Emphasize the separation of style and content
- Emphasize separation of content from container
- Clean HTML tags, semantic class names, logical hierarchies
- Semantic markup helps SEO
- With extensible markup and CSS styles, more components can be put into the library without affecting other components
For example
{border-bottom:1px solid # CCC; font-size:16px; font-weight:bold; color:#333; } // oocss.bb -c{border-bottom:1px solid # CCC; } .f16{ font-size:16px; } .bold{ font-weight:bold; } .c333{ color:#333; } // HTML <div class="f16 bold c333 bb-c"> title </div>Copy the code
However, you may feel that this adds too much burden to HTML, so I prefer to use Oosass.
Oosass is a scalable, object-oriented CSS that is essentially an evolution of OOCSS.
Oosass features:
- No CSS, only Sass
- The visual object is declared by %placholder
- Mixins allow you to create repeatable CSS
- Semantic class names are declared in the DOM, while visual class names are declared in Sass, otherwise it would be impossible to build UI structures and frameworks using CSS
- Classes are extended through Sass, not DOM
For example, the above code could become:
%bb-c{ border-bottom:1px solid #ccc; } %f16{ font-size:16px; } %bold{ font-weight:bold; } %c333{ color:#333; } %c999{ color:#999; } .title-1{ @extend %bb-c; @extend %f16; @extend %bold; @extend %c333; } // Suppose there is class title. title. title2 {@extend %f16; @extend %c999; }Copy the code
The generated code is:
.title-10 {
border-bottom: 1px solid #ccc;
}
.title-10..title-20 {
font-size: 16px;
}
.title-10 {
font-weight: bold;
}
.title-10 {
color: # 333;
}
.title-20 {
color: # 999;
}Copy the code
It’s worth noting that it’s important to think about how to build your atomic libraries before you start writing Oosass, because as long as your atomic classes are good enough, all your subsequent components and pages will need is the extend atomic class, and the code will barely increase. The construction idea of atomic library is as follows:
/** * align: left; /** * align: left; } %tr { text-align: right; } %tc { text-align: center; } /** * f12 {font-size: 12px; } %f14 { font-size: 14px; } %f16 { font-size: 16px; } %f18 { font-size: 18px; } /** * atom class - position */ %fl {float: left; } %fr { float: right; } %pr { position: relative; } %pa { position: absolute; }Copy the code
Of course, if you need to use overrides, you can’t do @extend because the atomic classes are at the top and don’t have enough priority.
What is BEM?
BEM stands for Block, Element, Modifier.
Blocks are independent blocks in a page that can be reused in different situations. Each page can be viewed as consisting of multiple blocks.
An Element is an Element that constitutes a Block. It is meaningful only within the corresponding Block and depends on the existence of the Block.
Modifier describes the property or state of a Block or Element. You can have more than one Modifier for the same Block or Element.
Many people’s first impression of BEM is: long, ugly, not beautiful at all!
Using the framework of BEM, website:
ElementUI, a framework for Ele. me, is a kind of BEM, and you can also study the website company.yandex.ru/
If you’re not familiar with BEM, check out the article definition of BEM
His naming conventions
Underline and underline
component-name
component-name--modifier-name
component-name__sub-object
component-name__sub-object--modifier-namCopy the code
hump
org-ComponentName
org-ComponentName--modifiername
org-ComponentName-subObject
org-ComponentName-subObject--modifiernameCopy the code
Because it is common for blocks to nest another block, you can use prefixes to distinguish
P-page (the class that applies to the body element), which is useful for static pages where maintainability is not so important -- nesting should be avoided (example: p-homepage); L-layouts, such as columning, wrappers and containers, etc. (e.g. L-masthead, l-footer); C - components (e.g. C-dropdown, C-button...) ; U - Utility classes - do not change and cannot be overloaded anywhere in the code. (example: U-TextCenter, U-ClearFix...) ; Js-javascript hooks: Should never appear in CSS. G-javascript hooks: Global JS classes that should never appear in CSSCopy the code
See article: Ten common problems with BEM and how to avoid them
Best practices:
<div class="c-card">
<div class="c-card__header">
<h2 class="c-card__title">Title text here</h3>
</div>
<div class="c-card__body">
<p>I would like to buy:</p><! -- Much nicer - a layoutmodule -->
<ul class="l-list">
<li class="l-list__item"> <! -- A reusable nested component -->
<div class="c-checkbox">
<input id="option_1" type="checkbox" name="checkbox" class="c-checkbox__input">
<label for="option_1" class="c-checkbox__label">Apples</label>
</div>
</li>
<li class="l-list__item">
<div class="c-checkbox">
<input id="option_2" type="checkbox" name="checkbox" class="c-checkbox__input">
<label for="option_2" class="c-checkbox__label">Pears</label>
</div>
</li>
</ul> <! -- .l-list -->
</div> <! -- .c-card__body -->
</div><! -- .c-card -->Copy the code
advantages
- Solve the namespace problem
- When multiple people collaborate, as long as the rules are clearly marked in the document, the next person can easily read and take over
- Easier to maintain
disadvantages
- Easy to write long and ugly
- More code, not so simple
- Good documentation and rules are required
I understand it
Personally, if from the component, it is good to use BEM, the custom style is to use OOsASS, the combination of the two, purely personal opinion, welcome to put forward your opinion and practice. After all, I’m just an armchair strategist.
Reference documentation
www.w3cplus.com/preprocesso… www.w3cplus.com/css/oocss-c… Segmentfault.com/a/119000000… www.w3cplus.com/css/fifty-s…