抽象组件库的可行性讨论
首先这篇博文不是教程也不是研究技术技巧，这只是我对目前我正在着手写的一个组件库的一些想法，以及我对当前主流的这些css框架的一些看法。
当前的一些主流css框架，YUI也好，bootstraps也好，都各自有各自的优点以及缺点。这也是所有的框架都会客观存在的问题。 拿优点来说，所有的框架都能提高项目的开发效率，规范开发流程，便于维护（仅针对使用框架情况下的维护）等等。 而缺点也都很明显，使用一个框架，你必须要了解整个框架，在查看代码，阅读文档的时候，学习成本明显偏高。对于一个小项目，或者单页面较少的大项目来说，css框架的代码量非常臃肿，夸张到有时候90%的代码都会用不到。最重要的一点，太依赖框架，有时可能无法帮助你提升自己。
我个人认为，要保留框架的优点，克服一些缺点的办法，就是自己开发框架。当然并不是说自己开发框架就没有了缺点，有一些是无法规避的，无论是使用别人的框架还是开发自己的框架，都要面对代码的臃肿这个难题，但是如果自己来写，就可以很清晰的知道，自己需要什么，不要什么，把臃肿，不灵活的损失最大程度的降低。
我正在写的这个东西，我个人管他叫组件库，因为在我动手的第一天，就决定抛弃框架对页面布局的限制。只保留组件内部布局。我认为，这样可以“最大程度的放开对设计师的束缚”。
我相信跟框架打过交道的设计师都会被各种束缚弄的头疼，我也做过美工，明白这里面的痛苦。所以我写的这个库就只把所有的组件抽象出来，不干涉页面布局，随意设计师去发挥。而我们只需要把固定的组件填充到设定的容器里。
说道这里，有一些框架比如Blueprint，把布局，排版跟组件完全分离，目的之一是减少css的引用，如果只引用他的组件文件，是不是就跟我想写的组件库一样了哪？这里我就说一下我的组件库还要抛弃元素的设计样式。
那些分离出来的组件库，设计程度依然太高，如果设计师的图跟框架自带样式区别较大，就要不停的写新样式去覆盖组件库，造成代码越来越臃肿。抛弃了设计样式之后，组件只剩下了基础的布局样式，这个时候把他拿出来放到页面上，就是一个简单原始的结构，就像是一个骨架，如下图：
上面是框架里的代码表现，下面是传进去设计样式参数之后的样子。对于给结构传样式的方法我还在研究，总之不会是到茫茫的样式表里去找着修改，肯定要设计一套比较方便的传参数的方法，
比如一个按钮，会想办法留两个传参数的接口，一个是标准浏览器下传两个数值做渐变，另一个是IE9以下的浏览器传一张背景图（当然也可能完全抛弃IE9以下版本的浏览器），这样的话按钮的结构就像
- <button><span></span></button>
标准浏览器下忽略span，但是IE下用span做滑动门，或者都使用图片背景，取决于是否想使用兼容性不好的新技术。这样做的好处是，让 按钮在所有浏览器下表现一样。
再比如表单跟列表，表格，对于各种横版竖版的结构都要写好，做到增添元素不影响基础布局，在这样的前提下传进去颜色，宽高（或者适应父元素的宽）等等参数。
……….. 目前这套东西我才刚刚开始着手设计架构，无论后面能不能抽象成为一个组件库，有一点是可以肯定的，根据自己的项目高度定制，在不引用其他第三方css框架的情况下，提高自己的开发效率，并且在写这套东西的时候加深对模块化的理解。暂时就当是练手吧，多写多练，总归是没有坏处的。
慢慢添加修改和完善吧。