听晴空讲Drupal主题——第六章主题中的CSS（14）

由 qingkong 提交于 30 August 2015

drupal的前端表现为什么这么差(2) Drupal主题系统的“变革”

Drupal7和它之前的版本，页面上每渲染出一个元素，都会被一层层的div包裹着，并且每一层div都有一长串的class／id选择器。然而，Drupal7在主题层上依然比前面的版本要强大、灵活。比如：

在Drupal5中，主题函数中没有预处理函数，因此你很难修改Drupal为你提供的CSS选择器。
在Drupal5中，view modes只有两个模式，一个是full一个是teaser，而在Drupal7中，你可以自己建立其他的模式，并且对内容的显示方式进行控制。这意味着在Drupal5中，如果你希望有第三种view modes，你就只能自己写额外的css去进行控制。

然而，因为上面第一点中提到的问题，你很难为某个元素指定一个class，因此你往往需要用一长串class去定位某个元素。而这就是为什么drupal页面上的每一个元素被一层层的div所包裹，并且每一个div都有一长串class名的直接原因。因为这样才能保证每一个元素在样式表中都能被正确的定位。可以说这是一个历史遗留问题，在Drupal7的时候也并没有被解决掉。

由于预处理函数的加入，Drupal7已经比前面的版本灵活多了，然而，这依旧是不够的。愤怒的Themer们不得不在他们的template.php中反复使用预处理函数来加入他们自己指派的CSS选择器——就好像前几节中介绍的那样。这样做的同时导致了template.php代码长度的增加，随随便便三五千行是正常状态——而这被称为themer的斯德歌尔摩综合症之一。

原因何在？

首先，我们要知道一个重要的时间节点，那就是Drupal7的发布日期：2011年1月5日。然后我们再看看Drupal主题开发者和Drupal模块开发者的态度，就不难理解，我们为什么会得到一个现在这样令人作呕的Drupal7主题层了。

在这个时间节点之前，Iphone已经在全世界火了好几轮了（这甚至都包括了中国！），同一年，SMACSS理论发布了，再过一年，Bootstrap2开始支持响应式了。

主题开发者

这个时期的（09年到11年）主题开发者们在反复的讨论一个问题：如何“可持续的为Drupal制作主题（Sustainable theming）”。具体来说，主题开发者经常遇到的一个情况是，他们做好的主题交付给客户之后，客户添加了一个区块，或者禁用／添加了某个模块，结果页面就出问题了。Sustainable theming的目标很明确，就是要求主题能正确应对客户使用过程中对网站内容和布局的修改，而不需要一个前端人员去进行维护——这个目标在现在来看依然是正确的，也是不容易做到的。

主题开发者如果做了一个不可持续的主题，那么往往都是因为前端代码中陷入了一些常见的误区。与这相关的内容我们已经在前面的内容中讲过了（第六章第七节）。在之后的章节中我们给出了解决方案，即SMACSS。然而SMACSS理论和Drupal7是同一年发布的，并且其实drupal7的发布还要早于SMACSS。而SMACSS理论的作者Jonathan Snook和Drupal一点关系都没有，所以Drupal7的开发过程没有人会想到我们要考虑SMACSS。

以下是一位资深Drupal主题开发者在09年的时候在她的Blog中讨论Sustainable theming时和其他人的对话：

Let me ask you first,...why does your HTML need to be short and sweet and specifically why don't you want it to be "15 words long"? What does it actually impact besides your own preferred style? I could see the need to have it clean for page weight issues but even then we're not talking about huge amounts of page weight. Drupal is not a build a template first system, its a install a module and theme it system. IMO the templates are there when you need to override something that just isn't working, not override it because you wish there was one last div.

翻译如下：

首先让我问一下，为什么你想要让你的HTML简短，或者更确切一点，为什么你不喜欢你的CSS class超过15个单词呢？这样有什么影响呢？除了不合你的个人口味之外？我知道，你会告诉我因为你不希望你的HTML过于冗长（重），但是，这样做并不会导致HTML长（重）得令人无法接受。Drupal不是一个先写模版的系统，它是一个先安装模块然后制作主题的系统。Drpal中的tpl模版文件，是让你在整个页面无法满足功能需求的时候去才覆写的，而并不是让你仅仅因为你希望里面出现某个div就去把他覆写掉的。

现在你知道为什么我在前面啰里八嗦的讲前端发展史了吧？从上面这段话，我们能知道哪些情况：

在Drupal7发布之前以及之后的一段时间内，Drupal主题开发者们极少有人用前端网格框架去做Drupal主题。这并不是因为他们不思进取，抵制新技术，而是因为Drupal8之前的主题系统设计根本没有给他们第一时间使用新技术的机会。他们没法绕开主题层去做自己想做的事情。而且那个时间段里也没有Headless Drupal这种东西。Drupal8之前的主题系统，在很大程度上拉低了主题开发者们的前端技术水平。
在Drupal7发布之前以及之后的一段时间内，Drupal主题开发者们都在非常努力的把页面尽量做得看上去像设计稿——因为他们只能做到这个地步。
在Drupal7发布之前以及之后的一段时间内，Drupal主题开发者们做主题唯一的工具就是CSS，参见此贴。
在Drupal7发布之前以及之后的一段时间内，Drupal主题中CSS选择器越多越好，DIV越多越好，选择器长度越长越好，用多个选择器组合起来定位某个元素非常流行。
在Drupal7发布之前以及之后的一段时间内，Drupal主题开发者们都没听说过SMACSS，但SMACSS能为他们想要解决的问题提供很好的理论依据。主题开发者们也在探索主题的可持续性，但是却一直做着和SMACSS理论正好相反的事情。
Drupal主题开发者们都患有斯德哥尔摩综合症，而且非常严重。

以上这些情况的根本原因有几个：

D7之前主题开发者无法掌控Drupal的主题层，这并不是因为他们蠢，而是因为在D7之前的版本根本就没有为主题开发者们提供相应的工具。而D7虽然有了一些工具，但是依然要求主题开发者非常了解整个Drupal7的主题系统，然而，这部分仅仅只是少数。
在D7发布的时候，人们对于网页设计工作的流程，依然停留在根据客户的需求、线框图为客户制作一份PSD，然后修改它，一个网页就ok了的层面。而这与我在前一节中提过的前端开发流程的第二次变革正好是相矛盾的——这就是Drupal前端最大的问题：我们不再需要Drupal为我们提供的HTML和CSS了，因为设计师已经作出原型页面了。
虽然下面我们会讲到核心／模块开发者的偏见也导致了Drupal主题层的问题，但是我们必须承认一个事实：CMS的开发周期总是很长的，核心开发者再怎么努力也赶不上前端流程的变革。

核心／模块开发者

核心／模块开发者是Drupal社区最重要的部分，他们决定了Drupal的属性。让我们来看一个博客，它的作者Larry Garfield是《Drupal 7 Module Development》的作者之一，在官网上提过很多的commit。这篇blog的名字是“Does design matter?”

users want content their way, not the way we (web designers, web authors, and web devleopers) want it. Visually impared users want content read to them, or resized. Color blind users want a different color scheme that they can actually read. Smartphone users want content in a narrow column, without a dozen sidebar blocks. Mobile users want content offline, so they can read it on a plane. Many users want just the content, no design, and so use tools like Instapaper to strip out everything but the text of an article. RSS feeds have been around for a decade, and are now growing rapidly thanks to mobile devices, and those are generally (mostly) layout-free. If you're doing responsive design, then you're not making a design but the framework of a design that will change, and possibly mostly disappear, under certain circumstances.

……

In the modern web, does web design even matter?

……

Most of the phone-sized designs that I've seen that have actually worked have been barely any design at all beyond a tiny header banner. And of course that ever-important user, the search engine, doesn't care about your design in the slightest and is usually better off if you don't bother with it at all.

……

I will make the following claim: Graphic design on the web is dead. User choice and user freedom is in the process of killing it, and will kill it. Fancy graphic designs will eventually fade out the way table-based layout did, because they will become increasingly irrelevant to most users. Users will circumvent them or simply ignore them, and it will eventually become simply not worth the investment to bother designing something that fewer and fewer users will ever see.

……

In short, focus on the data, not the presentation. The user will control the presentation, not us. Give the customer what they want, which is data, not an opportunity to marvel at how good a color choice we made ……

翻译如下：

用户对于内容有他们自己的期望，往往并不是我们（网页设计师，网站编辑和网站开发者）所期望的那样。视觉受损的用户希望内容能被读给他们听，或者文字能被放大。色盲用户希望网页换一套配色，以便他们能看清楚内容。智能手机用户希望文字内容的栏宽更窄，并且旁边没有边栏。移动用户希望内容能个离线阅读，这样可以在飞机上阅读。很多用户都只想读内容，并不需要设计，所以他们使用Instapaper这样的APP把除了内容之外的东西全部屏蔽掉。RSS已经出现了十年了，由于移动设备的兴起而迅猛增长，而它们大多数都是没有经过设计过的。如果你在做响应式设计，你做的其实并不是设计，而是一套会变化的设计框架，并且他们以后很可能都会消失。

……

在现代网页中，设计还有意义么？

……

我见到过的大多数真正用于生产环境的可以被称作手机版的设计都没有什么设计可言，除了一个很小的头部banner之外。而且对于那个最重要的用户——搜索引擎来说，它根本不关心你的设计，而且通常情况下如果你的页面不做设计的话，SEO的性能会更好。

……

在这里，我的观点是：网页上的视觉设计已经死了。用户的选择和权利正在慢慢的杀死网页设计，导致它再某一天会彻底消失。好看的网页设计最终会像基于table的页面那样退出历史舞台，因为它们对用户越来越没有意义。用户会想办法绕开它们或者干脆直接忽视它们，所以逐渐的，它们越来越不值得投入。

……

简言之，我们应该将精力集中在数据（内容）上，而不是表现上。用户自己会控制表现层，而不是我们。我们应该为用户提供他们想要的东西，即数据（内容），而不是让他们为我们的网站配色多么好看而感到惊奇……