CSS教程:面向对象CSS FAQ(2)

可以修改文件，或者用我自己的样式重写吗？

我不会修改grids, template, 或者 libraries。大量测试表明这些已恰到好处。如果要自定义，考虑下面的扩展基本对象。

粉红不是我要的颜色！怎么处理content.css？

获取你会想要修改content.css。去吧，改颜色，字体大小，大小写。只需注意这个文件在快速发展，同时我还没有任何文档来说明如何正确的处理。我会这么做，我保证。

我需要不只6种标题（h1~h6），如何增加？

如果需要不只6中标题样式，通过添加一个新class来扩展标题对象。

.category{font-size:108%; font-weight:normal; font-style: normal; text-transform:uppercase; color: #333;}

不要这样做：

#mySaleModule h2, #mySaleModule .h2{font-size:108%; font-weight:normal; font-style: normal; text-transform:uppercase; color: #333;}

如何扩展对象？

如果要扩展对象，比如一个160px的左列，而非默认值，你可以再列上增加额外的class。

如果默认值和扩展的列宽或者页面不适合你的站点，你可以扩展列来实现自定义的宽度。

列

myColumn 扩展列对象来实现自定义列宽。

.myColumn{width:400px;}

HTML

不要通过重写我的class来实现，而应扩展此框架提供的对象。我提供了列，标题及其他对象。你可以通过增加另外的class（只指定与我的基本对象的不同点）来扩展这些对象。相对而言此处混合比较好。

不要这样做（因为更新我的框架时会有些麻烦）：

.leftCol{… 此处自定义CSS …}

没有用到的样式。我的站点没有160px的gmail式的列，可以移除吗？

当然。移除对象或扩展对象非常合理。只需注意在站点发展时，很难预料到其他人用你的CSS创建的什么样的HTML。过早优化很危险。

为什么有一个单独的模板？

在OOCSS中，一个重要的目标是所有的页面创建自一个模板。这简化了CMS开发，因为有一个单独的起始点所有页面可以制作为其他的页面。CMS的用户不会落入已创建的页面不能变种为不同的页面类型的陷阱。OO模板的另一个目标是每一个section（列，header等）控制自己。实际上，这意味着如果要在模板上增加一个左列，只需在HTML中增加此列。你从来不想这样写CSS吧，为了使子元素满足表现而DOM树需要很多改变。对CMS开发来说DOM循环相当的昂贵。

这有语义吗？我要终止像 .formYellow 或 tinyBlueH2 的class命名吗？

OOCSS可以写得有语义也可无语义，取决于你创建模块时用 errorMod 而非 bigRedModule。我选择class名优一些原则（排名不分先后）：

短 - 每一字节计算起来，所以尽可能保持class短
清晰 - 可预料的行为/样式要显而易见
语义化 - 对象是什么高过看起来像什么。如何用在站点中？
通用 - 名称应该适用于多数站点。过于特殊的名称减少了适用场合或导致语义化的class以非语义化的方式使用
屏幕 - 移动阅读器或打印样式或许有不同的视图，会重写默认的屏幕视图，所以当有冲突时class为屏幕而特殊定义（Different views might be provided by mobile or print stylesheets, however they override the default screen view, so the classes chosen are screen specific when there was a conflict）。这简化了开发。

其它的框架如何？这只能同YUI一起使用吗？

在大量框架的生态系统中，YUI是专业性及可扩展性的一例。我同他们进行了对比，因为我不断受到他们代码和文档的影响。OOCSS不是一个真正意义上的框架，尽管我创建了很多例子，而是一种书写可扩展，健壮，可维护性强的CSS的一种方式。也许最好的比喻是一个新的语言。最终，它是未知的JavaScript库（it is JavaScript library agnostic），我希望贡献代码回YUI及其他框架。

CSS框架太超过！我需要从头开始编写所有代码吗?

每需要一个随机数字都要写一个数字class吗？

CSS is hard, not because it is broken , but because it is a legitimate technology requiring expertise to architect correctly. 为每个站点重复发明轮子非常的愚蠢。

源文件中右列在主列之前，会影响可访问性，SEO吗？

我早期工作过的站点有更标准的模板结构，body上有一个极好的class，依靠这个模板显示或隐藏左右列。自定义CMS的用户要创建一个3列布局的页面时非常沮丧，发现需要两列，找到它们不得不一个个从头开始，因为有多个模板/起始点。你或许注意到主列是个流体列，在左右两列渲染后自适应剩余的空间。

我更喜欢标签排序胜过视觉排序（因为如果标签顺序改变会变得非常怪异），但是我也只想要一个模板。在web开发中经常遇到的是，两个重要的目标发生了冲突，我做判断如何解决。这种情况下标签排序满足视觉顺序除了右列。在当前的代码中，只需在HTML增加一个左或右列，没有别处昂贵的DOM变化。

屏幕阅读器用户有两个选择：

跳过链接
导航链接经常为一个链接列表或嵌套的链接列表形式。这非常有趣，因为这允许屏幕阅读者通过屏幕阅读器的特殊操作设置跳过整个列表。

我的意见是对于跳过菜单这两种方式足够了。

每个人似乎都有一个回复观点：SEO，它们都不同，甚至相反。:)基于这个思潮，我倾向于：尤其对含有一定合理数量链接的导航菜单，不用太过在意。曾几何时，我看到过导航链接被索引在搜索结果的内容部分，不过是在几年前了。搜索爬虫非常智能，我已经准备好想当然的认为如果我以语义化，干净的方式标记内容，并非填充一坨垃圾链接，爬虫能区分的出来。

把导航菜单标记为列表，允许屏幕阅读器用户跳过，并提供“跳至内容”链接，对可访问性提供了双倍的备用措施。

为什么用了_ hack？我能把这些代码放在单独的文件中吗？或者添加IE专有的class？

很显然，首先考虑的是尽可能少和长远。

添加一个单独的样式表奖增加一个额外的HTTP请求，增加整体文件的大小，这早已是浏览器性能的对立点
我喜欢把一个对象的代码放在一个地方。我认为这有助于减少hack的数量，尤其是当项目随时间而发展
IE6-的开发工具非常原始，这使得hack和普通代码放在一起更加重要。我想能尽快找到一个可以使用属性的IE bug。同样，我认为这有助于减少hack
规则表明浏览器理解不了的属性会被忽略。对IE6-使用_早已众所周知，可以合理的预料好的浏览器将会忽略这个属性
使用条件注释意味着每个HTML页面必须包含一个IE专用样式。某一天（我不能等了！）当IE6的市场份额下降至像IE5那样低时，我将去除这些代码，但最后我要做的是触及百级或千级的HTML页面。我宁愿只有依赖CSS hack的CSS，而不是把它放在HTML中。不幸的是，恕我直言，IE6兼容性的末日比我们期望的要更加长远，因为IE中的quirksmode会回落到IE5.5的模式

我认为我的选择有助于减少hack的总体数量，提升性能，并只有忽略不计的风险。话说回来，如果觉得代码中的_令你作呕，你完全可以移至单独的文件。

为了添加表象效果比如边框而使用空 <b> 标签容器对象，会给屏幕阅读器用户带来问题吗？

不会，幸运的是屏幕阅读器会忽略空的b标签。使用这个表象标签（b是加粗）来实现表象具有优势。这个标签可以通过服务器端脚本包含，以至于有一天所有的CSS圆角和阴影都支持了，可以关闭脚本并拥有漂亮，干净，语义化的HTML。

OOCSS声称避免位置依赖的样式。是否意味着我不能使用类似 .myModule .title 的派生选择器？
不使用派生选择器没什么阻碍，只是把它们放在更高的DOM树而已。避免在body或页面中最外层的div放置wide-net class或id，然后对对象产生的变量写大量的样式。这不能复用，同时会使页面渲染变慢。相反，通过直接在对象上添加一个class来增加一个多余的“local”变量（并对其子元素写派生样式）。

一个好的经验是一个容器主体（body of a container）内的任意元素显然是一个单独的对象。

这无可厚非，因为UL显然是一个单独的对象：

#sidebar ul { ... }

因此，carousel显然不是body对象的一部分：

body.browseProducts .carousel

这是适当的层叠应用，因为子节点真正的是较大的父对象的一部分。b（角）和inner显然隶属于moudle，它们不能独立存在：

.myModule { ... }
.myModule b { ... }
.myModule .inner { ... }

如何贡献？

最好的方法是涉足其中，开始使用代码（libraries, grids, fonts）并提交 bug 报告及功能需求。我建了一个 OOCSS google group 来进行超过140个twitter字符的讨论。

译注：OOCSS的官方站点为 http://oocss.org/，有一些例子及下载等。