在做大型的项目的时候, 前期, 一定要做好规划,, 有条有理的进行之中...CSS 文件也是这样, 一般在做这种项目的时候, 网站都会有一个专门放置 CSS 的文件夹..
---------------------------------------------------------------------------------------------------
在当前浏览器普遍支持的前提下, CSS 被我们赋予了前所未有的使命. 然而依赖 CSS 越多, 样式表文件就会变得越大越复杂. 与此同时, 文件维护和组织的考验也随之而来.
(曾几何时)只要一个 CSS 文件就够了 -- 所有规则 (rule) 汇聚一堂, 增删改都很方便 -- 可这种日子早已远去.(现在)建立新网站时, 必须花点时间好好筹划怎么组织和架构 CSS.
文件的组织
构建 CSS 系统的第一步是大纲的拟定.(我认为)CSS 组织规划的重要性堪比网站目录结构.(htmlor 注: 用词夸张一点, 让你加深记忆) 没有哪种方案放之四海而皆准, 因此我们会讨论一些基本的组织方案, 以及它们各自的利弊.
主 CSS 文件
通常可以使用一个主 CSS 文件, 来放置所有页面共享的规则. 这个文件会包含默认的字体, 链接, 页眉和其他等样式. 有了主 CSS 文件之后, 我们开始探讨高级组织策略.
方法一: 基于原型
最基本的策略是基于原型页面 (archetype page) 分离 CSS 文件. 假如一个网站的首页, 子页面和组合页设计不同, 就可以采用基于原型的策略.(这种策略下)每个页面都会有专属的 CSS 文件.
在原型数量不多的情况下, 这个方法简单明了, 行之有效. 然而, 当页面元素并不按部就班的位于各个原型页时, 问题就出现了. 如果子页面和组合页共享某些元素, 而首页却没有, 我们应该怎么做呢?
把共享元素放入主 CSS 文件. 这虽不是最纯正的解决办法, 却适用于某些具体情况. 可是如果网站庞大,(这样做的话)主 CSS 文件会迅速膨胀 -- 这就违背了分离文件的初衷: 避免导入不必要的大文件.
在组合页和子页面的 CSS 文件里各放一份样式代码.(这么做)就意味着要维护冗余代码, 很显然我们不想这样.
创建一个新的文件, 由这两种页面共享. 这听起来不错. 不过假如只有 10 行代码, 我们创建这个 文件仅仅是为了共享这 10 行代码?(htmlor 注: 杀鸡用牛刀?) 这方法很纯粹, 但如果网站庞大有很多对页面共享很少量元素时(htmlor 注: 比如 30 对页面分别共享 10 行代码), 就显得很笨重了.
创建一个单独的 CSS 文件, 包含所有共享元素的样式. 这方法可能比较简单, 却要取决于网站的大小和共享元素的多少. 有种情况会很烦: 导入了一个很大的 CSS 文件, 但页面只用到一小部分样式 -- 还是那句话, 这违背了分离文件的初衷.
这就是我所说的重叠的两难(overlap dilemma). 零碎 CSS 规则的重叠不一而足, 并没有一个完全清晰无误的方案来组织它们.
方法二: 基于页面元素 / 块
如果网站使用服务器端 include, 这个方法会很不错. 举例说明, 如果使用页眉 include, 它会有自己相应的 CSS 文件. 页脚或者其他部分的 include 可以如法炮制, 只须导入自己的 CSS 文件. 这个方法简单干净, 不过可能会产生很多小 CSS 文件.
举例来说, 假如页脚的样式只需要 20 行 CSS 代码, 单独创建一个文件就划不来了. 而且这个方法会导致每个页面都包含一堆 CSS 文件 -- 因为有多少 include, 就得有多少 CSS 文件.
方法三: 基于标记
这个方案直观实际, 与前一个类似. 如果网站共有 30 个页面, 其中 10 个含有 form, 那么可以创建一个 CSS 文件专门处理 form 的样式, 只在这 10 个页面导入它. 如果另外 10 个页面含有 table, 就创建一个文件专门处理 table 样式...... 诸如此类.
另外的组织技巧
除了用主观的方法组织文件, 我们还要考虑如打印, 手持设备和屏幕等多种媒体类型. 这虽然已经很清楚的定义过, 可依旧是建立文件结构时应该考虑的一个因素. 一旦必须支持多种媒体类型, 主 CSS 文件里的某些规则可能就得重新考虑.
另外, 品牌联合也可能是一个重要因素.(htmlor 注: 如 google 和 nike 联手推出的 joga) 如果涉及品牌联合, 你就得考虑哪些元素应该调整以适应另一品牌. 比如分别使用不同的 CSS 文件等.
还有一个常被忽略的技巧: 使用嵌套的 @import 语句. 只包含一连串 @import 语句, 或者再加几句 CSS 规则, 就能创建一个 CSS 文件. 用这个方法完全可以创建网站的主 CSS 文件(用 @import 导入各部分的样式文件). 假如网站的每个 页面都导入了 4 到 5 个不同的 CSS 文件, 无疑你应该考虑使用这个技巧.
规则和选择器的组织
谈完了文件组织, 接着讨论一下怎么组织文件里的东西吧. 很自然, 我们希望在文件里畅通无阻的浏览, 迅速找到要编辑的选择器 (selector) 或规则.
冗余 vs. 附属
正如 Dave Shea 在其文章《冗余 vs. 附属》(Redundancy vs. Dependency)里所说的, 你必须不断了解级联(cascade). 你要决定是对选择器编组(意味着附属), 还是把它们分离(意味着冗余). 编组可 以保持代码简洁扼要, 可是会建立附属关系, 导致维护开销增加. 如果不编组, 就会增加文件大小, 让相似的选择器保持一致变得困难. 只有做好这种权衡, 取舍, 才能每次都作出正确的决定.
按相互关系 / 上下文编组
既然文件组织可以是主观的, 那么显然, 按照规则和选择器与其他部分的相互关系来进行编组是最好的方法. 举例说明, 假设你用容器, 页眉和页脚来完成布局, 就应该把它们编成一组.
这似乎很简单, 其实不然. 比如, 把页眉中的导航加入 CSS 时, 是将它跟父元素编组还是独立编组? 这种情况下, 要视乎规则的上下文. 通常, 页眉与页面布局相关, 应该与其他布局元素一起编组. 而导航是页眉的一块, 应该和页眉的其他块编组, 而不是页眉本身.
使用注释
跟大多数代码类似, 注释是组织良好与否的关键. 应该根据 CSS 的控制范围, 清楚的标注每节(section). 最好确保注释视觉突出, 以便在内容滚动, 一目十行时快速定位.
Doug Bowman 在其文章《CSS 组织技巧之一: 标记》(CSS Organization Tip #1: Flags)里把 CSS 注释玩得高明之极. 他详细说明了在节名之前加上等号, 以便使用文本编辑器的查找功能迅速跳到某节.
别忘了
你应该细致认真的了解了特异性, 级联和继承, 并善用它们. 它们之中的每一项都可以是你最可怕 的敌人, 也可以是你最友善的朋友. 当建立庞大的网站时, 是否理解这些细微精妙之处, 决定了你所构建的是坚如磐石的系统, 还是经不起风雨的豆腐渣工 程.(htmlor 注: 这句完全意译, 比较爽)
属性的组织
现在我们了解了文件的组织, 也知道了文件内规则的组织, 但还有一个重要的组织环节(没有提到), 那就是属性(attribute). 虽然属性比前两个概念更简单, 可是还有一些非常好的, 能够保持规则整洁的方法很值得一提.
按字母排序
提到属性, 如果说需要遵循什么原则的话, 那就是: 按 - 字 - 母 - 排 - 序. 其实这招对于属性浏览帮助不大, 不过可以防止属性值覆盖这种偶然事件的发生.
举个例子吧, 已经数不清有多少次, 我为某个选择器定义过了 margin 值, 之后的某天无意间 又加了一个 (或前或后).(这种情况下) 后一个属性自然会起作用. 假设不知道第二个属性存在, 不管我怎么调整第一个属性值, 刷新浏览器, 也看不到页面变 化.(htmlor 注: 这个问题我深有体会) 如果按照字母顺序排列, 你就会发现 margin 被定义了两次(因为它们挨在一起), 这个问题自然可以避免.
优先项
当网站复杂, 牵涉太多 CSS 文件时, 会建立大量的附属关系. 一旦需要定制某个元素特有的样式,!important 选项似乎是最佳选择. 没错,!important 是能解一时之需, 但最好搞清楚导致问题的根源, 然后根据级联关系决定是否真的需要用它.
如果你对上文提到的特异性, 级联和继承很熟悉, 大可不必抱着! important 一颗树不 放.(htmlor 注: 整片森林等着你~) 当然它还是会派上用场, 不过使用之前要对具体情况了然于胸. 千万不要因为不知问题的症结所在而把! important 当作捷径或是补救方案.
小结
当我们变得依赖 CSS 而使样式表日渐复杂时, 就需要正确的计划来避免犯错, 并使代码易于维护. 既然完美无缺的方案并不存在, 那么了解 CSS 的工作方式以及文件, 选择器和属性的多种组织方案, 无疑有助于我们写出优质的代码, 经受住时间考验.
更多 web 前端开发 https://www.html.cn/ 知识, 请查阅 HTML 中文网 !!
来源: http://www.css88.com/qa/css3/16737.html