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