设计者的框架

为设计师准备的框架 by  JEFF CROFT

    现如今“框架”这个专业词在web开发领域非常流行。类似YUI、JQuery和Prototype等JS框架获得了许多关注，而Rails和Django等web开发框架的则得到了更多的青睐，似乎所有的人都在用一些框架去开发和构建他们的站点。那么到底什么是框架？它们除了对于程序员有用之外，能否能让我们web设计者也获益于此呢？

框架是什么？

至少在本文中，让我们一起给“框架”下一个定义：它包括一组基础的组件、类库以及一些公认约束定义，开发者能很容易利用它们的把抽象事务生成一般模型实例，并具有良好的复用性。它的目的在于允许设计者和开发者把焦点集中在他们所开发项目的独特性上，而不用每次都重新发明轮子（做重复开发）。总之，就是类似前文提及的那些JS和web开发框架。

这里要澄清的是，我们没有必要讨论关于一些已近建立、封装好并派发给公众的东西。相反，一个框架可能只是对于你或是你的团队来说很合适。（译者注：我认为这里Jeff是为了避免读者认为本文在讨论如何选择一个框架，毕竟现在的框架之争太多了。）

设计师的框架

有时候，对一些CSS代码的抽象会有助于你的设计。获益最多的是那些为多个具有同质性站点工作的设计者。此外，在团队里面要与其他设计人员配合工作的设计者也将从框架中获益。例如，我所在的一个报业公司，旗下二十几个站点都有许多相似之处。由于是新闻站点的简略风格，他们喜欢的是统一而不是不同。但即使是一位在项目中需要实现许多风格迥异的独立web设计者，也可能会发现一些设计适于抽象成通用的CSS框架。

最近在我为之工作的Lawrence Journal-World（http://www2.ljworld.com/），我们建立了一个CSS框架并且发现它确实是一个不错的开发利器。当然，开发这样一个框架费了不少时日，但框架一旦完成，它在页面设计实施时的速度是惊人的。而且，自从最近每一个设计师开始同一个框架之后，团队里当一个人要修改他人的设计时，他们不需要浪费20分钟来试图让对方明白为什么原本的设计是这样的？他们只需要直接修改就好了。

什么样的东西能够被抽象？

当你一头扎进准备建立一个CSS框架时，你会想要找出每个项目里那些在经常重复的设计。我们的目的是把这些东西集中集中到一个位置上，遵循DRY（Don't Repeat Yourself）的编码原则。这不仅能简化维护工作，还能够节省很多带宽。

在我为之工作的所有单独的项目里，有一点所有CSS都要申明的是：默认样式的“批量重设”。例如，把所有元素的边距和补白都设置默认为0，把所有的Framset和图片的边框都设置为无，等等。

对所有的排版都设置对齐的到一致的基准线上。这包括把类似p，header，li等块元素统一（或者部分分类）设置成站点的统一行高。

为表格设置基本样式。

设置一些常用的CSS类，比如.hide（我成设置不出现的那些东西）和.mute（我设置成小一点的类型或者有时是一些清淡的配色）。

当然还有一些更加有趣的特性。许多Web设计师发现他们自己在重复使用一些基本的结构和组件。为什么不把以一种更灵活的分类方法来重用和移植样式表以及结构。Yahoo已经做到了这个－－YUI组件（http://developer.yahoo.com/yui/grids/）。当我们在Journal-World上建立自己的CSS框架时，我们参考了Yahoo的组件。虽然我们认为它并不是我们真正想要的，但它拥有很多良好的函数例子并带给我们许多启示来构建自己的框架。我们建立在一个16种分类基础上，这已经足够灵活来让我们用它在拥有的所有站点上使用，甚至在每个站点上看起来感觉相对于相邻站点都有很大的不同。

同时许多站点共享一个通用的组件，类似下拉菜单，导航条，按钮等等。这些也同样都是可供抽象的基础组件。除了这些之外，你可能会有一些常见的内容表现用法，比如把一系列的相片用相册的形式表现出来。你可以设置一个叫做“thumbnail-list”的标准化CSS类，然后你所要做的就是添加这个类让你的相册有效。另外一种可能性就是去把各种技巧和方法（比如旧浏览器的兼容性）抽取到外部来变成扩展模块。我已经尝试过这个方法，当时发现那些高级的技巧因为太特殊了而难以抽取出来形成框架。也许你比我有更好的解决方法。

实际应用中的好处？

拥有这样一个框架的真正美丽之处在于你能够快速启动。你能够新建一个（X）HTML文档，其中包括你的框架，并且已经预先设置好了默认的补白和边距、合适的排版、清爽的表格、清晰的分层以及一些工作构件等等。

但显而易见的是，你希望为每个站点定制独特的外观并创造不同的感觉。为了实现这一点，所有你需要做的是按照需求重写默认样式和添加样式。例如，如果你的框架为所有的标记了“tabs”的ul设置为基础样式的的水平导航栏，它们是灰底黑边的，你能很容易地通过很少几行代码把它们设置成你自己独特的设计。

ul.tabs li {

  border: none;

  background-image: url('/images/tabs/ »

site-specific-tab-look.jpg');

}  

所有包括浮动的li条目到左边、添加内部链接、显示为块元素并居中文字等操作都已经由框架来为你完成了。你只要关注那些在你站点上有趣的特性就好了，而不用再重复写那些你以前已经重复了百万次的CSS代码了。

如何建立CSS框架？

有许多可行的关于建立框架的方法，当时最常见和公认最有用的方法是把你常用CSS

样式分条成组抽象归类，让每一条都分别包括一个方面或者是一个部分的样式。

例如，你可以有一条样式专门设置字体排版同时另外一条样式是专门管理批量设置。这种处理方法的妙处在于能分拣出你需要的样式。你可以写上六、七种不同的样式在你的框架里面，但是当一个特定的项目不需要其中的一两种的时候，你不需要把它们加载到样式表中。我们团队建立的框架有五种不同的样式：

reset.css－－处理样式批量设置。

type.css－－处理字体排版样式等。

grid.css－－处理网格布局样式。

widgets.css－－处理类似tabs、下拉菜单、“越多更多”按钮等小组件的样式。

base.css－－包括所有其他的延时，所以我们的（X）HTML只需要调用base.css即可使用整个框架。然后我们把这个框架存储在一个独立的位置，并让许多站点从那里调用。当然每个站点都有一些特有的样式表来按需重写和添加框架理的默认样式。

一些忠告

这个方法使用的很好，但同时也有一个需要提及的影响：这增加了加载页面所需的HTTP连接数。在大型高流量的站点，每个页面的浏览增加五个HTTP连接数可能会导致系统资源紧张。对于此有两种解决方法：

不把文件拆散成多个模块单独加载，而是在一个文件里面加载所有的东西。这种方法的问题在于你失去了只加载部分框架内容的能力，并增加了维护的难度。

1、在服务器端进程中动态平滑地让多个分开的文件变成一个响应。我没有看到过这样的实现，但是如果能够实现将是非常有效。以我以上的框架为例，这样的动态进程可以设置成在仅在base.css需要时被触发，而type.css,grids.css等被请求时却不这样被触发。这样的方式能够保证部件分组，同时整个框架也能够保证以一种平滑的方式加载。

2、最后，需要牢牢记住重要的一点是，我们的目标并不是为了得到你朋友的赞赏而尽可能的抽象所有的事情。换句话说就是，我们的目的是为了让你有一个快速的开始并让你的设计进程更加有效率。这是绝对有可能做过头的事。如果你过分提炼抽象，事情往往变得让人迷惑，并且你会因为使用了太多的HTTP请求而让你的站点表现大打折扣。记住：一个好的框架必须永远不要把事情搞复杂或者是难懂，越简单和简洁越好。

   结论

底线是我们Web设计者就像我们在程序世界里面的朋友一样，经常重复我们自己。我们发现自己在重复设置默认浏览样式表，设置一个布局基线，为了导航条目一次又一次的写css－－几乎在所有的项目中。花点时间去抽象总结一些常用的惯例变成一个框架，让你能够在每个你建立的站点上面使用，并让你快速开始开发，让你的维护更加简单易行，同时帮助团队里其他设计者理解你的决定。只要你能小心一点，你就能够避免通胀和影响站点的性能表现而享受上述的框架带来的妙处。何乐而不为呢？