我一直严重依赖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开发的速度。这样,将来可能在这个网站上工作的其他人也将开始使用良好的编码实践,而不必像我一样学习。


很多时候,我看到有人把文件分成几个部分,在部分之间加上标题注释。

类似的

/* Headings and General Text */

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

/* Main page layout */

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

它工作得很好,可以让你很容易回头看看你正在做什么。


这是一个非常好的问题。在我所看到的任何地方,CSS文件都倾向于在一段时间后失去控制——尤其是,但不仅仅是在团队中工作时。

以下是我自己努力遵守的规则(并不是说我总能做到)。

Refactor early, refactor often. Frequently clean up CSS files, fuse together multiple definitions of the same class. Remove obsolete definitions immediately. When adding CSS during fixing bugs, leave a comment as to what the change does ("This is to make sure the box is left aligned in IE < 7") Avoid redundancies, e.g. defining the same thing in .classname and .classname:hover. Use comments /** Head **/ to build a clear structure. Use a prettifier tool that helps maintain a constant style. I use Polystyle, with which I'm quite happy (costs $15 but is money well spent). There are free ones around as well (e.g. Code Beautifier based on CSS Tidy, an open-source tool). Build sensible classes. See below for a few notes on this. Use semantics, avoid DIV soup - use <ul>s for menus, for example. Define everything on as low a level as possible (e.g. a default font family, colour and size in the body) and use inherit where possible If you have very complex CSS, maybe a CSS pre-compiler helps. I'm planning to look into xCSS for the very same reason soon. There are several others around. If working in a team, highlight the necessity of quality and standards for CSS files as well. Everybody's big on coding standards in their programming language(s), but there is little awareness that this is necessary for CSS too. If working in a team, do consider using Version Control. It makes things that much easier to track, and editing conflicts that much easier to solve. It's really worth it, even if you're "just" into HTML and CSS. Do not work with !important. Not only because IE =< 7 can't deal with it. In a complex structure, the use of !important is often tempting to change a behaviour whose source can't be found, but it's poison for long-term maintenance.

构建合理的类

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

我首先应用全局设置:

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

然后,我确定页面布局的主要部分。顶部区域、菜单、内容和页脚。如果我写了好的标记,这些区域将与HTML结构相同。

然后,我开始构建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>,它们都有相同的字体大小,并且项目都是彼此相邻的(与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在使用多个类时存在问题,因此本例使用id。

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

菜单的标记看起来像这样:

<ul id="level1" class="menu"><li> ...... </li></ul>
<ul id="level2" class="menu"><li> ...... </li></ul>
<ul id="level3" class="menu"><li> ...... </li></ul>

如果页面上有语义相似的元素(比如这三个菜单),首先试着找出共性,然后把它们放到一个类中;然后,计算出特定的属性并将它们应用到类中,或者,如果您必须支持Internet Explorer 6,则应用ID。

其他HTML技巧

如果你将这些语义添加到HTML输出中,设计师以后可以使用纯CSS定制网站和/或应用程序的外观,这是一个很大的优势和节省时间。

If possible, give every page's body a unique class: <body class='contactpage'> this makes it very easy to add page-specific tweaks to the style sheet: 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: <ul class="mainmenu"> <li class="item_first item_active item_1"> First item </li> <li class="item_2"> Second item </li> <li class="item_3"> Third item </li> <li class="item_last item_4"> Fourth item </li> </ul> This way, every menu item can be accessed for styling according to its semantic context: Whether it's the first or last item in the list; Whether it's the currently active item; and by number.

请注意,如上例中所述的多个类的分配在IE6中不能正常工作。有一个变通方案可以使IE6能够处理多个类。如果没有解决方法,则必须设置对您来说最重要的类(项目编号、活动或第一个/最后一个),或者使用id。


我发现最难的事情是将网站所需的设计转化为一系列规则。如果站点的设计清晰且基于规则,那么你的类名和CSS结构就可以由此而来。但是,如果人们随着时间的推移,随机地在网站上添加一些没有多大意义的内容,那么在CSS中就没有太多办法了。

我倾向于这样组织我的CSS文件:

CSS reset, based on Eric Meyer’s. (Because otherwise I find that, for most elements, I’ve got at least one or two rules that are just resetting default browser styles — most of my lists don’t look like the default HTML style for lists, for example.) Grid system CSS, if the site calls for it. (I base mine on 960.gs) Styles for components that appear on every page (headers, footers, etc) Styles for components that are used in various places across the site Styles that are only relevant on individual pages

如你所见,这主要取决于网站的设计。如果设计清晰有条理,你的CSS也可以做到。如果不是,你就完蛋了。


以下是4个例子:

CSS约定/代码布局模型 在编写我的第一个样式表时,我应该遵循哪些CSS标准? 整理CSS的最佳方法是什么? 最佳实践- CSS样式表格式

在所有4个问题上,我的回答都包含了下载并阅读Natalie Downe的PDF CSS系统的建议。(PDF包含了大量幻灯片上没有的注释,所以请阅读PDF!)注意她对组织的建议。

四年后,我想说:

Use a CSS pre-processor and manage your files as partials (I personally prefer Sass with Compass, but Less is quite good as well and there are others) Read up on concepts like OOCSS, SMACSS, and BEM or getbem. Take a look at how popular CSS frameworks like Bootstrap and Zurb Foundation are structured. And don't discount less popular frameworks - Inuit is an interesting one but there are plenty others. Combine/minify your files with a build step on a continuous integration server and/or a task runner like Grunt or Gulp.


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

我注意到您只使用了类标识符(div.title)。您知道您也可以使用ID,而且ID比类更重要吗?

例如,

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

将使所有这些元素共享一个字体大小,或者颜色,或者任何你的规则。您甚至可以使所有的div都是#page1的后代获得某些规则。

至于重量,请记住CSS轴从最一般/最轻到最特定/最重。也就是说,在CSS选择器中,一个元素说明符被一个类说明符取代,一个ID说明符取代。数字计数,因此具有两个元素说明符(ul li)的选择器将比只有一个说明符(li)的选择器具有更大的权重。

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

顺便说一句,在类中添加元素说明符(div.title)是没有必要的,除非你遇到了与其他具有class="title"的元素冲突。不要增加不必要的重量,因为你以后可能会用到这些重量。


我的回答是高水平的,针对你刚才提到的高水平的关切。也许你可以通过一些低级的组织技巧和调整来使它更漂亮,但这些都不能解决方法上的缺陷。有几个因素会影响CSS的爆炸。显然是网站的整体复杂性,但还有像命名语义、CSS性能、CSS文件组织和可测试性/可接受性等问题。

在命名语义方面,您似乎走在了正确的道路上,但还可以更进一步。重复出现在站点上而没有进行结构修改的HTML部分(称为“模块”)可以被视为选择器根,从那里您可以相对于根确定内部布局的范围。这是面向对象的CSS的基本原则,您可以在Yahoo工程师的演讲中阅读/观看更多关于它的内容。

需要注意的是,这种干净的方法可能与性能问题相反,它倾向于基于id或标记名的短选择器。找到平衡取决于你,但除非你有一个庞大的网站,这应该只是一个指南在你的脑后提醒你保持你的选择器简短。这里有更多关于性能的信息。

最后,您将为整个网站使用一个CSS文件,还是多个文件(单个基本文件用于每个页面或-section文件)?单个文件对于性能来说更好,但是对于多个团队成员来说可能更难理解/维护,并且可能更难测试。对于测试,我建议您使用一个CSS测试页面,其中包含所有受支持的CSS模块,以测试冲突和意外级联。

或者,您也可以采用多文件方法,将CSS规则作用于一个页面或一个部分。这需要浏览器下载多个文件,这是一个性能问题。您可以使用服务器端编程动态地指定和聚合(并缩小)CSS文件到单个文件中。但是,由于这些文件是分开的,对它们的测试也是分开的,因此可能会在页面/部分之间引入不一致的外观。因此测试变得更加困难。

由你来分析客户的具体需求,并相应地平衡这些问题。


看一看 1. 萨斯 2. 指南针


不要用CSS写标题

只是将部分分割成文件。任何CSS注释,都应该是注释。

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

使用脚本将它们合并为一个;如果有必要的话)。您甚至还可以拥有一个漂亮的目录结构,只需让脚本递归地扫描.css文件。

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

TOC中的标题应该与您稍后编写的标题完全相同。搜索标题是件痛苦的事。更麻烦的是,人们怎么知道在第一个头文件之后还有另一个头文件呢?注:写toc时不要在每行开头加上类似doc的*(星号),这只会让选择文本变得更烦人。

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

使用规则或在规则内编写注释,而不是在块之外

首先,当您编辑脚本时,有50%的几率您会注意到规则块之外的内容(特别是如果它是一大块文本;))。其次,(几乎)不需要在外部添加“注释”。如果是在室外,那么99%的情况下都是游戏,所以保持这种状态。

将页面拆分为多个组件

组件应该有位置:相对的,没有填充和空白,大多数时候。这大大简化了%规则,并且允许更简单的元素的绝对:位置,因为如果有一个绝对定位的容器,绝对定位的元素将在计算上、右、下、左属性时使用容器。

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

组件也可以被认为是页面上的一个独立单元。用门外汉的话说,如果把一个东西当作一个黑盒是有意义的,那么就把它当作一个组件。

还是以QA页面为例:

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

通过将页面划分为组件,您可以将工作划分为可管理的单元。

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

例如,边框、边距和填充(但不包括轮廓)都会增加你要样式化的元素的尺寸和大小。

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/classes时,避免使用TAGs作为选择符

首先,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更改为一篇文章,那么您的风格就会中断。

或者如果你喜欢更清晰的表述:

#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属性是一个特殊的属性,只有应用于表时才有意义。如果.statistics不是一个表,它就不应该应用。

通用规则是邪恶的!

如果可以的话,避免编写通用的/神奇的规则 除非是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 .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;
}

复杂的“逻辑”评论不起作用:)

如果你这样写:“this value is dependent on blah-blah and height of blah-blah”,这是不可避免的,你会犯错误,它会像纸牌屋一样倒塌。

保持你的评论简单;如果你需要“逻辑操作”,考虑一种CSS模板语言,比如SASS或LESS。

我怎么写一个颜色托盘?

把这个留到最后。为你的整个色盘准备一个文件。如果没有这个文件,你的样式在规则中仍然有一些可用的颜色托盘。您的颜色托盘应该覆盖。你使用一个非常高级的父组件(例如。#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 Selectors(提示:指向您的sitemap.xml)来帮助您找到一些隐藏在css nukes和carnies中的垃圾。

保持一个未排序的。css文件

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

原因如下:

在完成之后进行重构更快,然后搜索规则(可能不存在)并注入代码 你会写一些你要删除的东西,注入代码只会让你更难删除这些代码 附加到原始文件很容易导致重复规则/选择器


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

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

一些意识形态与上面的答案相悖,但一旦你知道如何以面向对象的方式构建CSS,你就会发现它实际上有助于保持代码的精简和平均。

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

Facebook聘请了OOCSS的创建者Nicole Sullivan,以节省大量的前端代码(HTML / CSS)。是的,你实际上可以得到节省,不仅在你的CSS,但在你的HTML太,这是由它的声音,是非常有可能为你,因为你提到转换一个基于表格的布局到很多div的

另一个很好的方法在某些方面与OOCSS类似,就是从一开始就计划和编写可伸缩和模块化的CSS。Jonathan Snook写了一本关于SMACSS的书/电子书——CSS的可伸缩和模块化架构

让我给你介绍一些链接: 海量CSS的5个错误-(视频) 海量CSS的5个错误(幻灯片) CSS膨胀-(幻灯片)


就像我之前说的:进入OOCSS。Sass/Less/Compass使用起来很诱人,但在正确使用CSS之前,Sass/Less/Compass只会让事情变得更糟。

首先,阅读高效css。尝试谷歌页面速度和阅读Souders关于高效css的文章。

然后进入OOCSS。

学会使用级联。(毕竟,我们称之为级联样式表)。 学习如何获得正确的粒度(自底向上而不是自顶向下) 学习如何分离结构和皮肤(什么是唯一的,这些对象的变化是什么?) 学习如何分离容器和内容。 学会爱上网格。

它将彻底改变css的每一个细节。我完全焕然一新,爱上了它。

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


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


我可以建议少CSS动态框架吗

它类似于前面提到的SASS。

它帮助维护每个父类的CSS。

E.g.

 #parent{     
  width: 100%;

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

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

它的作用: 将width:100%应用于#child1和#child2。

此外,#child1特定的CSS属于#parent。

这将导致

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

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

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

这样你可以两全其美,提高性能(从浏览器请求的HTTP请求更少),并在开发时分离代码关注点。


你应该看看边界元法。

理论

BEM试图提供一组用于组织和命名css选择器的指令,以使选择器更具可重用性和模块化,并避免选择器之间的冲突,这种冲突通常会导致意大利面条式的代码和特定的问题。

如果正确使用,它实际上有一些非常积极的影响。

当样式被添加到元素中时,它们的作用是您所期望的 样式不会泄露,并且只影响它们所添加的内容 样式与文档结构完全解耦 不同的风格不需要被强迫凌驾于彼此之上

BEM works well with SASS to bring an almost object oriented style to CSS. You can build modular files, that handle the display of a single UI element and contain variables, such as colours and 'methods' such as how internal elements are handled. While a hardcore OO programmer might balk at this idea, in fact, the applied concepts bring in a lot of the nicer parts of OO structures, such as modularity, loose coupling and tight cohesion and context free re-usability. You can even build in a way that looks like an encapsulated object by using Sass and the & operator.

更多来自Smashing杂志的深入文章可以在这里找到;还有一个来自CCS Wizardry的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中仍然非常复杂——好吧,你不需要做任何服务器端编码,所以这部分很简单,但是宣传册前端有20个模块和每个模块的3个变体:你有一些非常复杂的CSS !

Web组件

在2015年,我们开始关注Web组件。我对这些还不太了解,但它们希望将所有前端功能放在自包含的模块中,有效地尝试将各种原则从BEM应用到前端作为一个整体,并将分散但完全耦合的元素(如DOM片段、Js (MVC)和CSS)组合在一起,这些元素都构建相同的UI小部件。

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

这里有一些进一步的阅读材料,还有一个框架聚合物,非常值得一看

最后

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


合理CSS的核心原则,摘自CSS重构:从仅追加到模块化CSS

Write in SASS. You'd be insane to forego the advantages of variables, mixins, and so on. Never use an HTML ID for styling; always use classes. HTML IDs, when used correctly, appear only once in the whole page, which is the complete opposite of re-usability — one of the most basic goods in sensible engineering. Moreover, it's really hard to override selectors containing IDs and often the only way to overpower one HTML ID is to create another ID, causing IDs to propagate in the codebase like the pests they are. Better to leave the HTML IDs for unchanging Javascript or integration test hooks. Name your CSS classes by their visual function rather than by their application-specific function. For example, say ".highlight-box" instead of ".bundle-product-discount-box". Coding in this way means that you can re-use your existing style-sheets when you role out side-businesses. For example, we started out selling law notes but recently moved into law tutors. Our old CSS classes had names like ".download_document_box", a class name that makes sense when talking about digital documents but would only confuse when applied to the new domain of private tutors. A better name that fits both existing services — and any future ones — would be ".pretty_callout_box". Avoid naming CSS classes after specific grid information. There was (and still is) a dreadful anti-pattern in CSS communities whereby designers and creators of CSS frameworks (cough Twitter Bootstrap) believe that "span-2" or "cols-8" are reasonable names for CSS classes. The point of CSS is to give you the possibility to modify your design without affecting the markup (much). Hardcoding grids sizes into the HTML thwarts this goal, so it is advised against in any project expected to last longer than a weekend. More on how we avoided grid classes later. Split your CSS across files. Ideally you would split everything into "components"/"widgets" and then compose pages from these atoms of design. Realistically though, you'll notice that some of your website pages have idiosyncrasies (e.g. a special layout, or a weird photo gallery that appears in just one article). In these cases you might create a file related to that specific page, only refactoring into a full-blown widget when it becomes clear that the element will be re-used elsewhere. This is a tradeoff, one that is motivated by practical budgetary concerns. Minimise nesting. Introduce new classes instead of nesting selectors. The fact that SASS removes the pain of repeating selectors when nesting doesn't mean that you have to nest five levels deep. Never over-qualify a selector (e.g. don't use "ul.nav" where ".nav" could do the same job.) And don't specify HTML elements alongside the custom class name (e.g."h2.highlight"). Instead just use the class name alone and drop the base selector (e.g. the previous example should be ".highlight"). Over-qualifying selectors doesn't add any value. Create styles for HTML elements (e.g. "h1") only when styling base components which should be consistent in the whole application. Avoid broad selectors like "header ul" because it's likely that you have to override them in some places anyway. As we keep saying, most of the time you want to use a specific, well-named class whenever you want a particular style. Embrace the basics of Block-Element-Modifier. You can read about it for example on here. We used it quite lightly, but still it helped us a lot in organising CSS styles.


我已经使用级联样式表(CSS)超过20年了。所以下面是我的解决方案来帮助你:

ALWAYS use External CSS via a <link> tag. External CSS is far superior to "embedded" <style> and "inline" element styles <span style="color:blue;">my text</span> simply because external styles downloaded to the browser are cached for every page in your website and affect all web pages, not just one. Consider moving all those styles sprinkled throughout your website to CSS classes in your sheets. Make sure you add selectors to increase their weight in cases where they might have cascaded over earlier inherited styles. Note: Many JavaScript API's like Angular and others use embedded CSS which means they are slower and have to reload CSS every refresh or revisit to the site. Bad design! ALWAYS use a "Reset" Style Sheet for all your basic HTML Elements. Most CSS packages like Bootstrap and others come with a reset or reboot sheet. These restyle all your HTML element selectors so they look decent across all browsers and user agents. This saves you the nightmare of having to restyle and customize design across basic elements like form controls, layouts, text, etc. I wrote my own "reset" sheet years ago. I am going to post it on GitHub under "Universal CSS Framework" soon if you would like mine. Works in all the old and new browsers. Remember, all text-based styles cascade and inherit naturally down through the sites elements! So, you should rarely need to repeat font styles, line-heights, etc. Most young developers forget this. Text-based styles are inherited down the HTML tree so only have to be written one time in a parent. Often the <body> element is the best placed to set basic font styles, etc. Because of #3 you do NOT need CSS precrocessors like SASS to reorganize or manage your style sheets. Stay away from these third-party dependencies. CSS can be written to inherit or cascade styles through the site so you do not have to repeat the same font styling or properties across CSS classes, etc. Group your Block Level/Layout styles that control design. Use ID selectors (#myid) on top level HTML blocks to separate sections and use those in CSS selectors to manage items specific to that page or website section (#main .someclass {...}). These have the advantage that they are easy to track and easy to segregate, but ID selectors have very high selectivity or weight. ID selectors have a 1-0-0 or 100 weight over class which has 0-1-0 or 10 weight. This prevents any later style shifts from damaging your previous custom styles in specific protected sections. Design all CSS around a Single CSS Class that can be Reused. Avoid attaching more element and chains of classes in CSS selectors until you absolutely need to override a common shared class with a custom one. Example: .articlelink{...} would be the shared universal style everyone can access. .block1 .area2 .articlelink{...} would allow you to create a custom version throughout a section without creating a new class or changing the HTML. Use CSS Comments! /* My New Styles */ ...followed by blocks of related CSS or just use comments to explain what is not intuitive in your code. If you have big projects, have each developer write their own custom CSS sheets for their sections, but inherit the main site style sheets. First, make sure all sections of the website link to your basic reset and base site sheets first. This allows basic element styles, font settings, layout, page design, forms, and colors to be enforced by the base sheets first so developers only add new styles needed rather than reinventing the same wheel. As you update the base sheets all developers inherit, those appear naturally across all sections of the project with no effort, and the teams can see those instantly.

Remember, you are working with cascading style sheets, not style sheets! That means most text-based styles are designed to inherit from all the parent elements, then cascade those same styles down into your trees of HTML across thousands of pages with no extra code. Most new web developers fail to grasp the simplicity of CSS, so struggle with SASS and other tools to fix it. It just is not needed. CSS was designed this way over 20 years ago by very smart people that solved all these issues for you.

如果你真的开始以正确的方式使用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>

和平