设计师的框架(翻译)

第一速度 楼主

闲来无事，从www.alistapart.com翻译了一篇文章，发出来与大家分享，翻译水平有限，还请见谅！

设计师的框架

by Jeff Croft

翻译：qing

原文地址：http://www.alistapart.com/articles/frameworksfordesigners

近来，在Web开发中”框架”是一个相当时髦的词。比如JavaScript 框架 YUI、 JQuery和Prototype 都引起广泛的关注， Web应用框架Rails and Dojo 更是引人瞩目，仿佛所有人都使用某种框架来开发自己的网站。但究竟什么是框架?是不是框架仅仅是对程序员有用，设计师是否可以从中收益？

什么是框架?

为了便于沟通，我们给“框架”统一一个定义（至少在本篇文章中是统一的）：一套包含工具、函数库、约定，以及尝试从常用任务中抽象出可以复用的通用模块，目标是使设计师和开发人员把重点放在任务项目所特有的方面，避免重复开发。通常的讲，框架就是上面提到的JavaScript框架和Web应用框架。

需要强调说明的是，我们不必讨论构造、打包发布，相反，一个框架只为你或你的团队使用即可。

CSS框架

有些时候，你可能尝到了抽象类似的CSS代码的甜头，在那些同时设计几个类似网站的设计师身上表现最为明显。此外，团队中的设计师们从框架的方法上有很多的获益。比如，我在一家报馆工作，所有的20多个网站保持着很多的共同点，基于新闻网站的特点，它们趋向于更加相似，而不是差异。但是，即使单独一个设计师，设计一个从表面上看有差异很大的项目，也可以为CSS框架抽象出一些通用的小碎片。

劳伦斯日报（Lawrence Journal-World），我在那里工作，我们最近建立了一个CSS框架，并发现它是一个巨大的效率倍增。当然，我们花了数天时间自己创建了一个CSS框架，但一旦框架完工，开发高质量网页的速度是极快的。更何况，既然团队每一个设计师现在都使用这个框架，当一个设计师修改另一个团队成员网页时，他们不再需要花20分钟理解别人的构建思路，可以马上上手。

有那些可以忽略?

当投入到一个整体性很强的CSS框架，你想寻找的东西，是每个项目都做了一遍又一遍的重复通用的代码，目标是巩固这些代码核心地位，遵循“不重复自己（Don’t Repeat Yourself）”编码方法。这使得维护工作容易了许多，还可以帮访问者节省带宽开销。

几乎每个我参与的项目中，我必须声明的几个CSS问题：

    * “大量重置”浏览器默认风格，比如，设置所有元素的margin和padding为0，去掉框架（framesets）和图片（images）的border，等等。
    * 以基线对齐。这包括诸如设定块级元素的margins相同的(或多个)基准行高，如段落（paragraph）、头（header）、以及列表（list）。
    * 创建表单（Form）的基本样式。
    * 创建几个常用的CSS 类，例如，.hide(把display置为none，即隐藏元素)、.mute(设定为一个较小的字体和较亮的颜色)。

还有更有趣的事情，许多网站设计师发现自己不断重复使用着相同的基本结构，为什么不动它整理成自己的，在某种程度上可以非常灵活的用于多个网站?Yahoo这样做了，这就是YUI。当我们为的劳伦斯日报网站（the Journal-World）建立CSS框架的时候，我先看看Yahoo是怎么做的。我们很肯定那不是我们想要的，但作为一个很好的例子，给我们提供了很多思考和如何建构自己框架的想法。我们解决了16个布局模块，它具有足够的灵活性使我们的每一个网站都可以应用，即使每个网站看上去与下一个版本有些差异。另外大多数网站共用 widgets ，象下拉菜单、导航菜单、按钮等，这些也是主要的需要抽象提取的对象。除此之外,你可能有共同的内容名称，如图片列表的缩略图，你可以规范对CSS命名，如“thumbnail-list”，让所有显示缩略图的都使用这个CSS类。

另外要做的可能是抽取hack（如兼容那些旧浏览器)加入自己的扩展的样式模块。我自己尝试过，但发现hack过于专有而不能抽取到通用框架里。

什么是真正的益处?

框架的真正好处是能够快速启动工作，你可以创建一个新的(X)HMTL文件，引入你框架，你不用再处理重置padding 和 margins的事情，漂亮的排版，干净的表单，整齐的布局，有效的widgets，等等。很明显，很明显，虽然，你一定要来定制外观和感觉为每个站点。为实现这一目标,所有你需要做的是复写,并添加到默认的风格是必要的。

很显然，尽管你必须为每个网站定制外观，为了完成这一任务，你所需要做的就是在默认的样式上加几行代码。举个例子，如果在你的框架里，为所有的 class属性为“tabs”的UL标签设置了基本的水平导航样式，并且有一个灰色的边框，你只需要几行CSS代码，就可以定制成你的网站所符合的外观样式。

ul.tabs li {

border: none;

background-image: url(’/images/tabs/ ?site-specific-tab-look.jpg’);

}

列表左浮动，并且将链接以块的形式置于列表当中，链接也左浮动，字体居中，象烦人的广告一样的这些工作，框架以帮你完成，在你的网站设计工作中，只需集中精力处理特别的、有趣的网站细节，而不是写已经写过百万次的CSS代码。

如何构建一个CSS框架?

构建一个框架有几种可能的方式，但最常见，可以说是最有用的，抽象通用的CSS放到一个独立样式表文件，该样式表文件只包含整体的一个特有部分。例如,你可以，一个样式处理排版，另一个处理大量重置。这种好的方法能使你选择性引入你需要的样式，在你框架里可能有六七个不同的样式文件，但不需要其中的一两个，只要不引入即可。我们团队创建的框架包含5个样式文件：

    * reset.css —处理重置
    * type.css —处理排版
    * grid.css —处理布局
    * widgets.css —处理小零件（widgets），如tab菜单、下拉菜单、以及“更多”按钮
    * base.css —包含所有的其他样式表文件，以便我们只需要在(X)HTML引用base.css即可使用整个CSS框架

然后，我们把框架存放在一个单独的地方，使每一个站点都引入这个框架。当然，每一个网站也需要有特有样式表，特有样式对框架进行了必要的补充。

忠告

这种方法不错,但也带来新的问题：增加了每一个页面的http链接数。对于大流量和中等流量的网站，每个页面增加5个以上HTTP连接数，系统管理员可能就麻烦大了。两个可能解决办法：

   1. 把所有样式都放到一个文件里，而不是分成多个模块。这里的问题是，失去了框架只包含特定文件的灵活性，而且维护也变得麻烦。
   2. 有一个服务器端程序,动态把多个单个文件处理成一个响应。我还没看到这种做法，但如果做好了应该是很有效率的。以我上面框架为例，当请求（Request）base.css时候，而不是请求（Request）type.css , grids.css 等的时候，这一动态处理过程触发。这样一来,单个文件仍然可用，而在平台版本上整个框架也有效的。

总之，我们目标不是尽可能的抽象，这点非常重要。相反,其目标是提供了一个快速启动和更有效率的设计过程，这是绝对有可能去做过的。如果你过于的抽象，事情会变得混乱，太多的HTTP链接数会影响你网站的性能。记住：一个好的框架不是把事情搞更难更复杂，而是一个简单的从零的开始。

总结

我们web设计师往往经常重复自己，就像我程序世界里的那些朋友，我们重置浏览器默认样式、设计布局和导航菜单写了一遍又一遍——几乎每个项目。花一点时间整理CSS 框架，可以使你快速的启动每一个网站项目，更轻松的维护网站，并帮助团队里其他的设计师理解你作品。要注意的一点，这些益处的获得必须以不影响网站的性能为前提。

第一速度 楼主

Frameworks for Designers
by Jeff Croft


These days, “framework” is quite a buzzword in web development. With JavaScript frameworks like the Yahoo User Interface library, jQuery, and Prototype getting a lot of attention and web application frameworks like Rails and Django getting even more, it seems like everyone is using some kind of framework to build their sites. But what exactly is a framework? And are they only useful to programmers, or can we web designers benefit from the concept, as well?
What is a framework?

So that we’re all on the same page, let’s agree—at least for the duration of this article—on this definition of “framework”: a set of tools, libraries, conventions, and best practices that attempt to abstract routine tasks into generic modules that can be reused. The goal here is to allow the designer or developer to focus on tasks that are unique to a given project, rather than reinventing the wheel each time around. Generally speaking, this is the approach taken by the aforementioned JavaScript and web application frameworks.

To be clear, we’re not necessarily talking about something that is built, packaged, and released to the public. Rather, a framework may be solely for you or your team.
A framework for designers

Chances are, you can benefit from a similar abstraction of CSS code for your web design process. Those who can benefit most are designers who work on several sites of a similar nature. Additionally, designers working on a team with other designers have a lot to gain from a framework approach. For example, I work for a newspaper company, and all of the 20+ sites in our stable have a lot in common. Simply by virtue of being news sites, they tend to be more similar than they are different. But, even a solo web designer who works on projects which are all quite different on the surface can probably find pieces that are suitable for abstraction into a general-purpose CSS framework.

At the Lawrence Journal-World, where I work, we’ve recently built a CSS framework and found it to be a huge efficiency booster. Sure, it took us a few days to create the framework itself, but once that was done, the speed at which we can put together quality page designs is tremendous. What’s more, since every designer on the team is now using the same framework, when one goes to make edits to another team member’s work, they don’t have to spend 20 minutes trying to understand why things were built the way they were. They can just dive right in.
What sorts of things can be abstracted?

When you jump into putting together a CSS framework, you’ll want to look for things that you tend to do over and over again on every project. The goal is to consolidate these things into one central location, following the Don’t Repeat Yourself (DRY) coding methodology. This makes maintenance a lot easier, and can also save on bandwidth costs.

A few things I account for in the CSS of almost every single project I work on are:

    * A “mass reset” of default browser styles. For example, setting margin and padding to 0 on all elements, turning off borders on framesets and images, etc.
    * Aligning the type to a consistent baseline. This includes things like setting the margins on block level elements like paragraphs, headers, and lists to the same value as (or some multiple of) the base line-height setting for the site.
    * Creating basic styles for forms.
    * Creating a few CSS classes I always use, such as .hide (where I set the display value to none) and .mute (which I set to a smaller type size and sometimes a lighter color).

There are more interesting possibilities, too. Many web designers find themselves using the same basic grid structure over and over again. Why not move it into its own stylesheet and structure it in a way that is flexible enough to be used on multiple sites? Yahoo has done this, with their YUI grids component. When we built our CSS framework at the Journal-World, we looked at Yahoo’s implementation first. We decided it wasn’t quite what we wanted, but it served as a nice functional example and gave us lots of ideas on how to construct our own. We settled on a 16-unit grid, which is flexible enough that we should be able to use it on every one of our properties’ sites, even though every site looks and feels quite a bit different from the next.

Also, most sites share common widgets, like drop-down menus, navigation tabs, buttons, etc. These are prime candidates for abstraction, as well. Beyond that, you may have common content display idioms, such as a list of photos that appear as thumbnails. You could standardize on a CSS class name like “thumbnail-list,” so that all you need to do is add that class to get your thumbnails working.

Another possibility is to extract hacks and workarounds (such as those that accommodate older browsers) into their own external stylesheet modules. I’ve tried this myself, but found that ultimately hacks and workarounds tend to be too site-specific to pull out into a generic framework. But your mileage may vary.
What’s the real world benefit?

The real beauty of having a framework like this is getting off to a fast start. You can create a new (X)HMTL document, include your framework, and be off to the races with reset padding and margins, good typography, clean forms, a layout grid, working widgets, and more.

Obviously, though, you’ll want to customize the look and feel for each site. To accomplish this, all you’ll need to do is overwrite and add to the default styles as necessary. For example, if your framework sets up basic-looking horizontal navigation tabs for any ul with the class “tabs,” and they are grey with a black border, you can easily customize them to match the look and feel of your site with just a few lines (Line wraps marked ? —Ed.):

ul.tabs li {
  border: none;
  background-image: url('/images/tabs/ ?
site-specific-tab-look.jpg');
}  

All the work of floating the list items the to the left and making the links inside them display as blocks (also floated to the left) with the text centered in the middle—ad nauseam—has already been done for you. You are left to focus on what is unique and interesting about the specific site you’re working on, rather than writing the same CSS you’ve written a million times before.
How should a CSS framework be built?

There are several possible ways to go about building a framework, but the most common and arguably the most useful is to abstract your common CSS into individual stylesheets that each cover a particular part of the whole. For example, you may have a stylesheet that sets up the typography and another that handles the mass reset. The beauty of the approach is the ability to selectively include only the styles that you need. You may end up with six or seven different stylesheets in your framework, but if a particular project doesn’t need one or two of them, they don’t have to be included. The framework we created in our office has five stylesheets:

    * reset.css—handles the mass reset.
    * type.css—handles the typography.
    * grid.css—handles the layout grid.
    * widgets.css—handles widgets like tabs, drop-down menus, and “read more” buttons.
    * base.css—includes all the other stylesheets, so that we only need to call base.css from our (X)HTML documents to use the entire framework.

We then store the framework in a single location and have every site pull it in from there. Then, of course, there are also site-specific stylesheets for each site which overwrite and add to the framework’s default as necessary.
A word of caution

This method works quite well, but there is a valid concern to be raised: it adds to the number of HTTP connections needed to render each page. On large, high-traffic sites, adding five more HTTP connections to every page view may result in angry system administrators. Two possible solutions to this are:

   1. Include everything in a single file, rather than breaking it into modules. The problem here is that you lose the ability to include only certain parts of the framework, and you also make maintenance more difficult.
   2. Have a server-side process that dynamically flattens the individual files into a single response. I’ve not seen this done, but it could be very efficient if done well. Using my example framework above, this dynamic process could occur when base.css is requested, but not when type.css, grids.css, etc. are. This way, the individual components are still available, but the entire framework is available in a flattened version, as well.

In the end, it’s important to keep in mind that the goal isn’t making things as abstract as possible so that you can impress your friends. Rather, the goal is to get you off to a fast start and make your design process more efficient. It is definitely possible to over do it. If you abstract too much, things start to get confusing, and you end up hurting your website’s performance with too many HTTP requests.

Remember: a good framework should never make things harder or more complex than simply starting from scratch.
In conclusion

The bottom line is that we web designers, just like our friends in the programming world, tend to repeat ourselves often. We find ourselves resetting the browser default styles, setting up a baseline grid and writing CSS for navigation tabs over and over again—on almost every project. Taking a bit of time out to abstract some of these idioms into a framework that you can utilize on every site you build will get you off to a faster start, make for easier maintenance, and help the other designers on your team understand the decisions you made. With a bit of care, these benefits can be realized without adding bloat or hurting the performance of a website.

miqi2214

这就是涉及到CSS代码的可复用性的问题，最近我也在琢磨这个事情，高效的CSS开发是个问题，关注相关文章，顶上去

cssxp

个人认为开发速度和效率摆在第一位了。重构的时候再去维护。至少现在中小公司的网站都是给个页面限制多少时间内完成，或者一天完成多少个页面……

[ 本帖最后由 cssxp 于 2007-7-20 22:53 编辑 ]

261509559

有过这个想法,找个时间整理出来

第一速度 楼主

这种方法不错,但也带来新的问题：增加了每一个页面的http链接数。对于大流量和中等流量的网站，每个页面增加5个以上HTTP连接数，系统管理员可能就麻烦大了。两个可能解决办法：

   1. 把所有样式都放到一个文件里，而不是分成多个模块。这里的问题是，失去了框架只包含特定文件的灵活性，而且维护也变得麻烦。
   2. 有一个服务器端程序,动态把多个单个文件处理成一个响应。我还没看到这种做法，但如果做好了应该是很有效率的。以我上面框架为例，当请求（Request）base.css时候，而不是请求（Request）type.css , grids.css 等的时候，这一动态处理过程触发。这样一来,单个文件仍然可用，而在平台版本上整个框架也有效的。

针对这种问题，我有一个解决办法是：
css文件文件分为开发版本和发布版本，开发版本：适合开发过程中使用，方便灵活，发布版本：在最终发布时，把css文件按一定规则进行整理，主要考虑访问效率等问题，可以减少文件数目，压缩css大小等。
开发版本转到发布版本，要有明确的规则，建议尽量简单明了。
当然，这个方法如果有一个小工具，就像java一样，发布前编译一下，那个强人是不是开发一个dw插件，或者dw来增加这个功能最好了

[ 本帖最后由 第一速度 于 2007-7-21 12:42 编辑 ]

Mooodern

我们重置浏览器默认样式、设计布局和导航菜单写了一遍又一遍——几乎每个项目

效率啊……确实值得关注

greengnn

性能第一位
开发效率第二位

我的开发的目的是为了提高网页开打的性能，你如果告诉你的老板，我这么做开发效率有多高多高，就等着老板开除你吧

dearmonkey

不错，很多时候并发的问题，和框架分开css文件的问题是不好协调的。

dearmonkey

真正的开发，还用用户第一，速度上不去，其它的也没用。

majer

很好，看了受益了。dreamonkey说的很好，良好的用户体验是web开发的基本点。

第一速度 楼主

用户体验深入人心了！

第一速度 楼主

用户体验深入人心了！

gandie

很有用的东东哦

261509559

原帖由 greengnn 于 2007-7-22 16:03 发表
性能第一位
开发效率第二位

我的开发的目的是为了提高网页开打的性能，你如果告诉你的老板，我这么做开发效率有多高多高，就等着老板开除你吧

言之有理,性能是最核心的保障

huayun321

貌似最近这类问题很热哦

holyli

dreamonkey说的很好，良好的用户体验是web开发的基本点。
开发效率也很重要.
1来节省开发时间,减轻工作强度,2来也不变对付万变

benboba

不变永远都不可能应万变。
不然我们也不必告别table布局时代了。

gway

我想每个设计师都有搜集一下框架的代码吧，比如滑动门
这些都可以重复利用的
如果所有设计师都把自己搜集的框架都共享出来，我想其价值一定非常大

zym500

翻译的不错！
鼓励！！！

oivp

除了设计师要清晰的知道，我想更主要是boss以及我们的团队成员都了解这样做的意义！

TBlack

有没有写好的css框架?

xd888

性能第一位
开发效率第二位

同意！

greengnn

   1. 把所有样式都放到一个文件里，而不是分成多个模块。这里的问题是，失去了框架只包含特定文件的灵活性，而且维护也变得麻烦。
   2. 有一个服务器端程序,动态把多个单个文件处理成一个响应。我还没看到这种做法，但如果做好了应该是很有效率的。以我上面框架为例，当请求（Request）base.css时候，而不是请求（Request）type.css , grids.css 等的时候，这一动态处理过程触发。这样一来,单个文件仍然可用，而在平台版本上整个框架也有效的。

对于减少请求数和容易维护，可以有两个开发环境，一个是开发环境，一个是预发布环境。

开发环境下，把你的样式分成页面专属和公用两个部分，公用的样式import你的这些个库文件，等到发布的时候，人工或者使用工具合并成为一个大的文件。

zbm2001z

似乎在javaeye上看过，可能是引用了原文的部分思想

也相信很多的前端架构设计师都在身体力行着……

css框架重在归类，和语义化的文档是一脉相承的，适用于数据化结构和功能模块的敏捷开发。

但是小心！web世界如此丰富多彩，不要让css框架束缚了你的视觉想象。