影の域 » Web

IE6+和FF的CSS Hack

影之迷惑 — Thu, 22 Apr 2010 16:59:21 +0000

一、CSS HACK
以下两种方法几乎能解决现今所有HACK.

1, !important

随着IE7对!important的支持, !important 方法现在只针对IE6的HACK.(注意写法.记得该声明位置需要提前.)

2, IE6/IE77对FireFox

*+html 与 *html 是IE特有的标签, firefox 暂不支持.而*+html 又为 IE7特有标签.

注意:
*+html 对IE7的HACK 必须保证HTML顶部有如下声明：

二、万能 float 闭合(非常重要!)

关于 clear float 的原理可参见 [How To Clear Floats Without Structural Markup]
将以下代码加入Global CSS 中,给需要闭合的div加上即可,屡试不爽.

三、其他兼容技巧(再次啰嗦)

1, FF下给 div 设置 padding 后会导致 width 和 height 增加, 但IE不会.(可用!important解决)
2, 居中问题.
1).垂直居中.将 line-height 设置为当前 div 相同的高度, 再通过 vertical-align: middle.( 注意内容不要换行.)
2).水平居中. margin: 0 auto;(当然不是万能)
3, 若需给 a 标签内内容加上样式, 需要设置 display: block;(常见于导航标签)
4, FF 和 IE 对 BOX 理解的差异导致相差 2px 的还有设为 float的div在ie下 margin加倍等问题.
5, ul 标签在 FF 下面默认有 list-style 和 padding . 最好事先声明, 以避免不必要的麻烦. (常见于导航标签和内容列表)
6, 作为外部 wrapper 的 div 不要定死高度, 最好还加上 overflow: hidden.以达到高度自适应.
7, 关于手形光标. cursor: pointer. 而hand 只适用于 IE.

1 针对firefox ie6 ie7的css样式
现在大部分都是用!important来hack，对于ie6和firefox测试可以正常显示，
但是ie7对!important可以正确解释，会导致页面没按要求显示！找到一个针
对IE7不错的hack方式就是使用“*+html”，现在用IE7浏览一下，应该没有问题了。
现在写一个CSS可以这样：

#1 { color: #333; } /* Moz */
* html #1 { color: #666; } /* IE6 */
*+html #1 { color: #999; } /* IE7 */
那么在firefox下字体颜色显示为#333，IE6下字体颜色显示为#666，IE7下字体颜色显示为#999。

2 css布局中的居中问题
主要的样式定义如下：

body {TEXT-ALIGN: center;}
#center { MARGIN-RIGHT: auto; MARGIN-LEFT: auto; }
说明：
首先在父级元素定义TEXT-ALIGN: center;这个的意思就是在父级元素内的内容居中；对于IE这样设定就已经可以了。
但在mozilla中不能居中。解决办法就是在子元素定义时候设定时再加上“MARGIN-RIGHT: auto;MARGIN-LEFT: auto; ”
需要说明的是，如果你想用这个方法使整个页面要居中，建议不要套在一个DIV里，你可以依次拆出多个div，
只要在每个拆出的div里定义MARGIN-RIGHT: auto;MARGIN-LEFT: auto; 就可以了。

3 盒模型不同解释.

#box{ width:600px; //for ie6.0- w\idth:500px; //for ff+ie6.0}
#box{ width:600px!important //for ff width:600px; //for ff+ie6.0 width /**/:500px; //for ie6.0-}

4 浮动ie产生的双倍距离

#box{ float:left; width:100px; margin:0 0 0 100px; //这种情况之下IE会产生200px的距离 display:inline; //使浮动忽略}
这里细说一下block,inline两个元素,Block元素的特点是:总是在新行上开始,高度,宽度,行高,边距都可以控制(块元素);Inline元素的特点是:和其他元素在同一行上,…不可控制(内嵌元素);

#box{ display:block; //可以为内嵌元素模拟为块元素 display:inline; //实现同一行排列的的效果 diplay:table;

5 IE与宽度和高度的问题

IE不认得min-这个定义，但实际上它把正常的width和height当作有min的情况来使。这样问题就大了，如果只用宽度和高度，
正常的浏览器里这两个值就不会变，如果只用min-width和min-height的话，IE下面根本等于没有设置宽度和高度。
比如要设置背景图片，这个宽度是比较重要的。要解决这个问题，可以这样：
#box{ width: 80px; height: 35px;}html>body #box{ width: auto; height: auto; min-width: 80px; min-height: 35px;}

6 页面的最小宽度

min-width是个非常方便的CSS命令，它可以指定元素最小也不能小于某个宽度，这样就能保证排版一直正确。但IE不认得这个，
而它实际上把width当做最小宽度来使。为了让这一命令在IE上也能用，可以把一个

放到标签下，然后为div指定一个类：
然后CSS这样设计：
#container{ min-width: 600px; width:expression(document.body.clientWidth < 600? “600px”: “auto” );}
第一个min-width是正常的；但第2行的width使用了Javascript，这只有IE才认得，这也会让你的HTML文档不太正规。它实际上通过Javascript的判断来实现最小宽度。

7 清除浮动

.hackbox{ display:table; //将对象作为块元素级的表格显示}或者.hackbox{ clear:both;}
或者加入:after（伪对象）,设置在对象后发生的内容，通常和content配合使用，IE不支持此伪对象，非Ie 浏览器支持，
所以并不影响到IE/WIN浏览器。这种的最麻烦的……#box:after{ content: “.”; display: block; height: 0; clear: both; visibility: hidden;}

8 DIV浮动IE文本产生3象素的bug

左边对象浮动，右边采用外补丁的左边距来定位，右边对象内的文本会离左边有3px的间距.

#box{ float:left; width:800px;}#left{ float:left; width:50%;}#right{ width:50%;}*html #left{ margin-right:-3px; //这句是关键}
HTML代码

9 属性选择器(这个不能算是兼容,是隐藏css的一个bug)

p[id]{}div[id]{}
这个对于IE6.0和IE6.0以下的版本都隐藏,FF和OPera作用
属性选择器和子选择器还是有区别的,子选择器的范围从形式来说缩小了,属性选择器的范围比较大,如p[id]中,所有p标签中有id的都是同样式的.

10 IE捉迷藏的问题

当div应用复杂的时候每个栏中又有一些链接，DIV等这个时候容易发生捉迷藏的问题。
有些内容显示不出来，当鼠标选择这个区域是发现内容确实在页面。
解决办法：对#layout使用line-height属性或者给#layout使用固定高和宽。页面结构尽量简单。

11 高度不适应

高度不适应是当内层对象的高度发生变化时外层高度不能自动进行调节，特别是当内层对象使用
margin 或paddign 时。
例：

p对象中的内容

CSS：#box {background-color:#eee; }
#box p {margin-top: 20px;margin-bottom: 20px; text-align:center; }
解决方法：在P对象上下各加2个空的div对象CSS代码：.1{height:0px;overflow:hidden;}或者为DIV加上border属性。

Data URI 和 MHTML

影之迷惑 — Sat, 10 Apr 2010 03:32:45 +0000

Data URI

Data URI是由RFC 2397定义的一种把小文件直接嵌入文档的方案。通过如下语法就可以把小文件变成指定编码直接嵌入到页面中：

data:[][;base64],

MIME-type：指定嵌入数据的MIME。其形式是[type]/[subtype]; parameter，比如png图片对应的MIME是image/png。parameter可以用來指定附加的信息，更多情況下是用于指定text/plain和text/htm等的文字编码方式的charset参数。默认是text/plain;charset=US-ASCII。
base64：声明后面的数据的编码是base64的，否则数据必须要用百分号编码（即对内容进行urlencode）。

在上个世纪HTML4.01引入了Data URI方案，到今天为止除了IE6和IE7之外，所有主流浏览器都支持，但IE8对Data URI的支持还是有限制的，只支持object（仅是图片时）、img、input type=image、link和CSS中的URL，且数据量不能大于32K。

优点：

减少HTTP请求数，没有了TCP连接消耗和同一域名下浏览器的并发数限制。
对于小文件会降低带宽。虽然编码后数据量会增加，但是却减少了http头，当http头的数据量大于文件编码的增量，那么就会降低带宽。
对于HTTPS站点，HTTPS和HTTP混用会有安全提示，而HTTPS相对于HTTP来讲开销要大更多，所以Data URI在这方面的优势更明显。
可以把整个多媒体页面保存为一个文件。

缺点：

无法被重复利用，同一个文档应用多次同一个内容，则需要重复多次，数据量大量增加，增加了下载时间。
无法被独自缓存，所以其包含文档重新加载时，它也要重新加载。
客户端需要重新解码和显示，增加了点消耗。
不支持数据压缩，base64编码会增加1/3大小，而urlencode后数据量会增加更多。
不利于安全软件的过滤，同时也存在一定的安全隐患。

MHTML

MHTML是MIME HTML (Multipurpose Internet Mail Extension HTML)的缩写，是由RFC 2557定义的把一个多媒体的页面所有内容都保存到同一个文档解决方案。这个方案是由微软提出从IE5.0开始支持，另外Opera9.0也开始支持，Safari可以把文件保存为.mht（MHTML文件的后缀）格式，但不支持显示它。

MHTML和Data URI还比较类似，有更强大的功能和更复杂的语法，并且没有Data URI中“无法被重复利用”的缺点，但MHTML使用起来不够灵活方便，比如对资源引用的URL在mht文件中可以是相对地址，否则必须是绝对地址。hedger在《Cross Browser Base64 Encoded Images Embedded in HTML》针对IE的解决方案使用的是相对路径就是因为声明了Content-type:message/rfc822使IE按照MHTML来解析，如果不修改Content-type则需要使用MHTML协议，这个时候必须使用绝对路径，如《MHTML – when you need data: URIs in IE7 and under》。

应用

Data URI和MHTML两者的配合可以完整的解决所有的主流浏览器，它们由于无法被缓存和重复利用的缺陷，所以并不适合直接在页面中使用，但在CSS和JavaScript文件中对图片适当地使用有非常大的优越性：

大大减少请求数，现在大型网站的CSS引用了大量的图片资源。
CSS和JavaScript都可以被缓存，间接的实现了数据的缓存。
利用CSS可以解决Data URI的重复利用问题
告别CSS Sprites，CSS Sprites的出现是为了减少请求数，但它除了带来在不确定情况下的异常外，CSS Sprites还需要人为的图片合并，即使有合并工具也依旧必须人为地在如何有效的拼图上耗费大量的时间，并带来维护的困难。当你遵循一定的设计原则后，你就可以完全抛弃CSS Sprites来编写CSS，最后使用工具在上传到服务器环节把图片转换成Data URI和MHTML，如《利用data-uri合并样式表和图片》中用python实现的工具，这可以节约大量的时间。
base64编码把图片文件增加了1/3，Data URI和MHTML同时使用相当于增加了2/3，但CSS和JavaScript可以使用gzip压缩，其可以节省2/3的数据量，所以使用gzip压缩后的最终数据量是(1 + 1/3) * 2 * (1/3) = 8/9，所以最终流量是减少的。

为了方便在CSS中实现Data URI和MHTML，我写了一个Data URI & MHTML 生成器，你可以看利用其生成Data URI & MHTML应用实例。

其他DEMO： demo1 demo2

5 个简单实用的 CSS 属性

影之迷惑 — Tue, 09 Mar 2010 01:57:06 +0000

这篇文章介绍了 5 个实用的 CSS 属性。你应该很熟悉，但很可能很少会使用到。我并不是在谈论展望全新的 CSS3 属性，我指的是旧的 CSS2 中的属性，如：clip，min-height，white-space，curosr 和 display 等一些被所有浏览器广泛支持的属性。因此，千万不要错过这篇文章，因为你可能发现它们竟有如此之大的用途。

1、CSS Clip

剪辑 (clip) 属性就像一个面具。它允许你使用矩形掩盖页面元素的内容。要剪辑一个元素：你必须指定其 position 属性为 absolute，然后指定相对于元素的 top，right，bottom，left 值。

图片剪辑实例（演示）

以下示例演示了如何使用 clip 属性掩盖一张图片。首先，指定

元素为 position:relative，然后指定元素为 position:absolute，并且根据实际需要设定 rect 值。

.clip {
  position: relative;
  height: 130px;
  width: 200px;
  border: solid 1px #ccc;
}
.clip img {
  position: absolute;
  clip: rect(30px 165px 100px 30px);
}

图像调整尺寸和剪辑（演示）

在这个示例中，我将展示如何调整图像尺寸和剪辑图片。素材图片是矩形的，我想将其削减至 50％的尺寸，用来创建一个正方形格式的缩略图。因此，我用宽度和高度属性来调整图像，并使用 clip 剪辑属性予以掩盖。然后用 left 属性将图片移开左侧 15px 的距离。

.gallery li {
  float: left;
  margin: 0 10px 0 0;
  position: relative;
  width: 70px;
  height: 70px;
  border: solid 1px #000;
}
.gallery img {
  width: 100px;
  height: 70px;
  position: absolute;
  clip: rect(0 85px 70px 15px);
  left: -15px;
}

2、Min-height （演示）

min-height 属性允许你指定元素的最小高度，适用于需要平衡布局的情况。我将它用于 Job 面板上，以确保内容区域高于侧边栏。

.with_minheight {
  min-height: 550px;
}

IE6 的 Min-height hack

注：神奇的 IE6 原生不支持 min-height 属性，不过幸好有一个 min-height hack。

.with_minheight {
  min-height:550px;
  height:auto !important;
  height:550px;
}

3、White-space（演示）

white-space 属性指定了元素中空白的处理方式。比如，指定 white-space:nowrap 会阻止文本自动换行。

em {
  white-space: nowrap;
}

4、Cursor（演示）

如果你改变了按钮的行为，其指针也应该随之改变。比如，当一个按钮不可用时，指针应该改变为默认的箭头，来表明它不可点击。因此，cursor 属性在开发 Web 应用程序时相当有用。

.disabled {
  cursor: default;
}

.busy {
  cursor: wait;
}

.clickable:hover {
  cursor: pointer;
}

5、Display inline / block（演示）

如果你不知道：块级元素是作为独立的一行来渲染的，而行内元素是在同一行被渲染的。

，

和

标签都是块级元素，，， 都是行内元素。通过 display:inline 或 block 的方式，你可以重设这些元素的 display 样式。

.block em { display: block; } .inline h4, .inline p { display: inline; }

英文原稿：5 Simple, But Useful CSS Properties | WebDesignWall 翻译整理：5 个简单实用的 CSS 属性 | 芒果

本文链接：http://www.blueidea.com/tech/web/2010/7410.asp

Comet—“服务器推”技术

影之迷惑 — Wed, 03 Mar 2010 06:02:46 +0000

一、名称解释：

Comet最早是由Alex Russell（Dojo Toolkit 项目主管和Dojo Foundation主席）在自己的博客中提出的术语，他是这样说的：”New services like Jot Live and Meebo are built with a style of data transmission that is neither traditional nor Ajax. Their brand of low-latency data transfer to the browser is unique, and it is becoming ever-more common. Lacking a better term, I’ve taken to calling this style of event-driven, server-push data streaming “Comet”.” “They all use long-lived HTTP connections to reduce the latency with which messages are passed to the server. In essence, they do not poll the server occasionally. Instead the server has an open line of communication with which it can push data to the client.”

Comet指的是一种Web应用程序架构。可以直接说，它不是一种技术，而是一种思想，只是这种思想采用了已有的技术去实现。在这种思想里，客户端（Client）不需要显式地向服务器端（Server）发出请求，Server会在其数据发生变化的时候主动将数据异步发送给Client，从而使Client能够及时更新数据并呈现给用户。它不同于传统的Web，也不同于当前流行的Ajax，这种思想非常架构思想非常适合event-driven(事件驱动)式的Web应用和对交互性及实时性要求很强的应用，比如股票交易，聊天室，Web IM，网游等。

二、成功案例：

GMail’s GTalk integration

Jot Live

Renkoo

Meebo

三、实现方式：

Comet使用Client和Server之前的HTTP长链接最为数据传输的通道。

实现Comet，最常见的有下面两种方式：

Ajax的长轮询（long-polling）：Javascript在处理完服务器返回的信息后再次发出请求，重新建立连接。不同于一般的Ajax，Javascript请求Server，无数据时Server不中断请求，still loading，在一定时间内，获取到数据后，返回请求，又Javascript获取数据后再次发出请求，由此轮询。需要注意的是请求的间隔时间以及每次请求的最长Loading时间。
优点：异步请求；无需浏览器任何插件支持；采用Ajax技术，兼容性强；
缺点：会产生大量的通信量，只能通过增加轮询的时间间隔来减轻Server的压力；

Iframe结合Htmlfile流（streaming）：通过在页面上嵌入一个隐藏的Iframe，设置其src属性为一个长连接的请求，Server采用flush方式将数据作为前端Javascript函数的参数传递；
优点：不会有很大的通信量，而且数据接收非常及时，并且无中断；
缺点：会产生进度条的Loading状态并一直穿着，用户使用体验很不好，在Google Talk中，通过Htmlfile Active解决了IE下的进度条显示问题；保持长期链接也非常耗服务器资源；

四、临时采用方案：

目前，白社会(bai.sohu.com)采用了第一种方式来实现实时消息的推送，这种方式还存在一个问题就是，在多个tab页下，如何保证没有相同域的长连接请求（IE在同域下只能同时支持两个长链接），于是采用了子域形式来区分多个域，以保证每个tab页下访问的地址都不在一个域名下，此时问题又出来了，出现了Ajax跨域名请求，不过这个问题比较常见，解决方案也很多，我们采用的是Iframe形式；由此，为了实现Comet，我们走了很长一条路，虽然路的确走完了，但是走得很长很艰难，这也是为什么称它为“临时解决方案”，因为它并不是一个完美的方案，但我也相信，以后会更加完美。

五、现有可参考框架

Cometd：官方地址：www.cometd.org
可以参考http://www.blogjava.net/xmatthew/archive/2008/11/20/208911.html

Pushlet：官方地址：www.pushlets.com
pushlet 提供了基于 AJAX 的 JavaScript 库文件用于实现长轮询方式的”服务器推”；还提供了基于 iframe 的 JavaScript 库文件用于实现流方式的”服务器推”。
可以参考http://www.javaeye.com/topic/89158

六、文章参考

Comet：基于 HTTP 长连接的”服务器推”技术

实战 Comet 应用程序开发

Comet on wikipedia

最后，本人对Comet也未进行深入的研究，只是希望通过此文能给大家起一个抛砖引玉的作用，希望大家能够在客户端实时技术上能够起点帮助作用，能够越来越丰富我们前端技术。

原文地址： http://ued.sohu.com/article/118

Understanding and Solving Internet Explorer Leak Patterns

影之迷惑 — Sun, 28 Feb 2010 06:01:57 +0000

Understanding and Solving Internet Explorer Leak Patterns

Justin Rogers
Microsoft Corporation

June 2005

The Evolution of the Web Developer

In the past, memory leaks haven’t posed huge problems for Web developers. Pages were kept relatively simple and navigation between different locations within a site was a great way to clean up any loose memory. If there was a leak, it was most likely small enough to go unnoticed.

New Web applications live up to higher standards. A page might run for hours without being navigated and retrieve updated information dynamically through Web services. Language features are pushed to the breaking point by combining complex event schemes, object-oriented JScript, and closures to produce entire applications. With these and other changes, certain memory leak patterns are becoming more prominent, especially those previously hidden by navigation.

The good news is that memory leak patterns can be easily spotted if you know what to look for. Most of the troublesome patterns you might face have known workarounds requiring only a small amount of extra work on your behalf. While some pages might still fall prey to small memory leaks, the most noticeable ones can be easily removed.

Leak Patterns

The following sections will discuss patterns of memory leaks and point out some common examples of each pattern. One great example of a pattern is the closure feature of JScript, while another example is the use of closures in hooking events. If you’re familiar with the event hooking example, you might be able to find and fix many of your memory leaks, but other closure-related issues might go unnoticed.

Now, let’s look at the following patterns:

Circular References—When mutual references are counted between Internet Explorer’s COM infrastructure and any scripting engine, objects can leak memory. This is the broadest pattern.

Closures—Closures are a specific form of circular reference that pose the largest pattern to existing Web application architectures. Closures are easy to spot because they rely on a specific language keyword and can be searched for generically.

Cross-Page Leaks—Cross-page leaks are often very small leaks of internal book-keeping objects as you move from site to site. We’ll examine the DOM Insertion Order issue, along with a workaround that shows how small changes to your code can prevent the creation of these book-keeping objects.

Pseudo-Leaks—These aren’t really leaks, but can be extremely annoying if you don’t understand where your memory is going. We’ll examine the script element rewriting and how it appears to leak quite a bit of memory, when it is really performing as required.

Circular References

Circular references are the root of nearly every leak. Normally, script engines handle circular references through their garbage collectors, but certain unknowns can prevent their heuristics from working properly. The unknown in the case of IE would be the status of any DOM elements that a portion of script has access to. The basic principle would be as follows:

Figure 1. Basic Circular Reference Pattern

The cause of the leak in this pattern is based on COM reference counting. The script engine objects will hold a reference to the DOM element and will be waiting for any outstanding references to be removed before cleaning up and releasing the DOM element pointer. In our case we have two references on the script engine object: the script engine scope, and the DOM element expando property. While terminating the script engine will release the first reference, the DOM element reference will never be released because it is waiting on the script engine object to release it! You might think it would be easy to detect this scenario and fix the problem, but in practice the basic case presented is only the tip of the iceberg. You could have circular references at the end of a 30 object chain and those would be much harder to detect.

If you are wondering what this pattern looks like in HTML, you can cause a leak by using a global script engine variable and a DOM element as shown.

To break the leak pattern you can make use of explicit null assignments. By assigning null before the document unloads you are telling the script engine there is no longer an association between the element and the object inside the engine. It can now properly clean up references and will release the DOM element. In this case, you as the Web developer know more about the relationships between your objects than the script engine does.

While that is the basic pattern, it can be difficult to spot more complex scenarios. A common usage of object-oriented JScript is to extend DOM elements by encapsulating them inside of a JScript object. During the construction process, you generally pass in the DOM element you want to attach to and then store a reference to the DOM element on the newly constructed object while at the same time storing an instance of the newly constructed object on the DOM element. That way your application model always has access to everything it needs. The problem is this is a very explicit circular reference, but because it uses different language aspects it might go unnoticed. Breaking up this kind of pattern can become more complex, and you can use the same simple methods discussed earlier.

More complex solutions to this problem involve registration schemes to note which elements/properties need to be unhooked, having the peer element hook events so that it can clean up before the document unloads, but often you can run into additional leak patterns without actually fixing the problem.

Closures

Closures are very often responsible for leaks because they create circular references without the programmer being fully aware. It isn’t immediately obvious that parent function parameters and local variables will be frozen in time, referenced, and held until the closure itself is released. In fact this has become such a common programming tactic, and users have run into issues so often, there are quite a few resources already available. Because they detail some of the history behind closures as well as some of the specific instances of closure leaks we’ll check those out after applying the closure model to our circular reference diagram and figuring out where these extra references are coming from.

Figure 2. Circular References with Closures

With normal circular references there were two solid objects holding references to each other, but closures are different. Rather than make the references directly, they are made instead by importing information from their parent function’s scope. Normally, a function’s local variables and the parameters used when calling a function only exist for the lifetime of the function itself. With closures, these variables and parameters continue to have an outstanding reference as long as the closure is alive, and since closures can live beyond the lifetime of their parent function so can any of the locals and parameters in that function. In the example, Parameter 1 would normally be released as soon as the function call was over. Because we’ve added a closure, a second reference is made, and that second reference won’t be released until the closure is also released. If you happened to attach the closure to an event, then you would have to detach it from that event. If you happened to attach the closure to an expando then you would need to null that expando.

Closures are also created per call, so calling this function twice will create two individual closures, each holding references to the parameters passed in each time. Because of this transparent nature it is really easy to leak closures. The following example provides the most basic of leaks using closures:

If you are wondering how to break this leak, it won’t be as easy as a normal circular reference. The “closure” can be viewed as a temporary object that exists in the function scope. Once the function exits, you lose reference to the closure itself, so what would you end up calling detachEvent with? One of the most interesting approaches to this problem was demonstrated on MSN spaces thanks to Scott Isaacs. The approach uses a second closure to additionally hook the window’s onUnload event, and because this closure has the same “scoped” objects it is able to detach the event, detach itself, and finish the clean up process. To make everything easily fit with our model we can also store the closure on an expando, detach it, and then null the expando, as in the following example.

In a Knowledge Base article, we actually recommend that you try not to use closures unless they are necessary. In the example, I’ve given we don’t need to use a closure as the event handler, instead we can move the closure to a global scope. When the closure becomes a function, it no longer inherits the parameters or local variables from its parent function so we don’t have to worry about closure-based circular references at all. Most code can be fixed by creating an architecture that doesn’t rely on closures where they aren’t necessary.

Finally, Eric Lippert, one of the developers of the scripting engines, has a great post on closures in general. His final recommendations are also along the lines of only using closures when truly necessary. While his article doesn’t mention any of the workarounds for the closure pattern, hopefully we’ve covered enough examples here to get you started.

Cross-Page Leaks

Leaks that are based on order of insertion are almost always caused by the creation of intermediate objects that don’t get cleaned up properly. That is exactly the case when creating dynamic elements and then attaching them to the DOM. The basic pattern is attaching two dynamically created objects together temporarily which creates a scope from the child to the parent element. Later, when you attach this two-element tree to the primary tree, they both inherit the scope of the document and a temporary object is leaked. The following diagram shows two methods for attaching dynamically created elements to the tree. In the first model, attach each child element to its parent, and finally attach the entire subtree to the primary tree. This method can cause leaks through temporary objects if other conditions are met. In the second model, we attach elements into the primary tree working our way from top-level dynamically created element down through all of the children. Because each attachment inherits the scope of the primary document we never generate temporary scopes. This method is much better at avoiding potential memory leaks.

Figure 3. DOM Insertion Order Leak Model

Next, we are going to cover an example of a leak that is transparent to most leak-detection algorithms. Because we don’t leak any publicly visible elements and the objects we leak are very small you might never notice this problem. For our example to work, the dynamically created elements will have to contain a script pointer in the form of an inline function. This will allow us to leak an internal script object that is created temporarily as we attach elements together. Because the leak is small, we’ll have to run thousands of samples. In fact, the objects leaked are only a few bytes. By running the sample and navigating to an empty page, you can see the difference in memory consumption between the two versions. When we use the first DOM model of attaching child to parent, then parent to the primary tree, our memory usage goes up a bit. This is a cross-navigation leak and the memory isn’t reclaimed until you restart the IE process. If you run the sample a few more times, using the second DOM model of attaching the parent to the primary tree and then the child to the parent, your memory won’t continue to climb and you’ll find that you’ve fixed the cross-page navigation leak.

This leak deserves clarification, because our workaround goes against some best practices in IE. The key points to understand about the leak are that DOM elements are being created with scripts already attached. This is actually crucial to the leak, because if we create DOM elements that don’t contain any script and attach them together in the same manner we don’t have a leak problem. This gives rise to a second workaround that might be even better for larger subtrees (in the example we only have two elements, so building the tree off the primary DOM isn’t a performance hit). The second workaround would be to create your elements with no scripts attached initially so that you can safely build your subtree. After you’ve attached your subtree to the primary DOM, go back and wire up any script events at that point. Remember to follow the principles for circular references and closures so you don’t cause a different leak in your code as you hook up your events.

I really wanted to point out this issue because it shows that not all memory leaks are easy to find. It could take thousands of iterations of a smaller pattern to become visible, and it might be something slight, like the order of insertion of DOM elements that causes the problem to arise. If you tend to program using only best practices, then you think you are safe, but this leak shows that even best practices can exhibit leaks. Our solution here was to improve upon the best practice or even introduce a new best practice in order to remove the leaking condition.

Pseudo-Leaks

Often times the actual behavior and expected behavior of some APIs can lead you to misdiagnose memory leaks. Pseudo-leaks almost always appear on the same page during dynamic scripting operations and should rarely be visible after navigation away from the page to a blank page. That is how you can eliminate the issue as a cross-page leak and then start to work on whether the memory consumption is expected. We’ll use script text rewriting as our example of a pseudo-leak.

Like the DOM Insertion Order issue, this issue also relies on the creation of temporary objects in order to “leak” memory. By rewriting the script text inside of a script element over and over again, slowly you’ll begin to leak various script engine objects that were attached to the previous contents. In particular, objects related to debugging script are left behind as are fully formed code elements.

If you run the above code and use the Task Manager trick again, while navigating between the “leaking” page and a blank page, you won’t notice a script leak. This script leak is entirely within a page and when you navigate away then you get your memory back. The reason this one is bad is due to expected behavior. You expect that after rewriting some script that the original script won’t stay around. But it really has to, because it might have been used already for event attachments and there might be outstanding reference counts. As you can see, this is a pseudo-leak. On the surface the amount of memory consumption looks really bad, but there is a completely valid reason.

Conclusion

Every Web developer builds a personal list of code examples that they know leak and learns to work around those leaks when they see them in code. This is extremely handy and is the reason the Web is relatively leak-free today. Thinking about the leaks in terms of patterns instead of individual code examples, you can start to develop even better strategies for dealing with them. The idea is to take them into account during the design phase and make sure you have plans for any potential leaks. Use defensive coding practices and assume that you’ll need to clean up all your own memory. While this is an overstatement of the problem, you very rarely need to clean up your own memory; it becomes obvious which variables and expando properties have the potential for leaking.

In the interest of patterns and design I highly recommend Scott’s short blog entry because it demonstrates a general purpose example of removing all closure-based leaks. It does require a bit more code, but the practice is sound and the improved pattern is easy to spot in code and to debug. Similar registration schemes can be used for expando-based circular references as long as care is taken that the registration method itself isn’t riddled with leaks (especially where closures are used)!

About the author

Justin Rogers recently joined the Internet Explorer team as an Object Model developer working on extensibility and previously worked on such notable projects as the .NET QuickStart Tutorials, .NET Terrarium, and SQL Reporting Services Management Studio in SQL Server 2005.

CSS圆角—透明圆角化背景图片

影之迷惑 — Thu, 21 Jan 2010 03:11:53 +0000

作者：by0001　来自：蓝色理想
原文：http://www.blueidea.com/tech/web/2010/7353.asp

序言：第一章中我介绍了最基本的纯CSS圆角框的实现原理，并给出Demo，在本章中会对上一个模型作一些新的创新，实现将背景图片透明圆角化。并给出一些漂亮的通用演示效果。

在上面的案例中，我只给出最为原始的圆角框模型，它还是存在一些不足之处。比如不能将图片应用到圆角框内。而在本例中，我会在上面的基础上作出一些创新。就是将背景图片也圆角化，好像目前在网络上还没有这样的功能应用，我只见过用js方式来实现的，可以参看我的《超圆滑圆角框的半完美解决方案》一文中后面几种JS方案。但是纯CSS方式的实现可是我独家所创，如有雷同，只能说英雄所见略同。呵呵！

还是先看看最终的效果图，让大家有一个大概的印象。

图一

像这种小面积布局在网页设计中应用得很普遍，但目前网络流行的作法都是采用图片的方式来实现的，将图片按上中下切成三块内容，然后使用三个同级的DIV或SPAN容器各自填充一张图，但是这种方法有一个最大的毛病：不能自动适应宽度的变化，一般做法都是采用固定宽度的方式，这是由于图片的宽度决定的。

当然对于一些比较有经验的人员来说，可以采用九宫格布局（可参看我的另一篇文章《九宫格基本布局》）方式或者滑动门方式来做到自适应宽度的变化，九宫格一般都需要用到八张图片，而滑动门虽然只用一张图片，但为了适应宽度的变化，这张图片一般都做得很大。
而我现在独创的这种方法可以完全做到适应不同宽度的需要，并且全部兼容所有的浏览器，而所需要的仅仅是一张很小的水平平辅的背景图片而已。

基本原理：

我们都知道图片是方方正正的，不可能做出圆角效果，那么我们如何来做外圆透明的图片呢？其实道理说明了也就是一件很简单的事情，你看过下面的放大示意图后可能就会“哦”地一声，原来不过如此……

图二

是的，看到这个效果图你会一目了然，可是要想到这个方法，我却浪费了不少脑细胞。呵呵！

实现这种方法原理很简单：在每个b标签中各加载一次同样的图片，并结合背景定位background-position方式来达到效果。我们知道，同一张图片加载多少次对于性能的影响并不大，因为这张图片已经被电脑缓存到本地，和用css sprites合并图片一样的道理。

但是需要注意的是：每个B标签加载图片的定位是不一样的。

背景图片定位原理：　　

b1标签位于第一位，它主要用来描绘上边框线，所以它不需要加载背景图片。

b2标签位于第二位，它是第一个需要加载背景图片的，但是不需要图片负偏移，所以直接居左居顶定位就可以了。

.b2{background-position:left top;}

b3标签位于第三位，它需要加载背景图片，让它的背景图片向上负偏移b2的高度值就可以，也就是1px。

.b3{background-position:left -1px;}

b4位于第四位，所以它向上负偏移b2+b3高度值的和，为2px.。

.b4{background-position:left -2px;}

H3标签位于第五位，所以它的背景图片需要向上负偏移b2+b3+b4高度值的各，也就是4px；

h3{background-position:left -4px;}

这样，b2、b3、b4、h3的图片叠加起来和原始图片上下渐变的效果完全重合，如同一张图片，这样就达到模拟圆角图片的效果。
怎么样，原理够简单明了吧！

原理清楚后，要实现起来也就是一件水到渠成的事！

HTML结构层：

如同我们在第一章中模型所见，保持结构不变。

CSS样式层：（只写关键代码）

将上面的几句代码进行合并，如下所示：

.sharp b.b2{background-position:left top;} .sharp b.b3{background-position:left -1px;} .sharp b.b4{background-position:left -2px;} .sharp .content h3{background-position:left -4px;}

和第一章中同样的道理，我们肯定要在各个不同的块框中有不同的背景图片的变化，也就是说，我们也要实现不同的换肤方案，当一个页面要多次调用同一个圆角框时，也可以让它们有些丰富的变化。实现不同的风格。OK，没问题，你只需要简单的将下面的样式中的背景图片的路径改变一下就可以了。

.color1 .b2,.color1 .b3,.color1 .b4,.color1 h3{background:url(images/bg1.gif) repeat-x;}

你可以实现不同的颜色方案，就看你的设计师给你多少张不同图片了。

一种风格的定制也是一件简单的事情：

*颜色方案一,绿色风格----------------------------------------*/ /*边框色*/ .color1 .b2,.color1 .b3,.color1 .b4,.color1 .b5,.color1 .b6, .color1 .b7,.color1 .content{border-color:#A0C044;} .color1 .b1,.color1 .b8{background:#A0C044;} .color1 h3{border-bottom:1px #679800 solid;} /*图片路径*/ .color1 .b2,.color1 .b3,.color1 .b4,.color1 h3{background:url(images/bg1.gif) repeat-x;} /*文字内容背景色*/ .color1 .b5,.color1 .b6,.color1 .b7{background:#FFF;}

你只需要复制上面的代码，简单修改一下边框色，背景色，图片路径就变成你想要的风格了，是不是很简单呢？然后在你想应用样式的容器上定义这个color1类名即可。

在我的演示模型中，我定义了9种风格的变化，看看有没有适合你需要，直接复制就可以使用了，祝您用得开心！

为了演示效果，本模型的宽度值全部采用百分比实现的，你可以随意伸缩宽度，看看它能否适应弹性的变化。

本模型在以下浏览器中完美通过：
IE5.5、IE6、IE7、IE8、FF3、TT、Maxthon2.1.5、Opera9.6、Safari4.0、Chrome2.0。

压缩包下载

CSS圆角—基本圆角框

影之迷惑 — Thu, 21 Jan 2010 02:50:03 +0000

作者：by0001　来自：蓝色理想

原文：http://www.blueidea.com/tech/web/2010/7347.asp

序言：在我的文章《超圆滑圆角框的半完美解决方案》中已经总结了七种不同的圆角框解决方案，基本上总结完了目前网络上比较流行的圆角框实现方案。而在我的另一篇文章《无图片山顶角》中又是一个另类的实现方法。

纯CSS实现圆角框是一件大家都说烂了的事件，我也写过两篇总结文章，为什么还会有这篇文章呢，事情是这样的。在我们的以前的项目中，实现圆角框往往是用背景图片来实现的，但是，当这些项目发布上线后，在维护过程中，有时需要添加一些新的需求，因为以前的项目中大量采用了圆角图片，并且这些图片全部采用了CSS sprites方式合并的图，为了不增加更多的额外工作，并且也不想用JS来添加更多的http请求，所以需要一些简单的CSS方案来解决这个问题。而我的个人爱好，也喜欢采用无图片的方式来处理这些效果。总觉得CSS能完成的工作，为什么不让它来实现呢？

实现原理：

纯CSS方式实现圆角框的原理在网络上已经有很多人详细解说了，下面这个示意图是我将其中的一个圆角进行放大后的效果。

图一

从上面效果图中我们可以看到其实这种圆角框是靠一个个容器堆砌而成的，每一个容器的宽度不同，这个宽度是由margin外边距来实现的，如：margin:0 5px;就是左右两侧的外边距5像素，从上到下有5条线，其外边距分别为5px，3px，2px，1px，依次递减。因此根据这个原理我们可以实现简单的html结构和样式。

1、Html结构层：


文字内容



b1~b4构成上面的左右两个圆角结构体，而b5~b8则构建了下面左右两个圆角结构体。而content则是内容主体，将这些全部放在一个大的容器中，并给它的一个类名sharp，用来设置通用的样式。再给它叠加了一个color1类名，这个类名用来区别不同的颜色方案，因为可能会有不同颜色的圆角框。

2、CSS样式：

.b1,.b2,.b3,.b4,.b5,.b6,.b7,.b8{height:1px; font-size:1px; overflow:hidden; display:block;} .b1,.b8{margin:0 5px;} .b2,.b7{margin:0 3px;border-right:2px solid; border-left:2px solid;} .b3,.b6{margin:0 2px;border-right:1px solid; border-left:1px solid;} .b4,.b5{margin:0 1px;border-right:1px solid; border-left:1px solid; height:2px;}

将每个b标签都设置为块状结构，并定义其高度为1像素，超出部分溢出隐藏。从上面样式中我们已经看到margin值的设置，是从大到小减少的。而b1和b8的设置是一样，已经将它们合并在一起了，同样的原理，b2和b7、b3和b6、b4和b5都是一样的设置。这是因为上面两个圆和下面的两个圆是一样，只是顺序是相对的，所以将它合并设置在一起。有利于减少CSS样式代码的字符大小。后面三句和第二句有点不同的地方是多设置了左右边框的样式，但是在这儿并没有设置边框的颜色，这是为什么呢，因为这个边框颜色是我们需要适时变化，所以将它们分离出来，在下面的代码中单独定义。

接下我们设置内容区的样式：

.content {border-right:1px solid;border-left:1px solid;overflow:hidden;}

也是只设置左右边框线，但是不设置颜色值，它和上面八个b标签一起构成圆角框的外边框轮廓。

往往在一个页面中存在多个圆角框，而每个圆角框有可能其边框颜色各不相同，有没有可能针对不同的设计制作不同的换肤方案呢，答案是有的。在我的这个应用中，可以换不同的皮肤颜色，并且设置颜色方案也并不是一件很难的事情。下面看看我是如何将它们应用到不同的颜色的。

在上面的样式设计中，我已经给颜色方案留下了可以扩展的空间。我将所有的涉及到边框色的类名全部集中在一起，用群选择符给它们设置一个边框的颜色就可以了。如下所示：

.color1 .b2,.color1 .b3,.color1 .b4,.color1 .b5,.color1 .b6, .color1 .b7,.color1 .content{}{border-color:#96C2F1;} .color1 .b1,.color1 .b8{background:#96C2F1;}

注意：需要将这两句的颜色值设置为一样的，第二句中虽说是设置的background背景色，但它同样是上下边框线的颜色，这一点一定要记住。因为b1和b8并没有设置border，但它的高度值为1px，所以用它的背景色就达到了模拟上下边框的颜色了。
现在已经将一个圆角框描述出来了，但是有一个问题要注意，就是内容区的背景色，因为这儿是存载文字主体的地方。所以还需要加入下面这句话，也是群集选择符来设置圆角内的所有背景色。

.color1 .b2,.color1 .b3,.color1 .b4,.color1 .b5, .color1 .b6,.color1 .b7,.color1 .content{background:#EFF7FF;}

这儿除了b1和b8外，其它的标签都包含进来了，并且包括content容器，将它们的背景色全部设置一个颜色，这样除了线框外的所有地方都成为一种颜色了。在这儿我也用到包含选择符，给它们都加了一个color1，这是颜色方案1的类名，依照这个原理可以设置不同的换肤方案。

好了，我们将上面的所有代码集中起来，就完成一个纯CSS圆角框的实例模型，在源码中，我设置了六套颜色方案，其它的颜色方案就看你的了。

下面是源码演示后的截图：

图二

为了演示效果，本模型的宽度值全部采用百分比实现的，你可以随意伸缩宽度，看看它能否适应弹性的变化。

本模型在以下浏览器中完美通过：
IE5.5、IE6、IE7、IE8、FF3、TT、Maxthon2.1.5、Opera9.6、Safari4.0、Chrome2.0。

压缩包下载

腾讯TT、遨游浏览器检测

影之迷惑 — Sat, 16 Jan 2010 15:39:30 +0000

最近腾讯TT4.5版发布后，为了兼容一处FLASH的WMODE参数异常的BUG使用到了新版检测方法，特此记录一下，省的以后忘记。

TT4.5 检测方法:   调用 external.getTTVerStr() 返回浏览器信息，非TT或此版本均会抛出异常。

TT通用版检测方法: 首先检测 navigator.userAgent 是否含有 Tencent 特征串，继而调用 external.ShowBrowserUI(’ku6′) ，非TT均会抛出异常

顺便提一下遨游的检测方法：

也是通过 external 对象来辅助检测，调用 external.tab_count 不抛异常即为遨游浏览器。