CSS语义思维

2015-03-14 Zhang zhengzheng 更多博文 » 博客 » GitHub »

css style front-end

原文链接 http://www.tychio.net/tech/2015/03/14/thinking-in-semantic-css.html
注:以下为加速网络访问所做的原文缓存,经过重新格式化,可能存在格式方面的问题,或偶有遗漏信息,请以原文为准。


Linguistic

前一阵子在项目组中讲了一个关于CSS的Session,在讲之前我曾收到了许多意见,大部分是希望能讲讲CSS实用性的技术,比如盒模型,CSS3之类的。干货人人都喜欢,因为看得见摸得着,拿来就有用,但我最后还是决定讲一些”湿货“。因为在Code Diff的时候我发现了许多样式的问题不是由于不会写CSS导致的,而是由于在错误的地方使用了写在错误地方的样式。

其实CSS很简单,没有计算没有流程,只是一直描述,无论什么复杂的效果,你只要Google一下就知道怎么写了,甚至可以直接copy。但CSS又很复杂,一个元素的表现会受到它旁边的兄弟元素,也会受到内部的子元素影响,还会受到父元素影响,在这种多重影响下,一个元素的显示逻辑会变得错综复杂。有没有面对塌陷的块级元素而束手无策?无论怎么改它的属性就是得不到自己想要的,但看看似乎一模一样的示例程序却安然无恙,是不是恨得咬牙切齿?我想这就是本文所要解决的主要问题,让你学会如何优雅的写CSS。

<!-- more -->

泾渭分明 - 明确书写意图和表现语义

其实我们只要稍微接触过CSS,一定都学过盒模型,我假设你已经对margin、padding和border已经很熟悉。好了,我们经常会遇到一种情况,想让父元素和子元素之间有一些空间,比如布局的时候,container和content之间的留白。一般来说有两种方式,一种是给父元素加padding内边距,另一种是给子元素加margin外边距。现在想想,你是否慎重考虑过用哪一种方式?你是否明白两者的区别?如果你从未考虑过这些,现在考虑也不迟,这真的很重要,如果你真的想优雅的运用CSS,而不是被它耍的团团转,如果你真的想把CSS写出规模,那你就要认真的思考这里面的逻辑。

先说说父元素的container加上padding的方式,子元素的背景将不会延伸到空白区域,另一种给子元素加margin的方式则反之。但我想先抛下这个表象,看看此时加上padding的父元素的逻辑。它意味着,我创建了一个容器,并且该容器的内部有一些区域是被看不见的东西填充的,无论放入什么都不应该占据这个区域。在你的脑海中想象一个厚厚的玻璃瓶,它就好像是在说“虽然我是透明的,但是在这厚厚的玻璃之内才是你应该呆的地方,无论是什么只要你想放在瓶子里”。现在来看看子元素,是的,其背景也应该并且确实在内部,而不该占据那段空白的区域。如果是为子元素加上margin,这意味着我在容器中创建了某个东西,而这个东西有一个自己的地盘,容器内的其他东西都不能进入这里。

所以他们的本质区别在于其所表达的意义,也就是语义,一个是容器上的语义,另一个是容器内元素的语义,主语也不同,谓语意义也不同。那么这能说明什么呢,不得不提一下高级语言中的高级,这代表某个语言将机器语言封装的更好,接口更接近自然语言,其强大不言而喻。其实编程语言的发展轨迹就是不断把机器语言往自然语言翻译,让人们可以更容易的跟机器沟通,终极目标自然是人工智能,和机器用自然语言自由沟通。所以虽然代码或者说CSS的语法并没有什么变化,但我们应该在思维上清楚的区分代码片段的意图和语义来写CSS。

语言学家乔姆斯基曾构造过一句符合语法的话:

“Colorless green ideas sleep furiously”

意思是无色的绿色想法愤怒的睡觉。想法睡觉是违反常识的,无色的绿色是矛盾的,愤怒的睡觉是不合常理的。仅仅符合语法是不够的,仅仅不报错也是不够的,尤其是CSS这种描述性的语言很少会报错,所以我想说的是,其描述性质让我们有更多选择来实现我们所期望的效果,但我们却应该慎重,要让语义分明,而不是在有限的语法规则下任意妄为,那样写不出好的CSS代码。除了其本身的语法规则,我们必须自我约束,引入语义规则,不仅仅是为了提高可读性这样的理由,而是拉近人与机器的距离,让我们在思维上更加和代码契合,这样才能写出优秀的程序。

言归正传,究竟如何语义化CSS呢。之前有讲过OOCSS,其实面向对象的思想就是一种语义化,将虚拟的元素看作实际的对象,用常识来构造代码,就像是用户体验中的用户习惯一样,这是一种遍及全人类的用户习惯,让代码更友好,即所谓的优雅。

比如最常见的布局,我们一般都会有header、body和footer,这样无需任何说明和规则,谁都会理解,header在前,footer在后,中间是body。有趣的是table中的thead、tbody和tfoot,由于加载优化,我们即使把tfoot放在tbody前面,让其先加载,但显示的时候tfoot仍然会在tbody下面,由此可见语义化的重要,否则你一定会以为不是W3C的人弄错了标准,就是浏览器厂商搞出了Bug。虽然这是HTML标签不是CSS,但我觉得这个例子很恰当的说明了一点,显示逻辑是独立的,不应该和其他逻辑混为一谈,它应该只关心如何显示。

再比如,一个导航条一般分为左右两边,里面各有若干链接。你会如何命名?navbar-left和navbar-right是Bootstrap所使用的class,但当宽度减少,Responsive响应式的Bootstrap会让这些链接都收进下拉菜单中,左和右又从何谈起呢?同样是Bootstrap中的颜色命名就做的十分成熟,不是green、blue、red这些词汇,而是success、primary、warning这些词,它们的区别是表现化与语义化的区别,我喜欢把这个叫做显示逻辑。也就是说在class层面我们应该只关注元素(或者说对象)是用来做什么的(意图)以及它应该表示什么(语义)。这里三种颜色代表成功、重要和警告,至于我们是用绿、蓝和红来表示还是通过其他什么颜色甚至形状,应该在style层面写CSS属性表示。如此我们使用class时无需迷茫于表示成功应该用绿色还是红色,意图明确无误。回到导航栏的例子,我们应该使用main和sub之类的词语标识导航栏中重要的和次要的链接,即使在某些实现下,主要和次要没有区别也不用担心,那是该实现的显示逻辑,我们不应该横加干涉。

狡兔三窟 - 善用class与style多对多的复杂关系

说到class和style(样式属性),这又是一段混乱不清的关系。其实每当我们要实现一个样式,自觉或不自觉的都会考虑,是将元素和class一一对应,然后为元素上的class写style,还是用class和几条style对应之后在元素上搭配组合。前者的好处是每个class中的style不会影响其他class,但可用性十分的低,极端点说这已经不算是在编程了,而是在画页面;后者的好处可以灵活使用不同的样式搭配给元素使用,组合出元素需要的效果,但很难维护,牵一发动全身,样式很难测试,无法保证在你动了一条style之后,没有影响其他的地方。甚至最要命的是大部分CSS代码都是无意识的游走在这两种情况之间,所以我们要做的不是选择一种极端,而是找到一个平衡点,并使用一些方法使得我们的CSS既能灵活复用在各种元素上,又能易于维护,不致修了这破坏那的情况。

分组

首先,对于一个或一套元素的样式,我们应该有自己的创建原则,而不是想到哪写到哪。比如,我一般使用这样的步骤来创建元素:

  1. 结构

首先仅关注结构布局,以站点整体为基准,将元素抽象为一个或多个结构。

比如制作一个按钮,你也许会发现它的尺寸和导航上的链接一致,而内外边距以及display和overflow之类的属性又和页面容器一样,这时你就可以把按钮的结构拆成两个结构,一个是尺寸,一个是边界逻辑,这种情况时常发生,所以有的CSS理论认为应该把width和height这对尺寸属性和padding以及margin这对边距属性彻底的分开也是这个道理。其实并不是说它们4个放一起就决定不行,只是一般它们都有各自复用的价值,所以常常被拆开使用,归根揭底这是由显示逻辑决定的。

  1. 皮肤

一般由于设计统一性,我们可以借助设计指导,轻松的制作出标准皮肤。但要注意的是,皮肤指的不仅仅甚至不一定是颜色之类的。继续用Bootstrap举例,有5种基础颜色,但这并不是皮肤,5种颜色的语义不同,它们只是默认用了5种颜色,勉强可以看作默认皮肤,而真正的皮肤是theme,让按钮变得有立体感。还有一个误区就是认为哪几种属性是皮肤,哪几种不是。就像前面所说的,我们要在语义上进行划分。一个属性在某些意图下可能是结构,在另外的意图中可能是皮肤。Logo举个极端的例子,在一个Workshop中我用CSS和HTML制作了左边这样的Logo,Logo本身应该完全算是皮肤,因为一般来说就是一张图片,所以制作它的所有CSS属性都应该算作皮肤。下面的CSS代码中,无论是定位还是文字的处理,以及尺寸等,都是为了构造Logo,所以这些属性都是皮肤。

#logo i, #logo b {
  position: relative;
}
#logo i {
  left: -30px;
  transform: rotate(-30deg);
  font-size: 60px;
  letter-spacing: -11px;
  opacity: 0.3;
}
#logo b {
  top: -43px;
  left: 40px;
  font-size: 68px;
  word-break: break-all;
  width: 3px;
  line-height: 10px;
  text-indent: 6px;
}
  1. 状态

除了结构和皮肤,其实还有一类很容易被人忽视的样式,即使是设计人员也经常忘了它,那就是状态。最常见的是hover,鼠标触碰元素与否的状态,以及active,当前选中的标签,当前所在的分页等等。通常人们会把它划分到皮肤中,但你要明白我们划分的依据是意图,很显然,状态不是皮肤,仅仅是通常为表达某些状态时会使用一些颜色,毕竟颜色是最好的表示方法。它还与各种逻辑有着千丝万缕的联系,经常会使用JavaScript来加以控制,所以将状态单独分出来是极有必要的,JavaScript只需要更改一个class就可以实现状态的切换,而不是在执行的时候才想起来应该把哪里隐藏把哪里显示,或者是变个颜色出个动画之类的。

使用

接着,无论我们是已经把各种写好的CSS属性分好了组,还是正准备以这种方式开始写CSS,我先引入一个语言学的术语 语块(Lexical chunk),创造这一术语的 Michael Lewis 认为语言并非由传统语法和词汇组成,而是由多个词汇的预制语块组成。我们现在分好的组其实就是一个个CSS的语块,CSS本身就是这种预制功能,我们要做的就是把style语块化,然后在HTML中写上代表它的class名称,当HTML元素上的多个class组合在一起时就组成完整的语义。

比如表示步骤的元素,这是一个形状类似标签,一个挨一个的排列的元素。我将它的尺寸等属性抽出来命名为label,然后把布局的属性组命名为float-left,如果我的设计风格是扁平化的,我可以把相关的皮肤属性命名为flat,你知道虽然扁平化一般用不着特别的属性,但我也可以写一些强制去掉圆角和渐变背景的属性。作为步骤,会分为当前的步骤,之前的步骤,以及还没到的步骤,当前的步骤可以命名为current,或者is—active,后面的步骤不能点所以可以命名为is-disable,这些都是状态。而现在我们来看看当前步骤元素是什么样的

    <div class="flat label float-left is-active"></div>

总结成一句话就是“The flat label which float left is active”。这就是语义化的CSS。把组织好的语块像说话一样作用于元素上,对元素发出指令,让其变成想要的样式。而且你应该会发现,一组该元素所独有的属性,或者是尺寸之类的一般是主语,布局是动宾短语,而皮肤多是一些形容词,最后状态可以用表语。

总之,CSS作为一个描述性的语言,有很多人觉得不能算一种语言,但我反而觉得这是一种高级语言,因为更接近自然语言。当然其主要作用是在视觉渲染上,所以应该是一种受限的语言,可以看作是接近自然语言的子集。所以它的性质觉得了其重语义轻语法的特点,写CSS不能仅靠语法规则,一定要用上语义规则,最好是能和项目中所有人达成共识,CSS框架其实就是一种通用共识。