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


当前回答

我可以建议少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;
}

其他回答

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

类似的

/* Headings and General Text */

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

/* Main page layout */

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

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

不要用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样式表中。

原因如下:

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

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

我注意到您只使用了类标识符(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"的元素冲突。不要增加不必要的重量,因为你以后可能会用到这些重量。

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

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

然后进入OOCSS。

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

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

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

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

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

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

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

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

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