本文档包含了Isobar公司的创意技术部（前端工程）开发web应用的规范。现在我们把它开放给任何希望了解我们迭代过程最佳实践的人。
编写本文档的主要驱动力是两方面：1)代码一致性以及2)最佳实践。通过保持代码风格和传统的一致性，我们可以减少遗留系统维护的负担，并降低未来系统崩溃的风险。而通过遵照最佳实践，我们能确保优化的页面加载、性能以及可维护的代码。
对于所有编程语言，我们要求缩进必须是软tab（用空格字符）。在你的文本编辑器里敲Tab应该等于4个空格。
对于维护现有文件，我们认为可读性比节省文件大小更重要。大量空白和适当的ASCII艺术都是受鼓励的。任何开发者都不必故意去压缩HTML或CSS，也不必把Javascript代码最小化得面目全非。
我们会在服务器端或build过程中自动最小化并gzip压缩所有的静态客户端文件，例如CSS和JS。
任何网页的首要组件就是基于标签的HTML标记语言。超文本标记语言(HTML)曾有一段不堪回首的历史，但最近几年已经是皇上回宫了。经过对它基于XML的XHTML变种的漫长试验之后，整个行业终于接受了HTML代表web的未来这一事实。
在合适的时候，我们会使用HTML5Doctype和HTML5特性。
标记中必须总是使用合适的Doctype来指示浏览器触发标准模式.永远要避免Quirks模式。
所有标记必须通过UTF-8编码传递，因为这种编码方式是对国际化最友好的。必须在HTTP的header和HTML文档的head部分都指定这种编码。
设定字符编码是通过标签进行。
如果是HTML5，则只需要写：
下面是编写HTML标记的总体原则。提醒大家一点，在创建的HTML文档里总是要使用能够代表内容语义的标记。
在HTML5规范里并没有严格要求属性值两边加引号。但考虑到一些属性可以接受空白值，为了保持一致性，我们要求所有属性值必须加上引号。
网页的第二个组件就是在层叠样式表（CSS）中包含的表现信息。Web浏览器成功实现CSS后，整整一代web开发者对他们网站的外观和体验拥有了全部的控制权。
深入学习和理解CSS及基于浏览器的盒子模型，对于掌握CSS布局的基础是非常必要的。
作为提高的要求，关联或孩子样式要增加2-4个空格的缩进。这样有利于分层查看和组织，产生（对某些人来说）可读性更好的样式表。
另外，在给一个样式指定多个选择器的时候，把每个选择器单独放一行是个好主意。这样可以避免一行变得太长，也能提高可读性及版本控制流程。
在多个开发者协作环境下，避免用单行CSS格式，因为这样会给版本控制带来问题。
对于所用的样式只出现一次的元素，给它设一个id属性。这个属性只会应用于该元素，不会用到其他地方。Class属性则可以用到多个具有相同样式属性的元素上。具有相同外观和表现的元素可以具有相同的class名。
无论是ID还是class，对任何东西最好总是根据它是什么而不是它看上去是什么样子来命名。比如一个页面上的特别提示的class名是bigBlueText（大蓝字），可它的样式早就被改成红色小字体，这个名字就没意义了。使用更聪明的惯例如noteText（提示文字）就好多了，因为即使视觉样式改变了，它也还是管用的。
ID选择器比属性选择器明确度高，class选择器比任何数量的元素选择器明确度高。尽量使用ID选择器来提高明确度。有时候我们可能会想方设法给一个元素应用一条CSS规则，但用尽方法也不能如愿。这种情况有可能是因为我们使用的选择器比另外一个的明确度低，所以明确度高的另一个选择器里的属性就比我们想应用的选择器优先了。这种情况在更大或更复杂的样式表里更为常见。在小一些的项目里，通常这不是大问题。
明确度的计算方式是对你的CSS的各种组件计数，并用(a,b,c,d)格式表达出来。
不过，也许使用现成的明确度计算器更好一些。
使用!important会覆盖掉所有的明确度，不管它有多高。因此我们倾向于避免使用它。大部分时候是没必要用它的。即使你需要覆盖某个你访问不到的样式表里的选择器，往往也会有其他的办法去覆盖。尽可能避免使用它。
我们使用px作为定义fontsize的度量单位，因为它能提供对文本的绝对控制。我们知道为字体大小使用em单位一度很流行，这样可以解决IE6无法改变基于像素的文本大小的问题。不过，现在所有的主流浏览器（包括IE7和IE8）都支持基于像素单位的文本大小和/或整页缩放。既然IE6被广泛认为已废弃，用像素定义文本尺寸更好。另外，无单位的line-height也应该优先考虑，因为它不会从父元素继承一个百分比值，而是基于font-size的一个乘数。
一般情况下要优先使用CSS速记格式，一是因为它的简洁，二是用它也可以扩充已有的值，例如margin和padding的情况。开发者必须注意TRBL缩写，它表示元素的各边按顺时针方向定义的顺序：上、右、下、左。如果bottom没有定义，它就会从top继承值。同理，如果left未定义，它从right继承值。如果只有top的值有定义，所有的边都会继承那一个值。
下面是关于减少样式表代码冗余和使用CSS速记格式的更多内容：
JavaScript是网页的第三个主要部件。在网页上适当地应用JavaScript代码，通过绑定事件和控制整体行为层，能够增强整体的用户和基于浏览器的体验。
总的来说，使用留空应该遵循源远流长的英语阅读惯例。例如，每个逗号和冒号（以及适用的分号）后面要空一格，但在括号内部的左侧和右侧都不要加空格。另外，大括号应该总是和他们前面的参数出现在同一行。
来看看下面的JavaScriptfor循环的例子…
从H5BP开始我们看到了两个文件，plugins.js和script.js。本节概述这两个文件的基本用法。
Plugins.js的用处是存放网站的所有插件代码。相比链接到很多不同的文件，我们可以把插件代码统一放到这个文件里，从而改善性能。这种用法会有也应该有例外。例如，一个超级大的插件，又只是用在一个很少被访问到的页面上，放在单独的一个下载链接里就会更好，这样只会在目标页面被打开的时候才会被访问。不过，大部分情况下，直接把所有插件的最小化版本粘贴到这里以便访问是靠谱的。
下面就是一个样例文件，包括一个小目录。它可以作为所用到插件的随身指南，包括文档URL，使用它们的思路，诸如此类。
在分配低调（unobtrusive）的事件监听器时，通常可接受的做法是把事件监听器直接分派给那些会触发某个结果动作的元素。不过，偶尔也会有多个元素同时符合触发条件，给每个元素都分配事件监听器可能会对性能有负面影响。这种情况下，你就应该改用事件代理了。
即使采用了最好的校验器，浏览器的怪异性也会不可避免地产生一些问题。有几个堪称无价之宝的工具可以帮助优化代码的健全性和加载速度。很重要的一点是，你手头准备好了这些工具，不管你主要用来开发的浏览器是哪个。我们推荐先在Firefox和Safari上做开发，然后用GoogleChrome和Opera，最后针对IE用条件判断做一些额外的微调。下面列出的是一些有帮助的调试器和速度分析器：
—本公司开发的接口必须符合第一优先级指南。
在生产环境传输CSS和Javascript，必须采用很多优化措施：
在页面加载的时候，通常会有很多脚本等待执行，但你可以设定优先级。下面的顺序就是基于用户反馈设定的优先级：
CSS精灵（Sprites）基本上就是把一批图片资源合并成单个图片文件。然后每个部分用CSSbackground-position来展现。典型的CSS看起来是这样的
接力sprites实现:hover悬停效果是很普遍的。这种情况下你会看到类似于这样的定义：
你应该会用到四种主要的图片格式，细节如下：
不过，对于足够多的资源（特别是图片），请求数的增加足以让页面加载变慢。很多浏览器对于他们从每个域能并发下载的资源数有比较低的限制。（在IE6和IE7，这个数字仅仅是2）。在这种情况下，我们可以把资源存放在多个子域，例如：
我们推荐在页面加载完成（DOMready事件或window的load事件）之后，再用Javascript把OmnitureJavascript代码加入DOM中。通过使用这个技术，可以避免外部域脚本的依赖性，这种依赖性会减慢（并可能挂起）页面加载过程。
在所有情况下，Flash的位置必须有备选的HTML内容，以使SEO值最大化。对于XML驱动的Flash，备选HTML内容必须利用同一个XML文件，以确保数据的一致性。
所有替换内容必须使用SWFObject，但不应加入内联脚本标签。SWFObject的初始化必须在DOMReady事件后触发。最小的播放器版本必须设置为最小v9，以确保AS3兼容性。
谈到浏览器体验，有两个主要的事实：
那么，基于这两条人生真谛，我们需要通过什么样的步骤让大家满意呢？
这些指标必须针对你的客户和项目来定制，在线框图布局阶段之前完成。这些目标从技术角度必须是合理的，也是可测试的。
可能适用的一些目标
如果客户对于意向设计有比合理目标更激进的目标，就必须在整个项目决策委员会中统一期望值，并让项目组了解性能指标是最关键的。
内部
在IA、IxD和视觉设计阶段，前端工程师是负责沟通性能对于交互特性的影响或在目标浏览器上采用特定的视觉技术的角色。要给出设计师的限制条件：“如果我们使用Cufon，每个页面上用到定制字体的元素就不能超过10个。”
外部
需要设定期望值：并不是所有的浏览器都有相同的体验。它们的表现不会彼此相同，指望它们的特性完全一样也不现实。在IE7的体验中放弃一些新的特性也许是合理的。会考虑被放弃的一些特性可能是：阴影、过渡、圆角、透明度、渐变色。
当沟通某件事的影响时
测试用的工具
如果性能指标没有达到，有三个选择：
今天的用户可以从相当大的范围中选择web浏览器，每种浏览器都提供了略微（或相当）不同的体验。作为开发者，我们的责任恰恰是选择我们创建的网页展示给用户的方式。本节描述我们是如何做出这当中的一些决定的。
我们会努力支持任何客户指定的其他任务关键浏览器(IE5.5,Opera,Konqueror,Safari3onPC,等等)，虽然我们不能保证所有功能都可能实现。
全面的浏览器测试对于每个web项目都是必须的。必须付出大量精力进行跨浏览器和平台测试，以确保质量和一致的用户体验。配置测试环境会是一项挑战，却是值得去做的。
GoogleChrome会自动更新，正常情况下绝大部分用户都会有最新版本。要是每种浏览器都这样多好啊。对于GoogleChrome就不需要担心旧版本的问题了。
对于核心的MacOSX浏览器，MozillaFirefox,GoogleChrome和AppleSafari提供的浏览体验基本和它们的Windows版本一样。尽管如此，某些操作系统级的差异还是会出现，网站必须在两个平台上进行测试。典型的差异是关于字体渲染，所以有时候会冒出间距问题。
其他选择包括在MacOSX内部虚拟化Windows，让你可以在MacOS内部运行Windows。
注意：IE6standalone版在某些情况下对透明度的实现是有bug的。这会导致任何应用于CSS过滤器的透明度（例如alpha透明度或者24位PNG）失效。在这种情况下必须测试透明度，你会需要本地安装的IE6。
除了适应各种浏览器，开发者还必须持续注意用户的屏幕分辨率。随着显示器屏幕越来越大，分辨率的广度也随之增加。下面是关于分辨率的一些工作准则。
1024px分辨率
关于窗口大小的当前统计
不过，系统分辨率和浏览器尺寸并不是一样的
良好的web设计和开发的一个重要部分就是SEO。要想确保一个网页不仅能让搜索引擎合适地索引到，而且能让那些只有有限的web能力的人访问到，结构良好的代码是其中的关键。
你必须使用语义化的标记，在关闭Javascript和CSS之后它仍然是可读和逻辑的。所有页面内容必须是HTML形式；我们不希望使用iframe或Javascript来加载初始的可索引内容。
这样既能被搜索引擎正确索引，也能让用户在新窗口或新标签中打开链接。
每个页面的title标签应该突出目标关键字。每个页面的title应该是独特的。标题（h1,h2,等等）应该构成文档的轮廓并代表该页面最重要的关键字。URL应该是人类可读的，其中包含主要的目标关键字：
访问他们的站点时，诸如修复404错误和无效链接、简化URL选项、提供易于理解的标题以及页面摘录等简单的步骤，其实对用户和搜索引擎都是有利的。
为啥俺要参加代码审查涅？
经常地，接口开发者被要求根据线框图或视觉构图编写标记。不过，有可能设计的屏幕不能轻易转换为标记，或者转换后质量有损失。代码审查为在页面投入生产之前发现并解决这些风险提供了一个机会。
代码审查能够提升跨项目的整体知识水平
代码审查能在bug从一些模板繁衍到多个页面之前就封杀它们
理想情况下，代码审查是在开发过程的早期进行的，早于页面开始全面投入生产。当模板被团队审查并在多个校验工具和浏览器运行，潜在的bug就会冒出来。这是修复bug的理想时机。
代码审查给不熟悉项目的外部成员提供了发现代码中问题的机会
哪些人应该参加代码审查？
归根到底，项目的前端工程主管要负责确保代码审查遵循合适的流程。
理想情况下，一位部门主管应该作为代码审查的主持人，除非部门主管自己正好是被审查代码的接口开发者。在这种情况下，由一位项目经理进行主持。
审查小组应该包括至少两位来自接口技术团队精通开发和最佳实践的资深成员。
代码审查中有哪些要求？
在进行代码审查之前，需要审查的模板必须整体完成开发、经过校验、并针对项目需要用到的浏览器和平台进行了测试。
部门主管和/或接口开发者必须在代码审查前至少48小时分发以下材料：
在代码审查过程中，一位部门主管和/或接口开发者应该主持会议，而部门主管或项目经理做记录并分配行动事项。审查者应该在事前审阅过代码并准备好提问或提供反馈意见。
记录和行动事项（包括负责人）应该在代码审查后分发给所有参与者。如果代码审查产生了本质性的变更，或没有完成对所有代码的审查，就有必要安排第二次代码审查。不过，这必须在项目组内讨论以确定其可行性。
（【译者注】下面的内容以链接为主，是一些辅助性的材料，这次就不翻译了。如有不理解的内容，可与本人联系。）
Agreatcodeeditorcansparkproductivityinexceptionalways.Manydeveloperspreferrudimentarytexteditors,otherspreferpowerfulintegradeddevelopmentenvironments(IDEs).Whatfollowsisagenerallistingofsomeofthemorewell-knowntools,itwouldbeimpossibletolistthemall.
CompanionJS,DebugBar,IE8Devtools.
2014Isobar,Allrightsreserved.AllcontentlicensedunderCreativeCommonsAttribution3.0UnportedLicense