Progressive Enhancement（下文称为PE），渐进式增强是现在Web Development中一个很流行的开发思想，目的是在以内容为核心的同时，可以渐进地提升体验，为用户提供更好的服务，随之而来的好处是，其网站或者web程序的最核心内容并没有改变，用户接受到的信息是完整的，而且能达到浏览器兼容的目的，这里提到的兼容并不是说网站的体验必须是一样的，这里的兼容指的是提供给用户的内容和功能是完整的，甚至在不兼容CSS和JS的浏览器上内容和功能也是完好的。

这里是两个比较好的了解PE的资源，《Understanding Progressive Enhancement》和Nicholas Zakas: Progressive Enhancement 2.0（需要翻墙）。

最能体现PE思想的还是这个图：

说到这可能有人会问，为什么体验不一样也算兼容呢？那么我会反问你，谁说的一定要在每个浏览器上一模一样才算是兼容呢？我们的目标是尽可能的保持一样的体验。

以内容为核心，在保证内容的基础上，添加样式添加行为是最基础的开发思路，在其之上还会有更多的样式+行为添加上，增强开关是我用来控制增强的一种方式，我利用它可以控制应该针对那些浏览器或者哪些内容进行增强。对于PE，我有这样的思考。

现在的PE模型已经变成了这个样子了：

├─Level 4 ─ ...
├─Level 3 ─ JavaScript
├─Level 2 ─ CSS
├─Level 1 ─ JavaScript + CSS
└─ Basic  ─ Content

首先，所有问题的解决需要建立在持续性的沟通和改进上。

问题1：对于网站来说是谁来决定核心内容文字可能来自于BA和产品经理，进一步想，那么一个web程序，带有更强用户交互的网站功能的核心内容是什么呢？，比如UX会给于最终的界面效果，往往会是一个CSS+JS的混合体，而被掩盖的最基本的功能应该是我们思考的。

这是每一个UI开发都考虑的问题，我们开发一个功能是以功能效果作为导向呢还是以内容作为导向，如果是前者那么往往会忽略基本的HTML文档结构，语义，虽然效果是完成了，但是可扩展性变差了，当遇到体验变化时，需要推到从来，整个功能失效直到你的新体验完成，浏览器兼容性会变得很麻烦，因为有可能要hack很多浏览器已保证体验一样。而后者就不一样，在考虑内容的同时，HTML文档的结构简单，语义健全，而且还能保证基础功能是具备的，满足各种浏览器的基础功能，兼容性也是随之而来的，不必特意去考虑跨平台，因为出发点已经跨平台了，但是开发者首次需要做更多的effort不但要保持原有功能前后台功能，也要保证增强后的前后台功能以及增强的开关控制。

我们往往都会选择后者，什么是一个功能的核心内容，比如一个查询功能来说，不论其最终效果有多么绚丽多彩，那么开发者应该保持一个纯净的心灵，把它归结为一次form的get请求，查询的选项需要根据具体的查询内容而定具有语义的标签，比如是文字那么就选择input，甚至还可以选择type是search的input，如果是二者选择一那么选择下拉框select或者radio，如果是开关那么可以选择checkbox，这些都是最基本的元素，form提交那么可以选择submit按钮，而且能自动带上回车提交的功能。在最基础的get请求完成之后，再来考虑加上样式，我们的输入是否需要autocomplete，checkbox需不需要做成iphone样式等等才是正确的道路。

问题2：随着渐进增强的开发，体验甚至会形成一个从下到上的链式结构，那么如果最底层的内容改变的时候应该怎么处理建立在其上的所有增强呢？

当最初的基础内容改变的时候，怎么处理之后的所有增强呢，我想说这种情况是比较糟糕的一种，有点像需求改变了的重构。我还在寻找这个问题的答案，我能想到的是应该加强对每个增强的条件，每个增强的位置和条件，如果能知道这两个点，这个问题也迎刃而解，而且还能很好的控制增强的开关。除了这点，还需要加强对增强的Testing，因为Testing是保证重构的基本要素，也是程序功能质量的见证。最近遇到一个内容改变的需求，需求很简单，就是在新的页面显示中不需要看到没页面的title了，它是一个h2标签。我看到这个需求时候第一个想要问的这个title是不是核心内容一部分，我觉得是，但是需求是需要看不到它，我只好隐藏它，但是又没有新的体验去替代或者增强它，那它还属于核心内容的一部分么，我应该问谁，问BA和产品经理，他们要的是最终效果，就是看不到，我说可以让阅读器看到所以应该把它隐藏，和同事的讨论中，他们觉得既然没有替代品的话，说明已经不属于核心内容一部分了。最终，我很是纠结，不情愿的直接删除了。看到这个问题，我觉得我才刚上路呢，理解PE才是皮毛。

问题3：在增强过程中，选择适合的增强方式也是一个问题

选择适合的增强方式，我的原则是优先用CSS解决这个问题，然后在考虑JS解决，但是有趣的是，这里有了动态添加具有更多功能的CSS和JS的问题，针对不同的增强开关动态的加载样式和行为，而且要保证相互不影响，对于动态加载JS可以考虑使用AMD加载。另外，增强往往隐藏一些之前有的view，所以隐藏应该属于增强的一部分，在移除增强后原有view应该显示。动态加载js行为可能会引入更多的view，这些新的界面会有新的css，首先所有东西都应该是动态加载上的，然后view的DOM结构可以使用现在有的模板技术来处理，如果是简单的dom结构的话，也可以用DOM API生成。像jQuery UI/jQuery Mobile就是这样做的。

问题4：由于功能是渐进增强上去的，那么Testing需要cover的点就会变多，被增强的部分可能增强后功能是好的但不见得增强之前的功能也是好的，即使增强前的版本没有人用到。这些多余的effort是值得做的么？

这个问题可以分两个部分，一个是我们发现PE对我们用处不大，反而带来了更多的effort，还值得不值得这么做，我的答案是应该要这么做，PE的好处不是局部的，而是随着项目的变大，长时间的坚持才能看到的，它在跨平台上给我们带来的好处是显而易见的，因为我们没有那么刻意的去追求它，它就是个附属品。另外PE以内容为核心，可以让我们的焦点永远都集中在应该给用户提供的内容上，内容才是业务的重中之重。第二个部分是关于我们需要花很大的effort来用Testing保证增强前和增强后的功能么，我的想法是对于我们现在支持的所有功能，包括增强前后的功能，但是会有侧重，如果80%人都可以使用上chrome这样的浏览器，那么我们会加大最增强后的Testing，它是用户使用驱动的。而我们可以花一部分精力去Testing那些我们能想到的功能，但是不是主要功能，比如说阅读器、搜索引擎加载等等，我想这也是卓越软件追求的一个方面吧。

啰嗦说了很多我的想法，也表示我对PE也在学习研究中，还没有总结出来一套方法论。现在项目里面也要加强PE的引入，随时随地都要敏感的想到PE理论，最近还在看《Designing with Progressive Enhancement》，里面提到了很多各种增强的方法应该会帮到我。

感谢在工作中和我耐心讨论的同事们。

-完-