Css很容易，只要会英文的人，都可以写css。但是，正是因为它太容易了，我们很少有人去关注如何有效的整理和架构它。接下来的几节中，我们将试图讨论这个问题。
对于刚入门的themer来说，他们最容易犯的一个错误就是，他们会立刻用css去做主题。他们也许是从前端转来的，也许是从其他的CMS转而做Drupal主题的。对于这些人来说，css是他们最熟悉，最能把握分寸的部分。基本上，只要指定好标签的style，然后创建几个模版文件，就算是做了一回主题了。或者他们是开发人员，主题和CSS只是他们顺带的工作，能做就不错了，做得很好并不是他们所追求的。
Drupal是一个CMS，它并不知道你的网页会设计成什么样子，也不知道你的网站的业务逻辑。Drupal的设计者和开发者为你提供的页面代码，是为了尽可能的灵活，让你能更容易的实现业务所需要的功能。但是，如果你的CSS技术足够过硬的话，你就可以为页面上的每一个markup写出对应的样式，并最终让页面和设计图一致。
但是这样的坏处是：
1 臃肿的CSS
2 样式和markup绑定在一起
3 可扩展性差
4 维护开销大
以上4点也许没有讲得非常清楚，但是，你可以做一个调查，有谁喜欢用drupal建设一个新网站，有谁喜欢维护一个老的Drupal站点。Drupal在主题层面到处充斥着覆写的概念，在样式表这一块也是如此，一个老的Drupal项目，如果没有合理的CSS架构，一般都意味着无尽的样式覆写以及以上四点的存在。
我们的目标：（以下见https://www.drupal.org/node/1887918(link is external)）
好的CSS架构目标和其它任何软件工程的目标都是一致的。
1 可预见的
Drupal核心和贡献模块中的css应该是始终如一的，可以被理解的。改动它们的效果应该是可以被预见的，并且不会产生副作用。
2 可重用的
CSS rules should be abstract and decoupled enough that you can build new components quickly from existing parts without having to recode patterns and problems you’ve already solved. – Philip Walton, CSS Architecture
3 可维护的
当需要为系统添加新的组件和特性时，添加、修改或者扩展现有的CSS样式应该很容易，并且不会破坏或者影响现有的样式。
4 可扩展的
CSS应该即可以很容易的被一个开发者所管理，也可以很容易的被一个分布式的团队管理。
常见的CSS误区
误区1: 根据上下文添加样式
/* Modifying a component when it’s in a sidebar. */
.sidebar .component {}
这样做看起来很正常，但实际上让你的CSS缺乏可预见性和可维护性。早晚你会发现你需要将这个组件放在别的地方，而不仅仅是放在sidebar（边栏）中。或者，反过来的情况也有可能：一个新加入的开发者将另一个组件放入到边栏中，却因为这条CSS而产生了他预计不到的效果。
误区2: 依赖HTML结构
直接根据HTML的结构去写CSS规则，使得样式结果容易被打乱（当html改变的时候）且难于重新利用（因为规则高度依赖某段特定HTML）
Overly complex selectors: nav > ul > li > a, article p:first-child
Qualified selectors: a.button, ul.nav
误区3: 太过于普通的class名称
和根据上下文添加样式的误区类似，经常有人用子组件＋父组件的方式来指定元素。
.widget {}
.widget .title {}
.widget .content {}
这种CSS规则看上去很经济，但是很可能适得其反： .title 和.content太普通了。之后，你可能会写一条单独的 .title规则，这个规则就会影响到 .widget .title {}，但是，基本上，这不是你想要的。
误区4: 规则过长
在一条规则中尝试定义过多的属性（如： positioning, margins, padding, colors, borders 和 text styles）。这样做，会使得规则很难甚至不可能被重用。特别是在之后出现的某个元素或组件也包含规则中的某些特性时。
误区5: 创建undo规则
创建undo规则，如.component-no-padding。这使得你的CSS过度复杂，难于理解和维护，而且会撑爆你的样式表。如果你觉得你需要写一个这样的规则，你应该反省一下.component规则是不是写得太长了。
ps.春节了，晴空祝愿大家新年新气象