在不同的时期对页面前端的看法似乎是多变的。在互联网早期的时候，小车还是比房子贵的，烧饼和粉丝还只是用来吃的，菊花还只是用来泡茶的。那时的页面设计风格相对单一，对应的页面需求比较简单，并且当时的浏览器也基本是 IE6 的天下，javascript 也只是网页特效的代名词，HTML 页面本身没有引起太多人的关注，似乎只要能用 div 甚至 table 加 css 辅助把图片定好位，把页面内容预留好就 OK 了，并且这种观念存在了很长一段时间。随着页面内容的丰富，设计风格的发展，交互复杂性的增加，AJAX 的应用，浏览器的更新换代，又让大家重新对最基本的页面本身重视起来。然后热议的就是浏览器的兼容性，碰到问题最热衷的就是满网络搜索 hack，顺便再骂骂 IE6、7……当这些都做一遍后，似乎又遇到了瓶颈，又开始寻找出路。我们就从这个阶段开始说起。
实现效果图是最基本的工作
把视觉稿通过页面代码的方式表现出来包含了两个基本诉求：1.能够真实反映视觉稿；2.能够通过浏览器的兼容。这两个诉求的达成需要我们有追求细节的态度和一定的页面功底，能完成这两个内容就可以初步进入页面前端的从业者行列了，但这就代表着我们可以胜任页面开发的工作了？不，才刚刚开始！
与设计师的沟通和项目的参与
沟通很重要。先抛出几个问题：我们有没有和设计师探讨过某些效果对低端浏览器渲染效率影响比较大？有没有探讨过部分效果可以用 CSS3 实现从而使得结构更加简洁清晰？有没有在代码和视觉中寻追求过平衡？页面前端的开发向基本用户，编写的代码也直接作用在浏览器上，我们有义务对页面的稳定性和渲染效率负责。我们也经常碰到项目在总体进度压力下导致的设计与页面前端开发同步进行，这时更有必要尽量多地获取项目信息，了解我们还要做些什么，这些可以帮助我们充分考虑重用和框架拓展。
良好的页面结构
页面结构的编写好比盖房的地基建设，其好坏会直接影响到 CSS 代码的质量、js 开发、后台开发还会影响到以后的页面拓展、迭代和页面调整。拿到视觉稿后，不要忙着动手开始，多观察思考。先分析布局，划分框架，然后规划结构，编写代码。特别在大型项目中，合理使用模块化的开发不论从整体进行还是拓展维护都有相当大的好处。
关于 hack
很多同学在页面开发时上网搜索最多的就是 hack 了，是否我们完全要依赖 hack 来实现页面兼容性，答案是否定的。大家经常比喻 IE6 向我们撒了一个谎，结果我们要再撒一百个谎来圆这个谎。不否认 IE6 经常让我们口吐鲜血，但不代表我们用更多的“谎言”来弥补就可以心安理得。大部分情况下可以通过变换思路调整 HTML 结构，或使用一些虽然无法解释但相对安全的 css 来干掉 hack。谁都无法预计使用 hack 什么时候会让我们栽一个大跟头。比如触发 layout 或 position:relative 就可以帮助解决很多 IE6 的问题。
优美的代码
现在很多 web 项目功能复杂，代码规模也会变得很庞大，如何更好地进行协同开发和维护是我们面临的一个问题。需要考虑完善统一的规划，还有要养成良好的代码开发习惯才会在面临各种情况时游刃有余。翻阅页面代码，看到合理的标签使用、良好的注释、清晰的代码结构、用意准确的 css 不仅犹如欣赏一个艺术品，更为下游开发和协同开发降低了不小的沟通成本，我们有什么理由不去这么做呢？举个反面例子：div 滥用是现在比较典型的一个问题。数数看自己使用的标签有多少个呢？不同的语义都该使用对应的标签代码，特别是 HTML5 提供了更丰富的语义化标签，它们都苦苦地在等待战场上的冲锋号，让我们去解放它们吧！
无障碍页面开发
可访问性与易用性是非常主观且人性化的东西。普通人看上去上完美呈现的页面在特殊群体中不一定显得那么贴心。当盲人用读屏软件在页面某个区域内陷入循环时，我们应该感到内疚。只能说目前国内的网站对此的重视程度还远远不够，这就需要我们共同努力，让更多的人感受到我们的热情。
保障效率
作为项目开发中比较靠前的一环，页面开发可能需要尽早完成为项目争取时间，这就需要我们尽可能地提高效率。“工欲善其事，必先利其器”，除了实战经验和代码习惯的形成可以帮助我们提高效率外，想要提高对自己开发的进度掌控能力，还有很多辅助工具可以帮助我们进行页面开发。比如使用 Less 或 Sass 可以帮助我们拓展和组织 CSS，大大提高 CSS 的编写效率增加了可维护性。比如可以通过 zen coding 的自动自动完成和自定义代码块让你可以剑指如飞。甚至还见过通过自定义输入法的代码块关键字来提升开发速度的。多多发掘一定会找到最合适自己使用的工具。