We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
原文:https://medium.freecodecamp.com/leveling-up-css-44b5045a2667#.tgvzlhlv5
CSS初识看起来挺容易的,毕竟,只是样式而已,对吧? 但是,给它点时间。很快,CSS将会证明给你它真实的复杂程度。 为了在规模化CSS的时候保持代码清晰,有4件事是你可以做的:使用合适的语义,模块化,采用命名约定,以及遵循单一责任原则。
在HTML和CSS中都有语义标签的概念。语义化是指词语的意思以及它们之间的关系。在HTML上下文中,语义化意味着使用适当的标签。下面是个典型例子:
<!-- bad --> <div class=”footer”></div>
<!-- good --> <footer></footer>
语义化HTML相当简单明了。另一方面,语义化CSS相对更抽象,更主观。要写出语义化的CSS意味着要选用可以表达出结构的意思和功能的类名。想出容易理解的类名。确保它们不会太特殊。这样才可以复用你的样式类。
为了说明什么是好的语义化类名,这里是一个简化了的Medium的CSS例子。
<div class="stream"> <div class="streamItem"> <article class="postArticle"> <div class="postArticle-content"> <!-- content --> </div> </article> </div> </div>
根据代码,你可以直观的知道这段代码的结构,作用和意思。父类是stream,一个articles的列表。子类是stream_item, 这个列表中有一个真实的article。父级和子级如何相互关联一目了然。此外,这些类被用在每页上来突出articles。
你应该可以像一本书一样来读HTML和CSS代码。它应该在描述一个故事,这个故事有角色,角色之间有关系。CSS越语义化,你的代码最终将会更可维护。
更深一步阅读,查看是什么使类名语义化,给CSS命名这件事真的很难, 以及 语义和感觉。更长的,请看关于HTML语义化与前端体系架构。
在像React这样基于组件库的阶段,模块化就是关键。在解析界面结构时考虑可以组合的模块作为组件。下面是Product Hunt的前端页面输出。作为一个练习,我们来把它分解成不同的组件。
每个颜色边框代表一个组件。stream有很多stream_item。
<div class="stream"> <div class="streamItem"> <!-- product info --> </div> </div>
大部分组件都可以被分解成更小的组件。
每个streamItem有一个thumbnail和一个特定的产品信息。
<!-- STREAM COMPONENT --> <div class="stream"> <div class="streamItem">
<!-- POST COMPONENT --> <div class="post"> <img src="thumbnail.png" class="postThumbnail"/> <div class="content"> <!-- product info --> </div> </div>
</div> </div>
因为stream组件独立于它的子级,反之子级也独立于它的父级,所以你可以轻松地在不显著改变stream类的情况下调整或者将post类放出来。
组件思想帮助你将代码解耦。你代码解耦越多,你的类之间相互依赖性就越低。从长远来看,这使得你的代码更易于修改维护。
当模块化CSS时,从设计稿开始就分解成组件。你可以通过笔和纸或者像Illustrator、Sketch这样的软件程序中来完成。确定这些组件,会带给你一些关于怎样命名类以及它们之间是怎样关联的灵感想法。
要了解更多关于组件驱动的CSS,请查看 CSS架构: 可扩展与模块化方法, 用Sass编写模块化CSS, 以及为了长期的可维护性和健全性请模块化你的前端代码.
现在有很多种CSS命名约定。一些人对他们命名的选择信誓旦旦,声称他们的比其他人更好。事实上,对每个人来说最好的命名约定是不同的。在这方面我收到的最好的建议是:选择对你最有意义的命名约定。
下面列出了几个大家使用的一些命名约定:
其中我最爱的是BEM。BEM代表了块级、元素以及修饰符。Yandex,相当于俄罗斯的Google,为了发布他们有大规模的CSS代码库而提出了这个理论。
BEM是命名约定中最简单也是最严格的一种。
.block {} .block__element {} .block--modifier {}
块表示更高一层的类,元素是块的子类。修饰符代表不同的状态。
<div class="search"> <input type="search__btn search__btn--active" /> </div>
在上面的例子中,块是search类,search_btn按钮是它的元素。如果我们想修改这个按钮的状态,我们可以加上一个像 --active 的修饰符。
关于命名约定请记住一件事,无论你更喜欢哪种命名约定,你经常会从不同标准的代码库继承或者和它配合工作。保持开放的心态来学习新标准,多方位思考CSS。
了解更多关于BEM可以查阅全面理解BEM语法,BEM 101, 以及BEM介绍。大概了解各种不同的约定,请查看OOCSS, ACSS, BEM, SMACSS: 它们是什么? 我应该用哪个?
单一责任原则声明每个模块或者类应该有可以涵盖这个软件提供的一个单一部分功能的职责。而且这个职责应该完全封装在这个类中。
在CSS上下文中,单一责任原则强调一段代码块,类以及模块应该只做一件事。当运用于CSS文件组织时,单一责任原则意味着像幻灯片、导航条这样的独立组件应该有自己的CSS文件。
/components |- carousel |- |- carousel.css |- |- carousel.partial.html |- |- carousel.js |- nav |- |- nav.css |- |- nav.partial.html |- |- nav.js
在文件组织上另一种通用模式是通过功能归类文件。比如,上面的片段,所有和幻灯片组件相关的文件放在一起。采用这种方法使得查找文件变得更容易。
除了分离组件样式,使用单一责任原则来分离全局样式也是很好的选择。
/base |- application.css |- typography.css |- colors.css |- grid.css
在例子中,每种样式关注的被分离到自己的文件中。这样一来,如果你想更新颜色,就可以准确的知道该修改哪里了。
不管你使用哪种文件组织约定,单一责任原则可以指导帮助你做出决定。如果一个文件开始变得臃肿,考虑根据逻辑意义将它分隔出来。
更多关于文件结构和CSS架构方面的,请阅读 Sass之美1: 架构和样式组织, 可扩展易维护的CSS架构.
当单一责任原则运用于单独的CSS类时,意味着每个类应该只有一个功能。换句话说,根据关注点将样式单独分成不同的类,这里是个典型例子:
.splash { background: #f2f2f2; color: #fffff; margin: 20px; padding: 30px; border-radius: 4px; position: absolute; top: 0; right: 0; bottom: 0; left: 0; }
上面的例子将关注点混合在了一起。splash 类不止包含了它自己的描述和样式逻辑,也包含它子级的样式。为了纠正这一点,我们可以将这段代码分成两个单独的类。
.splash { position: absolute; top: 0; right: 0; bottom: 0; left: 0; }
.splash__content { background: #f2f2f2; color: #fffff; padding: 30px; border-radius: 4px; }
现在我们有一个 splash 和 splash_content类。我们可以用splash作为通用的放置任何子类的无边距外框类。子类的所有关注点,这个例子中的splash_content,就从父类中拆开了。
你可以通过单一责任原则运用于CSS 和专职专用了解更多关于在样式和类运用单一责任原则的方法。
问任何优秀的前端工程师或者CSS设计师,他们都会告诉你他们对自己的代码从来没有完全满意过。写出出色的CSS代码是一个不断反复的过程。从简单开始,遵循基本的CSS约定和样式指导,再反复这个过程。
如果你喜欢这篇文章,你也可能会喜欢我写的这篇透过k-pop教你五个良好设计的重要特征。
关于设计,k-pop可以教给我们什么 通过k-pop_meduim.com可以学到好设计的五个特征
我很想知道你是怎样处理CSS的,你最喜欢的命名约定是什么,你怎样组织代码的。请随意留言或者Tweet我。
P.S 如果你喜欢这篇文章,并推荐分享给了朋友,这对我来说意义重大。
如果你想知道更多,可以在Twitter上关注我。那上面有我发布的一些关于设计,前端开发,机器人和机械学习的随笔杂记。
The text was updated successfully, but these errors were encountered:
No branches or pull requests
原文:https://medium.freecodecamp.com/leveling-up-css-44b5045a2667#.tgvzlhlv5
CSS初识看起来挺容易的,毕竟,只是样式而已,对吧?
但是,给它点时间。很快,CSS将会证明给你它真实的复杂程度。
为了在规模化CSS的时候保持代码清晰,有4件事是你可以做的:使用合适的语义,模块化,采用命名约定,以及遵循单一责任原则。
使用合适的语义
在HTML和CSS中都有语义标签的概念。语义化是指词语的意思以及它们之间的关系。在HTML上下文中,语义化意味着使用适当的标签。下面是个典型例子:
语义化HTML相当简单明了。另一方面,语义化CSS相对更抽象,更主观。要写出语义化的CSS意味着要选用可以表达出结构的意思和功能的类名。想出容易理解的类名。确保它们不会太特殊。这样才可以复用你的样式类。
![](http://p0.qhimg.com/t01bf03ac4cdf7e0390.png)为了说明什么是好的语义化类名,这里是一个简化了的Medium的CSS例子。
根据代码,你可以直观的知道这段代码的结构,作用和意思。父类是stream,一个articles的列表。子类是stream_item, 这个列表中有一个真实的article。父级和子级如何相互关联一目了然。此外,这些类被用在每页上来突出articles。
你应该可以像一本书一样来读HTML和CSS代码。它应该在描述一个故事,这个故事有角色,角色之间有关系。CSS越语义化,你的代码最终将会更可维护。
更深一步阅读,查看是什么使类名语义化,给CSS命名这件事真的很难, 以及 语义和感觉。更长的,请看关于HTML语义化与前端体系架构。
模块化
在像React这样基于组件库的阶段,模块化就是关键。在解析界面结构时考虑可以组合的模块作为组件。下面是Product Hunt的前端页面输出。作为一个练习,我们来把它分解成不同的组件。
![](http://p0.qhimg.com/t01f250c969bb560fc3.png)每个颜色边框代表一个组件。stream有很多stream_item。
大部分组件都可以被分解成更小的组件。
![](http://p0.qhimg.com/t01d2124b5e4c7c8d32.png)每个streamItem有一个thumbnail和一个特定的产品信息。
因为stream组件独立于它的子级,反之子级也独立于它的父级,所以你可以轻松地在不显著改变stream类的情况下调整或者将post类放出来。
组件思想帮助你将代码解耦。你代码解耦越多,你的类之间相互依赖性就越低。从长远来看,这使得你的代码更易于修改维护。
![](http://p0.qhimg.com/t0144fbfaa520375fa3.png) [组件驱动的设计](https://dribbble.com/shots/1200218-iOS-7-UI-Components)当模块化CSS时,从设计稿开始就分解成组件。你可以通过笔和纸或者像Illustrator、Sketch这样的软件程序中来完成。确定这些组件,会带给你一些关于怎样命名类以及它们之间是怎样关联的灵感想法。
要了解更多关于组件驱动的CSS,请查看 CSS架构: 可扩展与模块化方法, 用Sass编写模块化CSS, 以及为了长期的可维护性和健全性请模块化你的前端代码.
选择良好的命名约定
现在有很多种CSS命名约定。一些人对他们命名的选择信誓旦旦,声称他们的比其他人更好。事实上,对每个人来说最好的命名约定是不同的。在这方面我收到的最好的建议是:选择对你最有意义的命名约定。
下面列出了几个大家使用的一些命名约定:
其中我最爱的是BEM。BEM代表了块级、元素以及修饰符。Yandex,相当于俄罗斯的Google,为了发布他们有大规模的CSS代码库而提出了这个理论。
![](http://p0.qhimg.com/t0129061d141820732b.png)BEM是命名约定中最简单也是最严格的一种。
块表示更高一层的类,元素是块的子类。修饰符代表不同的状态。
![](http://p0.qhimg.com/t01c657ca51655cbda8.png)在上面的例子中,块是search类,search_btn按钮是它的元素。如果我们想修改这个按钮的状态,我们可以加上一个像 --active 的修饰符。
关于命名约定请记住一件事,无论你更喜欢哪种命名约定,你经常会从不同标准的代码库继承或者和它配合工作。保持开放的心态来学习新标准,多方位思考CSS。
了解更多关于BEM可以查阅全面理解BEM语法,BEM 101, 以及BEM介绍。大概了解各种不同的约定,请查看OOCSS, ACSS, BEM, SMACSS: 它们是什么? 我应该用哪个?
遵循单一责任原则
单一责任原则声明每个模块或者类应该有可以涵盖这个软件提供的一个单一部分功能的职责。而且这个职责应该完全封装在这个类中。
在CSS上下文中,单一责任原则强调一段代码块,类以及模块应该只做一件事。当运用于CSS文件组织时,单一责任原则意味着像幻灯片、导航条这样的独立组件应该有自己的CSS文件。
在文件组织上另一种通用模式是通过功能归类文件。比如,上面的片段,所有和幻灯片组件相关的文件放在一起。采用这种方法使得查找文件变得更容易。
除了分离组件样式,使用单一责任原则来分离全局样式也是很好的选择。
在例子中,每种样式关注的被分离到自己的文件中。这样一来,如果你想更新颜色,就可以准确的知道该修改哪里了。
不管你使用哪种文件组织约定,单一责任原则可以指导帮助你做出决定。如果一个文件开始变得臃肿,考虑根据逻辑意义将它分隔出来。
更多关于文件结构和CSS架构方面的,请阅读 Sass之美1: 架构和样式组织, 可扩展易维护的CSS架构.
当单一责任原则运用于单独的CSS类时,意味着每个类应该只有一个功能。换句话说,根据关注点将样式单独分成不同的类,这里是个典型例子:
上面的例子将关注点混合在了一起。splash 类不止包含了它自己的描述和样式逻辑,也包含它子级的样式。为了纠正这一点,我们可以将这段代码分成两个单独的类。
现在我们有一个 splash 和 splash_content类。我们可以用splash作为通用的放置任何子类的无边距外框类。子类的所有关注点,这个例子中的splash_content,就从父类中拆开了。
你可以通过单一责任原则运用于CSS 和专职专用了解更多关于在样式和类运用单一责任原则的方法。
简单比复杂更难
问任何优秀的前端工程师或者CSS设计师,他们都会告诉你他们对自己的代码从来没有完全满意过。写出出色的CSS代码是一个不断反复的过程。从简单开始,遵循基本的CSS约定和样式指导,再反复这个过程。
如果你喜欢这篇文章,你也可能会喜欢我写的这篇透过k-pop教你五个良好设计的重要特征。
关于设计,k-pop可以教给我们什么
通过k-pop_meduim.com可以学到好设计的五个特征
我很想知道你是怎样处理CSS的,你最喜欢的命名约定是什么,你怎样组织代码的。请随意留言或者Tweet我。
P.S 如果你喜欢这篇文章,并推荐分享给了朋友,这对我来说意义重大。
如果你想知道更多,可以在Twitter上关注我。那上面有我发布的一些关于设计,前端开发,机器人和机械学习的随笔杂记。
The text was updated successfully, but these errors were encountered: