都 2015 年了,CSS 怎么还是这么糟糕

🎞 Slides:CSS Still Sucks 2015

Posted by Caleb on December 28, 2015

下滑这里查看更多内容

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

Thanks

Reveal.js