万峰’s Blog

浏览器专属 CSS Hack:区分 Firefox / Opera / Safari / Internet Explorer

Kelvin — Thu, 27 May 2010 00:24:52 +0000

<!doctype html>
<html>
<head>
<meta charset="gb2312" />
<title>CSS Browser Hackstitle>
<style>
body p {
display: none;
}
/* Opera */
html:first-child #opera {
display: block;
}
/* IE 7 */
html > body #ie7 {
*display: block;
}
/* IE 6 */
body #ie6 {
_display: block;
}
/* Firefox 1 - 2 */
body:empty #firefox12 {
display: block;
}
/* Firefox */
@-moz-document url-prefix() {
#firefox {
display: block;
}
}
/* Safari */
@media screen and (-webkit-min-device-pixel-ratio:0) {
#safari {
display: block;
}
}
/* Opera */
@media all and (-webkit-min-device-pixel-ratio:10000), not all and (-webkit-min-device-pixel-ratio:0) {
head~body #opera {
display: block;
}
}
style>
head>
<body>
我来自 Opera 7.2 - 9.5p>
我是神奇的 Safarip>
我来自 Firefoxp>
我是你爷爷 Firefox 1 - 2 p>
我是囧 IE 7p>
我是脑瘸 IE 6p>
body>
html>

Css3 新特性

Kelvin — Tue, 18 May 2010 01:57:46 +0000

CSS3发布有一段时间了，其中的新功能也是大家很期待的，但到什么时间才能广泛应用，这不是个技术问题，而是人们什么时候可以彻底放弃那些不符合 W3C 标准的旧阅读器的问题。虽然IE这些不符合标准的浏览器还在统领中国浏览器市场，但相信有一天，终究会被取代，因为社会是向前发展的。下边列表一些css3的新功能，相信你一定会感兴趣的。

圆角这个功能已经在诸如 Mozilla, Webkit 等阅读器广泛运用，对 Web 设计者来说无疑是最受期待的，然而 IE 仍然没有要支持这个功能的迹象。
多背景 这个功能是我最期待的，但向后兼容会是一个很大的疑问。
@font-face Firefox 的最新版本将支持该功能，Safari，Opera 甚至 IE 也将支持或已经支持该功能，我们会看到该功能的广泛使用，只是字体的版权疑问会很麻烦。
动画与渐变 Webkit 在这方面是领头军，动画也是设计的一部分，也该属于 CSS。这些会慢慢实现，当 Webkit 之外的阅读器也开始支持这个功能，我们会看到很多令人惊讶的效果。
渐变色 定义一个固定色背景很基本，但渐变色就没有那么基本了，渐变色很适合通过代码实现，Webkit 又在这方面抢了先。
Box 阴影 阴影也是一种渐变色，以往是通过背景图片实现的，如果考虑到多方向的阴影，事情会变得更复杂，Box 阴影机制让一切疑问迎刃而解。
RGBa – 加入透明色 RGBa 中的 a 代表透明色，透明对设计者来说非常主要，目前除了 IE，这一功能正在被广泛采用。
文字阴影 也属于渐变色的概念，让文字拥有阴影，以前甚至不能通过图片背景实现，因此这将为设计者带来前所未有的方便。

IE6 CSS bug: position:relative元素被overflow:auto/scroll元素包含

Kelvin — Tue, 16 Mar 2010 00:46:25 +0000

BUG描述：

页面中某div使用了position:relative，结合top=-25px等元素定位。在FF和IE7下表现正常，但是在IE6中该div会随鼠标滚动而滚动。

分析：

这是IE6一个已知的BUG：当某position:relative元素被带有overflow:auto/scroll属性的块级元素包含时，会表现出postion:absolute的行为。

解决方法：

为包含块元素添加属性position:relative。
把该元素的position:relative属性去掉，使用默认的static定位，并通过margin-top等属性实现类似的效果。

JavaScript类和继承：constructor属性

Kelvin — Fri, 12 Mar 2010 07:01:16 +0000

constructor属性始终指向创建当前对象的构造函数。比如下面例子：

// 等价于 var foo = new Array(1, 56, 34, 12);
var arr = [1, 56, 34, 12];
console.log(arr.constructor === Array); // true
// 等价于 var foo = new Function();
var Foo = function() { };
console.log(Foo.constructor === Function); // true
// 由构造函数实例化一个obj对象
var obj = new Foo();
console.log(obj.constructor === Foo); // true
// 将上面两段代码合起来，就得到下面的结论
console.log(obj.constructor.constructor === Function); // true

但是当constructor遇到prototype时，有趣的事情就发生了。

我们知道每个函数都有一个默认的属性prototype，而这个prototype的constructor默认指向这个函数。如下例所示：

function Person(name) {
this.name = name;
};
Person.prototype.getName = function() {
return this.name;
};
var p = new Person("ZhangSan");
console.log(p.constructor === Person); // true
console.log(Person.prototype.constructor === Person); // true
// 将上两行代码合并就得到如下结果
console.log(p.constructor.prototype.constructor === Person); // true

当时当我们重新定义函数的prototype时（注意：和上例的区别，这里不是修改而是覆盖），constructor属性的行为就有点奇怪了，如下示例：

function Person(name) {
this.name = name;
};
Person.prototype = {
getName: function() {
return this.name;
}
};
var p = new Person("ZhangSan");
console.log(p.constructor === Person); // false
console.log(Person.prototype.constructor === Person); // false
console.log(p.constructor.prototype.constructor === Person); // false

为什么呢？

原来是因为覆盖Person.prototype时，等价于进行如下代码操作：

Person.prototype = new Object({
getName: function() {
return this.name;
}
});

而constructor属性始终指向创建自身的构造函数，所以此时Person.prototype.constructor === Object，即是：

function Person(name) {
this.name = name;
};
Person.prototype = {
getName: function() {
return this.name;
}
};
var p = new Person("ZhangSan");
console.log(p.constructor === Object); // true
console.log(Person.prototype.constructor === Object); // true
console.log(p.constructor.prototype.constructor === Object); // true

怎么修正这种问题呢？方法也很简单，重新覆盖Person.prototype.constructor即可：

function Person(name) {
this.name = name;
};
Person.prototype = new Object({
getName: function() {
return this.name;
}
});
Person.prototype.constructor = Person;
var p = new Person("ZhangSan");
console.log(p.constructor === Person); // true
console.log(Person.prototype.constructor === Person); // true
console.log(p.constructor.prototype.constructor === Person); // true

JavaScript的事件代理

Kelvin — Tue, 02 Mar 2010 02:15:20 +0000

如果你想进一步了解如何用JavaScript来为网页添加交互性的话，你也许已经听过JavaScript的事件代理（event delegation）了，并且会觉得只有那些牛逼烘烘的JavaScript程序员才会关心这样复杂的设计模式。事实上，如果你已经知道怎么样去添加JavaScript的事件处理器（event handler），实现事件代理也是件轻而易举的事情。

JavaScript事件是所有网页交互性的根基（我指的是真正的互动性，而不仅是那些CSS的下拉菜单）。在传统的事件处理中，你按照需要为每一个元素添加或者是删除事件处理器。然而，事件处理器将有可能导致内存泄露或者是性能下降——你用得越多这种风险就越大。JavaScript事件代理则是一种简单的技巧，通过它你可以把事件处理器添加到一个父级元素上，这样就避免了把事件处理器添加到多个子级元素上。

它是怎么运作的呢？

事件代理用到了两个在JavaSciprt事件中常被忽略的特性：事件冒泡(Event Bubbling)以及目标元素。当一个元素上的事件被触发的时候，比如说鼠标点击了一个按钮，同样的事件将会在那个元素的所有祖先元素中被触发。这一过程被称为事件冒泡；这个事件从原始元素开始一直冒泡到DOM树的最上层。对任何一个事件来说，其目标元素都是原始元素，在我们的这个例子中也就是按钮。目标元素它在我们的事件对象中以属性的形式出现。使用事件代理的话我们可以把事件处理器添加到一个元素上，等待事件从它的子级元素里冒泡上来，并且可以很方便地判断出这个事件是从哪个元素开始的。

这对我有什么好处呢？

想象一下现在我们有一个10列、100行的HTML表格，你希望在用户点击某一单元格的时候做点什么。比如说有一次我就需要让表格中的每一个单元格在被点击的时候变成可编辑状态。如果把事件处理器加到这1000个单元格将会产生一个很大的性能问题，并且有可能导致内存泄露甚至是浏览器的崩溃。相反地，使用事件代理的话，你只需要把一个事件处理器添加到table元素上就可以了，这个函数可以把点击事件给截下来，并且判断出是哪个单元格被点击了。

用代码写出来的话是什么样呢？

代码很简单，我们所要关心的只是如何检测目标元素而已。比方说我们有一个table元素，ID是“report”，我们为这个表格添加一个事件处理器以调用editCell函数。editCell函数需要判断出传到table来的事件的目标元素。考虑到我们要写的函数中可能会重复用到这一功能，所以我们把它单独放到一个名为getEventTarget的函数中：

function getEventTarget(e) {
e = e || window.event;
return e.target || e.srcElement;
}

e这个变量表示的是一个事件对象，我们只需要写一点点跨浏览器的代码来返回目标元素。在IE里目标元素放在srcElement属性中，而在其它浏览器里则是target属性。

接下来就是editCell函数了，这个函数调用到了getEventTarget函数。一旦我们得到了目标元素之后，剩下的事情就是看看它是否是我们所需要的那个元素了。

function editCell(e) {
var target = getEventTarget(e);
if(target.tagName.toLowerCase() === 'td') {
// DO SOMETHING WITH THE CELL
}
}

在editCell函数中，我们通过检查目标元素标签名称的方法来确定它是否是一个表格的单元格。这种检查也许过于简单了点；如果它是这个目标元素单元格里的另一个元素呢？我们需要为代码做一点快速修改以便于其找出我们所需要的那个父级的td元素。如果说有些单元格不需要被编辑怎么办呢？此种情况下我们可以为那些不可编辑的单元格添加一个指定的样式名称，然后在把单元格变成可编辑状态之前先检查它是否不包含那个样式名称。选择总是多样化的，你只需找到适合你应用程序的那一种就可以了。

有哪些优点和缺点呢？

JavaScript事件代理带来的好处有：

那些需要创建的以及驻留在内存中的事件处理器少了。这是很重要的一点，我们得到了性能上的提升，同时降低了崩溃的风险。

在DOM更新后无须重新绑定事件处理器了。如果你的页面是动态生成的，比如说通过Ajax，你不需要再在元素被载入或者卸载的时候来添加或者删除事件处理器了。

潜在的问题也许并不那么明显，但是一旦你注意到这些问题，你就可以轻松地避免它们：

你的事件管理代码有成为性能瓶颈的风险，所以尽量使它能够短小精悍。
不是所有的事件都能冒泡的。blur、focus、load和unload不能像其它事件一样冒泡。事实上blur和focus可以用事件捕获(Event Capturing)而非事件冒泡的方法获得（在非IE的浏览器中），不过我们改天再说这个吧。
在管理鼠标事件的时候有些需要注意的地方。如果你的代码处理mousemove事件的话你遇上性能瓶颈的风险可就大了，因为mousemove事件触发得非常频繁。而mouseout则因为其怪异的表现而变得很难用事件代理来管理。

总结

已经有一些使用主流类库的事件代理示例出现了，比如说用jQuery、Prototype以及Yahoo! UI的。你也可以找到那些不用任何类库的例子，比如说Usable Type blog上的这一个。

在你需要的时候，事件代理将成为你工具箱里一件得心应手的工具，而且它真的很容易实现。

透支爱情

Kelvin — Mon, 22 Feb 2010 06:16:17 +0000