所以以下讨论结果都是大家的成果,我只是表达出来,外加自己一些小小想法.

a) 样式的分层管理 
i. 公共规则层 reset base layout-rules …
ii. 公共模块层 header footer …
iii. 项目模块层 频道、店铺、检索… 
iv. 项目文件夹尽量平级，不要多层嵌套
b) 样式的书写 
i. 编码 utf-8避免中文字符造成样式读取问题
ii. 注释 统一
iii. 模块区分，避免代码耦合增加维护难度 
c）CSS代码压缩

样式的分层管理

对于这一问题,大家都赞同”全局-项目公用-页面私有”这三个级别的样式分层.其中reset.css统一了元素默认样式及浏览器之间默认样式的差别,目前网上流行几种reset.css,但并不一定是原封不动的拿来用到自己的项目或网站上就可以了,可以根据自己的需求做些调整.base.css是用于存放网站全局的一些元素的样式,比如button,table,title….当然layout-rules.css是存放网站主要排版样式的文件.

如果是一个很小的个人网站,完全可以将所有样式合在一起,这样服务器请求次数可以减少,将来自己管理升级也十分方便.

但是对于一定规模的大型网站,特别是多人合作的网站,还是要合理分配样式文件,减小耦合,降低文件内容的关联度.不能动一处毁全局.当然具体到颗粒多小还是要根据每个网站情况,以及网站开发方式有关,有些网站的mockup不是一次出来的,很多样式是不可预见到底是否公用的时候,样式文件的分配就比较难做到合理了.这方面我还没有想到什么好的办法解决…

有的同学提出一些不经常变动的样式比如header,footer,nav等样式也可以单独提出来.

也有同学提到了css frame.当然这种框架是为样式管理做出了很好的榜样,一些想法很值得我们学习,但是其中一些class的命名却是以表现来命名的,而不是根据数据内容性质来命名的,这有悖于Web标准的核心理念.另外因为css frame是为了适用于大多数网站,其中肯定会有一些你用不到的样式,结果就是带来好多冗余的代码.所以我个人的观点是以学习为主,尽量不要使用css框架.

还有一些网站有换肤的需求,或者有布局自定义的需求.这时就要考虑将layout,color单独提出来作为一个样式文件了.

对于项目文件夹的放置,理想的情况是根据网站结构走,页面也如此,样式也如此.这样是比较合理的也比较清晰的.

样式的书写

样式的书写我想先说一点自己的习惯,我喜欢一行到底,前面的classname要用tab进阶式的,这样一个模块一个模块看起来非常方便,再加上后面属性有一些指定的排列顺序.hzhjun同学举了一个很形象的例子.他说假如现在桌子上有一台电视机,那么你首先看到的是电视机的大小(width,height),然后是它放在了一张桌子上(position),接着再仔细看这台电视机的具体属性(color,font,…)最后是一些不常用的属性(z-index…).也许这套顺序并不是最科学的,但我觉得一个团队至少要规定一套类似这样的规则,不然一行样式写下来,前面已经写过的样式会很容易被后面的样式覆盖,产生不必要的调试成本.

对于utf-8这个问题,虽然张丽同学给出了补充,但因为公司是做英文网站,所以没有涉及到这类问题,不太了解,因此这里不方便总结了…

关于注释,首先我得承认这方面我做得特别不好,基本上没写过注释.小组成员倒是说了一些他们的注释习惯.比如文件开头会写一些注释,比如这个样式文件是针对哪些模块或页面的,开发者是谁,最后一次修改是什么,有哪些注意事项.然后 每段代码后面如果有相应的bug修改也会注释一下,方便团队成员参考注意等等.

对于模块区分,我觉得这个问题嘛应该不是到了这里才开始考虑的,首先合理的html结构是基石,然后是正确的有语义的class/id命名,接下来再合理地区分模块才会变得更容易.当然原则就是提纲中提到有要避免代码耦合增加维护难度.

最后是CSS代码压缩:

我说说公司的作法吧,开发阶段,我不用担心css的文件个数会产生过多的http request. 因为后台程序会在网站发布之前用一个写好的函数将css文件合并成一个css文件并加个版本号,在这之前还会用一些工具将文件中的空格,缩进以及注释去掉.这些做完之后服务器端的Gzip设置会大大减小文件大小,一般会减小75%左右.

以上是第二主题的交流成果总结~~嘿嘿.明天继续最后一部分素材合理化