会议主题：W3C CEO与工程师面对面
会议日期：5月9日(周日)下午1点开始
会议地点：北航会议中心
预定人数：50人
参与费用：不收取任何费用
主办方：W3C中国，Web标准化交流会

W3C CEO Dr. Jeff Jaffe 5月来北京, Web标准化交流会努力争取到了这次难得的机会,邀请到Dr. Jeff Jaffe与工程师一起探讨Web前端的发展和与之相关的各类问题.希望大家积极报名.相信一定会收获不小~

在前天最新一期的web标准化交流会上,许多朋友都表述了自己关于前端开发在研发流程中与其他岗位协作效率的提升这一问题的看法,同时也有后台的同学到场一起参加大家的讨论,为了web开发这个小社会的和谐做一些贡献.

很感谢由腾讯公司提供场地,让热情参与讨论交流的50位同学(北京地区实际报名141人)可以在一个宽松舒适的环境下畅谈自己的想法.也非常喜欢Winter同学对于前端与其它职位微妙关系做出的分析与分享.其中有两点让我印象很深刻:一个是不同职位之间的分歧误会有一些是因为专业技能上的距离,另一个是各个职位之间在合作时产生的灰色地带.具体解释参看以下记录:

分享主题:Web开发中角色与协作(PPT)

重点内容:问题到底出在哪里?首先开发团队不能决定开发什么,是由客户决定的,还要有后台工程师的业务逻辑,再加上设计师的视觉美化,最后是前端工程师的前台实现.那么这么多角色之间是如何协作的呢?通常前端对后台有抱怨,对于设计师出来的效果图也觉得难以实现,除此之外还要应对客户随时提出来的新需求….

前端人员与其它职位之间的”距离”产生了抱怨与不和谐.也有很多公司前端与设计是同一人,或者后台来负责HTML,JS.更有一些小作坊式的公司是通通由一个人来负责建站.由于各位职位不能十分了解其它职位的工作方式或者具体的职业技能,因此产生的”距离”.所以适当的沟通与学习了解来缩短彼此之间的这种”距离”是有效愉快合作的关键之一.

再有一点就是”灰色地带”, 所谓灰色地地带是指那些谁做都可以的地方最容易产生问题.虽然大家的意识中的具体的工作范围,但一遇到实际问题谁来解决就取决于个人职业技能了.比如一个button的各种状态如果设计师没有在给你设计稿之前没有交待清楚的话,你有能力就要自己写全这几种状态.像这种模糊点需要去清晰化,大家的合作才能顺畅.有很多时候”同时负责==同时不负责”,工作中文档化的约定非常重要,工具的检测永远比人工要准确可靠得多.

再提”依赖关系”,一个项目的周期是取决于关键路径.”规范”并不只适用于那些大型的项目.解耦过程(略)

环场讨论

环场讨论时月影表述了一下自己的观点也让大家十分受用:再次强调灰色地带.百度的前端人员在一个项目开发过程中大概有50%以上的时间在与RD,PM,UE一起做调整,在match的过程中做smarty模板联调.这样可以保证与RD协同开发,并行,解耦,高效.当然每个公司协作方式不同,与项目特点及工作人员的技术水平有很大关系.

再有一个问题是到底一个项目开发时的规范与交流是如何来的?在百度,这个规范与流程不是由项目经理,团队leader决定的,是由下而上推动的,因为只有最前线的开发人员才是离产品最近的人,是他们共同协商的结果.遇到问题的时候可以参看文档,但是也不能完全按照文档操作.在百度通常新入职的同学是不会马上参加具体项目的开发的,比这更关键的是学习事情是如何做的.一个团队中合作,沟通感情是很重要的,个人经验吃饭是有效手段之一,沟通的关键是同理心,要站在对方的角度考虑问题.这里举一个简单的例子,假设现在桌子上有两个纸杯,分别装着一些水,如何让这两个纸杯里的水完全一样?有的人说完全倒掉就一样了…其实很简单,先将杯子里的水全部倒掉,然后将两个杯子套在一起,然后再往里面仪倒水,这样里面的杯子有多少水,那么套在外面的杯子也有同样多的水了.这里面要说明的问题是,两个起初装着不一样多的水的杯子代表不同职位上有着不同程度职业技能的团队成员,如何让大家有效的沟通,站在同一角度看问题呢?就是先完全抛开自己已有的想法跟观点,然后与其它职位上的同学同站在一个角度(两个杯子套在一起)再来讨论共同面对的项目或者问题(装上水),这样大家就可以更好的沟通,高效地解决遇到的问题.

以上是月影同学表述的观点.

个人观点

我没有参与过特别大型的团队开发项目,与一起合作的其它职位上的同学之间的关系也相对比较简单.合作起来也非常融洽.但我仍然期待自己可以有机会在一个大型项目中锻炼自己各方面的能力.针对这次交流会的讨论主题我想说的是首先一名合格的前端开发人员要先做好自己,要明确自己的工作职责.更要很好的规范自己,先想想自己是否真的把自己的工作先做到位了.这样就不会出现一些后台的朋友抱怨你的代码没有缩进,页面不兼容主流浏览器,代码繁琐,请求数目过多,图片过大等等问题了,而对于设计师的设计稿你又是否真正认真的去实现了呢?有没有偷懒的心理?正如会上”麦霸”同学说的:”到目前为止没有设计稿是绝对实现不了的,没有一个交互体验是实现不了的.所以没有那么绝对的事情!”从你自身就在先减少这些不必要的抱怨.

现在越来越强调”大前端”这个概念. 先将自己的眼光放宽,努力提高自己的职业技能与素质再主动去了解其它职位的知识,缩短”距离”才是一个有效沟通的必要前提.

再有一点就是目前我们面临的大环境.国内的开发环境一直是比国外落后,没有很规范的,在一个不成熟,不规范,很大程序上需要依赖等待国外的开发人员开拓新技术我们才能慢慢学过来的现状,再加之前端是一个最几年来刚刚开始受到重视的职业,我们怎么能一下子做到顺畅专业高效的团队合作呢?这需要大家的共同努力去营造这样一个理想或者说更专业的开发环境.那么所谓的规范才会离我们更近,我们才能更加清楚的认识到每个职位在开发中应该发挥的作用以及更高效的合作方式与开发流程.从而进入一个良性循环.这才是web开发中的”和谐”社会.

==================并不华丽的分隔线===================

之间克军在博客中发出的一道前端题目现在也可以公布答案了

题目:

有这么一段HTML，请挑毛病：

<P>&nbsp;&nbsp;哥写的不是HTML，是寂寞。<br><br>&nbsp;&nbsp;我说：<br>不要迷恋哥，哥只是一个传说

这是原来雅虎一道笔试题（文字变了变），用了很多年了，还没有一个人完全答对过。

答案在此,各位同学思考后再仔细查看吧 :p

嘉宾:张克军/月影/赵立元/管凌峰

讨论主题:页面重构合理化讨论后续

Javascript AJAX DOM

• 如何创建自己的js库或js框架,选择JS库或框架
• JS的管理
• JS的性能

HTML5+CSS3应用的时机

• 现阶段是否考虑应用HTML5和CSS3部分特性
• 如何应用HTML5
• 如何应用CSS3

具体会议记录如下:

(主):首先向大家说下针对此次会议场地的注意事项(略).Web标准化交流会办到现在已经是第四期了,今天从农历来说是2009年的最后一期,但从阳历来讲是2010年的第一期.代表交流会欢迎新老同学.首先感谢新浪为我们提供这么好的会议场地. 今天北京,上海,广州都同步进行交流会(主题同步).下面进入主要环节.先是环场介绍,请到场的嘉宾自我介绍下…(略)

(主):现在进行本期主题讨论:

Javascript AJAX DOM

先请嘉宾对此主题进行一些分享.然后可以由每位嘉宾带领一部分支持自己观点的同学进行分组讨论

(月影):对于团队开发所使用的JS类库,我个人比较喜欢jQuery.脚本的管理要根据项目需求与类型来,比如轻量级的项目,就更注重函数依赖等方面的研究,粒度可能会细化到一个function.然后再找到依赖的类.但如果是重量级的就会更加注重多人协作,基础类库和代码缓存等方面,不会特别在意依赖,而是会在意包的管理与代码的冲突.总之结论是:根据应用选择适合的框架

喜欢jQuery的原因是简单.YUI在大的项目应用上比jQuery出色.目前在自己负责的项目中使用的脚本库会分为3层.以后有机会会将相关经验跟代码分享给大家.

(主):谢谢月影的分享,下面请克军分享下这方面的丰富经验,因为克军曾经在Yahoo做过很长时间.对于YUI应该更加了解.

(克军):Yahoo的开发方式是讲究团队合作,非常强调代码结构的一致性与模块的管理. 做的都是整体性很强的东西.注重文档化.但是缺点是不够灵活.YUI在前端开发的理念问题上也有一些变化.05年之后都是库的概念,共同功能的集合.YUI3出来后,变化为不是功能的聚焦而是注重模块的组织,依赖的管理的系统.思想更倾向于团队协作与可维护性.当然每个人的代码风格不同,但Yahoo会限制个人风格,为了让开发人员的风格尽可能的统一,”限制”是必须要有的,但是要有一定的灵活性.库与框架是两个级别的东西.做前端框架 的人要考虑库与框架的结构.

豆瓣的JS目前是不提供业务层的,有核心库可灵活的加各种库,目前使用的jQuery.关键是在核心的基础上如何组织.之前我们总在讨论JS库,其实不用过多的考虑,做为第三方它们在功能方面已经很成熟了.就拿网易的JS来说.它分大块的和inline两种.所以代码的管理就显得特别重要.个人主张统一风格,对开发有利.jQuery与YUI其实没有太大可比性.jQuery最新版本的变化很大,已经60多K.作者也在考虑它的结构.不过目前这种大小还是可以接受的.

(主):谢谢克军,下面请新浪产品负责人赵立元进行分享

(赵立元):我想先了解下在座各位目前哪些朋友在工作中经常使用JS或者框架(人数不多).我来介绍下新浪的方法吧.不讲技术上的细节.新浪有自己的开发JS库.新浪目前有13个产品,代码的可维护性是个很大的难题,新人在接手项目的时候也非常吃力.所以想统一.当时参照了几个开发框架，其中包括了YUI2.如果使用自己开发的类库一是灵活度高二是风险低.自己做框架可与底层更好的结合,升级可以自动化,有问题可以rollback. 之前我们有开发文档,但是效果不好,后来我们就改为在代码里写注释,然后通过工具把注释提取出来方便多人协作.关于JS性能方面参考Yahoo的优化条例其中的几条就差不多可以了.

(主):因为大多数朋友对于这个话题本身还没有过多过深的研究,所以现在我们就抓紧这个难得的机会可以就这个话题向各位嘉宾提问.

以下是截取的部分提问回答记录

Q:如何区分一个方法是核心级的还是应用级的?

A(张克军):核心层解决的是创建标准化的浏览层,API的风格不一样.应用级的是与产品业务如Movie,Music相关的是应用级.如果与UE实际结合得密切的话,如果注意体验的话会更多的关注这些统一UE的库,那么也算应用层.所以分下来就是核心/全站/产品三个级别.

Q:依赖的概念是什么?

A(月影):如果你是要包括所有基本库的话没问题.但是有时是会为了一个简单的功能而去加载大库,非常不合算.就是一种很极端的情况,访问量非常大但是功能却非常简单,比如它只用到了这个库里10个方法中的两个.依赖管理就是开发的时候加载整个库,但是产品在上线的时候却只加载真正用到的那2个方法.

Q:网站的脚本是否都进行压缩?

A:是的.产品差异大.这是由应用特征决定的.基础类库会拆分为基础与产品两种,然后定规范.

Q:前端的HTML,CSS也要压缩么?

A:是的,工具就使用YUI提供的压缩工具就行.

Q:网站公用的header里会加载多个JS.但是页面里却只用到其中一点,这时候要怎么处理?

A(张克军):对于这种情况下后端的处理方法很简单就是都引入都加载.但是如果当我们有一套依赖管理系统就可以解决.产品上线的时候自动找方法所依赖的东西.

今天先总结到这里,其实讨论到这里大家还对于前端工程师的价值,理想等问题发表了各自的一些见解,非常热烈,也相当精彩.我会在最后做简单总结.

三、 素材合理化
a) 图片类型合理应用 jpg png-32 png-8 gif
b) 图片字节 
c) 图片管理 
e) css sprites
f) 图片缓存

其实那天因为要赶着回天津,所以并没有一直等到交流会结束.很遗憾…不过好在最后因为场地时间问题,我只错过了这一小节的讨论,呵呵.

我就简单说说自己的想法吧,最后会放上参与讨论的同学的总结(算偷懒不?嘿嘿)

图片类型合理应用 jpg png-32 png-8 gif

平时我经常用gif跟jpg,png-8基本上没用过,也是参加了交流会之后听这么多同学推荐才知道png-8的使用如此广泛,还是自己平时关注得少,学习得少啊.刚在twitter上看到了kejun提到了http://www.olegkikin.com/png_optimizers/ 有时间仔细学习下,然后实践实践. 做了一段时间网站才慢慢发现图片处理如此重要.原则真的是:压缩无极限!恩!

图片字节

不知道这小节是不是要讨论图片大小的控制要在什么范围呢?我平时尽量是将大图控制在不超过60k.

图片管理

这部分因为公司网站基本上是自己一个人在做,所以对于这些前端的东西自主性比较大,更新也不麻烦.但我也是一直头疼于图片的文件夹管理,到底如果分才会更合理呢?像CSS那样根据网站结构分好像也不太ok…

css sprites

这个话题说大不大,说小也不小.是第二次Web标准交流会的主题.讨论了两个小时左右,结论也没有特别明确.虽然大家对这个技术不陌生,也很认同.但是如何合并,什么时候要合并,合并成什么样.有更新或改动时要怎么办.对于单独图片的管理又如何处理等等没有一个相对统一的结论.

但讨论的过程中到是有几个问题是我之前不曾注意的.如果空白问题,按颜色合并,反对角排列,图片合并/导出工具的使用等等.

个人觉得CSS Sprites好处多多 但是管理更新实在是个问题…

图片缓存

公司网站图片上线没有版本号,更新的时候通常是重新命名,上传一个新文件.因为服务器端设置了过期时间,浏览器端会有缓存.同时也有会Gzip的设置.另外还有一个图片服务器.

以后就是对于这一小节的简单总结,相比之前两节有些简单.一是因为有些话题有些大,或者说实践性强些,目前没有一个特别统一的结论.日后会针对其中的一些小细节再做研究.

呵呵,就到这里吧.下期交流会会继续讨论js框架和html5/CSS3的一些相关话题.希望在这些方面有想法,想交流的同学积极报名参加.真的可以学到不少东西!

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

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

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

先说说这个”组织”吧,很简单,就是一帮对于”在国内高度普及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: <!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01//EN” “http://www.w3.org/TR/html4/strict.dtd”>
  Transitional:  <!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN” “http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd“>
  Frameset: <!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Frameset//EN” “http://www.w3.org/TR/1999/REC-html401-19991224/frameset.dtd”>
  XHTML1.0:
  Strict: <!DOCTYPE HTML PUBLIC “-//W3C//DTD XHTML 1.0//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
  Transitional:  <!DOCTYPE HTML PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd“>
  Frameset: <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Frameset//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd”>
  XHTML1.1
  <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.1//EN” “http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd”>
  HTML5
  <!DOCTYPE html>

• 通过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方面的优化基本就是可以了.