先列一下会议的主题，由于时间的关系没有讨论完，感觉很遗憾。
一、 结构合理化
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
一、结构合理化
DTD声明是给浏览器看的，可以让浏览器知道这个页面代码是哪个年代的写法，以便作出合理的解析。与会的朋友都认同同一个团队DTD声明要统一，但至于选择哪种类型的声明，会因某些历史原因、团队整体技术水平原因或者其他别的方面的原因而不同，甚至有些老旧的项目没有DTD声明。
W3C验证是检验我们代码标准化程度的工具。因为是工具所以在我们项目的进行中不一定是必须的。有朋友还提到，前端提交的静态页面是可以通过W3C验证的，但是交付后台嵌套程序后，绝大多数情况下又通不验证，所以完美的页面需要后端同学对W3C的标准也比较上心才行，而这个比较困难。结论是W3C验证是自己对自己严格的要求，对html和css各版本之间差异的理解，正确合理的标签嵌套，避免不小心犯下的书写错误，可以让自己的代码更健壮与优雅。
html标记语义化的讨论有些小小争论。不太认同这个观点主要是因为现阶段看不到特别出彩的好处，有同学说到现在的搜索引擎不一定对特有语义化的标记有特别的处理方式，爬虫抓取的只是文字与图片等实质内容，搜索引擎是不是真的认为h1标签的权重比h2标签大？语义化标记并非固定不变的，由于规则的变化，一些标记今天是推荐标准，明天或许就被舍弃。甚至选择合适的语义化的标记在开发过程中费掉了不少时间。持比较赞同观点的朋友认为标记语义化有更好的未来发展前景，提到不同的终端如盲人阅读器，家用电器接入互联网等等，有些特殊情况下浏览器对css文件解析出现问题，有语义化的标记依然能够让页面层次分明。
（会后我仔细考虑一下两方的观点，说一说我的理解：搜索引擎对语义化标记解释的不一致也许正说明了我们前端工程师对语义化标记的使用混乱。天然的即使我们对有语义的标记感到选择困难，也不会喜欢只用一个标记来完成所有的代码工具，想一想如果整个页面只有div一种标记虽然也能很好的完成工作，但这绝不是我们想要的，我们会根据自己的理解用到我们所认为符合语义的标记。随着互联网的发展，基于未来网络的各种终端设备会层出不穷，如果有一套大家都遵循的语义化标签，那么我们的工作量肯定会大大减少，因为至少不用考虑我们这套代码是工作在“IE”上还是“火狐”上。）
与会的朋友谈到微格式和RDFa都说不太了解，说实话我是第一次听到这些知识，为了避免理解上的偏差就不介绍了。
class和id命名规则，有些人习惯纯英文来命名，有些人习惯拼音首字母，有些人习惯拼音加下划线（或者间隔线），有些人习惯驼峰格式（第一个单词首字母小写，从第二个单词开始每个单词的首字母大写，如“className”）。至于具体哪种方式更好一些，没有具体结论。有些习惯的改变成本也是挺大的，只能建议大家按照根据团队的规则来做，这里大概可以叫做到建立“一致性”，与人方便自己方便嘛！
SEO大概可以算是上面的一个综合，因为完美的SEO方案并不是项目完成后再实施的，它要渗透到项目进展的个个方面，甚至视觉设计师也要参与进来。而关于外链方面的话题没有在此次交流会讨论。
二、样式合理化
对于小站来说一个样式文件就能满足需求，对于大的项目大家都比较认同三层机制：reset及layout、公共模块、频道具体应用。 对于共用样式在以后的特殊化问题，与会者有人表示对于极个别的特别不靠谱的需求可以打回，或者大范围的讨论是否真的有改动的必要。如果真的不能避免，我个人觉得可以讨论出调整公共模板的整体样式还是只在修改的地方按照css优先级的原则打个补丁。
编码的问题和DTD声明的问题差不多，新制作的页面大家都倾向于使用utf-8。
大家认为要有必要的注释，更多的考虑在维护方面。如果是utf-8编码那中文注释会增加字节，但这个是可以容忍的。代码压缩后，增加的字节数可以忽略。对于大型的站点，我们这组讨论的是喜欢两套代码，一套用于维护修改，一套用于站点，就是说写好代码后压缩上传，需要的修改的时候，修改未压缩的版本，改好后压缩上传。有的服务器支持自动压缩，上传一个未压缩的版本，服务器会自动压缩。如果有了比较深度的压缩，那么对于样式写法的具体细节，就不必那么太在意，有的人习惯每个样式占一行，有的人习惯每个class里的所有样式共占一行。
三、素材合理化
首先亮出了一个观点，图片的压缩是无止境的。这话当然有点狂妄，但要认识到fireworks对png的压缩要比photoshop更优化，而还有其他的工具可以对压缩后的图片进行更深度的压缩。根据算法的不同，将来我们也许能找到更好的压缩工具。
大家现在都比较认同png-8和jpg两种格式，之前在谷歌中国召开的第一届webrebuild北京年会，腾讯的彪叔说他们现在更多也是用这两种格式，有动画效果的才用到gif。png-24的兼容性有问题，全透明png-8的表现是很好的，而半透明gif的表现同样不好。涉及半透明的渐变叠加绚丽效果还是要拼合成jpg整图，甚至会用到flash实现渐变叠加效果。
大家还说了下自己公司或者自己对图片字节的要求，我记不清都是哪些公司，只好说有的要求是30K，有的是60K，而刚才看greengnn的博客他的底线是100K。这个还是看各公司具体更注重那方面吧。
我们组一位来自新浪乐居的朋友提出用SVN的方法来进行图片管理的观点很新颖。由于时间的关系不能更好的讨论感到很遗憾。
css sprites在第二届交流会上已经讨论过，大家有兴趣的看去w3ctech主页看看。
—————————————————-
最后要说的话，此次交流会是同百度UXday联合举办，谢谢盒子咖啡的美味糕点和优秀服务生。还要谢谢前两届提供场地的身边网，你们对前端工程师的重视，假以时日必将收到丰厚的回报。