CSS和JavaScript标签对照表

前端开发工具箱——抓色工具(ColorPic)
 

Javascript的IE和Firefox兼容性汇编

以下以 IE 代替 Internet Explorer，以 MF 代替 Mozzila Firefox
    
    1. document.form.item 问题
    (1)现有问题：
    现有代码中存在许多 document.formName.item(“itemName”) 这样的语句，不能在 MF 下运行
    (2)解决方法：
    改用 document.formName.elements["elementName"]
    (3)其它
    参见 2
    
    2. 集合类对象问题
    (1)现有问题：
    现有代码中许多集合类对象取用时使用 ()，IE 能接受，MF 不能。
    (2)解决方法：
    改用 [] 作为下标运算。如：document.forms(“formName”) 改为 document.forms["formName"]。
    又如：document.getElementsByName(“inputName”)(1) 改为 document.getElementsByName(“inputName”)[1]
    (3)其它
    
    3. window.event
    (1)现有问题：
    使用 window.event 无法在 MF 上运行
    (2)解决方法：
    MF 的 event 只能在事件发生的现场使用，此问题暂无法解决。可以这样变通：
    原代码(可在IE中运行)：
    <input type=”button” name=”someButton” value=”提交” onclick=”javascript:gotoSubmit()”/>
    …
    <script language=”javascript”>
    function gotoSubmit() {
    …
    alert(window.event); // use window.event
    …
    }
    </script>
    
    新代码(可在IE和MF中运行)：
    <input type=”button” name=”someButton” value=”提交” onclick=”javascript:gotoSubmit(event)”/>
    …
    <script language=”javascript”>
    function gotoSubmit(evt) {
    evt = evt ? evt : (window.event ? window.event : null);
    …
    alert(evt); // use evt
    …
    }
    </script>
    此外，如果新代码中第一行不改，与老代码一样的话(即 gotoSubmit 调用没有给参数)，则仍然只能在IE中运行，但不会出错。所以，这种方案 tpl 部分仍与老代码兼容。
    
    4. HTML 对象的 id 作为对象名的问题
    (1)现有问题
    在 IE 中，HTML 对象的 ID 可以作为 document 的下属对象变量名直接使用。在 MF 中不能。
    (2)解决方法
    用 getElementById(“idName”) 代替 idName 作为对象变量使用。
    
    5. 用idName字符串取得对象的问题
    (1)现有问题
    在IE中，利用 eval(idName) 可以取得 id 为 idName 的 HTML 对象，在MF 中不能。
    (2)解决方法
    用 getElementById(idName) 代替 eval(idName)。
    
    6. 变量名与某 HTML 对象 id 相同的问题
    (1)现有问题
    在 MF 中，因为对象 id 不作为 HTML 对象的名称，所以可以使用与 HTML 对象 id 相同的变量名，IE 中不能。
    (2)解决方法
    在声明变量时，一律加上 var ，以避免歧义，这样在 IE 中亦可正常运行。
    此外，最好不要取与 HTML 对象 id 相同的变量名，以减少错误。
    (3)其它
    参见 问题4
    
    7. event.x 与 event.y 问题
    (1)现有问题
    在IE 中，event 对象有 x, y 属性，MF中没有。
    (2)解决方法
    在MF中，与event.x 等效的是 event.pageX。但event.pageX IE中没有。
    故采用 event.clientX 代替 event.x。在IE 中也有这个变量。
    event.clientX 与 event.pageX 有微妙的差别（当整个页面有滚动条的时候），不过大多数时候是等效的。
    
    如果要完全一样，可以稍麻烦些：
    mX = event.x ? event.x : event.pageX;
    然后用 mX 代替 event.x
    (3)其它
    event.layerX 在 IE 与 MF 中都有，具体意义有无差别尚未试验。
    
    
    8. 关于frame
    (1)现有问题
    在 IE中 可以用window.testFrame取得该frame，mf中不行
    (2)解决方法
    在frame的使用方面mf和ie的最主要的区别是：
    如果在frame标签中书写了以下属性：
    <frame src=”xx.htm” id=”frameId” name=”frameName” />
    那么ie可以通过id或者name访问这个frame对应的window对象
    而mf只可以通过name来访问这个frame对应的window对象
    例如如果上述frame标签写在最上层的window里面的htm里面，那么可以这样访问
    ie： window.top.frameId或者window.top.frameName来访问这个window对象
    mf： 只能这样window.top.frameName来访问这个window对象
    
    另外，在mf和ie中都可以使用window.top.document.getElementById(“frameId”)来访问frame标签
    并且可以通过window.top.document.getElementById(“testFrame”).src = ‘xx.htm’来切换frame的内容
    也都可以通过window.top.frameName.location = ‘xx.htm’来切换frame的内容
    关于frame和window的描述可以参见bbs的‘window与frame’文章
    以及/test/js/test_frame/目录下面的测试
    —-adun 2004.12.09修改
    
    9. 在mf中，自己定义的属性必须getAttribute()取得
    10.在mf中没有 parentElement parement.children 而用
    parentNode parentNode.childNodes
    childNodes的下标的含义在IE和MF中不同，MF使用DOM规范，childNodes中会插入空白文本节点。
    一般可以通过node.getElementsByTagName()来回避这个问题。
    当html中节点缺失时，IE和MF对parentNode的解释不同，例如
    <form>
    <table>
    <input/>
    </table>
    </form>
    MF中input.parentNode的值为form, 而IE中input.parentNode的值为空节点
    
    MF中节点没有removeNode方法，必须使用如下方法 node.parentNode.removeChild(node)
    
    11.const 问题
    (1)现有问题:
    在 IE 中不能使用 const 关键字。如 const constVar = 32; 在IE中这是语法错误。
    (2)解决方法:
    不使用 const ，以 var 代替。
    
    12. body 对象
    MF的body在body标签没有被浏览器完全读入之前就存在，而IE则必须在body完全被读入之后才存在
    
    13. url encoding
    在js中如果书写url就直接写&不要写&amp;例如var url = ‘xx.jsp?objectName=xx&amp;objectEvent=xxx’;
    frm.action = url那么很有可能url不会被正常显示以至于参数没有正确的传到服务器
    一般会服务器报错参数没有找到
    当然如果是在tpl中例外，因为tpl中符合xml规范，要求&书写为&amp;
    一般MF无法识别js中的&amp;
    
    14. nodeName 和 tagName 问题
    (1)现有问题：
    在MF中，所有节点均有 nodeName 值，但 textNode 没有 tagName 值。在 IE 中，nodeName 的使用好象
    有问题（具体情况没有测试，但我的IE已经死了好几次）。
    (2)解决方法：
    使用 tagName，但应检测其是否为空。
    
    15. 元素属性
    IE下 input.type属性为只读，但是MF下可以修改
    
    
    16. document.getElementsByName() 和 document.all[name] 的问题
    (1)现有问题：
    在 IE 中，getElementsByName()、document.all[name] 均不能用来取得 div 元素（是否还有其它不能取的元素还不知道）。

基于网站性能有关的两个简单法则：
* 尽可能的减少数据的传输量
* 尽可能的减少数据的传输频率

若使用得当，此两条法则会：
* 提高网页的加载速度
* 降低服务器使用的资源
* 提高网络带宽利用率

    使用这些技巧来开发网站，不仅能够提高用户对一个网站或者是基于web的一个应用的满意度，更可以节约网站数据传输的成本。这篇文章所讲述的技术细节可帮助我们写出很好很实用的代码，从更广泛的角度来讲，这也将会给网站打造出良好的可用性基础。

第一部分 – 20个客户端代码优化技巧
      在一个典型的网页加载过程中，(X)HTML文件是最先被浏览器读到的。既然这个文件决定了其他文件的关系，我们可以管这个文件叫主文件(host document)。浏览器一旦接收到这个主文件，便开始解析各种markup；一般在解析的同时，也会触发一系列对相关对象的请求，例如外部脚本、关联的样式表单、图片、或嵌入式Flash等等。这些CSS和JavaScript文件有可能继续触发一些对相关图片或脚本等的请求。这些对相关文件的请求排成队列的速度越快，它们到达浏览器的速度也就越快，从而越早的开始显示出页面来。了解了主文件的重要性，我们便知道把它尽快地传给浏览器并加以解析的重要性，因为尽管主文件本身相对来说整个传输量来说只是一小部分，它却能够严重地阻碍网页的加载速度。要明白，用户才不在乎你使用的字节数的多少，用户在乎的是时间！

       那么您具体需要怎么做才能作到最优传输的万全准备呢？一个基本的方法是减少空白区域，精简CSS和JavaScript，更改文件名，以及对要提交的代码也采用前述相同的策略，使之越简洁越好(Google 就是一个例子).本文则列出我们认为最有效的优化markup和代码的二十大技巧。当然，您可以手动来做部分优化，或者使用网页编辑器及工具来完成一些优化，当然还可以开发出您自己的精简工具。

Makeup:
1. 尽可能的除去空白区域
一般而言，空白区域字符（空格、制表符、换行符等）都可以安全删除，但要避免修改 pre, textarea, 及受CSS属性中 white-space 影响的标签。

2. 除去注释
除了在客户端给IE和 doctype声明的条件注释外，几乎所有的注释都可以安全去除掉。

3. 使用最短格式的颜色表示
使用颜色时，不要一股脑的使用十六进制或全颜色名称(full color name)，要尽可能根据实际情况使用最短格式的颜色表示。比如，一个为 #ff0000 的颜色属性可以直接用 red来说明，而 lightgoldenrodyellow 可以换成 #FAFAD2.

4. 使用最短格式的字符表示
和最短颜色表示一样，一些名称可以用最短字符来表示，我们可以用较短的数字来代替某些长长的字母。比如：È可以变成 È;或者，偶尔这个方法反过来也行，比如：ð 如果变成 ð则可以省一个字节。不过，这个方法不太安全，而且成效有限。

5. 除去无用的标签
有些‘垃圾’markup，比如使用了多次的重复标签或者某些编辑器里用作广告的“meta”标签，都可以安全地被删除。
CSS优化
CSS也有一套成熟而又简单的优化方法。实际上，时下大多数的CSS都较 (X)HTML更容易压缩。下面所列的技巧除了最后一条都是安全的。最后一条涉及到客户端的网页技术，可能会变得比较复杂。
6. 除去CSS中的空白区域
相比起(X)HTML来，CSS对于空白区域没有那么敏感，所以除去空白区域便可以极大地减少CSS文件和样式表区域的大小。
7. 除去CSS注释
如同除去markup代码中的注释一样，由于CSS中的注释对普通的最终用户来说并没有什么实用价值，所以也应该被除去。不过，如果考虑到较低级的浏览器，则在CSS中的 style 标签中的屏蔽注释信息不可以被除去。
8. 使用最短格式来表示颜色值
和HTML一样，CSS颜色也可以用词语或十六进制格式表示。注意，在CSS中这样做的效果会稍微明显一些。主要是因为CSS中支持3位的十六进制色值，例如对白色可用 #fff 来表示。
9. 对CSS的规则进行合并、减少或删除
CSS中的诸如字体大小、字体重量等规则往往可以使用一种单属性字体的速记注释方式来表示。使用得当的话，这个技巧可以让您把如下的规则：
p {font-size: 36pt; font-family: Arial; line-height: 48pt; font-weight: bold;}
改写成下面简短的形式：
p{font:bold 36pt/48pt Arial;}�
如果继承方法使用得当的话，您还会发现在样式表单中的一些规则可以显著的减少或干脆删掉。到目前为止尚没有能自动移除规则的工具，所以只能通过手工调整CSS向导(Wizard)来进行这些工作。不过即将推出的w2compiler 2.0会有这个功能。
10. 对类和ID值进行重命名
在CSS优化中最危险的动作可能是重命名类或ID值了。看看如下规则：
.superSpecial {color: red; font-size: 36pt;}
可将其更名为sS。而对ID值一样可以遵循这样的原则，例如对于：
#firstParagraph {background-color: yellow;}
则可将原来的 “#firstParagraph” 重命名为 “#fp”，并在整个文档中重复这一动作 。诚然，这样做可能会涉及到“标识-样式-脚本”互相依赖的问题：如果一个“tag”有一个ID值，而这个值又可能不但用于样式表，还可能用于脚本参考，甚至可能是一个链接目标地址。在这种情况下，您一旦修改了这个值，您就必须得保证对所有相关的脚本和链接参考都进行了相应的修改，包括其他文件中的这个值，所以千万要小心细致。

改变类的值相对改变ID值来说，危险性小一些。因为经验告诉我们，比较起ID值来说，大多数JavaScript程序员都不太经常处理类的值。然而，改变类的名称来缩减CSS的尺寸也面临着和改变ID名称同样的问题，所以再次强调，要小心谨慎。

请注意：最好不要更改名称属性，尤其是表单区域中的名称属性。因为这些数值也会被服务器端程序所操作。虽然不是不可能，但对多数的网站来讲，要计算好这些相互依赖关系是困难的。

JavaScript优化
越来越多的网站都依赖于JavaScript来生成导航菜单、表格确认和其他各种各样实用的东西。不足为奇，大多数这些代码都非常笨重，亟待优化。对JavaScript代码的很多优化技术同那些用于markup代码和CSS的技术很相似。不过，对JavaScript的优化必须更加小心翼翼，因为一旦操作有误，其后果可能不仅仅是显示变形，并且可能导致网页残缺不全。下面我们先来看看一些最简单明了的方法，然后再探讨那些需要小心操作的技巧。

11. 除去JavaScript注释
除了 注释，其他所有的 or /* */ 注释都可以安全删除，因为注释对于最终使用者来说没有任何意义（除非有人想了解您的脚本是如何工作的）。
12. 除去JavaScript中的空白区域
有意思的是，除去JavaScript中的空白区域并不象想象的那么有用。一方面，像如下代码：
x = x + 1;
显然可以简短得写成：
x=x+1;
然而，很多随便的JavaScript程序员会忘记在两行之间加上分号，这时空白区域的除去就会带来问题。比如，下面合法的JavaScript使用了暗示的(implied)分号：
x=x+1 y=y+1
草率地删除了空白区域则会产生如下表达式：
x=x+1y=y+1
显然，错误就产生了。但如果您加上必需的分号，如下：
x=x+1;y=y+1;
则在字节数上并没有减少。然而在此，我们仍然鼓励这种格式的变化，因为对w3compiler Beta版的测试反馈中，很多人对‘看起来压缩了的’脚本非常满意（也许这是因为视觉上确认了对原始代码的格式转变）。他们也喜欢这种处理方法产生的另一个效果，那就是让交付的代码变得更难读。
13. 进行代码优化
简单的方法如除去暗示的(implied)分号，某些情形下的变量声明或者空回车语句都可以进一步减少脚本代码。一些简略的表达方式也会产生很好的优化，例如：
x=x+1;
可以写成：
x++;
不过得小心谨慎，不然代码很容易出错。
14. 重命名用户自定义的变量和函数
为了阅读方便，我们都知道在脚本中应该使用象 sumTotal 这样的变量而不是 s。不过，考虑到下载的速度，sumTotal 这个变量就显得冗长了。这个长度对于最终使用者来说没有意义，但对浏览器下载则是个负担。这个时候s 就成为较好的选择了。先写好方便阅读的代码，然后再使用一些工具来处理以供交付。这种处理方式在这里再一次展示了其价值所在。，将所有的名称都重新用一个或两个字母来命名将带来显著的改善。
15. 改写内建(built-in)对象
长长用户变量名会造成JavaScript代码过长，除此之外，内建(built-in)对象（比如Window、Document、Navigator等）也是原因之一。例如：
alert(window.navigator.appName); alert(window.navigator.appVersion); alert(window.navigator.userAgent);

可以改写成如下简短的代码：
w=window;n=w.navigator;a=alert; a(n.appName); a(n.appVersion); a(n.userAgent);

如果这几个对象使用频繁的话，这样改写带来的好处就不言而喻了。事实上这些对象也的确经常被调用。然而我要提醒的是，如果Window或Navigator对象仅仅被使用了一次的话，这样的替换反而使代码变得更长。所以手工进行这种优化时要格外小心，不过好在目前市面的常用的JavaScript代码优化工具都已经考虑到这个因素了。

这个技巧带来一个对象更名后脚本执行效率的问题：除了代码长短上带来的好处，这种改写更名实际上还会稍微的提高一点脚本执行的速度，因为这些对象将会被放在所有被调用对象中比较靠前的位置。JavaScript游戏开发程序员使用这个技巧已经有多年了，下载和执行速度都会有所提高，并且对本地浏览器的内存花销也会降低，可谓一石三鸟。

文件方面的优化

最后一类的优化技巧与文件和站点的组织有关。下面谈及的一些技巧可能会牵扯到服务器的调整和站点的重构。
16. 重命名用户访问不到的独立文件和目录
一些站点往往包含有诸如 SubHeaderAbout.gif 或 rollover.js 等是用户无法通过URL来访问的文件。它们通常都保存在一个标准名称的目录中，比如/images，因此我们常常会在markup代码中看到这样的句子： img src=”/images/SubHeaderAbout.gif” mce_src=”/images/SubHeaderAbout.gif”
或者更糟糕的象： img src=”../../../images/SubHeaderAbout.gif” mce_src=”../../../images/SubHeaderAbout.gif”�
既然这些文件从来都不会被访问到，对于最终使用者而言，方便不方便阅读便无关紧要。考虑下载速度的因素，上述句子改成下列形式更有意义：
img src=”/0/a.gif” mce_src=”/0/a.gif”
然而手工的文件和目录的修改工作量太大了，我们可以借助一些内容管理系统来完成相关的工作，比如将内容重命名成简短格式等。前面提到的w3compiler就有自动复制并且检查相互依赖关系的功能。如果使用得当，这个技巧会给引用这些文件的(X)HTML文件减肥不少，并且也让那些剽窃(X)HTML的人重新使用这些文件设置了重重障碍。
17. 使用URL rewriter来缩短所有的网页URL
注意在刚才提到的技巧中并不建议对网页的文件名（例如 products.html）进行重命名。那样的话，则下面的标示：
a href=”products.html” mce_href=”products.html”Products�
就会变成：
a href=”p.html” mce_href=”p.html”Products

这背后的主要原因是读者会看到一个这样的URL： http://www.sitename.com/p.html,相比起http://www.sitename.com/products.html来，后者比前者要来的更有意义、更好用的多。

不过，在不牺牲网页URL原义的前提下，假如我们结合更名技巧和修改服务器配置的话，我们还是有可能从缩短文件名中得到收获。譬如，在源代码中把products.html 用 p.html 替换掉，之后再设立一个URL复写(rewrite)规则，由服务器端的一个类似复写模块的过滤器比如mod_rewrite来使用这个规则，从而再把这个URL扩展成一个较为用户友好的值。注意这个窍门，如果这个复写规则只执行‘外部’(external)重定向的话，新的URL仅仅会写在使用者浏览器的地址条处，因而会强迫浏览器重新请求该页。在此种情况下，文件本身没有被重命名，仅仅是在源代码中URL里使用了重命名的简短的文件名。

像Yahoo!这样的大型网站通过积极使用该技巧得到了显著的获益，这个技巧是不能够被忽视的，毕竟它给目录及文件名称都是非常具描述性的站点提供了明显的减肥(X)HTML文件的效果。
18. 除去或缩短文件扩展名
想想看，其实有些情况下文件的扩展名并没有多大用处，比如 .gif, .jpg, .js等。浏览器不会依赖这些扩展名来显示页面，而是在处理时使用MIME类的头信息（header）。了解了这一点，我们就可以把：
img src=”images/SubHeaderAbout.gif” mce_src=”images/SubHeaderAbout.gif”
简化为：
img src=”images/SubHeaderAbout” mce_src=”images/SubHeaderAbout”
或是结合文件名目录名重命名，我们可以得到：
img src=”/0/sA” mce_src=”/0/sA”
您可别乍一看这个结果就吓跑了，sA.gif 仍然是 sA.gif文件，只不过网页的访问者不知道罢了。

不过，为了使用这个相对高级的技巧，您还需要对服务器来做一下修改。主要要做的工作是启用一个叫做“内容协商”(content negotiation)的东西。它可能是服务器自带的，也可能需要一个扩展（比如象Apache的 mod_negotation 模块或者IIS里Port80的PageXchanger组件）来支持。这样做会有一个负面的影响，它可能会造成服务器性能的一点损失。然而，内容协商的功能所带来的好处远大于所付出的。干净利落的URL可让您的网站即安全又轻便，甚至还使得自适应的内容传递变成可能：根据访问者浏览器的功能和系统的设置来向他传输不同类型的图片或语言！更多的说明请参看同作者所著的《Towards Next Generation URLs》一文。

注意：少了扩展名的URL不会降低您网站在搜索引擎上的排名。Port80软件和其他知名网站（如W3C网站）都使用此技术而没有负面效果。

19. 重构“脚本”和“样式”调用方式来优化请求次数
我们常常在一个HTML文件头中看到这样标记代码：

[script src=”/scripts/rollovers.js” mce_src=”/scripts/rollovers.js”][/script] [script src=”/scripts/validation.js” mce_src=”/scripts/validation.js”][/script] [script src=”/scripts/tracking.js” mce_src=”/scripts/tracking.js”][/script]

大多数情况下，上述代码应该被简化成：

script src=”/0/g.js” mce_src=”/0/g.js”

其中 g.js 包含了所有供全局使用的函数。虽然把脚本文件分成三份对于维护来说是有道理的，但对于代码的传输则没有意义。单个的脚本下载要比三个分离的请求高效的多，并且这也同时简化了markup代码的长度。有趣的是，这个方法模仿了传统编程语言编译器的连接概念。

20. 考虑代码级的cache能力
提高网站性能中最重要的方法之一是提高缓冲能力（cacheability）。网页开发者对使用 meta 标签来设置缓冲控制都很熟悉，可是撇开meta对代理的缓冲毫无用处不说，缓冲能力的真正价值是其对相关对象（比如图片或脚本）方面的应用。为了提高缓冲能力，您要考虑根据改变频率对相关对象进行分段，把更适合缓冲处理的东西放在某个目录中（比如：/cache 或者 /images/cache）。一旦您按照这个方法来组织您的网站，添加缓冲控制规则就很容易了，这样你的网站就会向经常来的访问者“跳”出来。

现在，您已经了解了20条有用的优化技巧来使您的网站变得更快。从单条来看它们可能没有很大的作用。可是把它们合起来使用的话，网站的传输能力便会有明显的提高。在下一篇文章中，我们将重点放在缓冲处理上。我们会解释缓冲如何经常会被错误使用，以及如何通过一些小小的改动来取得性能的显著提高。

哈哈。。。又发现一个很多小图标的站。。。里面好多小图标都很棒。。如果你用得着。。可以去保存下来。。。哈哈。。不用说谢谢的～

 域名就知道不错了～哈哈。。

http://www.iconarchive.com/

在CSSPlay上看到了一个垂直居中的例子，感觉还是不错的，跟大家分享一下：

======================CSS=======================
.holder{
width:740px;
height:300px;
border:1px solid #777;
text-align:center;
display:table-cell;
vertical-align:middle;
}
/*以下样式针对IE*/
.edge{
width:0;
height:100%;
display:inline-block;
vertical-align:middle;
}
.container{
vertical-align:middle;
display:inline-block;
}
================================================

====================HTML=======================
<div class=”holder”>
<!–[if IE]><span class=”edge”></span><![endif]–>
<!–[if IE]><span class=”container”><![endif]–><img src=”http://img68.imageshack.us/img68/8708/mylogo9we.gif” alt=”Homework” title=”Homework” />测试内容测试内容测试内容测试内容测试内容测试内容测试内容测试内容测试内容测试内容测试内容测试内容测试内容测试内容测试内容测试内容测试内容<!–[if IE]></span><![endif]–>
</div>
=================================================

代码改动了一点点。有两点必须要注意的：

HTML中IE条件注解部分的标签要用内联对象标签。
“<!–[if IE]><span class=”edge”></span><![endif]–>”要放在内容之前。如果放在之后，内容是中文时会不能居中。

看到这个标题很容易就会想到截断文字加“…”的做法。哈哈，就是这样。其实写这篇日志也只是把这样方法做个记录，因为好像写了这么多次，还是会不太记得。嘿嘿~~

一般的文字截断(适用于内联与块)：
==============CSS================
.text-overflow{
display:block;/*内联对象需加*/
width:31em;
word-break:keep-all;/* 不换行 */
white-space:nowrap;/* 不换行 */
overflow:hidden;/* 内容超出宽度时隐藏超出部分的内容 */
text-overflow:ellipsis;/* 当对象内文本溢出时显示省略标记(…) ；需与overflow:hidden;一起使用。*/
}
=================================

对于表格的话，定义有一点不一样：
==============CSS================
table{
width:30em;
table-layout:fixed;/* 只有定义了表格的布局算法为fixed，下面td的定义才能起作用。 */
}
td{
width:100%;
word-break:keep-all;/* 不换行 */
white-space:nowrap;/* 不换行 */
overflow:hidden;/* 内容超出宽度时隐藏超出部分的内容 */
text-overflow:ellipsis;/* 当对象内文本溢出时显示省略标记(…) ；需与overflow:hidden;一起使用。*/
}
=================================

注：这个东东只对单行的文字的效，如果你想把它用在多行上，也只有第一行有作用的。 这个写法只有IE会有“…”，其它的浏览器文本超出指定宽度时会隐藏。

YSlow是yahoo美国开发的一个页面评分插件，非常的棒，从中我们可以看出我们页面上的很多不足，并且可以知道我们改怎么却改进和优化。

仔细研究了下YSlow跌评分规则。

主要有12条：

1. Make fewer HTTP requests尽可能少的http请求。。我们有141个请求（其中15个JS请求，3个CSS请求，47个CSS background images请求），多的可怕。思考了下，为什么把这个三种请求过多列为对页面加载的重要不利因素呢，而过多的IMG请求并没有列为不利因素呢？

发现原来这些请求都是可以避免的。

15个JS和3个CSS完全可以通过特殊的办法进行合并（这个技术部已经帮我们解决了，实在是太感谢了，嘿嘿。），这样合并以后，一般情况下页面上只会出现一个JS和一个CSS（对JS的封装得有一定的要求）。

但是47个CSS background images请求改怎么解决呢？为什么页面上的纯IMG请求时合理的，而CSS background images请求过多就是不利因素了呢。这个我想了很久，总算明白，原来是这样的：

一般页面上的ICON，栏目背景啊，图片按钮啊，我们都会用图片CSS背景来实现，而一般这个图片CSS背景用到的图片都是比较小的，所以完全可以把这些图片合并成一个相对比较大的图片，这样页面上只会出现一个CSS background images请求，最多也就2-3个。后来仔细看了下雅虎美国的页面，他们的确也是这样做的，虽然这样做需要花一定的时间来有规则的合并这些ICON，栏目背景，图片按钮，以方便CSS调用，但是这样做绝对是合算的，而且是有必要的，YSlow也是极力推荐的。

2. Use a CDN这项我们的评分是F级，最低。说实在的，我刚开始什么是CDN都不知道。后来查了GOODLE才知道。CDN的全称是Content Delivery Network，即内容分发网络。其目的是通过在现有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的网络”边缘”，使用户可以就近取得所需的内容，解决Internet网络拥挤的状况，提高用户访问网站的响应速度。从技术上全面解决由于网络带宽小、用户访问量大、网点分布不均等原因所造成的用户访问网站响应速度慢的问题。

看来上述的解释后，基本上明白了CDN是怎么回事，后来咨询了下中文站点SA，得知我们网站目前的确还没有做CDN的优化，但是据说我们有更加先进的技术来解决类似的问题（具体什么技术那就保密了），但是毕竟CDN也是个相当不错的技术，所以在我们先进技术的基础上在做CDN优化，肯定比现在更好，嘿嘿。据说SA明年会做几个点的CND。

3. Add an Expires header设置过期的HTTP Header.设置Expires Header可以将脚本, 样式表, 图片, Flash等缓存在浏览器的Cache中.

其实我们网站也做了这个优化，至少图片在这个上做过优化，但是没有做完全。我们的CSS和JS都还没有做过优化，倒是外部引入的一个广告JS做了，呵呵。其实设置过期的HTTP Header 更应该做在脚本, 样式表, Flash上.不过据说这个SA也是没有做的，但是有一定的风险，因为JS和CSS是有一定的逻辑，如果服务器端和客户端都存在缓存的话，万一出了什么问题，对我们以后查找问题的所在和增加难度，不过我想两者中是可以权衡和并存的。
4. Gzip components对我们的页面内容进行Gzip格式的压缩，Gzip格式是一种很普遍的压缩技术，几乎所有的浏览器都有解压Gzip格式的能力，而且它可以压缩的比例非常大，一般压缩率为85%，就是说服务器端100K的页面可以压缩到25K左右的Gzip格式的数据发给客户端，客户端收到Gzip格式的数据后自动解压缩后显示页面。

这点我们网站基本上是100%做到了，但是我们这项的评分并没有达到想象中的A级，原因是出在我们的外部链接，比如我们首页，有外部的广告投放JS，这个JS说拥有的网站是没有做过GZIP优化，连累了我们网站，所以我们也只有B，或者C级：（

5. Put CSS at the top把CSS外部链接放到页面的顶部。

其实这个原则我们一般都遵守的，如果把CSS外部链接作为逻辑的一部分出现在页面头部以下，我个人觉得这个本身就是个错误。还好，我们的页面基本上都做到了，可是有些页面比如LIST页面，还是出现了和逻辑挂钩的CSS链接，原因是为了解决一些本来就不合理的产品逻辑。所以，我们WEB前端工程师有义务杜绝这些不合理的产品逻辑破坏我们的页面结果及页面加载速度，不能为了实现而实现。

6. Put JS at the bottom 把Javascript脚本尽量放到页面底部加载。

一开始为以为Javascript脚本尽量放到页面底部加载，是指所有的JS脚本都要放到底部，后来才发现，并不完全是这样，这里所指的脚本是指那些在加载过程中要执行的脚本，所以一般的处理办法还是页面头部引入JS链接，页面底部执行JS脚本程序。为什么要这么做呢？呵呵，其实很简单，为了实现最大的下载并行，页面加载初期做的事，最好只有下载，HTML的下载，CSS的下载,JS的下载，等下载完成后再去实现页面渲染，JS脚本运行。这个方面我们还需要努力，很多页面我们在加载过程中运行了一部分脚本，或许是为了实现一些功能，没有办法，不过或许有更好的办法来替代呢。。。

7. Avoid CSS expressions 避免CSS表达式

其实在CSS中运行表达式和页面加载中运行大量的JS脚本差不多，或许还更慢，而且还不兼容，虽然可以使我们在页面逻辑简单不少，但是我们完全可以抛弃之。这个点，我们的页面基本上都做到了。不过说实话，CSS表达式，嘿嘿，我以前还不知道有这么回事。惭愧。哈哈。

9. Reduce DNS lookups尽可能少的DNS查找。

这项我们做的不是很好。D级，有9个域名，一般不要超过4个。不过这个主要是服务器架构上的问题，我们也无能为力，现在单单首页的广告域名就有好几个，好耶的广告域名，雅虎的广告域名，淘宝店广告域名，打点的域名。如果去掉这些，我们其实还是够用的，一个主域名，一个图片的，一个STYLE的，最多加上IFREAM的刚好4个。

10. Minify JS对Javascript代码进行压缩。

这点我很早以前就对此关注了，也找到了一个不错的压缩工具，yuicompressor，雅虎美国开发的JAVA压缩包yuicompressor.jar。压缩的相当完美，不仅把代码间的空格换行给去除掉了，而且对变量名，北部方法名都进行的简化，无意中实现了混淆脚本的作用。现在我们仅仅做到了JS合并，并没有对齐进行压缩，如果我用yuicompressor手工的去压缩，虽然实现了JS压缩，但是给我们自己的维护量增加了一倍，因为我们需要维护2套JS脚本，一套是压缩前的（调试用的），一套是压缩后（发布到网上的），而且要保证2套代码一致。所以最完美的做法是在发布的时候实现JS脚本合并，并对其用yuicompressor进行压缩，然后发布到晚上，把关键点移到发布的时候，这样我们只需要关心一套JS脚本（发布前的版本）。而且我觉得这个方案完全是行动通的。

11. Avoid redirects 避免重定向（跳转）

怎么理解这点呢？

我们经常遇到的一种做法，注册成功后，旺旺会有一个页面提示“你已经注册成功，3秒后将自动跳转到XX页面”。我就觉得很奇怪，你为什么不直接跳转到该去的页面？还有一种，我们大家非常熟悉，一般我们页面的链接都写成：http://china.alibaba.com或者http://china.alibaba.com/,有人会问，有区别吗？我明确的告诉大家，有！服务器如果接收到的URL是http://china.alibaba.com，它会自动重新定向到http://china.alibaba.com/，虽然最后都打开了阿里巴巴中文站的首页，但是前者比后者多走了一步,重定向，显然多多少少浪费了一定的时间。所以以后我们加URL链接的时候，别忘了把最后的“/”给加上去。

12. Remove duplicate scripts 去除重复的脚本

这个其实没有什么好说的，大家都应该毫无条件的去遵守，但是越是明显，越是简单的事，我们往往会做不好，当然，很多理由的，项目时间太紧张了等等，导致代码很乱，很多重复的地方。其实谁都知道重负不好，不过还好，我们的页面重复的脚本代码不多（至少一个页面里面，呵呵）。不过，我到是希望，我们不仅要做到一个页面脚本不重复，而且要做到N个页面，脚本要重用。

13. Configure ETags 这个好像是服务器端配置的问题，我不太懂，也就不乱说了，怕把大家给误导了。

总共13个，但是看了YAHOO的官方说明，好像还有一个AJAX CACHE(AJAX 缓存)。我倒是觉得这个很重要，随着我们AJAX应用的广泛，AJAX 缓存这个概念一定要时刻在我们脑子中，AJAX是个好东西，但是重复的数据，无休止的向后台申请，绝对是个错误（不仅是速度上还是对服务器压力上来说），所以我们就要对我们已经申请到的数据进行缓存，当第2次用到的时候，就直接从缓存中取，不要在去访问我们宝贵的服务器资源了。其实这个思想不仅仅适合AJAX，在所有有数据复用的应用中都应该考虑到。

YSLOW就分析到这里完毕了，或许有些地方分析的不是很正确，或许有人分析的比我更早，更好，但是这些的确是我从工作中去积累，发现的，并很多都实际应用到工作中去了，顺便说下，嘿嘿，LIST页面进行优化后，在0.92版本的YSLOW评分将达到76分，甚至80分，相当于0.8版本的90分以上。不过评分毕竟是评分，关键还是速度。

本文最初发表《程序员》杂志第三期，现将全文贴上，内容已经过编辑修饰了很多:)

什么是Firebug
从事了数年的Web开发工作，越来越觉得现在对WEB开发有了更高的要求。要写出漂亮的HTML代码；要编写精致的CSS样式表展示每个页面模块；要调试javascript给页面增加一些更活泼的要素；要使用Ajax给用户带来更好的体验。一个优秀的WEB开发人员需要顾及更多层面，才能交出一份同样优秀的作业。为帮助广大正处于Web2.0洪流中的开发人员，在这里为大家介绍一款轻巧灵活的辅助开发工具。

Firebug是Firefox下的一款开发类插件，现属于Firefox的五星级强力推荐插件之一。它集HTML查看和编辑、Javascript控制台、网络状况监视器于一体，是开发JavaScript、CSS、HTML和Ajax的得力助手。Firebug如同一把精巧的瑞士军刀，从各个不同的角度剖析Web页面内部的细节层面，给Web开发者带来很大的便利。这是一款让人爱不释手的插件，如果你以前没有接触过它，也许在阅读本文之后，会有一试的欲望。笔者在撰写此文的时候，正逢Firebug发布1.0正式版，这不能不说是种巧合。

应用
Firebug插件虽然功能强大，但是它已经和Firefox浏览器无缝地结合在一起，使用简单直观。如果你担心它会占用太多的系统资源，也可以方便地启用/关闭这个插件，甚至针对特定的站点开启这个插件。

在安装好插件之后，先用Firefox浏览器打开需要测试的页面，然后点击右下方的绿色按钮或使用快捷键F12唤出Firebug插件，它会将当前页面分成上下两个框架，如图1所示。

图1：Firebug插件展开图示

从图1中看到，Firebug有6个主要的Tab按钮，下文将主要介绍介绍这几方面的功能。
Console HTML CSS Script Dom Net
控制台 Html查看器 Css查看器 脚本条时期 Dom查看器 网络状况监视

Console 控制台
控制台能够显示当前页面中的javascript错误以及警告，并提示出错的文件和行号，方便调试，这些错误提示比起浏览器本身提供的错误提示更加详细且具有参考价值。而且在调试Ajax应用的时候也是特别有用，你能够在控制台里看到每一个XMLHttpRequests请求post出去的参数、URL，http头以及回馈的内容，原本似乎在幕后黑匣子里运作的程序被清清楚楚地展示在你面前。

象C shell或Python shell一样，你还能在控制台中查看变量内容，直接运行javascript语句，就算是大段的javascript程序也能够正确运行并拿到运行期的信息。

控制台还有个重要的作用就是查看脚本的log, 从前你也许习惯了使用alert来打印变量，但是Firebug给我们带来了一个新朋友 —— console.log, 最简单的打印日志的语法是这样的：

如果你有一堆参数需要组合在一起输出，可以写成这样：

Firebug的日志输出有多种可选的格式以及语法，甚至可以定制彩色输出，比起单调的alert，显然更加方便，限于篇幅，这里不做详细说明，但是有志于提高debug效率的读者，可以到Firebug的官方站点（见附录）查看更详细的教程。

图2： 在控制台里调试javascript

查看和修改HTML
第一次看到Firebug强大的HTML代码查看器，就觉得它与众不同，相比于Firefox自带的HTML查看器，它的功能强大了许多。 HTML

首先你看到的是已经经过格式化的HTML代码，它有清晰的层次，你能够方便地分辨出每一个标签之间的从属并行关系，标签的折叠功能能够帮助你集中精力分析代码。源代码上方还标记出了DOM的层次，如图3所示，它清楚地列出了一个hml元素的parent、child以及root元素，配合Firebug自带的CSS查看器使用，会给div+css页面分析编写带来很大的好处。你还可以在HTML查看器中直接修改HTML源代码，并在浏览器中第一时间看到修改后的效果，光凭这一点就会让许多页面设计师死心塌地地成为Firebug的粉丝了。

有时候页面中的javascript会根据用户的动作如鼠标的onmouseover来动态改变一些HTML元素的样式表或背景色，HTML查看器会将页面上改变的内容也抓下来，并以黄色高亮标记，让网页的暗箱操作彻底成为历史。

利用Inspect检查功能，我们还可以用鼠标在页面中直接选择一些区块，查看相应的HTML源代码和CSS样式表，真正的做到所见即所得，如果你使用了外部编辑器修改了当前网页，可以点击Firebug的reload图片重新载入网页，它会继续跟踪你之前用Inspect选中的区块，方便调试。

图3:：HTML查看器

CSS调试
Firebug的CSS调试器是专为网页设计师们量身定做的。

如今的网页设计言必称div+css，如果你是用table套出来的HTML页面，就得按这规矩重构一遍，否则显得你不够时髦！用div做出来的页面的确能精简HTML代码，HTML标签减肥的结果就是CSS样式表的编写成了页面制作的重头戏。Firebug的CSS查看器不仅自下向上列出每一个CSS样式表的从属继承关系，还列出了每一个样式在哪个样式文件中定义。你可以在这个查看器中直接添加、修改、删除一些CSS样式表属性，并在当前页面中直接看到修改后的结果。

一个典型的应用就是页面中的一个区块位置显得有些不太恰当，它需要挪动几个象素。这时候用CSS调试工具可以轻易编辑它的位置——你可以根据需要随意挪动象素。
如图4中正在修改一个区块的背景色。

提示：如果你正在学习CSS样式表的应用，但是总记不住常用的样式表有哪些值，可以尝试在CSS调试器中选中一个样式表属性，然后用上下方向键来改变它的值，它会把可能的值一个个遍历给你看。

图4: CSS查看器，能够直接修改样式表

可视化的CSS尺标
我们可以利用Firebug来查看页面中某一区块的CSS样式表，如果进一步展开右侧Layout tab的话，它会以标尺的形式将当前区块占用的面积清楚地标识出来，精确到象素，更让人惊讶的是，你能够在这个可视化的界面中直接修改各象素的值，页面上区块的位置就会随改动而变化。在页面中某些元素出现错位或者面积超出预料值时，该功能能够提供有效的帮助，你可以籍此分析offset、margin、padding、size之间的关系，从而找出解决问题的办法。

图5：Firebug中的CSS标尺

经常有朋友问下一步应该如何学习，应该学习些什么内容，问自己的未来如何发展等等？我想很多人在迷惑，在徘徊，甚至有朋友怀疑自己职业的价值。

WEB标准第一境界，会用CSS布局，可以脱离table
WEB标准第二境界，能够兼容流行的浏览器，IE5.x——IE7.0，Firefox1.5+，Opera跟Firefox差不多
WEB标准第三境界，语义化的结构，搜索引擎优化初步，WAI（网站亲和力）基础，兼容打印，和手持设备
WEB标准第四境界，模块化的网页编码，大型项目的开发模式，网站前端性能优化，向前向后兼容所有浏览器和设备，搜索引擎优化高级，亲和力WAI1 AAA级（WAI2变动挺大，我不了解）
WEB标准第五境界（某些公司找前端的就要求这些），交互设计，前端编程（Javascript，Flex，AJAX），SEO关键词基本库等等外部技术，后台编程基础
WEB标准第六境境界，WEB前台架构师，负责前端编码架构，做类似与大型WEB2.0产品（Google web2.0，yahoo web2.0，qzone之类的）前端，DISCUZ论坛也很复杂。
貌似自己走的路和上面的也几乎相同，只是对于第四和第五或许应该齐头并进，而自己现在也只才走到这里，路还很远，还有许多东西需要自己去学习。对于第六点，也正是自己所想的下步目标。

当然因人而异，所走过的路有所不同，但最终的目标或许是一致的。

再让我们看看 淘宝 的一则招聘：

前端开发工程师 Web Developer

精通各种Web前端技术，包括XHTML/XML/CSS/Javascript/ActionScript等（JS和AS之一即可）；
深刻理解Web标准，对可用性、可访问性等相关知识有实际的了解和实践经验；
有基于Ajax或Flash的RIA应用开发经验；
至少精通一门非Web前端脚本的语言（如Java/PHP/C++），并有项目经验；
个性乐观开朗，逻辑性强，善于和各种背景的人合作；
计算机、数学、自动化等相关专业本科以上学历优先。
不难看出我们需要学习些什么，没事的时候可以多看看大公司的相应职位的招聘，也能从中找到自己的方向。

努力++

当你感觉无聊，无事时请不要浪费时间，而应该学习学习再学习，因为我们还年轻！