黄锦诚：前端设计师的心得

在头部的焦点广告图那里，用小BUG右键查看一下元素，看到这样的一个图像标签img代码：

img必备和可选的参数都有写了上了，但是必备参数里的一个值alt没写(其实一些大型的专业门户网站其实也是有存在一些小问题的，只要我们细心一点就能发现)。虽然这样alt不写，在页面中也不**有任何的问题，因为这个alt属性也只是在图像丢失、禁用或加载不到的情况下才显示，但是如果一些其他特定的设备访问或一些其他条件下图**不显示的情况下，那这里就是一块大红XX和一大块白块，多影响用户体验。

虽然只是一个小小的alt属性，但是有时候是细节决定决定成败，用与不用，表面上看不出有什么问题，但是在某些特定的条件产生的作用是无法估计的，也就是从这些小小的细节就可以看出一个前端工程师的水平如何。

一些前端的新同学甚至什么也不填，放一张无任意命名意义的图上去就算了事，养成这样的习惯是非常不好的。

　　2、规范语义使用标签

很多同学说是学习div+css，其实这个说法是存在误区的，甚至是错误的。一个规范标准的页面是合理地使用标签，使其更加语义化，如果只是靠一堆堆的div通过层层的嵌套来布局完成的话，那么，除了div和a标签这两个标签外，所有的HTML元素都没有存在的必要了。

上面是一个前来应聘的朋友发给我看的一个页面布局作品(点击进行查看)，这个同学还算是工作了一定的时间的，据他介绍之前是在游戏公司工作的，但不知是不是当时所在的公司是不是他负责 前端这块的，不做评论。

这个朋友的页面在浏览器查看没有什么大问题，浏览骂的兼容性还可以说是没有太大问题的，虽然从页面的效果上看起来没有什么问题，用小bug一看，可以看到他写的这个代码好像还蛮整齐的，所有的东西都是一层层的div，包裹得很仔细，类的命名也很有规律，但仔细一看，这个导航做的很有问题。查看一下源文件，发现不仅仅只是导航的问题了，整个页面都有问题，所有的body下出现过的HTML标签加起来总共只有七个，分别是：div、a、strong、font、input、br、img。先不说他写行内样式、align在HTML4.01中已经丢弃的属性这些很低级错误的问题，一个很大的问题就是，语义的使用极不规范，使用层层的div来包裹定位。

例如这个导航可以用一个无序列表ul来就可以完成了，这样简洁明了，不需要这么多div和巨量的样式来进行控制，最重要的是语义化也比较清晰了。

网页布局就像是一篇文章那样，有标题、有段落、有加强、有突出，HTML提供了这么多的元素给我们使用，就是要求我们要按照其语义来使用，该用标题的时候用标题(h)，该用段落的时候用段落(p)，该重点强调的时候用强调的强调(em、strong),而不是都不管三七二十一，千篇一律的先用div来包裹再来进行控制。我们使用了这些相应语义的HTML元素，同样可以使用css来进行控制的，可以达到任何我们想要的布局效果的。css的魅力就在于此。

研究表明， 语义化的标签，越少的嵌套，对浏览器的解析就越快，显示的速度就越快，当然对不同用户群的用户体验也就越好!特别是对于一些特殊群体和阅读设备，如盲人，使用的是阅读HTML的机器，对于一块块的div，就不知道哪里是标题哪里是正文了，只能阅读到的是这里有一整块的内容。如果使用的是语义化的标签就不一样了，即使看不到屏幕，但也知道哪里是标题哪里是标题下相应的正文。所以，我们有css这个这么神奇的东西帮助我们网页布局的时候，语义化的使用HTML标签，用最少的嵌套和代码实现同样的效果，就是我们前端工程师所追求的。

再次回到前面div+css布局的一些误区，什么是div?它的英文名是division，意思是分开、分割、分块的意思。也就是说div在网页中是用来进行分块布局或是在没有更适合的HTML元素的情况下用来配合分块布局的，如果胡乱的滥用div，那么就**犯上“div控”了。刚入门不久的新同学最容易**犯这种思想的。

　　CSS：

CSS (Cascading Style Sheets)指的是层叠样式表，现在普遍在用的版本是css2.1 ，虽然已经发布了3.0的版本，且有一些个人的博客和站点已经使用HTML5+CSS3了，但受目前国内的主流浏览器IE6的影响，更多的人还是在使用2.1的版本，在这个的基本上有选择性的使用少量的不影响兼容的css3某些功能，css3的普及还需时日。不管如何，css3的出现让我们眼前一亮，增加了很多新的属性，如圆角、阴影、渐变、动画、流媒体等等的效果，让页面实现的效果更加方便和容易。

现在要和大家分享的并不是css3哪些激动人心的属性如何使用和实现，因为这些当我们学习到了一定阶段的时候都**去学习到css3这个将来必将成为王者的使用，现在与大家分享一些与版本无关的东西，让大家在学习的过程中少走一些弯路。

　　1、 Reset

关于重置也有太多的东西要说了，YUI、Eric Meyer等都有各自不同的方法，甚至有些人是不用重置的，不管怎样，只要遵循一个原则：适合自己的就好。所以不对这方面过多的强求，也不作过多的讨论。因为要讨论的话几大篇幅也讨论不完。当然我自己有一个自己用的reset的地方，究竟好与不好，大家有空的时候可以研究，最好能把研究的结果与我分享，我也很愿意听。这个是我的Reset的文件，大家可以点击下载(aqy106_lab.css)

　　2、 样式书写要注意的事项

看过《Efficient, maintainable CSS》的译文《如何书写高效、可维护、组件化的CSS》，里面讲到一些样式的书写要注意的事项。还是看一看这个同样是一个新同学写的样式，看上去很整齐，命名也很有次序，但是仔细一看，问题还是很多的，先不说命名，因为这个得用另外的一个篇幅去说了。

如果作为一般的小站这样写，样式的也许只是多几个K的大小的问题，在性能上影响并不大，但在大型的网站中，几个K的大小就不容忽视了。

　　基于前人的总结，个人认为高效的css书写应该要注意：

　　1)、精简属性写法，提高可观赏性

　　很多属性是有精简的写法的，如padding、margin、background等等，这些写法虽然可拆可合，但我们习惯了精简的写法后，**让css更加整洁、明了，看起来更加赏心悦目，感觉写css就是一个雕刻一件艺术作品。

　　2)、使用多重选择器，提高可重用性

多重选择器的写法相信很多人都**使用，但是多重选择器的使用与进行二次编辑或多次编辑的时候**有一个矛盾，多次的修改，有可能需要重新定义的样式不同，这时候又需要重新的将原先的选择器进行分享出来单独定义，这不能不说是一件痛苦的事情，所以在使用多重选择器的时候，最好能将固定的版块进行使用多重选择器，这样大大降低你日后维护、编辑的成本。当然，这是需要你的时间和经验才能积累起来的。

　　3)、减少层级及继承的写法，一般不轻易用id

相信很多人都**考虑到重用这一高效的写法，所以越少的层级、越少的继承就为重用这一方法的实现提供了可能。也许有人**说，那我可以采用上面的“使用多重选择器”来进行提高css的可重用性啊。其实这里面还有另外一个原因，就是更少的层级，渲染所使用的时间更少。css的渲染与JavaScript的方式完全不一样，JavaScript的筛选直接使用id，能够精准的定位到相应的dom，但是css的层级多的话反而**影响到性能，但具体没做相应的测试。此处也许不严谨，请大家赐教，哪位大侠有空来测试一下，给一些相应的数据**有更好的说服力。但基于重用的原则，个人还是建议用最直接、有效的简短的命名，也同样就是这样的一个原则，虽然id的唯一性解决了冲突了问题，但违反了重用性的原则的同时也加大了维护和的成本，如非必要，尽量不用id。

　　4)、命名面向属性和面向对象结合

其实命名这个方面有很长的一个篇幅可以说的，因命名的方法和各个人的习惯也不样，有人喜欢用驼峰式，有人喜欢下杠线，有人喜欢缩写，也有人喜欢全写，个人认为这个主观色彩太重了，不予作过多的展开，不管哪一种，都是没有问题的。

和大家分享的是另外一个问题，是样式的命名是面向属性还是面向对象呢?相信这个也**困扰着一些同学。现在就和大家分享一些我的心得。在分享我的观点之前，先跟大家解释一下什么是面向属性、什么是面向对象。面向属性就是面向css的属性来进行命名，面向对象就是面向要重构的页面的模块这个对象来进行命名。如下图：

　　4.1面向属性命名

4.2面向对象命名

关于这个问题，有人觉得面向属性好，因为可以最大限度的利用好css的重用性;也有人认为面向对象好，因为面向对象可以让后期的维护更方便直接。既然各自都有好处，那我们可不可以将两者结合起来呢?答案是肯定的，而我个人也是这样做的。

对于一些固定的、常用的、重用性非常高的css，可以将其按面向属性来进行命名，前面前的“面向属性命名”的这个图这样，也可以说是一个小小的框架或是作为一个底层来方便自己的开发，放到哪里都是可以使用，具体可以见我整理的自已用的面向属性的css(点击下载aqy106_lib.css)。另外对于于具体的版块就应该使用面向对象，针对版块的对象来进行命名，这样也让后期维护或接手的人来编辑也不**困难。163采用的也是采用面向属性和面向对象结合的方法来进行命名的。

作为一名前端开发的工程师，应该要有一利节流的思想，把css的书写当作一门艺术来学习、来追求。书写出一个高效、可维护的样式往往是通向大师之路的必走之路。

样式不仅仅是写给自己看的，更要给团队开发或后来接手的人看的，如果能做到简洁、高效、重用性、可读性强，相信，你离大师的级别也不远了。

　3、 CSS Sprite(图**精灵、背景定位技术)

现在的网页，各种各样的媒体、图标、背景都是多得眼花缭乱的，特别是背景图**、图标是我们网页中使用最多的，按照以前的使用的话，插入一个个的小图标或图**用来控制来进行修饰，这些不和内容相关的图标图**也一并混排在内容中了，且页面中一大堆无关的图标图**，还不方便管理。并且还有一个很大的弊病，一个图**在页面中是一个http的请求，页面中存在n个的这样的小图标的话，对服务器的请求也就有N个，也许对于一些小站来说没什么影响，但对于一个大型网站来说的话，这个数字可就不得了，这时的服务器并发请求就**多上N乘以用户的个数，这样无疑加重了服务器的负担。

而解决这个问题的最好办法就是CSS Sprite。

将所有的图**整合到一张大图上，通过css来进行定位。首先能将内容和修饰的元素进行了分离;其次能减少页面请求的个数，那么减轻了服务器的负担;再次，能够提高页面加载的速度，加快页面载入速度，提升用户体验。

另外，将图标图**作为背景来进行加载，都是在文档的主要内容进行加载完毕，再加载样式时才进行请求的(细心的大家也许也发现，网络不好的时候，页面加载进来的是乱七八糟的，待一**样式加载进来后，页面马上正常了，其实这个就体现到了文档加载的先后顺序，如果不相信的话，可以用小bug或相应的工具查看一下是不是这样的加载顺序)。

当然，事物都是具有两面性的，将小图标小图**整合到一张图**上，虽说有百利，但仍有一害的，就是当需要更换图标或调整的时候，必须要在这张图**进行处理和定位，需要在FireWork等这些图像处理软件中定位好坐标再去写相应的CSS，**增加一定的工作量，如果身边没有这些工具，处理起来还是**有些麻烦的。但总的来说，图**整合，利大于弊，我们为何不用呢?

　　1、 兼容性

2、 以Trident为内核的IE、以Gecko为内核的FireFox、以Presto为内核的Opera、以Webkit为内核的google chrome和Safari等四大内核的浏览器四分天下。

兼容性的问题相信是很多前端工程师肯定**遇到且最头痛的一个问题，且不说目前市面在有这么多的浏览器，就仅仅单一的IE系列家族的问题也够多的了，特别是IE6，虽然微软宣布了IE6的死亡和下台，但国内的机器仍以IE6为主流，IE6在国内的法消亡还需时日，作为前端开发没法规避的情况下，暂时也只能折衷的进行兼容。不过虽然繁多复杂，但我们可以化繁为简，重点问题重点处理，基本上IE6的问题解决了，也就解决最大的问题了。

当然，这个IE6的问题太多了，需要用另外的篇幅去进行说明了，这里就不再跟大家再作深入的研究了，给大家提个醒，让我们一些新同学在成长过程中能够有目的地去学习、发现和处理问题就OK了。

　　3、 图**的优化

虽然现在的富媒体越来越多了，网页展现的数据从单一的图文向音频、视频、动画等类型扩展，但受限于网络传送带宽、速率等影响，图**仍以最高的可压缩比、传送速度快、展现效果好等优点作为一个主角在网页呈现和展示方面活跃着。目前网页主流的格式现在常用的也就不外乎几种：png、gif、jpg，其他一些在网页中不常用的格式暂不在本次的讨论之列。

　　3.1图**格式知多少

相信png、jpg、gif这些格式大家都能大概的了解和清楚一些使用，这里就不再细说，这里说一些使用中注意的事项或是大家不够深入了解的东西。

png：png有多个不同的位数的格式：png8、png24、png32。前端的新同学们常常遇到的就是png在IE6中不透明，其实IE6是支持PNG透明的，不过只支持png8的透明而已，具体可以看我的页面中图标，就是用了png8的透明，但是png8下不支持半透明，所以顶部的这个有背景色的时候用了png32配合JS处理了一下透明效果，不然有白白的边在IE6里太难看了。png8和gif都支持全透明和256色，所以在正常情况下两者是可以互换的，两者输出的大小也差不多，甚至png8比gif更有优势，但png8不能像gif那样做成动画。

而png24和png32也有一些不同。png24在png8的基础上增加了颜色的支持数，但是没有透明信息，png32在png24的基础上增加了透明的信息。Firework和Photoshop虽然同为Adobe公司的产品，但是输出的时候也是有些不太一致的。Firework能够正常的输出各种规格的png，但Photoshop不支持8位png+alpha透明的格式，而且Photoshop中也没有32位png选项，其中的png24+透明实际上就是 png32(不信你可以尝试用Photoshop输出一个png24+透明的png再到Firework中看看就知道了)，如果要IE6支持png32的透明，就只能用别的方法了，而我采用了js的方法，用法可见《IE6下PNG图像透明完美解决方案》(其实标题应该改成“IE6下PNG32图像透明完美解决方案”)。

gif：gif和png8一样，都是只支持256色，模式都是索引颜色，但gif比png一个较大的优势是可以将图**做成动画，而png8不能(现在最新版的png标准是支持一个文件内存放多个图像的，也就是说同样可以做动画的)。

现在还有一些更非常规的图**的用法，大家可以看到google的404页面(点击打开GOOGLE 的 404页面)，将图**进行base64编码再放到css中(当然IE6、7是无法正常解析的，嘿嘿)。

这种data: URI的格式能把base64(或其他数据)可以内嵌在image标签的属性当中(或者CSS中或JavaScript中)，通过对图**进行base64编码，可以实现将图**直接嵌入代码中的目的，如此一来，可以减少HTTP请求，这对于提升web性能很有好处。对于较小的图**，采用这样处理是非常实用的，但是IE6、7不能支持这种方法，因此可以在IE6、7中采用传统的方法，而在其他浏览器中使用这样的方法来进行全面的兼容。

这种做法有利有弊，好处是可以减少HTTP请求，不好的地方是图像的大小**增加1/3。因此，这种内嵌的方法适合对小的图形、小图标等进行处理，从而减少浏览器打开的连接数，但对大的照**、图**等则不应该使用base64编码了，以免影响图像下载的时间。

但这种图像的处理也需要另外的软件，所以不熟悉的情况下操作起来也有一定的困难，这里有一个在线版的转换工具，有兴趣的大家可以试试，尝尝鲜：点击打开

当然这些都是更深一点的应用了，我也在学习当中，无法再作更深入的论述了，大家可以自行进行扩展。当然，我也乐于分享你们的观点。

扩展阅读：《Data URI scheme》

　　更多的图**的格式可以查看一篇老外的文章，也有人进行了介绍：

《Tips for choosing a cache image format 》

《The difference between PNG24 and PNG32》

外文不太好的也可以看这里，有人进行了相应的概括：

淘宝UED： 《图**格式与设计那点事儿》

尹延**：《 PNG详解》

6.2如何输出合适的图**

说了这么多的图**格式相关的知识，现在要实际操作来说明一下我们怎样输出一个适合我们的图**了。

其实淘宝UED： 《图**格式与设计那点事儿》这里也说明得够详细了，这里就不重复里面的一些方法了。我们最常用的图像处理软件莫过于Firework和Photoshop，所以我们也以这两个软件就重点。虽然两个软件现在是同出一家，同属一个Adobe Master套装，但两者的算法还是有一定的差别的。所以在做图**处理的时候有时候可以在这两个软件中分别进行输出对比来决定最后图**的使用。

注：本文使用的是Adobe Master CS4开发套装的，其他的版本没测，已知的是Firework8中图**输出的算法也没有Firework CS4的好，具体可以亲测。

这里不再进行深入的论述，大家清楚了上面的格式的差别和软件的问题后，在具体的工作中通过不停的比较就能得出上面这些结论。

　　JavaScript：

因本人也是JS菜鸟一个，也正在努力学习的阶段，没法跟大家深入的讲JavaScript的一些核心代码分析什么的，所以讲一些无关紧要的所谓的**问题。

页面除了数据层的html、展示层的css，还有一个动画和交互层的脚本，那就是JavaScript。JavaScript可以说是目前Web开发中一个非常流行的语言了，如果一个前端工程师能够精通此语言，就单一项语言也能成就一份非常不错的工作。

相信大家对之前google里的那个用JavaScript做的纪念玛莎·葛兰姆的动画还不**陌生，点击此处观看，这个用JavaScript配合图像定位做成的动画，展示了JavaScript的强大功能。

现在Prototype、JQuery、Mootools、Dojo、Extjs等的框架，各种各样的基于js框架开发的插件方便我们的开发，大大的热缩短了我们学习的周期，简化了前端的开发，加快了开发速度，同时避免各类浏览器的兼容性问题。目前前端开发者使用JS框架是种很普遍的现象，但是我们的开发应该按需要。

来源：伯乐在线