我一直非常依赖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开发速度的能力。这样,将来可能在这个网站上工作的其他人也会参与使用良好编码实践的做法,而不是像我那样采用它。
答案 0 :(得分:557)
答案 1 :(得分:88)
以下只有4个例子:
在所有4中我的回答包括下载和阅读Natalie Downe的PDF CSS Systems的建议。 (PDF包含幻灯片中没有的大量笔记,因此请阅读PDF!)。记下她对组织的建议。
编辑(2014/02/05)四年后,我会说:
答案 2 :(得分:73)
答案 3 :(得分:55)
答案 4 :(得分:31)
我看到反击CSS
膨胀的最好方法是使用面向对象的CSS原则。
甚至还有一个OOCSS框架非常好。
一些意识形态与顶级答案中的许多内容相悖,但是一旦你知道如何以面向对象的方式构建CSS
,你就会发现它实际上可以保持代码精益。的意思。
这里的关键是在您的站点和架构师中识别“对象”或构建块模式。
Facebook聘请了OOCSS的创建者Nicole Sullivan,以便在前端代码(HTML / CSS)中节省大量资金。是的,你实际上不仅可以在你的CSS中节省成本,而且在你的HTML中也可以节省成本,因为你提到将基于table
的布局转换为大量的{{1} }的
另一个很好的方法在某些方面与OOCSS类似,就是从一开始就规划和编写CSS,使其可扩展和模块化。 Jonathan Snook撰写了关于SMACSS - Scalable and Modular Architecture for CSS
的精彩文章和书籍/电子书让我联系你一些链接:
5 mistakes of massive CSS - (Video)
5 mistakes of massive CSS - (Slides)
CSS Bloat - (Slides)
答案 5 :(得分:16)
您还应该了解级联,重量以及它们的工作原理。
我注意到你只使用类标识符(div.title)。您是否知道您也可以使用ID,并且ID比类更重要?
例如,
#page1 div.title, #page1 ul, #page1 span {
// rules
}
将使所有这些元素共享字体大小,比如说或颜色,或者您的规则。你甚至可以让所有作为#page1后代的DIV获得一定的规则。
关于重量,请记住CSS轴从最普通/最轻到最特定/最重。也就是说,在CSS选择器中,由类说明符推翻的元素说明符被ID说明符否决。数字计数,因此具有两个元素说明符(ul li)的选择器将比仅具有单个说明符(li)的选择器具有更多权重。
把它想象成数字。在一列中的9仍然小于十列中的一个。具有ID说明符,类说明符和两个元素说明符的选择器将比没有ID的选择器,500个类说明符和1,000个元素说明符具有更多权重。当然,这是一个荒谬的例子,但你明白了。关键是,应用这个概念可以帮助你清理很多CSS。
顺便说一句,除非你遇到与其他具有class =“title”的元素发生冲突,否则不必将元素说明符添加到类(div.title)中。不要添加不必要的重量,因为您可能需要稍后使用该重量。
答案 6 :(得分:13)
我可以建议Less CSS Dynamic framework
它类似于前面提到的SASS。
它有助于维护每个父类的CSS。
E.g。
#parent{
width: 100%;
#child1
{
background: #E1E8F2;
padding: 5px;
}
#child2
{
background: #F1F8E2;
padding: 15px
}
}
这是做什么的: 对#child1和#child2应用宽度:100%。
此外,#child1特定CSS属于#parent。
这将呈现给
#parent #child1
{
width: 100%;
background: #E1E8F2;
padding: 5px;
}
#parent #child2
{
width: 100%;
background: #F1F8E2;
padding: 15px;
}
答案 7 :(得分:12)
我发现难以将网站所需的设计转换为一系列规则。如果网站的设计清晰且基于规则,那么您的类名和CSS结构可以从中流出。但是,如果人们随着时间的推移,随意地向网站添加一些没有多大意义的内容,那么在CSS中你可以做很多事情。
我倾向于按照以下方式组织我的CSS文件:
CSS重置,基于Eric Meyer’s。 (因为我发现,对于大多数元素,我至少有一两个规则只是重置默认的浏览器样式 - 例如,我的大多数列表看起来都不像列表的默认HTML样式。)< / p>
网格系统CSS,如果网站要求它。 (我的基础是960.gs)
每个页面上显示的组件样式(页眉,页脚等)
网站各个地方使用的组件的样式
仅与各个网页相关的样式
如您所见,大部分内容取决于网站的设计。如果设计清晰有序,那么你的CSS就可以了。如果没有,你就搞砸了。
答案 8 :(得分:7)
我的答案是高级别的,以解决您在问题中提出的高级别问题。可能会有低级别的组织技巧和调整,你可以做的更漂亮,但没有一个可以解决方法上的缺陷。有几件事会影响CSS爆炸。显然,网站的整体复杂性,还有命名语义,CSS性能,CSS文件组织和可测试性/可接受性等。
您似乎在使用命名语义的正确路径上,但它可以更进一步。在没有结构修改的情况下在网站上重复出现的HTML部分(称为“模块”)可以被视为选择器根,从那里您可以将内部布局相对于该根进行范围。这是面向对象的CSS 的基本原则,您可以read/watch more about it in this talk by a Yahoo engineer。
重要的是要注意,这种干净的方法可能与性能的关注相反,这有利于基于id或标记名称的短选择器。找到这种平衡取决于你,但除非你有一个庞大的网站,这应该只是你头脑中的指南,提醒你保持你的选择器短。 More about performance here
最后,您是要为整个站点创建一个单个CSS文件,还是多个文件(每页或-section文件使用一个基本文件)?单个文件对性能更好,但可能更难理解/维护多个团队成员,并且可能更难测试。为了进行测试,我建议您使用单个CSS测试页,其中包含用于测试冲突和意外级联的所有受支持的CSS模块。
或者,您可以使用多文件方法,将CSS规则范围限定为页面或部分。这需要浏览器下载多个文件,这是性能问题。您可以使用服务器端编程来动态地指定CSS文件并将其聚合(并缩小)为单个文件。但由于这些文件是独立的,并且对它们的测试是分开的,因此您会在页面/部分之间引入不一致的外观和感觉。因此,测试变得更加困难。
由您来分析客户的具体需求,相应地平衡这些问题。
答案 9 :(得分:5)
如前所述:进入OOCSS。 Sass / Less / Compass很有吸引力,但在使用vanilla CSS之前,Sass / Less / Compass只会让事情变得更糟。
首先,阅读有关高效的CSS。试试Google Page Speed并阅读Souders撰写的有关高效css的文章。
然后,输入OOCSS。
它将彻底改变关于编写CSS的每一点。我完全更新并喜欢它。
更新:SMACSS类似于OOCSS,但一般来说更容易适应。
答案 10 :(得分:4)
从CSS Refactoring: From append-only to modular CSS
中提取的合理CSS的核心原则写入SASS。您可以放弃变量,混合等等的优点。
永远不要使用HTML ID进行样式设置;总是使用类。如果使用正确,HTML ID在整个页面中只出现一次,即 与可重复使用完全相反 - 这是最基本的商品之一 合理的工程。而且,覆盖选择器真的很难 包含ID,通常是压倒一个HTML ID的唯一方法是 创建另一个ID,导致ID在代码库中传播,如 它们是害虫。最好保留HTML ID以保持不变的Javascript 或集成测试挂钩。
通过视觉功能而不是特定于应用程序的功能来命名CSS类。例如,说&#34; .highlight-box&#34; 而不是&#34; .bundle-product-discount-box&#34;。以这种方式编码意味着 你可以在角色出来时重复使用现有的样式表 侧面的企业。例如,我们开始出售法律说明但是 最近搬进了法律辅导员。我们旧的CSS类的名字就像 &#34; .download_document_box&#34;,一个在谈话时有意义的类名 关于数字文件,但只有在应用于新文件时才会混淆 私人教师的领域。一个更好的名称,适合现有的 服务 - 以及任何未来的服务 - 将是&#34; .pretty_callout_box&#34;。
避免在特定网格信息之后命名CSS类。 CSS社区中存在(现在仍然)可怕的反模式 CSS框架的设计者和创建者(咳嗽 Twitter Bootstrap ) 相信&#34; span-2&#34;或&#34; cols-8&#34;是CSS的合理名称 类。 CSS的重点是为您提供修改的可能性 你的设计不会影响标记(很多)。硬编码网格 HTML中的大小会阻碍这一目标,因此建议不要使用任何大小 项目预计持续时间超过周末。更多关于我们如何避免 网格课后来。
跨文件拆分CSS 。理想情况下,您可以将所有内容拆分为&#34;组件&#34; /&#34;小部件&#34;然后从这些原子组成页面 设计。但实际上,您会注意到您的某些网站 页面有特质(例如特殊布局或奇怪的照片) 只出现在一篇文章中的画廊)。在这些情况下你可能会 创建一个与该特定页面相关的文件,只重构为一个 当元素变得清晰时,完整的小部件 在别处重复使用。这是一种权衡,是一种动机 实际的预算问题。
最小化嵌套。引入新类而不是嵌套选择器。 SASS消除了重复选择器的痛苦这一事实 当嵌套并不意味着你必须深入嵌套五个级别。 永远不要过度限定选择器(例如,不要使用&#34; ul.nav&#34;其中&#34; .nav&#34; 可以做同样的工作。)并且不要指定HTML元素 自定义类名(例如&#34; h2.highlight&#34;)。而只是使用该类 单独命名并删除基本选择器(例如前面的示例 应该是&#34; .highlight&#34;)。资格过高的选择者不会添加任何内容 值。
仅在为整个应用程序中应该保持一致的基础组件样式时,为HTML元素(例如&#34; h1和#34;)创建样式。 避免广泛的选择器,如&#34;标题ul&#34;因为你很可能 不管怎样,我必须在某些地方覆盖它们。正如我们一直在说的那样 你何时想要使用一个特定的,名称很好的课程 想要一种特殊的风格。
接受Block-Element-Modifier的基础知识。您可以在此处阅读相关内容。我们使用它很轻松,但它仍然有帮助 我们在组织CSS样式方面做了很多。
答案 11 :(得分:2)
很多时候,我会看到个人将文件分成几个部分,部分之间有标题注释。
像
这样的东西/* Headings and General Text */
.... stuff here for H1, etc..
/* Main page layout */
.... stuff here for layout page setup etc.
效果很好,可以让以后轻松找回你正在处理的内容。
答案 12 :(得分:1)
您应该查看 BEM 。
<强>理论强>
BEM试图提供一组用于组织和命名css选择器的指令,以试图使事物更易于使用和模块化,并避免经常导致意大利面条代码和特异性问题的选择器之间的冲突。
如果使用得当它实际上有一些非常积极的效果。
BEM与SASS配合使用可为CSS带来几乎面向对象的风格。您可以构建模块化文件,这些文件处理单个UI元素的显示并包含变量,例如颜色和&#39;方法&#39;例如如何处理内部元素。事实上,虽然硬核OO程序员可能会对这个想法不以为然,但应用概念带来了OO结构的许多更好的部分,例如模块化,松散耦合和紧密内聚以及无上下文的可重用性。您甚至可以使用Sass and the &
operato r。
Smashing Magazine的一篇更深入的文章可以是found here;还有一个来自CCS Wizardry的Harry Roberts(任何参与css的人都应该阅读)is here。
在实践中
我已经多次使用过这个,并且使用过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;
}
}
(我尽最大努力使一切尽可能通用和无上下文,这意味着一个好项目几乎所有东西都在可重复使用的模块中)
我在这里要做的最后一点是,无论你的项目是多么小而且不复杂,你应该从一开始就这样做,原因有两个:
网络组件
2015年,我们开始关注Web Components。我还不太了解这些内容,但他们希望将所有前端功能集中在自包含的模块中,有效地尝试将BEM的各种原则应用到整个前端,并将组件分散但是完全耦合的元素,如DOM片段,Js(MVC)和CSS,它们都构建相同的UI小部件。
通过这样做,他们将解决css中存在的一些原始问题,我们已经尝试用BEM之类的东西来解决这些问题,同时让一些其他前端架构更加清晰。
还有一些进一步的阅读here以及一个值得一看的Polymer here框架
<强>最后强>
我还认为这是一个excellent, modern best practice css guide - 专门用于阻止大型CSS项目变得混乱。我试着追随其中的大部分。
答案 13 :(得分:0)
答案 14 :(得分:0)
这里有一些很棒的资料,有些已经花了很多时间来回答这个问题但是当涉及到单独的或单独的样式表时,我会选择单独的文件进行开发,然后进入所有的通用css在部署时,选址合并为单个文件。
通过这种方式,您可以充分利用这两个方面,提高性能(减少从浏览器请求的HTTP请求)以及在开发过程中分离代码问题。