CSS方法论完全总结

软件开发领域所有的工程问题,归根结底衍生自一个问题:代码量大了怎么办?

对于CSS而言,因代码量增大导致的核心问题是命名冲突。

解决命名冲突的方法论是模块化,围绕此方法论,演化出种种模块化方案。

一、命名的模块化

基本思路是确保全局空间下一级域名不冲突,那么子域名就被限定在了独立的局部作用域中,从而保证命名的唯一性。

根据域名的划分方式,出现了不同的命名方案:

   BEM:Block-Element-Modifier,比较笼统,没有过多限制规定

   SUIT CSS

   1、将命名对象划分为组件(component)和功能(Utility)。组件直接命名,功能额外加前缀,比如专门给js调用的类名可加上js前缀:js-button

   2、规定了连字符的用法。普通隔断用单个连字符,描述性词汇用两个连字符:

   .nav-button { }

   .nav-button--primary { }

   沿着这个思路,其实还可以把下划线引进来,用来设置其它规则。

   3、状态切换用is-state型的相邻类名(adjoining class)

   .button { }

   .button.is-clicked { }

   <button class=”button is-clicked”></button>

   OOCSS

   简单的说就是抽象公共类,把复用度高的样式抽取出来,例如:

   .mt20 { margin-top: 20px }

   .tc { text-align: center }

   .abs { position: absolute }

   .clearfix:after { content: ‘’; display: block; clear: both; height: 0 }

   这种方案的思路是通过提高复用性,减少命名的需要,因为有的样式直接用公共类名就能实现,不需要额外命名。

   它的缺点是滥用就可能付出代价,比如有10个组件用同一个普通类名,那么修改样式只需要改一处CSS即可,但是在10个组件上用同一个公共类名比如mt20,意味着把mt20改成mt15,你需要改10处的class。所以公共样式少用公共类,不要图省事儿。

   SMACSS

   针对数量庞大的类名,SMACSS提出了一个分类的方案:

   1、Base:基础的样式规则

   2、Layout:用于布局的样式规则

   3、Module:可复用的模块样式规则

   4、State:状态样式

   5、Theme:UI样式

   针对不同分类,可以使用不同的前缀来划分命名空间,就不多赘述了。

   ITCSS

   此方案更像是CSS整体架构方案,与SMACSS横向分类不同,它综合了以上各种方法,提出了一个纵向分层模型:

   1、Settings:简单的说就是在SCSS中预设好变量

   2、Tools:简单的说就是在SCSS中预设好mixins和functions

   3、Generic:简单的说就是reset.css或normalize.css

   4、Elements:对元素的基本格式化,如h1 { font-size: 20px }

   5、Objects:使用OOCSS抽象公共类

   6、Components:UI组件的样式

   7、Trumps:辅助性、功能性的特殊样式,例如动画

二、CSS in JS

在大型项目中通过命名来避免冲突,是一件颇费脑力的事情,既需要记住所有规则,还需要判断你的命名是否符合规则。更深刻的问题是,这似乎不像是程序员解决问题的方式,命名这样的低级劳动也值得如此费劲?

   于是React提出了CSS in JS的思路,React是这样考虑的:在JS以及所有程序语言的最佳实践里,都会避免使用全局变量,而在CSS里,不管用什么命名方式,满屏幕都是全局变量,怎样才能避免使用全局变量呢?办法是采用内联样式,根本不用CSS选择器。

   var styles = {

   button: { width: ‘50px’, height: ‘30px’ , backgroundColor: ‘#ff4444’}

   }

   <div style = { styles.button }>

   我们不能简单的用“开历史倒车”这样的论调来判断一种技术方案,而应结合应用场景,在成本和收益上权衡。具体的说就是这种方案所解决的问题与其带来的问题相比,是否更划算。

   来源:https://speakerdeck.com/vjeux/react-css-in-js

大型CSS存在的问题有:

1、全局的命名空间容易污染、冲突

2、依赖管理复杂

3、无用代码难以清除

4、长命名导致代码体积无法进一步压缩

5、不利于和JS共享常量

6、不确定的解析结果(CSS中存在层叠,如果层叠系数高的代码加载更慢,会导致最终解析的样式发生突变)

   7、不能解耦(改一处CSS,所有使用该CSS的UI样式都会受影响)

   用JS + inline style 解决了上述所有问题,当然也带来了其它副作用,比如难以调试、不能用CSS预处理器、不能实现Media Query和伪元素等,而且如果你不用React……

三、CSS Module

  CSS Module可以看做是CSS in JS思路的另一条路线,就是使用JS编译原生的CSS文件,使其具备模块化的能力。

  CSS Module根据CSS文件划分模块,模块内部的类名都会使用哈希算法编译成独一无二的名称,因此不会出现模块之间命名冲突的问题。

  当然,必须使用构建工具如webpack,才能使用CSS Module提供的功能。

   CSS Module要求每个元素只能携带一个类名,不能用多个类名,那么要使用组合样式怎么办?解决方案是在CSS中使用component,这个其实在预处理器中已经有类似的实现:

   .common { }

   .normal {

   composes: common  // 继承common所有的样式

   }

   composes不仅可以引用本文件的类名,还可以引用其它文件的类名:

   .normal {

   composes: common;

   composes: primary from "../shared/colors.css";

   }

   另外,使用:global(.className)语法可以定义全局类名,结合PostCSS可以使用变量,具体请参见阮一峰的教程:

   http://www.ruanyifeng.com/blog/2016/06/css_modules.html

四、PostCSS

到这里,CSS方法论的发展脉络已经很清晰了。命名方案在中小型项目中仍然存在价值,但是在大型项目中,更好的方案是依据CSS in JS的思路加强原生CSS的能力。React提出的思路是抛弃CSS,能用JS解决的都用JS解决。另一种思路是使用编译工具,对CSS进行加工处理。

PostCSS就是近年来非常热门的一种编译工具,Vue官方提供的脚手架Vue-cli默认采用的CSS处理工具就是PostCSS。PostCSS和预处理器Less、Sass不同,预处理器仅仅是提供了一套语法糖,而PostCSS是一个全面的处理工具,通过丰富的插件,可以实现用于处理CSS的几乎所有的功能:类名编译、auto-prefixer、压缩、预处理器功能、属性简写……

PostCSS并不是唯一,前端界历来奉行的宗旨是“生命不息,折腾不止”,关于CSS in JS的方案,大家感受一下:

有这么多好轮子,妈妈再也不用担心我词汇量不够了。

时间: 2024-11-09 16:44:02

CSS方法论完全总结的相关文章

CSS 继承深度解析

FROM ME: 之前在研究前端性能优化的时候,就有学习关于CSS中“善用CSS中的继承”. 原文:CSS Inheritance, The Cascade And Global Scope: Your New Old Worst Best Friends 译文:掘金翻译计划 我酷爱模块化设计.长期以来我都热衷于将网站分离成组件,而不是页面,并且动态地将那些组件合并到界面上.这种做法灵活,高效并且易维护. 但是我不想我的设计看上去是由一些不相关的东西组成的.我是在创造一个界面,而不是一张超现实主

CSS代码重构

CSS代码重构的目的 我们写CSS代码时,不仅仅只是完成页面设计的效果,还应该让CSS代码易于管理,维护.我们对CSS代码重构主要有两个目的:1.提高代码性能2.提高代码的可维护性 提高代码性能 提高CSS代码性能主要有两个点:1.提高页面的加载性能提高页面的加载性能,简单说就是减小CSS文件的大小,提高页面的加载速度,尽可以的利用http缓存2.提高CSS代码性能不同的CSS代码,浏览器对其解析的速度也是不一样的,如何提高浏览器解析CSS代码的速度也是我们要考虑的 提高代码的可维护性 提高CS

CSS代码重构与优化之路

写CSS的同学们往往会体会到,随着项目规模的增加,项目中的CSS代码也会越来越多,如果没有及时对CSS代码进行维护,CSS代码不断会越来越多.CSS代码交错复杂,像一张庞大的蜘蛛网分布在网站的各个位置,你不知道修改这行代码会有什么影响,所以如果有修改或增加新功能时,开发人员往往不敢去删除旧的冗余的代码,而保险地增加新代码,最终的坏处就是项目中的CSS会越来越多,最终陷入无底洞. CSS代码重构的目的 我们写CSS代码时,不仅仅只是完成页面设计的效果,还应该让CSS代码易于管理,维护.我们对CSS

CSS的性能优化

---恢复内容开始--- 作者:徐尤熙链接:https://www.zhihu.com/question/19886806/answer/80432295 [CSS代码重构与优化之路] 写CSS的同学们往往会体会到,随着项目规模的增加,项目中的CSS代码也会越来越多,如果没有及时对CSS代码进行维护,CSS代码不断会越来越多.CSS代码交错复杂,像一张庞大的蜘蛛网分布在网站的各个位置,你不知道修改这行代码会有什么影响,所以如果有修改或增加新功能时,开发人员往往不敢去删除旧的冗余代码,而保险地增加

BEM —— 源自Yandex的CSS 命名方法论

人们问我最多的问题之一是在CSS类名中--和__是什么意思?它们的出现是源于BEM和Nicolas Gallagher... BEM的意思就是块(block).元素(element).修饰符(modifier),是由Yandex团队提出的一种前端命名方法论.这种巧妙的命名方法让你的CSS类对其他开发者来说更加透明而且更有意义.BEM命名约定更加严格,而且包含更多的信息,它们用于一个团队开发一个耗时的大项目. 重要的是要注意,我使用的基于BEM的命名方式是经过Nicolas Gallagher修改

css设计模式

(转载)原版地址:https://kb.cnblogs.com/page/551422/ 什么是设计模式? 曾有人调侃,设计模式是工程师用于跟别人显摆的,显得高大上:也曾有人这么说,不是设计模式没用,是你还没有到能懂它,会用它的时候. 先来看一下比较官方的解释:"设计模式(Design pattern)是一套被反复使用.多数人知晓的.经过分类的.代码设计经验的总结.使用设计模式是为了可重用代码.让代码更容易被他人理解.保证代码可靠性. 毫无疑问,设计模式于己于他人于系统都是多赢的:设计模式使代码

CSS命名规范——BEM思想(非常赞的规范)

人们问我最多的问题之一是在CSS类名中“--”和“__”是什么意思?它们的出现是源于BEM和Nicolas Gallagher... BEM的意思就是块(block).元素(element).修饰符(modifier),是由Yandex团队提出的一种前端命名方法论.这种巧妙的命名方法让你的CSS类对其他开发者来说更加透明而且更有意义.BEM命名约定更加严格,而且包含更多的信息,它们用于一个团队开发一个耗时的大项目. 重要的是要注意,我使用的基于BEM的命名方式是经过Nicolas Gallagh

CSS中的BEM命名

BEM是一个非常有用,强大,简单的命名约定. 它能让前端代码更容易阅读和理解,更容易协作,更容易控制,更加健壮和明确而且更加严密,更加容易地维护代码. BEM命名思路: .block{} .block__element{} .block--modifier{} .block{} .block__element{} .block--modifier{} 著作权归作者所有.商业转载请联系作者获得授权,非商业转载请注明出处.原文: http://www.w3cplus.com/css/mindbemd

Atitit.css 规范 bem &#160;项目中 CSS 的组织和管理

Atitit.css 规范 bem  项目中 CSS 的组织和管理 1. 什么是BEM?1 1.1. 块(Block)2 1.2. 元素(Element)2 1.3. BEM树(和DOM树类似).3 1.4. 修饰符(modifier)的3 2. 块的独立性4 3. 独立的CSS4 3.1. 为独立的CSS类命名5 4. BEM争议最大的就是它的命名风格 6 5. OOCSS6 6. ACSS6 7. CSS 组织和管理 结论attilax总结7 8. Atibem7 8.1. Modifier