前端工程师新手必读：掌握基本技能弄清概念

　　很多属性是有精简的写法的，如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性能很有好处。对于较小的图片，采用这样处理是非常实用的，但是IE６、７不能支持这种方法，因此可以在IE6、７中采用传统的方法，而在其他浏览器中使用这样的方法来进行全面的兼容。

这种做法有利有弊，好处是可以减少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框架是种很普遍的现象，但是我们的开发应该按需要

作者：黄锦诚

文章来源：aqy106.com