I'm Donkey » 页面重构合理化

页面重构合理化讨论(中)

Ting — Wed, 30 Dec 2009 04:07:21 +0000

上回书说到结构合理化,介回呢接着总结交流会成果之:样式合理化.因为交流会采用的分小组讨论,然后指定一位小组成员记录讨论内容,待各组讨论完毕后代表本组总结发言.本人不幸”手欠”拿过纸和笔,所以顺利成为这一话题的小组代言人~呵呵

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

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%左右.

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

页面重构合理化讨论(上)

Ting — Tue, 29 Dec 2009 10:06:33 +0000

认识建斌,裕波他们其实也算是件巧事儿,就是随便在BI里逛,看到一个”Web标准化交流会”的报名帖. 首先这个有”国际”范儿,但又不张扬的名字就吸引了我.来北京工作两年多,一直苦于没有与同行交流的机会.所以渴望能找到一个让我进步,学习跟”发泄”的组织~ 通过几次接触,我确定我找到了.哈哈

先说说这个”组织”吧,很简单,就是一帮对于”在国内高度普及Web标准应用范围”这一理想十分迫切的热血青年. 呵呵开得调儿调儿有点高.不过也不为过.大的方向是这样的.那么眼前的呢,就是希望通过交流能提高参加者的技术水平,从而提高整个Web前端开发人员的技术水平,最终让我们这些处境尴尬的”美工”,”Cutter”能受到公司的重视,行业的尊重及更好的工作机会跟实现自我价值的机会!

第一次参加,虽然大家都是第一次见面,但是讨论得特别热烈,让我想继续参加第二次.虽然第二次的讨论气氛不如第一次好,却让我认识到了这帮特别靠谱的人.我希望加入他们,能为这个交流会做些什么.哈哈,还没等我开口,组织的头儿就”相”上我了~~从此光荣地加入了这个组织~成为一名工作人员~~

最近开通了自己的博客,记录自己的学习过程,梳理两年来的知识. 借着交流会,阶段性的总结一下交流的成果分享给大家.慢慢认识到”分享”的重要性.

前两次的总结基本上也可以在这次讨论中有所体现,所以都整一起算了,可能会很长.我慢慢写,大家慢慢看哈

讨论的主题是:页面重构合理化讨论
具体话题是:

一、结构合理化
a) 统一的DTD声明 html4.01 xhtml1.0 html5
b) 通过W3C验证
c) 语义化的html 标记应用
d) 语义扩展 microformats或RDFa
e) Class id命名规则一致性,借鉴html5新标记名称和microformats。
f) SEO
二、样式合理化
a) 样式的分层管理
i. 公共规则层 reset base layout-rules …
ii. 公共模块层 header footer …
iii. 项目模块层频道、店铺、检索…
iv. 项目文件夹尽量平级，不要多层嵌套
b) 样式的书写
i. 编码 utf-8避免中文字符造成样式读取问题
ii. 注释统一
iii. 模块区分，避免代码耦合增加维护难度
c）CSS代码压缩
三、素材合理化
a) 图片类型合理应用 jpg png-32 png-8 gif
b) 图片字节
c) 图片管理
e) css sprites
f) 图片缓存
四、Javascript AJAX DOM
a) 如何创建自己的js库或js框架,选择JS库或框架
b) JS的管理
c) JS的性能

备选议题[如果会议时间还有富余可以讨论]

一、HTML5+CSS3
a) 如何使用html5
b) 如何使用CSS3

一、结构合理化

Web标准最被大家熟知的理念就是:结构合理化,标签语义化.虽说Web标准是个标准,但目前都是以一些”推荐”为主.更别说合理语义化了,这个词听起来就很”因人而异”的感觉.其实我个人觉得,一个页面结构是否合理很大程度上依赖于你对于这份从Marketing那边过来的需求文档理解得是否深刻,如果他们的需要明确,将网站网页需要表达的东西合理的展示给你,再加上你对文档的充分理解,想要将一个页面很有”语义”地”讲”给浏览器并让它也明白,让搜索引擎也明白并不是一件很难的事情.

统一的DTD声明 html4.01 xhtml1.0 html5
DTD(Document Type Definition) :文档类型声明.这个东西必须要在重构页面前统一声明好.因为它是告诉用户使用的各种浏览器按照什么方式去渲染页面的一系列语法规则文档.如果没有声明,浏览器就会用其它不理想的方式解释你的代码,到时候就会出现许多问题.
讨论过程中,大家都对于统一声明DTD这一点毋庸置疑.但什么情况下用什么样的类型呢?大多数同学都使用Xhtml1.0 的Transitional类型.
由于本人之前对这块具体分类比较混乱,所以在此查些资料,把结构理理清楚:
HTML4.01 :
Strict:
Transitional: Transitional//EN” “http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd“>
Frameset:
XHTML1.0:
Strict:
Transitional: “>
Frameset:
XHTML1.1

HTML5

通过W3C验证
讨论过程中,大家提到W3C验证到底有什么意义,难道通过了验证,你的网站就标准了?用户体验就最好了?对搜索引擎也友好了?不一定,通过验证,只能帮助你检查出一些语法错误,不符合规则的嵌套,我们不能将通过验证做为网站重构的最终目的,它只能是做为帮助我们检查代码的工具,算是推广Web标准过程中种小小的”手段”吧.不知道这么说是否合适.
语义化的html 标记应用
前面就提到了,语义化这个东西操作起来很难做到理想,首先HTML能提供给我们的有语义的标签就不多,再加上每个人对于数据,内容含义的理解也不同.所以想让浏览器,以及各个手持设备和其它终端准确地读出内容就更有一定难度了.也这是Web标准需要推广的主要意图.现在阶段我觉得我们能做的有下面几点:
1)良好的与产品团队及设计师沟通,充分理解网站内容
2)正确使用W3C推荐的合法标签以及嵌套规则
3)与前端开发团队制定好开发文档,统一模块代码及class/id命名,命名时要使用非表现形式的命名方式,要告诉机器这是什么数据,而不是告诉机器这是长成什么样的数据(因为后者是CSS的事情).
4)多学习借鉴HTML5的新标签定义方式,以及目前业内公认的大的模块的代码结构及命名方式.
语义扩展 microformats或RDFa
对于microformats我了解得不多,整体上感觉就像是用HTML写XML,只注重数据的内容与结构.具体应用上还需要进一步学习,学习之后会补上相应的文章,与大家分享
Class id命名规则一致性,借鉴html5新标记名称和microformats。
这个问题上面也提到了,问了几个大公司的同学,开发项目之前肯定是会统一UI模块代码,定义class/id命名规则.在class命名上大家都比较喜欢像Javascript函数变量声明那样,开关单词小写后面单词首字母大写,其它小写的方式.能用英文单词尽量用英文.另外还提出了有些公司不允许前端HTML/CSS开发人员使用id,是为了避免与前端脚本开发人员的命名冲突.但是我觉得一些大的唯一的模块的id命名还是应该交给html/css开发人员的,就像一位同学说的,id不只属于脚本开发人员,它是整个前端的东西.当然为了项目的方便管理,这点是可以理解的.
SEO
其实将以上几点做好,再加上注意一些图片描述,命名,关键字等等问题,前端人员对于seo方面的优化基本就是可以了.