10.28日音讯,css用法也分聪明和笨的引用。随着面向对象的CSS（OOCSS）的出现，越来越多人趋向于“把呈现的语义从文档语义中脱离出来”。借助于类（classes）的非特指含义，我们能够以分离的方式来管理一个文档和一个文档的外貌。
在这篇文章当中，我们会探索多种为Web文档添加样式的方法，他们能把文档语义与视觉设计相结合在一起。通过“聪明的”选择器的使用，我们通过这种方法给你讲解怎样去查询语义化的HTML文档现有的功能特性，以此作为对那些格式良好的标记的一个奖励。如果你的代码是正确的，你一定会得到你所期望设计出来的东西。
我想，如果你和我一样同时在开发几个不同的项目，我希望通过这些方法会简化你的工作流程和并能更轻松地穿梭在这些项目当中。另外，在最后的部分我们会讲解一个更被动的方法：我们会制作一个包含属性选择器的CSS书签来测试那些写得很糟糕的HTML文档并使用伪元素来反馈错误。
聪明的选择器
样式表的发明使我们能够将那些美化HTML文档的代码从HTML文档中分离出来。但它对于我们书写标准的HTML文档方面所带来的帮助并不像遥控器那样为电视机带来了更高质量的电视节目。它只不过把工作变得更加简单。因为我们能够使用一个选择器来为多个元素添加样式。（例如p可作用于所有的段落元素），页面的一致性和可维护性也不像以前那样那么令人畏惧。
p选择器最简单的形式就是智能选择器的一个代表。因为p选择器在语义分类方面具有先天的基础。不用开发者多做额外的事情它已经知道怎样确认一个段落以及何时为他们添加样式，非常简单而有效，特别是你想为所见即所得编辑器产生的所有的段落元素添加样式的时候。
但如果说它是智能的选择器，那非智能的选择器又是哪些呢？所有需要开发者介入并更改文档从而引起样式上的变化的选择器都被称之为非智能的选择器。class便是一个经典的非智能选择器因为它不是作为语义约定的一部分出现的。你可以灵活地命名和组织类，但需要一定的思考；除非你在文档上应用它们，否则它们不会自动地执行任何事情。
使用非智能选择器是很消耗开发时间的，因为我们需要手动地为每一个选择器添加对应的不同的样式并把类名复制到每一个需要应用此类的元素。如果我们没有p标签，我们不得不使用非智能选择器来管理段落，例如在每一个段落元素中使用一个
.paragraph
类来指明。这样做的其中一个缺点是这些样式表不是可移植的，因为你不能再没有为HTML文档的标签指定相应的类名的情况下而应用这些样式到所需要的元素当中。
非智能选择器有时候还是有必要的，并且我们很少人会完全依赖智能选择器。然而，一些非智能选择器可能会因为在文档的结构和表现之间搭配不当而变成“愚蠢的”选择器。我将会谈论
.button
这个使用频率极高的“愚蠢”的选择器。
不同组合的好处
智能选择器并不限制于HTML规范中所提供给我们的基础元素。想要构建复杂的智能选择器，你可以遵从上下文和功能属性的组合来区分基础元素。一些元素，例如
<a>
，提供了大量的功能差异给开发者考虑和利用。其他的元素，例如
<p>
元素，任何情景中在明确的功能上没什么差异，但也会根据上下文来承担轻微不同的角色。
像这样的简单后代选择器是非常有用的，因为它们让我们能够从视觉上看出一个元素的不同类型而无需从物理上更改底层的文档。这是整个样式表发明的原因：既促进物理上的分离而又无需破坏那些存在于文档和设计之间的概念上的相互关系。
不可避免的，一些OOCSS的粉丝们对这样的后代选择器是有点不太认同的，它们更喜欢像下面这个例子那样来做标记，这是从BEM的“定义”文档中找到的。
我不会再对后代选择器作进一步的讨论，因为我确定你每天都在使用它们，除非你偏好于上面这种过量的概述。换言之，我们接下来会集中于属性选择器和属性中描述的功能所带来的差异。
超链接属性
即使是那些CSS和HTML之间的概念分离的拥护者也乐于承认一些属性——除了类和自定义数据属性以外的大多数的属性，实际上和文档的内部工作的有重要关系的。没有
href
属性你的超链接不会链接到任何东西。没有
type
属性，浏览器无法知道渲染哪一个类型的input元素。没有
title
属性，你的
abbr
元素则可能代表任何东西。
像这样的属性有助于改善文档细节的语义化，否则你需要去确认主题元素是否正确被渲染以及运作。如果它们不存在，那么它们应该被创造，如果它们已经存在了，那为什么不适用它们呢？你不能够只写CSS而不写HTML吧。
REL属性
rel
属性是链接关系的一个标准属性，是一个描述链接的具体的用途的一个方法。并不是所有的链接的功能都是相同的。得益于众多的WordPress的使用者，
rel="prev"
和
rel="next"
成为两个最广泛采用的值，并有助于描述分页博客内容的每个单独页面之间的关系。从语义上来说，一个拥有
rel
属性的a标签仍然是一个
a
标签，但我们已经能更加具体地表现它了。这和类不相同，这种具体是从语义上间接表现的。
rel
属性应该只被用在合适的地方，因为它们是被HTML的功能规范所维护的，并能因此被不同的用户代理采用从而提高用户体验和搜索引擎的精确度。那么，你曾像下面这样为链接添加过样式吗？使用简单的属性选择器，如：
属性选择器被所有的浏览器所支持除了最古老和落后的浏览器（IE6），因此只要这个属性存在于标签中的时候没有任何理由不去使用它们。在它的优先级方面，它和类具有相同的权重值。然而，我记得它被建议，我们应该将文档和表现语义分离。我不想浪费这个
rel
属性，所以我最好元素设置一个毫无意义的属性并通过它来进行样式的添加。
此处首先要注意的第一件事情是，上面元素中唯一没有对文档的语义有帮助的是类这个属性。换句话说，类在上面的文档中式唯一的没有起到什么功能上的作用的东西。在实际中，这意味着类是唯一的打破了分离定律的并被解释为：它实际存在于文档中却又没对文档的结构有任何帮助。
好了，说了这么多抽象的概念，但它的可维护性方面如何？大家都接受使用
作为样式钩子，让我们看看当通过编辑或重构时移除了一些属性的时候会发生什么事情。假设我们使用了伪元素来为
链接的文字前面添加一个左指箭头：
移除类的同时也会同时移除了伪元素，反过来说这个举动会将箭头所移除。但没有了这个箭头，将没有其他的东西能告诉我们链接现存的
prev
关系。出于同样的原因，移除
rel
属性也会导致箭头的不完整：因为虽然
class
会继续让这个箭头得以显示，却总是使文档的状态关系丢失。只有直接的通过语义的属性来给出样式并应用，你才能让你的代码和你自己保持真实。只要是文档中存在的真实的功能，你就要让它被看见。
属性字串
我可以想象你正在想什么：“这很有趣，但在超链接中有多少个这样的语义样式钩子？我还是会不得不依赖类来应用样式。”那么请你看看下面不同的链接功能的不完全的列表吧，这就是链接功能上的差异，所有的类型都可以被用户代理所识别。现在让我们思考一个问题，为了让所有的这些具体链接类型都执行不同的功能，它们必须要有不同的属性。也就是说，为了执行不同的功能，链接的书写形式是需要有所变化的；并且，如果它们书写形式不同，它们就可以通过这个来添加不同的样式。
在准备这篇文章的时候，我对一个构思作了一个检验，命名为Auticons。Auticons是一个图标字体和样式表，用于自动地为链接添加样式。里面的所有选择器都是属性选择器而没有一个类，为格式良好的超链接来调用样式。
在许多的案例中，Auticons对
href
值的一个子集进行了查询来确定超链接的功能。通过的它们的属性值的开头或结尾来对相应的元素添加样式，又或者是根据它们属性值是否包含了一个指定的字串来查找对应元素也是可能的。
