设计师的框架(Frameworks for Designers)
时间：2008-01-19 来源：mymoodle
近来，在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.
什么是框架?
为了便于沟通，我们给“框架”统一一个定义（至少在本篇文章中是统一的）：一套包含工具、函数库、约定，以及尝试从常用任务中抽象出可以复用的通用模块，目标是使设计师和开发人员把重点放在任务项目所特有的方面，避免重复开发。通常的讲，框架就是上面提到的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.
相关阅读 更多 +
