Posts Tagged: 翻译
未分类 — 23 Comments
[转载/翻译]优化浏览器渲染
ISD Webteam的大布同学（twitter：@tc_bryanzhang）牺牲了自己大量的xx时间翻译了Page Speed系列中的Optimize browser rendering，因其blog还在重新打造当中，所以偶这里先转载了，以下是翻译全文：
优化浏览器渲染
资源被下载到客户端后，浏览器仍需加载，解释，并渲染HTML、CSS和Javascript代码。只需利用现有浏览器的特性简单地编排你的代码和页面，就可以提升客户端的性能。
使用高效率的CSS选择器
避免CSS expressions
将样式表放在页面顶部
指定图像尺寸
使用高效率的CSS选择器
避免低效率的匹配大量元素的键选择器【key selectors】可以加快页面渲染。
当浏览器解析HTML时首先构造一个内部文件树来代表所有显示的元素。然后浏览器根据标准的CSS级联、继承和排序规则，为元素指定匹配的各种样式。在Mozilla里的执行情况(可能在其他浏览器也是这样)，CSS搜索引擎通过样式规则为每个元素找到匹配的样式。该引擎由右至左评估每个规则，从最右边的选择器开始（称为“键”【Key】），并通过移动每个选择器，直到找到一个匹配或丢弃的规则。（“选择器”是应用规则的文档元素。）
基于此原则，引擎要评估的规则越少越好。所以提高渲染性能的重要一步就是删除未使用的CSS。在此之后，对包含大量的元素和/或CSS规则的页面来说，优化规则本身的定义就能够提高性能。优化规则的关键在于尽可能具体定义规则，并避免不必要的重复，让样式引擎快速找到匹配的规则,而不用花费时间查找不适用的规则。
下列各类规则被认为是低效的：
后代选择器的规则
通配选择器作为键的规则
body * {...}
.hide-scrollbars * {...}
标签选择器作为键的规则
ul li a {...}
#footer h3 {...}
* html #atticPromo ul li a {...}
后代选择器是低效的，因为对于每个与键相匹配的元素，浏览器必须遍历DOM树，评估每一个祖先元素，直到找到一个匹配或到达根元素。键越不具体，需要进行评估的节点数量就越大。
子代选择器和相邻选择器的规则
通配选择器作为键的规则
body & * {...}
.hide-scrollbars & * {...}
标签选择器作为键的规则
ul & li & a {...}
#footer & h3 {...}
子代选择器和相邻选择器是低效的，因为对每个匹配的元素，浏览器必须评估另一个节点。这样导致规则中的每个子选择器加倍消耗。同样，键越不具体，需要进行评估的节点数量就越大。尽管如此，虽然同样效率低下，在性能方面相对后代选择器而言，它们仍然是可取的。
有多余修饰的规则
ul#top_blue_nav {...}
form#UserLogin {...}
ID选择是唯一的定义。加上标签或类的限制只增加了多余的、引起不必要评估的信息。
对非链接元素应用:hover伪选择器的规则
h3:hover {...}
.foo:hover {...}
#foo:hover {...}
div.faa:hover {...}
非链接元素上的:hover伪选择器在某些情况下*会使IE 7 和IE 8 变慢。当页面没有一个严格的doctype时，IE 7 和IE 8 将忽略除了链接外的任何元素的:hover。当页面有严格的doctype，在非链接元素上的:hover将导致性能下降。
*查看bug报告/IE/feedback/ViewFeedback.aspx?FeedbackID=391387。
避免通配选择器。
允许元素继承祖先的样式，或者使用一个类来给多个元素应用样式。
使您的规则尽可能具体。
尽量使用class和ID选择器而非标签选择器。
删除多余的修饰语。
这些修饰语是多余的:
ID选择器被class选择器和/或者标签选择器限制。
class选择器被标签选择器限制(当一个类只是用于一个标签，无论如何这都是一个很好的设计实践)。
避免使用后代选择器，特别是那些指定多余祖先的。
例如，这一个规则 body ul li a {...} 指定了一个多余的body选择器, 因为所有的元素都是body标签的后代。
使用class选择器代替后代选择器。
例如，如果您需要有序列表项和无序列表项有不同的两个样式，而不是使用两个规则:
ul li {color:}
ol li {color:}
你可以将样式编码成两个类名并在规则中使用，例如：
.unordered-list-item {color:}
.ordered-list-item {color:}
如果您必须使用后代选择器，尽量使用子代选择器，这最少只需评估一个额外的节点，而非中间直至祖先的所有节点。
在IE中避免对非链接元素应用:hover。
如果您对非链接元素应用:hover，请在IE7和IE8中测试并确保页面可用。如果您发现:hover导致性能问题，可以考虑条件性的为IE使用JavaScript onmouseover事件（只对IE写mouseover事件）。
更多关于Mozilla里的高效CSS规则的细节，请看https://developer.mozilla.org/en/Writing_Efficient_CSS。
有关CSS的完整信息，请看Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification。有关CSS选择器的资料，请看Chapter 5。
Back to top
避免CSS expressions
CSS表达式会降低浏览器的渲染性能；用其他方案替换它们将会改善IE浏览器的渲染性能。
注意：本节最佳实践只适用于Internet Explorer 5到7，它们支持CSS表达式。Internet Explorer 8放弃使用CSS表达式，而其他浏览器是不支持的。
作为一种动态改变文档属性来响应各种事件的的手段，Internet Explorer 5引入了CSS表达式或 “动态属性”。它们由在CSS声明中的CSS属性值里嵌入JavaScript表达式构成。在大多数情况下，它们用于以下目的：
模拟其他浏览器支持但IE浏览器尚未支持的标准CSS属性。
使用比编写全面JavaScript注入式样式更小巧，更便捷的方法，来提供动态样式和高级的事件处理。
不幸的是，CSS表达式对于性能的不良影响是相当大的，因为每当有事件触发，浏览器都要重新计算每个表达式，如一个窗口改变大小，鼠标移动等。CSS表达式的低性能表现是IE 8弃用它们的原因之一。如果你在网页里使用CSS表达式，应该尽一切努力来消除它们并且使用其他方法来达到同样的功能。
尽可能使用标准的CSS属性。
IE 8已高度兼容标准CSS；IE 8只有在“兼容”模式才支持运行CSS表达式，而在“标准”模式下则不支持。如果你不需要向后兼容旧版本的IE，你应该转换成标准的CSS属性来替换所有对应的CSS表达式。如需CSS属性和支持它们的IE版本的完整列表，请参见MSDN的CSS属性索引。如果你确实需要支持所需CSS属性不可用的旧版本IE浏览器，请使用JavaScript来实现等效的功能。
使用JavaScript脚本样式。
如果你正在使用CSS表达式来实现动态样式，用纯JavaScript重写它们是很有意义的，因为这样既能提高IE性能，同时在其他浏览器获得相同效果的支持。在这个由MSDN动态属性页提供的例子里，下面的CSS表达式用于在浏览器里居中一个HTML块元素，并且该元素的尺寸可以在运行时改变，每次调整窗口大小都能重新定位在浏览器中心：
&div id=&oDiv& style=&background-color: #CFCFCF; position:
left:expression(document.body.clientWidth/2-oDiv.offsetWidth/2);
top:expression(document.body.clientHeight/2-oDiv.offsetHeight/2)&&Example DIV&/div&
下面是一个使用JavaScript和标准CSS的等价例子：
#oDiv { position: background-color: #CFCFCF;}
&script type=&text/javascript&&
// Check for browser support of event handling capability
if (window.addEventListener) {
window.addEventListener(&load&, centerDiv, false);
window.addEventListener(&resize&, centerDiv, false);
} else if (window.attachEvent) {
window.attachEvent(&onload&, centerDiv);
window.attachEvent(&onresize&, centerDiv);
window.onload = centerD
window.resize = centerD
function centerDiv() {
var myDiv = document.getElementById(&oDiv&);
var myBody = document.
var bodyWidth = myBody.offsetW
//Needed for Firefox, which doesn't support offsetHeight
if (myBody.scrollHeight)
bodyHeight = myBody.scrollH
else bodyHeight = myBody.offsetH
var divWidth = myDiv.offsetW
if (myDiv.scrollHeight)
var divHeight = myDiv.scrollH
else var divHeight = myDiv.offsetH
myDiv.style.top = (bodyHeight - divHeight) / 2;
myDiv.style.left = (bodyWidth - divWidth) / 2;
如果您使用CSS表达式来模拟早期IE版本中不可用的CSS属性，你应该提供版本测试的javascript代码，为支持CSS的浏览器禁止CSS表达式。举例来说，max-width属性，这个属性在一定数量的像素范围内强制文本换行，在IE 7前是不支持的。下面的CSS表达式作为一种解决方法，为IE 5和6提供了这个功能：
p { width: expression( document.body.clientWidth & 600 ? &600px& : &auto& ); }
为不支持此属性的IE浏览器版本使用等价的JavaScript替换CSS表达式，可以使用类似于下面的内容：
p { max-width: 300 }
&script type=&text/javascript&&
if ((navigator.appName == &Microsoft Internet Explorer&) && (parseInt(navigator.appVersion) & 7))
window.attachEvent(&onresize&, setMaxWidth);
function setMaxWidth() {
var paragraphs = document.getElementsByTagName(&p&);
for ( var i = 0; i & paragraphs. i++ )
paragraphs[i].style.width = ( document.body.clientWidth & 300 ? &300px& : &auto& );
Back to top
将样式放在页面头部
将内联样式块和&link&元素从页面&body&移动到页面&head&中，这样能提高渲染性能。
在HTML文件&body&中指定外部样式表和内联样式块可能对浏览器的渲染性能产生不利影响。浏览器阻塞渲染网页直到所有外部的样式表都已被下载。（用&style&标记指定的）内联样式块可能会导致reflows和页面跳动。因此，把外部样式表和内联样式块放在页面的&head&中是很重要的。通过确保样式表首先被下载和解析，可以让浏览器逐步渲染页面
HTML 4.01规范（第12.3节）规定，始终把使用&link&标签的外部样式表放在&head&部分里。不要使用@import。还要确保您指定的样式有正确的顺序。
把&style&区块放在&head&部分里。
Back to top
指定图片尺寸
为页面中所有图片指定宽度和高度可以消除不必要的reflows和重新绘制页面【repaints】，使页面渲染速度更快。
当浏览器勾画页面时，它需要能够流动的，如图片这样的可替换的元素。提供了图片尺寸，浏览器知道去环绕附近的不可替换元素，甚至可以在图片下载之前开始渲染页面。如果没有指定的图片尺寸，或者如果指定的尺寸不符合图片的实际尺寸，一旦图片下载，浏览器将需要reflows和重新绘制页面。为了防止reflows，在HTML的&img&标签中或在CSS中为所有图片指定宽度和高度。
指定与图片本身相一致的尺寸
不要使用非图片原始尺寸来缩放图片。如果一个图片文件实际上的大小是60×60像素，不要在HTML或CSS里设置尺寸为30×30像素。如果图片需要较小的尺寸，在图像编辑软件中，设置成相一致的尺寸(详见优化图像。)
一定要指定图片或它的块级父元素的尺寸
一定要设置&img&元素本身，或它的块级父元素的尺寸。如果父元素不是块级元素，尺寸将被忽略。不要在一个非最近父元素的祖先元素上设置尺寸。
Back to top
注：浏览器为了重新渲染部分或整个页面，重新计算页面元素位置和几何结构的进程叫做reflow
————————
补充 —————————–
Google后来对此文档做了更改，新增部分翻译见对《优化浏览器渲染》的补充【译】
未分类 — 11 Comments
[翻译]OOCSS FAQ
原文：/stubbornella/oocss/faq（翻译时为Version 28）
翻译：ytzong
在OOCSS中怎么定义“对象”？
对象类似JAVA中的类，保持着OO的特征。
一个CSS对象由4部分组成：
可能是一个或多个DOM节点的HTML
由wrapper节点的class名开始的CSS样式声明
类似于背景图片和显示用的sprites组件以及
JavaScript行为，监听或者与对象关联的方法
这可能令人费解，因为每个CSS class不是其自身必要的对象，但可以是一个wrapper class的一个部件。比如：
&div class=&mod&&
&div class=&inner&&
&div class=&hd&&Block Head&/div&
&div class=&bd&&Block Body&/div&
&div class=&ft&&Block Foot&/div&
对象是一个class为mod的模块。包括4个部件节点（不能独立于模块外，包括2个区块，inner和body，和两个可选择的区块，head和foot）
OOCSS如何提升性能？
OOCSS具有双倍的性能优势：
高度重用的CSS代码，只需要很少的CSS代码，意味着：
更小的文件，从而更快的传输
CSS代码在站点页面中调用的比重增大则有希望被复用或被浏览器缓存
就浏览器而言更少的重绘和布局计算
单个页面，CSS规则复用的越多，渲染引擎花在“computed values”的计算时间越少
手动增加的”extending”类，重写更少的规则，这再一次意味着引擎做很少去应用规则
要用ID来对内容写样式吗？
当你在同一页面（或者同一站点同时缓存良好）复用一个对象时，这是性能的“免费赠品”。用ID来写样式在同一页面中只能使用一次。@cgriego (twitter)拿它与singletons比较过，我认为非常精确。可能有些情况下你要用ID定义样式，比如非常特殊的header menus，此时你可以在用ID来沙箱（译注：动名词）特殊元素并确保此处的代码不会影响站点的其它地方。选择ID而非class前要三思，随着站点的发展，真的很难预料其他人会怎么处理依据你的CSS所构建的HTML。如有选择的余地，尽可能的考虑扩展性。
我正在考虑移除模板head, body, foot中的ID。某些人或许有多个主区域。站点的多个header 和 footer更难以猜测，但我敢打赌肯定有设计师会这样想，所以ID很可能会消失（不太顺，看原文：Someone could have multiple main content areas. Multiple site headers and footers are more difficult to imagine, but I bet there is a designer who can dream up something like that, so the IDs are very likely to disappear.）。
另一方面，ID hooks 对链接非常有用(译注：做锚点使用)。放在HTML中，不过别用它们来写样式。
设计师可以写OOCSS吗？
是的，设计师出于本能理解对象，比多数人当前书写CSS的方式要形象 — layers of exceptions (想一下，一个老太太吞了一只苍蝇)。事实上，他们爱上OOCSS的原因有两个：
这使他们能快速创建复杂高点击量的站点。他们不需纠结于不理解的结构除非有足够的能力并充足的了解语法
学CSS时，他们不需创建丑陋的 “hello world!” 站点。设计师在非常在意的是他们的工作看起来很漂亮。如果必需做一些丑陋的东东，即便是学习之由，他们很快就会有挫败感并灰常的郁闷。OO-CSS使得他们的工作在每个学习阶段都看起来很漂亮
设计师是聪明D。我们要给他们信任。他们会讲一种不同的，非工程师的语言，但是极客的语言经常以一种丑陋的方式来拒绝人。我们能做的更好。
我是个前端架构师，如何向团队传授OOCSS？
作为架构师，你应该写结构对象；圆角如何创建，为角或其他特性放置表象元素，并处理浏览器差异。新手为这些模块写皮肤（borders, colors, background images, 等等）。
我用OO-CSS方式创建了大批站点（千级的页面，百万级的访问者）。正确的完成后，很好扩展，这意味着新手将处理的个别元件可预见性很强。代码审阅很容易，因为有可接受的方法明确的规则来扩展对象。这种回馈使新开发者快速生产。
我在FullSIX（一个法国的网络营销机构）管理一个前端开发团队，是我工作过的最有才能的。某些时候我们的成功意味着我们将会有更多难以把控的工作。雇佣前端专家非常困难（没有这种学校！），所以我开始对一些对写代码有兴趣的设计师（很少或没有经验）推行一个内部实习项目，一个月就可以作为团队的初级成员工作。
第一周：学习语义并根据现有的CSS创建HTML。学习创建网页：不需要更多的CSS，HTML语法，多个class，验证，语义，介绍代码审阅等
第二周：创建简单的内容对象（标题，列表等），持续一周。学习CSS语法，怎么扩展对象，颜色，字体百分比，等等
第三周：创建区块的皮肤。边框，颜色，背景图片，基本的布局，sprites。让他们同一个回答过n个问题的资深开发者一起工作，使他们少走弯路，他也应是很好的代码审阅者。
第四周：他们已经是团队的皮肤制作成员了。
他们的代码在一个客户的网站上，同资深开发者写的一样好，或许更好因为他们还未学到一些坏习惯:)
入门：如何使用这些文件？
3个文件，libraries.css (reset 及 fonts 取自 yui), grids.css 及 template.css 已完成，其它的还非常不稳定。
打开template.html并存为新文件
通过扩展相应的对象来改写列的数量及宽度。站点中只需一个模板，即使你有不同列的页面，因为列也是对象。可以把它们当作任意的区域，可能会有0 ~ n个左列。查阅模板文档可了解更多
用栅格来分割内容区域为小的区块。查阅栅格文档了解更多
添加内容。提示：这也应OO
如何部署在站点上？
注意CSS文件在不断改进中，我会依据接到的反馈进行改变。
我把CSS文件分为了模块，比如栅格和模板。在使用时移除不必要的注释并减少HTTP请求，否则站点会超级慢。这意味着要合并CSS文件为一个稍大的文件。我通过嵌套的注释来组织CSS。最后，作为上线/部署的一部分，用CSS压缩器来移除注释.
可以修改文件，或者用我自己的样式重写吗？
我不会修改grids, template, 或者 libraries。大量测试表明这些已恰到好处。如果要自定义，考虑下面的扩展基本对象。
粉红不是我要的颜色！怎么处理content.css？
获取你会想要修改content.css。去吧，改颜色，字体大小，大小写。只需注意这个文件在快速发展，同时我还没有任何文档来说明如何正确的处理。我会这么做，我保证。
我需要不只6种标题（h1~h6），如何增加？
如果需要不只6中标题样式，通过添加一个新class来扩展标题对象。
.category{font-size:108%; font-weight: font-style: text-transform: color: #333;}
不要这样做：
#mySaleModule h2, #mySaleModule .h2{font-size:108%; font-weight: font-style: text-transform: color: #333;}
如何扩展对象？
如果要扩展对象，比如一个160px的左列，而非默认值，你可以再列上增加额外的class。
&div class=&leftCol gMail&& ... &/div&
如果默认值和扩展的列宽或者页面不适合你的站点，你可以扩展列来实现自定义的宽度。
myColumn 扩展列对象来实现自定义列宽。
.myColumn{width:400}
&div class=&leftCol myColumn&& ... &/div&
不要通过重写我的class来实现，而应扩展此框架提供的对象。我提供了列，标题及其他对象。你可以通过增加另外的class（只指定与我的基本对象的不同点）来扩展这些对象。相对而言此处混合比较好。
不要这样做（因为更新我的框架时会有些麻烦）：
.leftCol{… 此处自定义CSS …}
没有用到的样式。我的站点没有160px的gmail式的列，可以移除吗？
当然。移除对象或扩展对象非常合理。只需注意在站点发展时，很难预料到其他人用你的CSS创建的什么样的HTML。过早优化很危险。
为什么有一个单独的模板？
在OOCSS中，一个重要的目标是所有的页面创建自一个模板。这简化了CMS开发，因为有一个单独的起始点所有页面可以制作为其他的页面。CMS的用户不会落入已创建的页面不能变种为不同的页面类型的陷阱。OO模板的另一个目标是每一个section（列，header等）控制自己。实际上，这意味着如果要在模板上增加一个左列，只需在HTML中增加此列。你从来不想这样写CSS吧，为了使子元素满足表现而DOM树需要很多改变。对CMS开发来说DOM循环相当的昂贵。
这有语义吗？我要终止像 .formYellow 或 tinyBlueH2 的class命名吗？
OOCSS可以写得有语义也可无语义，取决于你创建模块时用 errorMod 而非 bigRedModule。我选择class名优一些原则（排名不分先后）：
短 – 每一字节计算起来，所以尽可能保持class短
清晰 – 可预料的行为/样式要显而易见
语义化 – 对象是什么高过看起来像什么。如何用在站点中？
通用 – 名称应该适用于多数站点。过于特殊的名称减少了适用场合或导致语义化的class以非语义化的方式使用
屏幕 – 移动阅读器或打印样式或许有不同的视图，会重写默认的屏幕视图，所以当有冲突时class为屏幕而特殊定义（Different views might be provided by mobile or print stylesheets, however they override the
default screen view, so the classes chosen are screen specific when there was a conflict）。这简化了开发。
其它的框架如何？这只能同YUI一起使用吗？
在大量框架的生态系统中，YUI是专业性及可扩展性的一例。我同他们进行了对比，因为我不断受到他们代码和文档的影响。OOCSS不是一个真正意义上的框架，尽管我创建了很多例子，而是一种书写可扩展，健壮，可维护性强的CSS的一种方式。也许最好的比喻是一个新的语言。最终，它是未知的JavaScript库（it is JavaScript library agnostic），我希望贡献代码回YUI及其他框架。
CSS框架太超过！我需要从头开始编写所有代码吗?
每需要一个随机数字都要写一个数字class吗？
CSS is hard,not because it is broken , but because it is a legitimate technology requiring expertise to architect correctly. 为每个站点重复发明轮子非常的愚蠢。
源文件中右列在主列之前，会影响可访问性，SEO吗？
我早期工作过的站点有更标准的模板结构，body上有一个极好的class，依靠这个模板显示或隐藏左右列。自定义CMS的用户要创建一个3列布局的页面时非常沮丧，发现需要两列，找到它们不得不一个个从头开始，因为有多个模板/起始点。你或许注意到主列是个流体列，在左右两列渲染后自适应剩余的空间。
我更喜欢标签排序胜过视觉排序（因为如果标签顺序改变会变得非常怪异），但是我也只想要一个模板。在web开发中经常遇到的是，两个重要的目标发生了冲突，我做判断如何解决。这种情况下标签排序满足视觉顺序除了右列。在当前的代码中，只需在HTML增加一个左或右列，没有别处昂贵的DOM变化。
屏幕阅读器用户有两个选择：
导航链接经常为一个链接列表或嵌套的链接列表形式。这非常有趣，因为这允许屏幕阅读者通过屏幕阅读器的特殊操作设置跳过整个列表。
我的意见是对于跳过菜单这两种方式足够了。
每个人似乎都有一个回复观点：SEO，它们都不同，甚至相反。:)基于这个思潮，我倾向于：尤其对含有一定合理数量链接的导航菜单，不用太过在意。曾几何时，我看到过导航链接被索引在搜索结果的内容部分，不过是在几年前了。搜索爬虫非常智能，我已经准备好想当然的认为如果我以语义化，干净的方式标记内容，并非填充一坨垃圾链接，爬虫能区分的出来。
把导航菜单标记为列表，允许屏幕阅读器用户跳过，并提供“跳至内容”链接，对可访问性提供了双倍的备用措施。
为什么用了_ hack？我能把这些代码放在单独的文件中吗？或者添加IE专有的class？
很显然，首先考虑的是尽可能少和长远。
添加一个单独的样式表奖增加一个额外的HTTP请求，增加整体文件的大小，这早已是浏览器性能的对立点
我喜欢把一个对象的代码放在一个地方。我认为这有助于减少hack的数量，尤其是当项目随时间而发展
IE6-的开发工具非常原始，这使得hack和普通代码放在一起更加重要。我想能尽快找到一个可以使用属性的IE bug。同样，我认为这有助于减少hack
规则表明浏览器理解不了的属性会被忽略。对IE6-使用_早已众所周知，可以合理的预料好的浏览器将会忽略这个属性
使用条件注释意味着每个HTML页面必须包含一个IE专用样式。某一天（我不能等了！）当IE6的市场份额下降至像IE5那样低时，我将去除这些代码，但最后我要做的是触及百级或千级的HTML页面。我宁愿只有依赖CSS hack的CSS，而不是把它放在HTML中。不幸的是，恕我直言，IE6兼容性的末日比我们期望的要更加长远，因为IE中的quirksmode会回落到IE5.5的模式
我认为我的选择有助于减少hack的总体数量，提升性能，并只有忽略不计的风险。话说回来，如果觉得代码中的_令你作呕，你完全可以移至单独的文件。
为了添加表象效果比如边框而使用空 &b& 标签容器对象，会给屏幕阅读器用户带来问题吗？
不会，幸运的是屏幕阅读器会忽略空的b标签。使用这个表象标签（b是加粗）来实现表象具有优势。这个标签可以通过服务器端脚本包含，以至于有一天所有的CSS圆角和阴影都支持了，可以关闭脚本并拥有漂亮，干净，语义化的HTML。
OOCSS声称避免位置依赖的样式。是否意味着我不能使用类似 .myModule .title 的派生选择器？
不使用派生选择器没什么阻碍，只是把它们放在更高的DOM树而已。避免在body或页面中最外层的div放置wide-net class或id，然后对对象产生的变量写大量的样式。这不能复用，同时会使页面渲染变慢。相反，通过直接在对象上添加一个class来增加一个多余的“local”变量（并对其子元素写派生样式）。
一个好的经验是一个容器主体（body of a container）内的任意元素显然是一个单独的对象。
这无可厚非，因为UL显然是一个单独的对象：
#sidebar ul { ... }
因此，carousel显然不是body对象的一部分：
body.browseProducts .carousel
这是适当的层叠应用，因为子节点真正的是较大的父对象的一部分。b（角）和inner显然隶属于moudle，它们不能独立存在：
.myModule { ... }
.myModule b { ... }
.myModule .inner { ... }
如何贡献？
最好的方法是涉足其中，开始使用代码（libraries, grids, fonts）并提交bug 报告及功能需求。 我建了一个OOCSS google group 来进行超过140个twitter字符的讨论。
OOCSS的官方站点为 http://oocss.org，有一些例子及下载等。
未分类 — 5 Comments
[翻译]Object Oriented CSS
什么是面向对象的 CSS
框架？工具？哲学？
Object-oriented CSS is a coding paradigm that styles “objects” or “modules”—nestable
chunks of HTML that define a section of a webpage—with robust, reusable styles.
很像语言的进化
令 CSS 更强大
有什么不同？
ul li{...}
ul li a(②但是，结构在这里){①直至现在，我们只关心这里}
CSS 大约 2005
意大利面条
CSS 大约 2008
稍微好一点
而不是使我们的代码变好
我们筑了大栅栏
公认的毒药中心
文件大小和 HTTP 请求未作优化
CSS 大约 2009
面向对象的CSS
性能的最佳实践、可扩展性、和最重要的-容易使用
创建对象而不是页面或模块
在内容对象上设置好的公用默认值
抽象重用元素
分离结构和皮肤(为两个 class)
分离容器和内容(开放的编辑区)
对看起来 OO 的应用多个 class
9条最佳实践
组件库：可重用和冗余
一致性：避免位置依赖(location-dependent)的样式
优化图像和 sprites
学会爱栅格
避免非标准的浏览器字体
避免高度对齐(alignment)
谨慎卖弄你的技术(choose your bling carefully)
位置依赖的样式
避免指定一个 class 的标签
避免用 ID 定义主内容区域内的样式
避免不规则背景上阴影和圆角
不要拼合所有图片(触发只有少数几个页面)
避免高度对齐
文字就是文字，不要做成图片
避免过早优化
创建组件库
可重用的“乐高积木”
重用元素使得它们
性能“免费”
组件就像乐高积木
组合并匹配来创建不同的和有趣的页面
从组件库创建 HTML
新的页面一般不需要额外的 CSS
根据你需要的语义来完成你想要的表现
必须对页面中的所有模块可用
SIDE-WIDE LOGES
列表(比如 action list, external link list, product list, 或 feature list)
模块 headers 和 footers
圆角 boxes
Tabs, Carousel, toggle blocks
在不能增加价值的元件上浪费性能资源
近似相同的模块
h3 和 h5 太相似了
经验法则：
如果一个页面中的两个模块看起来太相似，它们在一个站点中太相似，选择一个！
Yahoo! 个人财经
2+不同的 tab 风格。能用相同的图像吗？
3个元件的轮廓太相似了。选择一个。
模块宽度、背景色或背景图片的改变是个很好的模块复用的例子。
避免位置依赖(location-dependent)的样式
沙盒比意大利面条好，不过引起了性能问题
避免什么？
在 CSS 中我们一直这么做
#weatherModule h3{color:}
#tabs h3{color:}
h3 的全局颜色未定义，将导致
在新模块中没有定义样式
开发者被迫为相同的样式写更多 CSS
h3{color:}
#weatherModule h3{color:}
#tabs h3{color:}
定义了全局颜色(更好！)
Weather 和 tabs 覆盖了缺省的 h3
h3 的3种样式在同一模块中不能并存
缺省样式不能用在 weather 和 tabs 除非有更高的优先级
Weather 和 tabs 的 h3 永远不能在其他模块中使用
写更多规则去重写之前的疯狂规则。
比如标题在任意模块的表现是可预见的。
用这个来代替
h1, .h1{...}
h2, .h2{...}
h3, .h3{...}
h4, .h4{...}
h5, .h5{...}
h6, .h6{...}
定义全局值
遵循语义(同时允许灵活的视觉)
需要超过6个标题？
真的吗？没有重复？没有相似的？
仍然需要更多标题？
.category{...}
.section{...}
.product{...}
.prediction{...}
通过对象本身的 class 扩展标题对象
避免使用继承来改变嵌套对象的表现
复用代码段
是抽象不同水准的语义失败所导致的
容器和内容
结构和皮肤
轮廓和背景
对象和混合物
分离容器和内容
定义每个对象的界限
开放的编辑区
图像或 flash
混合与匹配
容器和内容对象达到高性能设计
分离轮廓和背景
内部透明！
MAKING IT LOOK FAB
需要小心选择像素
考虑 PNG8 来渐进增强
可变的或渐变背景
提防圆角后的可变或渐变背景
分离结构和皮肤
两个单独的 class
示例：模块
Sloves borwser bugs, positions presentational elems, and generally does the heavy
lifting of CSS
弄漂亮些。
目标是非常明确的皮肤，复杂的被结构对象和跨网站共享所吸收(The goal is very predictable skins, complexity is
absorbed by the structure object and shared across the site)。
/* ----- simple (extends mod) ----- */
.simple .inner{
-moz-border-radius:7
-webkit-border-radius:7
border-radius:7
.simple b{
*background-image:url(skin/mod/corners.png);
什么属于皮肤？
皮肤的每个值应该是确定的，容易预测并测量。
可延长的高度和宽度
Limit the ways in which a module can be resued
学着爱上栅格
坚信其会很美
传授 OO CSS
给设计师和工程师
从简单到复杂的任务
一个真实案例
Gonzalo Cordero Yahoo! 前端开发工程师
需要考虑的设计因素
跨浏览器兼容
多语言支持
按时完成全部布局和功能
为什么“简单的东东”变复杂？
为什么要妥协？
为什么我们不能依固定的规则和结构？像讲台上那样？
OOCSS SAVES THE DAY
单个简单的标签结构
跨浏览器支持(甚至 IE 5.5！)
非常少的 CSS
可剥离的，容易应用在多个设计上
这不仅仅是 OOCSS！
本文内容来源于：
Object Oriented CSS 高清视频下载
What is Object Oriented CSS?
The Fast And The Fabulous
The Cascade, Grids, Headings, and Selectors from an OOCSS Perspective, Ajax Experience 2009
After YSlow “A”
Design Fast Websites
由 ytzong 翻译整理，算是把 Yahoo! 女性能工程师 Nicole Sullivan 给“榨干”了，嘿嘿。 另外，之前的《驯服CSS选择器》也是她的作品，富含 OOCSS 的思想。
未分类 — 6 Comments
[翻译]加速 JavaScript：处理 DOM
原文：Speeding up JavaScript: Working with the DOM
作者：KeeKim Heng, Google 页面工程师
翻译：ytzong
当制作 RIA(Rich Internet Application) 时，我们使用 JavaScript 来改变或增加元素。这是靠 DOM (Document
Object Model 文档对象模型) 来完成的，这是如何影响 app 的速度呢？
处理 DOM 会使浏览器 reflow (浏览器决定如何显示东东的进程)。直接操作 DOM，改变元素的 CSS 样式，改变浏览器窗口的大小会触发 reflow。访问元素的布局属性(如offsetHeight 和 offsetWidth) 会触发 reflow。由于每次 reflow 需要时间，所有我们能减少 reflow 越多，app 越快。
处理 DOM 不仅操作页面中存在的元素还包括创建的元素。下面四个部分覆盖了 DOM 操作和 DOM generation，减少浏览器中 reflow 触发的次数。
CSS class 切换 DOM 操作
这个部分我们改变一个元素和它后代的多个样式属性，只触发一次回流。
我们写一个函数来改变一个元素中的所有链接的 className 属性。可以通过简单遍历每个 a 并更新他们的 className 属性。
function selectAnchor(element) {
element.style.fontWeight = 'bold';
element.style.textDecoration = 'none';
element.style.color = '#000';
我们可以增加一个设置所有样式属性的 class 来解决这个问题。通过给元素增加这个class，现在我们只触发一次浏览器 reflow。同时分离了表现和行为(译注：这个在我之前的《body标签class属性的妙用(Google Reader前端简单分析)》中也有提及)
.selectedAnchor {
font-weight:
text-decoration:
color: #000;
function selectAnchor(element) {
element.className = 'selectedAnchor';
Out-of-the-flow DOM 操作
这个部分我们创建多个元素并把它们插入 DOM 只触发一次 reflow。使用了叫做 DocumentFragment 的东东。我们在 DOM 外创建一个DocumentFragment (所以是 out-of-the-flow)。之后创建并添加进多个元素。最后，我们移动该 DocumentFragment 中的所有元素到 DOM，这只触发一次 reflow。
让我们写一个改变一个元素中所遇链接的 className 属性的函数。通过简单的遍历每个 a 并更新他们的 href 属性。问题在于，每个 a 会触发一次reflow。
function updateAllAnchors(element, anchorClass) {
var anchors = element.getElementsByTagName('a');
for (var i = 0, length = anchors. i & i ++) {
anchors[i].className = anchorC
解决这个问题，可以从 DOM 中移除元素，更新所有链接，之后插入回元素到原始位置。为此，我们写一个可复用的函数，不仅从 DOM中移除元素，并且返回一个将会插入回元素至元素位置的函数。
* Remove an element and provide a function that inserts it into its original position
* @param element {Element} The element to be temporarily removed
* @return {Function} A function that inserts the element into its original position
function removeToInsertLater(element) {
var parentNode = element.parentN
var nextSibling = element.nextS
parentNode.removeChild(element);
return function() {
if (nextSibling) {
parentNode.insertBefore(element, nextSibling);
parentNode.appendChild(element);
现在我们用这个函数去更新一个元素中的所有链接，这 out-of-the-flow，并且在移除元素时和插入元素时只触发一次 reflow。
function updateAllAnchors(element, anchorClass) {
var insertFunction = removeToInsertLater(element);
var anchors = element.getElementsByTagName('a');
for (var i = 0, length = anchors. i & i ++) {
anchors[i].className = anchorC
insertFunction();
单个元素的 DOM Generation
这个部分我们创建并添加一个元素至 DOM 中，仅触发一次 reflow。创建元素后，在新元素添加至 DOM 前做好所有的改变。
写一个添加新a 元素至父元素的函数。这个函数让你为该链接提供 class 和 文本。我们可以创建元素，添加进 DOM，之后设置这些属性。这触发3次 reflow。
function addAnchor(parentElement, anchorText, anchorClass) {
var element = document.createElement('a');
parentElement.appendChild(element);
element.innerHTML = anchorT
element.className = anchorC
最后插入这个子节点至 DOM。这触发一次 reflow。
function addAnchor(parentElement, anchorText, anchorClass) {
var element = document.createElement('a');
element.innerHTML = anchorT
element.className = anchorC
parentElement.appendChild(element);
尽管如此，如果我们要添加大量的链接至一个元素时这有一些问题。通过这个方法，每添加一个链接触发一次 reflow。下一部分解决这个问题。
DocumentFragment DOM Generation
这个部分，我们创建多个元素并把它们插入 DOM 触发一次 reflow。使用了一个叫做 DocumentFragment 的东东。我们在 DOM 外创建一个DocumentFragment (所以是 out-of-the-flow)。之后创建并添加多个元素进来。最后，把所有DocumentFragment 中的元素移至DOM 并只触发一次 reflow。
写一个添加10个连接至一个元素的函数。如果只是简单的添加每个新链接至这个元素，会触发10次 reflow。
function addAnchors(element) {
for (var i = 0; i & 10; i ++) {
anchor = document.createElement('a');
anchor.innerHTML = 'test';
element.appendChild(anchor);
为了解决这个问题，我们创建一个 DocumentFragment 并添加每个新链接至此。当我们使用appendChild 添加 DocumentFragment至元素时，所有 DocumentFragment 的子节点 实际上添加进了这个元素中。这只触发一次 reflow。
function addAnchors(element) {
var anchor, fragment = document.createDocumentFragment();
for (var i = 0; i & 10; i ++) {
anchor = document.createElement('a');
anchor.innerHTML = 'test';
fragment.appendChild(anchor);
element.appendChild(fragment);
未分类 — 6 Comments
[翻译]用Page Speed Activity捕获并分析浏览器渲染
原文：Capturing and analyzing browser paint events using Page Speed Activity
作者：Bryan McQuade, 软件工程师
翻译：ytzong
Page Speed 是一个 Firebug/Firefox 扩展，安装地址：/speed/page-speed/download.html
背景：逐步呈现
快速的网页逐步呈现。即随浏览器的加载而逐步显示其内容。一个逐步呈现的页面给浏览者页面在加载的视觉回馈，并尽快给给用户请求信息。Google和Yahoo 都建议逐步呈现页面，比如把 CSS 写在页面 head 中。
对多绝大多数页面来说，有一些很好的实践来优化逐步呈现。一个快速的页面应该先给用户呈现可见的内容(译注：浏览器第一屏)，随后呈现视线外的内容(即当前滚动区域外的内容)。一个快速的页面会在加载和渲染重量级的资源(如图片和视频)之前加载和渲染轻量级的资源(如文字)。
一些众所周知的技术会禁止逐步呈现。使用大量表格，甚至用来布局，在一些浏览器中会使逐步呈现失效。应用样式表在页面后方，即便这些样式表在开始的页面加载中使用不到，也会阻止逐步呈现。
用Page Speed Activity捕获浏览器渲染
很难决定一个页面是否要进行逐步呈现优化。大多数页面对肉眼来说呈现太快，以至于意识不到个别的渲染事件(尤其是在高速网络连接下)，而且看不到屏幕区域外的内容是否呈现了。
幸运的是，Firefox 3.5 支持捕获浏览器渲染事件。Page Speed Activity 面板用这个功能可为页面呈现过程录制一个“幻灯片”。幻灯片的每一单元显示了哪一个屏幕区域被渲染(黄色)，哪些区域在屏幕外(灰色)用户看不到。
启用渲染快照
由于捕获渲染快照会增加一些开销并拖慢浏览器，Page Speed Activity 屏幕快照默认是禁用的。启用渲染快照，确保Activity 下拉菜单中的”Paint Snapshots (slow)” 被选中。
Activity 面板中的渲染快照
一旦渲染快照启用，就开始用 Activity 面板录制。Activity 面板将在时间线上显示网络，缓存，和 JavaScript 事件。渲染快照幻灯片出在Activity 面板右侧。渲染快照会按捕获顺序绘制，最早的快照在顶部。拖动右侧的滚动条可看到所有的快照。
快照回放示例
译注：请到这里看演示
在这个例子中，我们可以看到以渲染快照慢动作回放的 Google 搜索结果页面的逐步呈现。这些快照用 modem 连接捕获。
用 Page Speed Activity 回放这个例子的渲染快照，请点击 Play Paint Events按钮。
在快照中，用户可见的区域为白色，用户不看见的区域(当前浏览器滚动区域之外)用灰色遮罩。每个快照用黄色遮罩显示重绘区域。
请注意，可见区域的文本内容首先呈现，之后是屏幕外的文本内容。通过先呈现屏幕内的可见区域，用户尽早获取了尽可能多的有用信息。
文本内容呈现后，图像内容接着呈现。推迟图像内容呈现直到文本内容下载完成并呈现完成，这使得浏览器尽早的显示文本内容，再一次尽早给用户尽可能多的有用信息。
在页面标签中给所有图像指定宽度和高度属性，浏览器不需在图像加载后 reflow 页面。尽管没有严格的与逐步呈现有关，指定图像的宽高会带来更好的用户体验，在页面加载时页面内容不会在附近移动。
最后，注意图像自身的逐渐呈现。允许用户在全部图像完成加载前看到图像内容。现代浏览器在 HTML 中用 &img& 标签逐步呈现图像。相反，许多浏览器中用CSS 的background-image 属性不会逐步呈现。为了逐步呈现图像，用 HTML 的 &img& 标签来代替 CSS 的 background-image属性。
使用 Page Speed Activity 面板的渲染快照功能，我们可以清晰的观察页面的逐步呈现行为。这使得网页开发者可以为逐步呈现而优化页面，这是快速网页非常重要的特性之一。
Page Speed – 开源的 Firefox/Firebug扩展，评估页面性能并捕获屏幕快照
Web Performance Best Practices: Put CSS in the document head – Google 的最佳网页优化实践讨论 CSS 放在页面
head 的重要性
Response Times: The Three Important Limits – Jakob Nielsen 指出了一些关于响应时间的经验准则，并强调当页面加载过程中给用户持续反馈的重要性
How Design Affects Performance: Progressive Rendering – 做了一个非常好的并排视觉对比来说明逐步呈现的好处，讨论了HTML表格对逐步呈现的影响
High Performance Web Sites: Put Stylesheets at the Top – Steve Souders 的第一本网页性能的书介绍了如何加载样式表可以禁止逐步呈现
Charles Web Debugging Proxy – Charles 允许网页开发者调节他们的网络连接，去模拟低速用户的页面加载
未分类 — 5 Comments
[翻译]驯服CSS选择器–健壮我们的样式表
PPT:Taming CSS Selectors
作者：Nicole Sullivan
翻译：ytzong
CSS 文件的大小和所引起的 HTTP 的请求数
是 CSS 性能的最关键因素
回流(reflow)和渲染时间
(非常！)没那么重要
副本(duplication)比陈旧的规则(stale rules)更糟糕
因为我们有工具处理后者
定义缺省值
不要在每处都重复编码
#weatherModule h3{color:}
#tabs h3{color:}
h1, .h1{...}
h2, .h2{...}
h3, .h3{...}
h4, .h4{...}
h5, .h5{...}
h6, .h6{...}
用单独的 class 来定义结构
不要在每处都重复编码
使用 class
而不是元素选择器
div.error{...}
.error{绝大多数代码写在这里}
div.error{单独定义}
p.error{单独定义}
em.error{单独定义}
避免使用元素选择器
初始化除外
.error{...}
.section{...}
.products{...}
给规则同样的权重
使用级联去重写先前的规则
.myModule .inner b{...}
.myModule2 b{...}
.myModule b{...}
.myModule2 b{...}
保守的使用 hack
.mod .hd{...}
.ie .mod .hd{...}
.weatherMod .hd{...}
.mod .hd{color:_zoom:1;}
.weatherMod .hd{...}
译注：此点来自The Cascade, Grids, Headings, and Selectors from an OOCSS Perspective, Ajax Experience 2009第96P，为作者在 Ajax Experience 2009 上所做的补充。
避免指定位置
应用 class 在你想要改变的对象上
.sidebar ul{...}
.header ul{...}
.mainNav{...}
.subNav{...}
避免太过特别的 class
它们是都有语义的，而且有限制
.ducatiMonster620{...}
.nicolesDucatiMonster620{...}
.vehicle{...}
.motorcycle{...}
避免单独的定义
id 在每个页面只能使用一次
#myUniqueIdentifier{...}
#myUniqueIdentifier2{...}
避免重复编码
不要直接访问对象的子节点
.inner{...}
.weatherMod .inner{...}
.weatherMod .tr{...}
.weatherMod .bl{...}
未分类 — No Comments
[翻译]重(zhòng)载下的动态 UI 设计技巧
TechTarget 主办的 Ajax Experience 2009 大会9月14日至16日在波士顿举行，业内大牛纷纷向 Web2.0 世界发起挑战，探讨一些诸如用户体验、高性能与可维护性、架构等伟大主题，放出的 PPT 在此。
下面是 Patrick Lightbody分享的后半段总结翻译(前半段为演示)：
PPT：Design Tips for Dynamic UIs Under Heavy Load
作者：Patrick Lightbody
翻译：ytzong
为失败而设计
不要忘记 AJAX 仍为网络应用
网络会由于各种原因失败
网络不可预知
为 AJAX 请求意外添加 Hook
为存储请求状态及重试而编码
为失败而测试
谨慎对待 DOM
非必要时不要改变 DOM 状态
Avoid aggressive “synchronization” common in some AJAX toolkits
合并数据而非替换
页面局部加载(div.innerHtml=…)也不是很好
会带来更多工作，但是运行不畅时会有更好的体验
不要给用户机会去改变那些可能由你来改变的事情
比如提交后禁用按钮
如有必要，使用模拟的对话框来锁住整个 UI
请记住：要有恢复措施！
为失败而测试并确保发生意外时 UI 解锁
始终让用户知道正在发生什么
当发生糟糕的错误时给他们一个完美的“逃生舱”
为逃生舱设置入口
Gmail 是个很好的案例
至少，有个简单的”loading”指示器
未分类 — 4 Comments
IE 团队的前端性能优化建议
~ ，微软面向 Web 开发和 Web 设计人员的 MIX 09 年度大会在拉斯维加斯举行，本届大会的主题是”The Next Web Now”，关于开发技术和设计怎么更加有效结合起来，服务未来互联网的发展趋势。120多场精彩的课程，3000多来自各国的专家参会。
视频及PPT在此下载，虽然其中多数是微软的产品宣讲，不过也有一些很有价值的分享，比如：
C23FWindows Internet Explorer 8 in the Real World: How Is Internet Explorer 8 Used
C24FMeasuring Social Media Marketing
C26FDesigning the Windows 7 Desktop Experience
T25FWeb Development Using Microsoft Visual Studio: Now and in the Future
今天主要介绍的是 IE 团队给出的前端性能优化建议，下面是摘要翻译，有兴趣的话可以看下原PPT
出处：Building High Performance Web Applications and Sites
演讲人：John Hrvatin，Internet Explorer 项目经理
翻译整理：ytzong
中心思想：
适用于所有浏览器
没有魔术般的解决方案
考虑可维护性
Top 100 sites IE8 CPU 使用情况：
84% – 布局，渲染，格式化…
16% – JScript & DOM
Top AJAX sites IE8 CPU 使用情况：
67% – 布局，渲染，格式化…
33% – JScript & DOM
从以下4个方面来进行优化：
CSS 性能：
尽量减少样式
未用到的样式增加了下载量
浏览器必须解析并匹配所有选择器
失败代价很高！
简化选择器
复合的元素选择器会慢
使用 class 或 ID 选择器
元素选择器尽可能简单
使用子(child)选择器代替后代(descendent)选择器
不要混用 RTL 和 LTR
减少样式使这一切变得简单
table tr td ul li {color:}
li#pass {color:}
ul li {color:}
ul & li {color:}
不要使用 expressions
慢 – 通常被这样评价
IE8 标准模式不支持
尽量减少页面重新布局
移动内容体验不好
浏览器执行不必要的任务
优化符号解析(Symbol Resolution)(译注：原文更详细)
Watch for expensive name lookups
缓存多次查找的为本地变量
当需要时才优化
考虑可维护性
JavaScript 代码低效(译注：原文更详细)
Use the native JSON object
Turn large switch statements into lookups
Avoid property access methods
Minimize DOM interaction
Use querySelectorAll for groups
当需要时才优化
考虑可维护性
HTTP 性能：典型的访问
从服务端/缓存请求
针对此的优化：
不要拉伸图片
分别合并JS/CSS
合并图片(sprites)
有条件的 HTTP 请求
简单的 HTTP 请求
If-modified-since:
GET /images/banner.jpg HTTP/1.1
If-Modified-Since:
Wed, 22 Feb :54 GMT
HTTP/1.1 304 Not Modified
Content-Type:
image/jpeg
Last-Modified:
Wed, 22 Feb :54 GMT
提供缓存内容
GET /images/banner.jpg HTTP/1.1
HTTP/1.1 200 OK
Content-Type: image/jpeg
Fri, 12 Jun :50 GMT
GET /images/banner.jpg HTTP/1.1
无响应：从缓存请求服务
减少请求数
外联JS/CSS/图片
减小请求量
使用 HTTP 压缩
使用条件请求
避免阻塞因素
将 JS 放在 HTML 底部
未分类 — 8 Comments
[翻译] gzip 压缩原理
译注：本打算翻译这篇文章的，搜了一下已经有人翻译过了，不过网站失效，通过快照获取了部分内容，在此基础之上进行了一些修改，感谢 bloglei。
原文：How gzip compression works
作者：Kevin Khaw & Eric Higgins，Google 网站管理员
翻译：bloglei &ytzong
译注：以上是 youtube 视频，请翻墙观看（文中图片调用自 picasa，若显示不了也要翻墙）
浏览器请求有无 gzip 压缩的高级预览
服务器未 gzip：
连接服务器并请求页面。
通知服务器，浏览器支持 gzip “Accept-Encoding: gzip”。
不支持 gzip。忽略 gzip 请求。发送未压缩的页面。
接收页面。
显示页面。
服务器 gzip：
连接服务器。
通知服务器，浏览器支持 gzip “Accept-Encoding: gzip”。
收到 gzip 支持通知。
发送 gzip 编码过的页面，并设置响应头“Content-Encoding: gzip”。
接收页面。
根据响应头“Content-Encoding: gzip” 解码 gzip 编码过的页面。
显示页面。
如何进行 gzip 压缩
简单的说，gzip 压缩是在一个文本文件中找出类似的字符串，并临时替换他们，使整个文件变小。这种形式的压缩对 web 来说特别适合，因为 HTML 和 CSS文件通常包含大量的重复字符串，例如空格，标签，及样式定义。
在这个例子中，我将用一小段代码演示 gzip 压缩中用相同的标签跟不同的标签的对比。
在第一段代码中，我用了5个标题标签。
未压缩: 69 bytes
压缩后: 85 bytes (译注：某天77问我怎么压缩后比压缩前还大？我回来后看了下原文并测试了一下，事实如此，并非翻译错)
&h1&One&/h1&&h2&Two&/h2&&h3&Three&/h3&&h4&Four&/h4&&h5&Five&/h5&
把标题标签改为相同的 div 标签，源代码增大了 10 bytes，但是压缩后，它缩小到 66 bytes，比先前的源代码片段还小！
未压缩: 79字节
压缩后: 66 字节
&div&One&/div&&div&Two&/div&&div&Three&/div&&div&Four&/div&&div&Five&/div&
许多开发者可能依此只使用 div 和 span 标签而使页面更大程度的压缩。在多数情况下当然无可非议，但必须注意到正确的语义化标记对可访问性（accessibility）来说非常重要，而且使页面更容易阅读。即便如此，可以使用此方法做一些优化，这取决于你，开发者来决定哪些是合适的。
Page Speed – Enable gzip compression
未分类 — 1 Comment
[翻译]纯 CSS 无 Hack 跨浏览器的多列等高
原文：Equal Height Columns with Cross-Browser CSS and No Hacks
作者：Matthew James Taylor
翻译：ytzong
纯 CSS 打造多列等高并不像想象中那么容易。本文着重讲述多列布局出现的问题，之后提供一个在所有浏览器都正常工作的简单解决方案。这个方法 100% 无 CSS hack，无图片，无 javascript，甚至可以用在最严格编码的网站上。
多列等高的问题
上例中有包含不同内容的 3 列，可以看出存在的问题是列的背景色随着其包含内容的高度而自适应展开。这是我们要解决的问题。如何使所有的列等高？或具体的说，如何使所有列的高度等于最高列的高度？这很棘手，因为我们不清楚每列将会多高，哪一列是最高的。不能简单的给所有列一个固定的高度，如果内容很少将会导致页面底部有大片空白；如果内容太多则会在文字显示完全前关闭。两种情形都不妥。实际上，内容的长度是动态的，所以每列的高度也是动态的。必须意识到Web 上没有固定的东东，乡民们有不同的屏幕分辨率，浏览器中的文字也可能被设置为任意大小，所有这些都会影响内容的高度。
分离列内容与其背景色
解决等高问题的第一步是把能分离的破开。方法是每列用两个 div 替代原来的一个。第一个 div 用来放内容，另一个用来作背景色。分离使我们可以单独控制这些额外的元素，之后用更有效的方法把它们放在一起。答案呼之欲出。
浮动的容器的高度始终取决于其浮动的内容（高度）
这是本文多列等高方法的核心。 使一个 div 的高度等于最高列高度的唯一方法是这个 div 包含所有的列。换句话说，通过把所有的列放在一个容器中，容器的高度就是最高列的高度。这是个非常有用的结构。
3列 HTML div 结构
上例中 3 个内容列在一个 div 容器中。
&div id=&container1&&
&div id=&col1&&Column 1&/div&
&div id=&col2&&Column 2&/div&
&div id=&col3&&Column 3&/div&
下面是使 div 容器等高于最高列的 CSS。
#container1 {
width:100%;
width:30%;
background:
width:40%;
background:
width:30%;
background:
为了让这一结构在所有浏览器中正确工作，容器 div 必须浮动（左或右），同时每一个内容列的 div 也要浮动，哪种方式并不重要。浮动内容 div 的进程使它们在页面中排列在一条水平线上。浮动容器使其自适应到最高列的高度。如果不浮动容器，内容
div 将会从容器底部溢出，容器不会拥有正确的高度。事实上在此例中，容器不浮动的话其最终高度为0。
增加额外嵌套的容器
下一步是增加额外的容器，它们彼此嵌套。我们需要容器的数量等于列的数量：3。这 3 个容器用作各列的背景。请注意，我们去除了原始列的背景色，并将其加至容器上。
3列 HTML div 结构
两个额外的容器加至下面的 HTML 中。
&div id=&container3&&
&div id=&container2&&
&div id=&container1&&
&div id=&col1&&Column 1&/div&
&div id=&col2&&Column 2&/div&
&div id=&col3&&Column 3&/div&
所有元素左浮动，容器宽度设为100%，使他们占满页面的宽度。背景色从内容 div 移除并加至容器上。
#container3 {
width:100%;
background:
#container2 {
width:100%;
background:
#container1 {
width:100%;
background:
width:30%;
width:40%;
width:30%;
用相对定位移动容器
现在用相对定位把容器移至新的位置。移动后 div 如下图所示。即等高列背景容器的层叠和位置。为了显示右侧的绿色列 container2 向左移了30%，为了显示中间的黄色列container1 向左移动了40%，与此同时红色部分依然可见作为左侧列。
相对定位的 CSS
下面是添加了相对定位的CSS。
#container3 {
width:100%;
background:
#container2 {
width:100%;
background:
right:30%;
#container1 {
width:100%;
background:
right:40%;
width:30%;
width:40%;
width:30%;
将每列的内容移回
下一步是把每列的内容移回到页面上，使之排列在下面的背景色上。再次使用简单的相对定位来完成它。
最后在最外面的容器 container3 上添加overflow:hidden，砍去超出容器的部分。
相对定位的 CSS
下面是增加了相对定位和溢出的 CSS 规则。请注意 container3 上额外的position: 这是为了解决一个
IE bug ，阻止overflow:工作。
#container3 {
width:100%;
background:
#container2 {
width:100%;
background:
right:30%;
#container1 {
width:100%;
background:
right:40%;
width:30%;
width:40%;
width:30%;
对列增加 padding
最后还需对列增加 padding，这样每列边缘的文字不至于显得拥挤。如果我们增加 padding，一些浏览器中可能正常显示，但不是所有。IE 错误的盒模型，导致其估算拥有padding 的元素宽度异常。一个 200px 宽 20px padding 的 box 在 IE 中被视为 200px 宽，在其他浏览器中则为正确的 240px。padding应该加在元素的宽度上。凸微软！
不过不用担心…我们可以用完全不依赖于 padding 的方法来解决这个问题。相反，我们把列弄窄一点（列宽减去两侧的 padding），之后用相对定位把它们移至正确的位置。在我们的例子中我们用了2% 的 padding，则 30% 的列将减至 26%，40% 的列减至 36%。用相对定位移回列时需谨记，现在列变窄了，所以当它们一起像最初那样左浮动时，每一个需要比上一个移动更远的距离。
为了使布局保持在小宽度我在每个内容列增加了overflow: 这将切去超出列宽的东东，并阻止其干扰其他布局。重申一下，这只是IE 的问题，其他所有浏览器会保持正确的布局，不管列内是虾米。如果你真想这样做，可以用 IE 条件注释只对 IE 写规则。
#container3 {
width:100%;
background:
#container2 {
width:100%;
background:
right:30%;
#container1 {
width:100%;
background:
right:40%;
width:26%;
width:36%;
width:26%;
好了，就是这样。我希望这篇文章对你有用。可以自己弄一下 CSS 看一下它是如何工作的。你可以搞很多列，只要容器和内容列的数目相等。不要忘记看看我的 demo：2列 ，3列，4列，以及5列。
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：13710次
排名：千里之外
原创：10篇
(1)(1)(1)(3)(2)(3)(4)(1)(2)(1)