innerHTML 的些摘记May 31, 2009

异步 innerHTML

innerHTML 插入节点的性能的问题,通常是我们最关注的。在回答这问题时James Padolsey 给出了他的解决方案,看到上述代码不仅赞叹了下:

function asyncInnerHTML(HTML, callback) {
    var temp = document.createElement('div'),
        frag = document.createDocumentFragment();
    temp.innerHTML = HTML;
    (function(){
        if(temp.firstChild) {
            frag.appendChild(temp.firstChild);
            setTimeout(arguments.callee, 0);
        } else {
            callback(frag);
        }
    })();
}
  1. 充分利用闭包解决 IE6 的内存溢出问题
  2. 使用延时 0 将操作从队列中拉出,防止浏览器假死
  3. Document Fragment 给予我们个相当好的沙盘,只是我们经常忘记了它
  4. 回调的节点可以使用 DOM 标准的手法(appendChild)插入

了解了参数就很容易调用,例如

var htmlStr = '<div><p>...</p><p>...</p><div><div>...</div>';
asyncInnerHTML(htmlStr, function(fragment){
    document.body.appendChild(fragment);
});

再次不禁赞叹下!

组织 innerHTML 字符串

说到 innerHTML ,通常在这操作之前会有大部分的字符串操作用于连接节点。考虑下面的三种做法,有何不同

方式一

var arr = ['item 1', 'item 2', 'item 3', ...];
for (var i = 0, l = arr.length, list = ''; i < l; i++) {
    list += '<li>' + arr[i] + '</li>';
}
list = '<ul>' + list + '</ul>';

方式二

var arr = ['item 1', 'item 2', 'item 3', ...];
for (var i = 0, l = arr.length, list = []; i < l; i++) {
    list[list.length] = '<li>' + arr[i] + '</li>';
}
list = '<ul>' + list.join('') + '</ul>';

方式三

var arr = ['item 1', 'item 2', 'item 3', ...];
var list = '<ul><li>' + arr.join('</li><li>') + '</li></ul>';

详细的对比测试在这里(没错,还是 James Padolsey 那小子的 Blog)。同时,PPK 也整理了份有关 innerHTML 的速度测试报告

IE 的陷阱

对于 IE,innerHTML 有个不大不小的陷阱(via),就是在 tbody 中插入 innerHTML 时,会报莫名的“未知的运行错误”。

测试地址在这里(经过测试,在 IE8 中仍然如此)。有兴趣的同学可以参看更详细的信息

IE8 的 JSON 解析 BugMay 21, 2009

使用 IE8 时发现其原生的 JSON 解析器存在 Bug,让我们先用 IE8 打开 DEMO 页面体验下。

http://lab.gracecode.com/bug/ie8-json-stringify.html

主要的问题就是 IE8 的 JSON 组件对空的表单输入控件(input、textarea)的值检测存在类型检测错误,它会认为空的表单值为 NULL,进而造成 JSON 解析错误。

IE8 会将 input_value 为空(没有任何输入)的情况下,解析成

{"value":"null"}

而实际的预期应该是

{"value":""}

所以如果你不幸要针对 IE8 Coding(这是不可避免的)而且胆子大想尝试其原生的 JSON 解析组件时,最好先保证类型是预期的。例如上述的 Bug,在修复之前只能使用

JSON.stringify({value: input_value + ''});

这样的方式。

再次赞叹 IE 系列给咱前端创造的那么多的就业机会。

-- Update --

找了下微软官方,发现这个 Bug 早有人提交,查看详细

看图购的 AIR 版本(预览版)April 18, 2009

http://lab.gracecode.com/imgo/images/logo.png

相信很多关注淘宝的朋友都知道淘宝近期出了个“看图购”项目。细心的朋友也会发现,看图购本身是基于 API 的,那么我们就可以根据这个 API 玩出很多花样。

最近也了解了下有关 Adobe AIR的些东西,于是就拿它来练练手。AIR 真的很容易上手,花一天的时间了解 SDK、花一天的时间编写界面、然后花两天的时间编写脚本,于是就捣鼓出了这个小玩意。

由于 PD、PM、交互、视觉、前端几乎都是我一个人,加上时间较紧,这东西还有很多优化的余地。大家有任何的意见和建议,欢迎提出。

-- Split --

Realazy 兄已经有了针对 AIR 的很中肯的点评,在这里我说下我的看法:

使用原有的技术即可实现传统桌面端软件的效果,AIR 的确提供给众 Web 应用提供商开发“桌面端”软件的最低成本的一种方式。同时,AIR 本身的易用性真的让人感到惊艳,以前使用的些开发经验和技巧可以完全的保留。

很多人都看好类 AIR 这种技术会在不久的将来会风行,我还是持比较谨慎的态度。

首先,传统桌面端开发环境的成熟程度是 AIR 望尘莫及的,这犹如小毛孩子和七尺壮男打一架是不现实的。

其次,还是不得不说的架构问题。AIR 目前架构从本质上说,还只是浏览器套上了层系统的外皮 -- 它实质上还是浏览器。要求它完全实现客户端软件的功能,还是有点强人所难的。

同时,正因为此,AIR 的性能还是让人感所诟病。不解决这一问题,AIR 会难以胜任更高层的应用,只能沦为前端的调味品。

正是因为利用 AIR 如此的便利,如果发挥不当会如 cherish 所言的那样,“让大部分的 Web 开发者变成披着狼皮的羊”。在目前相对浮躁的互联网环境下,尤其要注意这点 -- 工具本身没有错,就看怎么利用了。

最后,还有个心得是设计模式上的 -- 桌面端与传统的 Web 开发思维的确有微妙的不同,由于使用 AIR 时间并不长,就不班门弄斧了。

-- Split --

下面是“不负责任”的免责声明,有时候这是必须的。

本程序出于个人兴趣爱好制作,与淘宝网官方无关。因此程序造成的所有后果,本人与淘宝网不承担任何责任。

-- Split --

好了,说了那么多,兄弟们这就开始体验吧:http://lab.gracecode.com/imgo/ ,等到代码“可以见人了”,在适合的情况下会开源的 :^)

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. ...
  9. 25
Yahoo 统计