下滑这里查看更多内容
Watching Fullscreen →
你也可以通过扫描二维码在手机上观看
这个 Web Slides 开源在我的 Github 上,欢迎你帮助我完善这个展示文稿,你可以给我提 issue,可以 fork & pull request。如果它能帮助到你了,希望你还能不吝啬 star 一下这个项目
Catalog
- Document Times
- Frameworks
- Style Guide
- OOCSS
- SMACSS
- Pre-processer
- PostCSS
- Application Times
- Shadow DOM
- CSS “4”
- Naming Convention
- BEM
- SUIT
- Atomic CSS
- CSS in JS
- CSS Modules
- Interoperable CSS
- PostCSS, again
- My Opinionated Proposal
- POCss
POCss: Page Override Components CSS
1. Scoping Components
CSS Blocks should only be used inside a component of the same name.
1
2
3
4
5
6
7
8
// Component/index.scss
.ComponentName {
&--mofierName {}
&__decendentName {
&--modifierName {}
}
.isStateOfComponent {}
}
1
2
// Component/index.js
require('./index.scss');
CSS is always bundled with components
(from loading, mount to unmount)
2. Components can be Overrode by Pages
There is always requirements to rewrite styles of components in pages
1
2
3
4
5
6
7
// Pages/PageA.scss
#PageA {
.pagelet-name {
.pagelet-descendent-name {}
}
.ComponentName{ /* override */ }
}
1
2
// Pages/index.js
require('./PageA.scss');
- #Page for absolutely scoping between pages
- .pagelet-name should be lowercase to prevent conflicting with components
Why POC?
-
It’s technology-agnostic One css framework can be played with whatever technology stacks
You can combined Scss, PostCSS and whatever you want -
Solving problems, and easy Makes reading and teamwork much easier
Get all benefit from BEM, SUITCSS and others -
Leverage the power of cascading properly Scoping components but allow reasonable overriding
It’s pragmatic, flexible and hitting the sweet spot