管理 CSS 爆炸

我正在开发的网站一直严重依赖 CSS。现在，所有的 CSS 样式都以每个标签为基础应用，所以现在我正试图将其移动到更多的外部样式，以帮助应对未来的任何更改。

但现在的问题是，我已经注意到我得到了一个“CSS爆炸”。我很难决定如何最好地组织和抽象 CSS 文件中的数据。

我在网站中使用了大量div标签，从一个严重基于表格的网站移动。所以我得到了很多看起来像这样的CSS选择器：

div.title {
background-color: blue;
color: white;
text-align: center;
}


div.footer {
/* Styles Here */
}


div.body {
/* Styles Here */
}


/* And many more */

还不算太坏，但作为初学者，我想知道是否可以就如何最好地组织CSS文件的各个部分提出建议。我不想为我网站上的每个元素都有单独的CSS属性，我总是希望CSS文件相当直观且易于阅读。

我的最终目标是使 CSS 文件易于使用，并展示它们提高 Web 开发速度的能力。这样，将来可能在这个网站上工作的其他人也将开始使用良好的编码实践，而不必像我一样学习。

48740 次浏览
小开

很多时候，我会看到个人将文件分成几个部分，在部分之间有一个标题注释。

就像

/* Headings and General Text */


.... stuff here for H1, etc..


/* Main page layout */


.... stuff here for layout page setup etc.

它工作得很好，可以很容易地稍后返回并找到您正在处理的内容。

小开
最佳答案

这是一个非常好的问题。无论我走到哪里，CSS 文件都会在一段时间后失控——尤其是但不仅限于在团队中工作时。

以下是我自己试图遵守的规则（不是我总是设法做到的）。

  • 早重构，常重构。经常清理CSS文件，将同一个类的多个定义融合在一起。立即删除过时的定义。

  • 在修复错误期间添加CSS时，留下注释说明更改的作用（“这是为了确保框在IE<7中保持对齐”）

  • 避免冗余，例如在.classname和.classname:hover中定义相同的内容。

  • 使用注释/** Head **/构建清晰的结构。

  • 使用一个美化工具来保持一个固定的风格。我使用Polystyle，我对这个工具很满意（花费15美元，但花得值）。周围也有免费的工具（例如代码美化器基于CSS Tidy，一个开源工具）。

  • 构建合理的类。请参阅下面的一些注释。

  • 使用语义学，避免DIV汤-例如，使用#EYZ作为菜单。

  • 在尽可能低的级别上定义所有内容（例如body中的默认字体系列、颜色和大小）并尽可能使用inherit

  • 如果你有非常复杂的CSS，也许CSS预编译器会有所帮助。出于同样的原因，我计划很快研究xCSS。还有其他几个。

  • 如果在团队中工作，也要强调CSS文件质量和标准的必要性。每个人都很重视自己编程语言的编码标准，但很少有人意识到这对CSS也是必要的。

  • 如果在团队中工作，请考虑使用版本控制。它使事情更容易跟踪，编辑冲突更容易解决。这是非常值得的，即使你“只是”进入超文本标记语言和CSS。

  • 不要使用!important。不仅因为 IE =< 7 无法处理它。在复杂的结构中，使用!important通常很容易改变无法找到来源的行为，但它是长期维护的毒药。

构建合理的类

这就是我喜欢建立合理类的方式。

我首先应用全局设置：

body { font-family: .... font-size ... color ... }
a { text-decoration: none; }

然后，我确定页面布局的主要部分-例如顶部区域，菜单，内容和页脚。如果我写了好的标记，这些区域将与超文本标记语言结构相同。

然后，我开始构建CSS类，尽可能多地指定祖先，并尽可能紧密地对相关类进行分组。

div.content ul.table_of_contents
div.content ul.table_of_contents li
div.content ul.table_of_contents li h1
div.content ul.table_of_contents li h2
div.content ul.table_of_contents li span.pagenumber

把整个CSS结构想象成一个树，离根越远，定义就越具体。你想保持类的数量尽可能少，你想尽可能少地重复自己。

例如，假设您有三个级别的导航菜单。 这三个菜单看起来不同，但它们也共享某些特征。例如，它们都是

    ，它们都有相同的字体大小，并且项目都彼此相邻（与ul的默认呈现相反）。此外，没有一个菜单有任何项目符号（list-style-type）。

    首先，在名为menu的类中定义常见特征：

    div.navi ul.menu { display: ...; list-style-type: none; list-style-image: none; }
div.navi ul.menu li { float: left }

    然后，定义三个菜单中每个菜单的具体特征。1级为40像素高；2级和3级为20像素。

    备注：您也可以为此使用多个类，但Internet Explorer 6有多个类的问题，因此此示例使用ids。

    div.navi ul.menu#level1 { height: 40px; }
div.navi ul.menu#level2 { height: 20px; }
div.navi ul.menu#level3 { height: 16px; }

    菜单的标记如下所示：

    如果您在页面上有语义相似的元素（如这三个菜单），请尝试先找出共性并将其放入类中；然后，找出特定属性并将其应用于类，或者，如果您必须支持Internet Explorer 6，则ID。

    杂项超文本标记语言提示

    如果您将这些语义学添加到超文本标记语言输出中，设计人员可以稍后使用纯CSS自定义网站和/或应用程序的外观，这是一个很大的优势和节省时间。

    • 如果可能，给每个页面的主体一个唯一的类：这使得向样式表添加页面特定的调整变得非常容易： 

      body.contactpage div.container ul.mainmenu li { color: green }

    • When building menus automatically, add as much CSS context as possible to allow extensive styling later. For example:

        

      •  First item 
        • 

      •  Second item 
        • 

      •  Third item 
        • 

      •  Fourth item 
        •

      这样，每个菜单项都可以根据其语义上下文访问样式：无论是列表中的第一个还是最后一个项目；无论是当前活动的项目；和数字。

    说明即上面示例中概述的多个类的分配在IE6中无法正常工作。有一个变通方法使IE6能够处理多个类。如果没有解决方法，您将不得不设置对您最重要的类（项目编号、活动或第一/最后），或者使用ID。

小开

我发现困难的是将网站所需的设计转化为一系列规则。如果网站的设计清晰且基于规则，那么您的类名和CSS结构可以由此产生。但是，如果人们随着时间的推移，随机添加一些没有多大意义的内容到网站中，那么在CSS中您可以做的不多。

我倾向于组织我的CSS文件大致如下：

  1. CSS重置，基于Eric Meyer的（因为除此之外，我发现，对于大多数元素，我至少有一两个规则只是重置默认浏览器样式-例如，我的大多数列表看起来不像列表的默认超文本标记语言样式。）

  2. 网格系统CSS，如果站点需要它。（我的基础是960.gs）

  3. 每个页面上出现的组件的样式（页眉、页脚等）

  4. 跨站点不同位置使用的组件的样式

  5. 仅与单个页面相关的样式

如您所见，大部分取决于网站的设计。如果设计清晰且有条理，您的CSS可以。如果不是，你就完蛋了。

小开

这里仅举4个例子：

在所有4个问题上，我的回答都包括下载和阅读Natalie Downe的PDFcss系统的建议。（PDF包含大量幻灯片中没有的注释，所以请阅读PDF！）。注意她对组织的建议。

编辑（2014/02/05）四年后，我会说：

  • 使用CSS预处理器并将您的文件作为部分管理（我个人更喜欢带有指南针的Sass，但更少也很好，还有其他）
  • 阅读OOCSS、SMACSS和BEM或getbem等概念。
  • 看看Bootstrap和Zurb基金会等流行的CSS框架是如何结构化的。不要忽视不太流行的框架-因纽特人是一个有趣的框架，但还有很多其他框架。
  • 将您的文件与持续集成服务器和/或Grunt或Gulp等任务运行器上的构建步骤结合/缩小。
小开

您还应该了解级联、重量以及它们是如何工作的。

我注意到您只使用了类标识符（div.title）。您知道您也可以使用ID，并且ID比类更重要吗？

例如， 

#page1 div.title, #page1 ul, #page1 span {
// rules
}

将使所有这些元素共享一个字体大小，例如，一种颜色，或者您的任何规则。您甚至可以使作为#page1后代的所有DIV获得某些规则。

至于权重，请记住CSS轴从最一般/最轻到最特定/最重。也就是说，在CSS选择器中，元素说明符被类说明符覆盖，被ID说明符覆盖。数字计数，因此具有两个元素说明符（ul li）的选择器将比仅具有单个说明符（li）的选择器具有更多的权重。

可以把它想象成数字。one列中的9仍然小于10列中的1。具有ID说明符、类说明符和两个元素说明符的选择器将比没有ID、500个类说明符和1,000个元素说明符的选择器具有更大的权重。当然，这是一个荒谬的例子，但你明白了。关键是，应用这个概念可以帮助你清理大量CSS。

顺便说一句，除非您遇到与具有class="title"的其他元素的冲突，否则无需向类（div.title）添加元素说明符。不要添加不必要的权重，因为您稍后可能需要使用该权重。

小开

我的回答是高层次的，以解决你在问题中提出的高层次的担忧。你可以做一些低级的组织技巧和调整来使它更漂亮，但这些都不能解决方法上的缺陷。影响CSS爆炸的有几个因素。显然是网站的整体复杂性，还有命名语义学、CSS性能、CSS文件组织和可测试性/可接受性。

你在命名语义学上似乎走在了正确的道路上，但还可以更进一步。未经结构修改而重复出现在站点上的超文本标记语言部分（称为“模块”）可以被视为选择器根，从那里你可以相对于该根限定内部布局。这是面向对象的CSS的基本原则，你可以阅读/观看更多关于雅虎工程师的演讲。

重要的是要注意，这种干净的方法可能与对性能的关注相反，这有利于基于id或标签名称的短选择器。找到平衡取决于你，但除非你有一个庞大的网站，否则这应该只是一个提醒你保持选择器简短的指南。更多关于性能在这里。

最后，你是打算为整个站点提供单个CSS文件，还是为多个文件（用于每个页面或-部分文件的单个基本文件）？单个文件对性能更好，但可能更难理解/维护多个团队成员，并且可能更难测试。对于测试，我建议你有一个单个CSS测试页面，它包括每个受支持的CSS模块，以测试冲突和意外的级联。

或者，您可以使用多文件方法将CSS规则的范围限制在一个页面或一个部分。这需要浏览器下载多个文件，这是一个性能问题。您可以使用服务器端编程动态指定和聚合（和缩小）CSS文件到一个文件中。但是由于这些文件是单独的，并且对它们的测试将是单独的，您引入了跨页面/部分外观不一致的可能性。因此测试变得更加困难。

由您来分析客户的具体需求，相应地平衡这些关注点。

小开

看一下 1.SASS 2.指南针

小开

不要在CSS中写标题

只需将部分拆分为文件。任何CSS注释，都应该是注释。

reset.css
base.css
somepage.css
someotherpage.css
some_abstract_component.css

使用脚本将它们组合成一个；如果需要。您甚至可以拥有一个不错的目录结构，只需让您的脚本递归扫描.css文件。

如果你必须写标题，在文件的开头有一个TOC

TOC中的标题应该完全等于你稍后写的标题。搜索标题是一件痛苦的事情。更糟糕的是，人们怎么会知道你的第一个标题之后还有另一个标题呢？ps。在编写TOC时，不要在每行的开头添加像文档一样的*（星号），这只会让选择文本变得更烦人。

/* Table of Contents
- - - - - - - - -
Header stuff
Body Stuff
Some other junk
- - - - - - - - -
*/
...
/* Header Stuff
*/
...
/* Body Stuff
*/

用规则或在规则内写评论，而不是在块外

首先，当你编辑脚本时，有一半的机会你会注意规则块之外的内容（特别是如果它是一大堆文本 ;) ). 其次，（几乎）没有情况需要在外面“评论”。如果它在外面，99%的时间都是标题，所以保持这样。

将页面拆分为组件

大多数时候，组件应该有position:relative、padding和margin。这大大简化了%规则，并允许元素的absolute:position'ing简单得多，因为如果有一个绝对定位的容器，绝对定位的元素将在计算top、right、bottom、left属性时使用该容器。

HTML5文档中的大多数DIV通常是一个组件。

组件也可以被认为是页面上的一个独立单元。用外行的话来说，如果像黑盒这样的东西有意义，就像对待组件一样对待某物。

再次使用QA页面示例：

#navigation
#question
#answers
#answers .answer
etc.

通过将页面拆分为组件，您将工作拆分为可管理的单元。

将具有累积效应的规则放在同一行。

例如border、margin和padding（但不是outline）都会添加到您正在样式化的元素的尺寸和大小中。

position: absolute; top: 10px; right: 10px;

如果它们在一行上不那么可读，至少把它们放在很近的地方：

padding: 10px; margin: 20px;
border: 1px solid black;

尽可能使用简写：

/* the following... */
padding-left: 10px;
padding-right: 10px;
/* can simply be written as */
padding: 0 10px;

永远不要重复选择器

如果您有相同选择器的多个实例，那么您很有可能不可避免地最终会遇到相同规则的多个实例。例如：

#some .selector {
margin: 0;
font-size: 11px;
}
...
#some .selector {
border: 1px solid #000;
margin: 0;
}

当您可以使用id/类时，避免使用标签作为选择器

首先，DIV和SPAN标签是例外：你永远不应该使用它们！；）只使用它们来附加类/id。

这…

div#answers div.answer table.statistics {
border-collapse: collapsed;
color: pink;
border: 1px solid #000;
}
div#answers div.answer table.statistics thead {
outline: 3px solid #000;
}

应该这样写：

#answers .answer .statistics {
border-collapse: collapsed;
color: pink;
border: 1px solid #000;
}
#answers .answer .statistics thead {
outline: 3px solid #000;
}

因为那里额外的悬空DIV没有给选择器添加任何东西。它们还强制执行不必要的标签规则。例如，如果您要将.answer从div更改为article，您的样式将中断。

如果你更喜欢清晰度：

#answers .answer .statistics {
color: pink;
border: 1px solid #000;
}
#answers .answer table.statistics {
border-collapse: collapsed;
}
#answers .answer .statistics thead {
outline: 3px solid #000;
}

原因是border-collapse属性是一个特殊属性，只有在应用于table时才有意义。如果.statistics不是table，它不应该应用。

一般规则是邪恶的！

  • 如果可以，避免编写通用/魔法规则
  • 除非是用于CSS重置/取消重置，否则您的所有通用魔法都应该适用于至少一个根组件

他们不会节省你的时间，他们会让你的头爆炸；以及使维护成为一场噩梦。当你编写规则时，你可能知道它们适用于哪里，但这并不能保证你的规则不会在以后困扰你。

添加到这个泛型规则是令人困惑和难以阅读的，即使您对正在样式化的文档有一些了解。这并不是说您不应该编写泛型规则，只是不要使用它们，除非您真的打算让它们成为泛型，甚至它们尽可能多地将范围信息添加到选择器中。

像这样的东西…

.badges {
width: 100%;
white-space: nowrap;
}


address {
padding: 5px 10px;
border: 1px solid #ccc;
}

…与在编程语言中使用全局变量存在相同的问题。您需要给它们范围！

#question .userinfo .badges {
width: 100%;
white-space: nowrap;
}


#answers .answer .userinfo address {
padding: 5px 10px;
border: 1px solid #ccc;
}

基本上读作：

components                   target
---------------------------- --------
#answers .answer   .userinfo address
-------- --------- --------- --------
domain   component component selector

每当我知道某个组件是页面上的单例时，我都喜欢使用ID；您的需求可能不同。

注意：理想情况下，您应该写得足够。然而，与提及较少组件相比，在选择器中提及更多组件是更宽容的错误。

让我们假设您有一个pagination组件。您在网站的许多地方使用它。这将是您编写通用规则的一个很好的例子。假设您display:block单个页码链接并为它们提供深灰色背景。为了让它们可见，您必须有这样的规则：

.pagination .pagelist a {
color: #fff;
}

现在让我们假设你使用你的分页列表的答案，你可能会遇到这样的东西

#answers .header a {
color: #000;
}
...
.pagination .pagelist a {
color: #fff;
}

这会让你的白色链接变成黑色，这是你不想要的。

不正确的解决方法是：

.pagination .pagelist a {
color: #fff !important;
}

正确的修复方法是：

#answers .header .pagination .pagelist a {
color: #fff;
}

复杂的“逻辑”评论不起作用：）

如果你写这样的东西：“这个值取决于blah-blah和blah-blah的高度”，你不可避免地会犯错误，它会像纸牌屋一样倒塌。

保持你的注释简单；如果你需要“逻辑操作”，可以考虑使用SASS或少之类的CSS模板语言。

我怎么写颜色托盘？

把这个留到最后。为你的整个颜色托盘准备一个文件。没有这个文件，你的样式在规则中仍然应该有一些可用的颜色托盘。你的颜色托盘应该覆盖。你使用一个非常高级别的父组件（例如#page）链接选择器，然后将你的样式编写为一个自给自足的规则块。它可以只是颜色或更多。

eg.

#page #header .description,
#page #categories .description,
#page #answers .answer .body
{
color: #222; background: #fff;
border-radius: 10px;
padding: 1em;
}

这个想法很简单，你的颜色托盘是一个独立于基本样式的样式表，你级联进入。

更少的名称，需要更少的内存，使代码更易于阅读

使用更少的名称更好。理想情况下使用非常简单（简短！）的单词：文本、正文、标题。

我还发现简单单词的组合更容易理解，然后有一大堆长的“适当”单词：postbody，posthead，userinfo等。

保持词汇量小，这样即使有陌生人来阅读你的样式汤（比如几周后的你自己；））只需要了解单词的使用位置，而不是每个选择器的使用位置。例如，每当一个元素被认为是“选定项目”或“当前项目”时，我都会使用.this，等等。

你自己洗干净

编写CSS就像吃饭，有时你会留下一团糟。确保你清理了那个烂摊子，否则垃圾代码会堆积起来。删除你不使用的类/id。删除你不使用的CSS规则。确保一切都很好，你没有冲突或重复的规则。

如果您像我建议的那样，将某些容器视为您的风格中的黑盒（组件），在选择器中使用这些组件，并将所有内容保存在一个专用文件中（或使用TOC和标头正确拆分文件），那么您的工作就会轻松得多。

您可以使用Firefox扩展Dust-Me选择器（提示：将其指向您的sitemap.xml）等工具来帮助您找到隐藏在css nukes和carnies中的一些垃圾。

保存unsorted.css文件

假设您正在设计QA站点的样式，并且您已经有了“答案页面”的样式表，我们将其称为answers.css。如果您现在需要添加很多新的css，请将其添加到unsorted.css样式表中，然后重构到您的answers.css样式表中。

有几个原因：

  • 完成后重构更快，然后是搜索规则（可能不存在）并注入代码
  • 你会写一些你会删除的东西，注入代码只会让删除代码变得更难
  • 附加到原始文件很容易导致规则/选择器重复
小开

我见过的对抗CSS膨胀的最好方法是使用面向对象的CSS原则。

甚至有一个OOCSS框架非常好。

一些意识形态与上面的答案中所说的很多内容背道而驰，但是一旦你知道如何以面向对象的方式构建CSS，你就会发现它实际上可以保持代码的精益和平均。

这里的关键是在您的站点中识别“对象”或构建块模式并使用它们进行架构。

Facebook聘请了OOCSS的创建者妮可·沙利文来节省他们的前端代码（超文本标记语言/CSS）。是的，您实际上不仅可以在CSS中节省开支，还可以在超文本标记语言中节省开支，听起来，这对您来说是非常有可能的，因为您提到将基于table的布局转换为许多div

另一个很好的方法在某些方面与OOCSS相似，就是从一开始就计划和编写CSS，使其具有可扩展性和模块化。

让我给你一些链接：
5个大规模CSS错误-（视频）
5个大规模CSS错误-（幻灯片）
CSS Bloat-（幻灯片）

小开

正如我之前所说：进入OOCSS。Sass/less/Compass很容易使用，但在以正确的方式使用vanilla CSS之前，Sass/less/Compass只会让事情变得更糟。

首先，阅读有关高效css的信息。尝试Google Page Speed并阅读Souders撰写的有关高效css的内容。

然后，输入OOCSS。

  • 学习使用级联。（毕竟，我们称之为级联样式表）。
  • 了解如何获得正确的颗粒度（自下而上而不是自上而下）
  • 了解如何分离结构和皮肤（什么是独特的，这些对象的变化是什么？）
  • 了解如何分离容器和内容。
  • 要学会爱格子。

它将彻底改变关于编写css的每一点。我完全更新并喜欢它。

更新：SMACSS类似于OOCSS，但一般来说更容易适应。

小开

我建议你看看“指南针风格”CSS框架。

小开

我建议少CSS动态框架

它类似于前面提到的SASS。

它有助于维护每个父类的CSS。

例如。

 #parent{
width: 100%;


#child1
{
background: #E1E8F2;
padding: 5px;
}


#child2
{
background: #F1F8E2;
padding: 15px
}
}

这是做什么的： 适用宽度：100%，同时适用于#儿童1和#儿童2。

此外，#儿童1特定的CSS属于#父。

这将使

#parent #child1
{
width: 100%;
background: #E1E8F2;
padding: 5px;
}


#parent #child2
{
width: 100%;
background: #F1F8E2;
padding: 15px;
}
小开

这里有一些很棒的材料，有些人花了很多时间来回答这个问题，但是当涉及到单独或单独的样式表时，我会使用单独的文件进行开发，然后在部署时将所有通用css合并到一个文件中。

通过这种方式，您可以两全其美，提高性能（从浏览器请求的HTTP请求更少）并在开发时分离代码问题。

小开

你应该看看BEM。

理论

BEM试图提供一组用于组织和命名css选择器的指令，以使事情更加可重用和模块化，并避免经常导致意大利面条代码和特异性头痛的选择器之间的冲突。

当它被正确使用时，它实际上有一些非常积极的影响。

  • 样式在添加到元素时执行您期望的操作
  • 样式不会泄漏，只会影响它们添加到的内容
  • 样式与文档结构完全分离
  • 风格不需要被迫超越彼此

BEM与SASS配合得很好，为CSS带来了几乎面向对象的风格。你可以构建模块化文件，处理单个UI元素的显示，并包含变量，例如颜色和“方法”，例如如何处理内部元素。虽然铁杆OO程序员可能会对这个想法犹豫不决，但事实上，应用的概念带来了OO结构的许多更好的部分，例如模块化、松耦合、紧密内聚和上下文无关的可重用性。你甚至可以使用萨斯和&歌剧r以看起来像封装对象的方式构建。

《粉碎》杂志上更深入的文章可以是在这里找到；还有一篇来自CCS Wizardrie的Harry Roberts（任何参与css的人都应该阅读）在这里。

在实践

我用过这个，好几次，同时也用过SMACSS和OOCSS，这意味着我也有东西可以比较它们。我也在一些大混乱中工作过，通常是我自己的，没有经验的创作。

当我在现实世界中使用BEM时，我用几个额外的原则来增强该技术。我使用实用程序类-一个很好的例子是包装类：

.page-section {
width: 100%;
}
@media screen and (min-width: 1200px) {
margin: 0 auto;
width: 1200px;
}

我还在一定程度上依赖于级联和特异性。这里的BEM模块将是.primary-box，.header将是特定覆盖的上下文

.header {
.primary-box {
color: #000;
}
}

（我尽最大努力使所有内容尽可能通用和上下文自由，这意味着一个好的项目几乎所有内容都在可重用的模块中）

我在这里要说的最后一点是，无论您的项目看起来多么小和不复杂，您都应该从一开始就这样做，原因有两个：

  • 项目的复杂性增加，所以打好基础很重要，包括css
  • 即使是一个看起来很简单的项目，因为它是建立在WordPress上的，几乎没有JavaScript，在CSS中仍然可以非常复杂-好吧，你不必做任何服务器端编码，所以这部分很简单，但是小册子前端有二十个模块和每个模块的三个变体：你有一些非常复杂的css！

Web组件

2015年，我们开始关注Web组件。我对这些还不太了解，但它们希望将所有前端功能整合在自包含的模块中，有效地尝试将BEM的各种原则应用于整个前端，以及组件分散但完全耦合的元素，例如DOM片段，Js（MVC）和CSS，它们都构建了相同的UI小部件。

通过这样做，theyb将解决css存在的一些原始问题，我们试图用BEM之类的东西来解决这些问题，同时使其他一些前端架构更加理智。

还有一些进一步的阅读这里和一个框架聚合物在这里，非常值得一看

终于

我也认为这是一个优秀的现代最佳实践css指南-专为阻止大型css项目变得混乱而设计。我试着遵循其中的大部分。

小开

明智CSS的核心原则，摘自CSS重构：从仅追加到模块化CSS

用SASS写。放弃变量、混合等的优势是疯狂的。

切勿使用超文本标记语言ID进行样式化；始终使用类.超文本标记语言ID在正确使用时，在整个页面中只出现一次 与可重用性完全相反-这是最基本的商品之一 合理的工程设计。而且，真的很难覆盖选择器 包含ID，并且通常压倒一个超文本标记语言ID的唯一方法是 创建另一个ID，导致ID在代码库中传播，如 他们是害虫。最好保留超文本标记语言ID以保持不变的JavaScript 或联调挂钩。

通过可视化函数而不是特定于应用程序的函数来命名CSS类。例如，说“. stolin-box” 而不是“. bundle-product-display-box”。以这种方式编码意味着 当您退出角色时，您可以重新使用现有的样式表 副业。例如，我们开始销售法律票据，但 最近搬进了法律家教。我们以前的CSS课程有这样的名字 ".download_document_box"，一个说话时有意义的类名 关于数字文档，但在应用于新文档时只会混淆 私人导师的领域。一个更好的名字，既适合现有 服务-以及任何未来的服务-将是“.pretty_callout_box”。

避免在特定网格信息之后命名CSS类。在CSS社区中存在（并且仍然存在）一种可怕的反模式 CSS框架的设计者和创造者（咳嗽twitter Bootstrap） 认为“span-2”或“oles-8”是CSS的合理名称 类。CSS的重点是给你修改的可能性 您的设计而不会影响标记（很多）。硬编码网格 超文本标记语言的大小阻碍了这一目标，因此建议不要在任何 项目预计将持续超过一个周末。更多关于我们如何避免 稍后的网格类。

跨文件拆分您的CSS。理想情况下，您将所有内容拆分为“组件”/“小部件”，然后从这些原子组成页面 设计。实际上，你会注意到你的一些网站 页面具有特质（例如特殊的布局或奇怪的照片） 仅在一篇文章中出现的画廊）。在这种情况下，您可能会 创建与该特定页面相关的文件，仅重构为 完整的小部件，当它变得清晰，该元素将是 在其他地方重复使用。这是一个权衡，一个动机是 实际预算问题

减少嵌套。引入新类而不是嵌套选择器。SASS消除了重复选择器的痛苦 当嵌套并不意味着你必须嵌套五层深。 永远不要过度限定选择器（例如，不要在“. nav”中使用“ul.nav” 可以做同样的工作。）并且不要在 自定义类名（例如“h2.highlight”）。相反，只需使用类 单独命名并删除基本选择器（例如前面的示例 应该是“.突出显示”）。过度限定的选择器不会添加任何 值。

为超文本标记语言元素（例如“h1”）创建样式仅当样式化基本组件时，该组件应在整个应用程序中保持一致。 避免像“头ul”这样的宽选择器，因为您可能 必须在某些地方覆盖它们。正如我们一直说的，大多数 无论何时，您都希望使用特定的、命名良好的类 想要一个特定的风格。

拥抱块元素修改器的基础知识。例如，您可以在此处阅读有关它的信息。我们很轻易地使用它，但它仍然有帮助 我们在组织CSS样式方面做了很多。

小开

我一直在为超过20年使用层叠样式表（CSS）。所以下面是我的解决方案来帮助你：

  1. 通过<link>标签始终使用外部CSS。外部CSS远远优于“嵌入式”<style>和“内联”元素样式<span style="color:blue;">my text</span>，这仅仅是因为下载到浏览器的外部样式会为您网站中的每个页面缓存并影响所有网页，而不仅仅是一个。考虑将整个网站上散布的所有样式移动到工作表中的CSS类中。确保添加选择器以增加它们的权重，如果它们可能已经级联在早期继承的样式上。注意：许多javascript api的，如Angular和其他使用嵌入式CSS，这意味着它们速度较慢，并且每次刷新或重新访问网站时都必须重新加载CSS。糟糕的设计！
  2. 始终为所有基本超文本标记语言元素使用“重置”样式表。大多数CSS包，如Bootstrap和其他包，都带有一个重置或重新启动表。这些重新设计你所有的超文本标记语言元素选择器，使它们在所有浏览器和用户代理中看起来都很不错。这让你不必在表单控件、布局、文本等基本元素上重新设计和自定义设计的噩梦。几年前我写了自己的“重置”表。如果你喜欢我的，我很快就会把它发布在GitHub上的"通用CSS框架下。适用于所有新旧浏览器。
  3. 请记住，所有基于文本的样式级联和自然地通过站点元素继承！所以，你应该很少需要重复字体样式、行高等。大多数年轻的开发人员都忘记了这一点。基于文本的样式是沿着超文本标记语言树继承的，所以只需要在父级中编写一次。通常<body>元素是设置基本字体样式等的最佳位置。
  4. 因为#3，你不需要像SASS这样的CSS前置程序来重组或管理你的样式表。远离这些第三方依赖项。CSS可以编写为通过站点继承或级联样式，因此您不必在CSS类等之间重复相同的字体样式或属性。
  5. 将控制设计的块级别/布局样式分组。在顶级超文本标记语言块上使用ID选择器（#myid）来分隔部分，并使用CSS选择器中的选择器来管理特定于该页面或网站部分的项目（#main .someclass {...}）。这些选择器的优点是它们易于跟踪和隔离，但是ID选择器具有非常高的选择性或权重。ID选择器的权重为1-0-0或100，而类的权重为0-1-0或10。这可以防止任何以后的样式变化破坏您以前在特定受保护部分中的自定义样式。
  6. 避免在CSS选择器中附加更多的元素和类链，直到你绝对需要用自定义类覆盖公共共享类。示例：.articlelink{...}将是每个人都可以访问的共享通用样式。.block1 .area2 .articlelink{...}允许你在整个部分中创建自定义版本，而无需创建新类或更改超文本标记语言。
  7. 使用CSS评论！/* My New Styles */…后面是相关的CSS块，或者只是使用注释来解释代码中不直观的地方。
  8. 如果您有大项目，请让每个开发人员为他们的部分编写自己的自定义CSS表，但继承主站点样式表。首先，确保网站的所有部分首先链接到你的基本重置和基本网站工作表。这允许基本元素样式、字体设置、布局、页面设计、表单和颜色首先由基本工作表强制执行，因此开发人员只需添加所需的新样式，而不是重新发明相同的轮子。当你更新所有开发人员继承的基本工作表时，这些工作表会自然地出现在项目的所有部分，并且团队可以立即看到那些。

请记住，您使用的是级联样式表，而不是样式表！这意味着大多数基于文本的样式旨在继承所有父元素，然后将相同的样式级联到数千页的超文本标记语言树中，而无需额外代码。大多数新的Web开发人员都无法掌握CSS的简单，因此很难使用SASS和其他工具来修复它。它只是不需要。20多年前，非常聪明的人以这种方式设计了CSS，为您解决了所有这些问题。

如果你真的开始以正确的方式使用CSS，你会发现你可以擦除大多数样式，SASS，最小化和其他外部例程以及你的网站曾经使用过的额外代码，同时享受CSS的级联效果，这些效果旨在使很久以前的最小编码成为可能。

<html>
<body style="color:blue;">
<main>
<section>
<div>
<div>
<div>
<p>hello blue world</p>
</div>
</div>
</div>
</section>
</main>
</body>
</html>

和平


提交答案