無標題文檔

关联的 script 标签

从 James Padolsey 这里 得到个好的点子。

在实际写脚本过程中可能有段 Javascript 和 HTML 非常相关(比如实例化 Slider 等这样组件),那么通常我们会将它紧放到 HTML 的后面。

「传统」的做法需要顾虑的点有很多。因为脚本是立即被执行的,所以要考虑例如调用的组件是否已经声明,以及如果有 Ajax 请求是否会堵死浏览器等等。

下面的代码就是本篇 Blog 提供的另个思路,但愿我看起来不是那么的火星:

<div id="some-div">
    <script type=":contextual">
        alert(this.id); // "some-div" is alerted
    </script>
</div>

原文 作者的想法是改变 script 标签的 this 指向到父节点的 Element,从而关联上下文 HTML 结构。

看它的实现代码:

<script type="text/javascript">
~function() {
    var scripts = document.getElementsByTagName('script'),
        script, i = 0;
    while ((script = scripts[i++])) {
        if (/:contextual$/.test(script.type)) {
            (new Function(script.innerHTML)).call(script.parentNode);
        }
    }
}();
</script>

不过如原作者所说的外,其实还有很多顺带的好处

  1. 将 this 指向关联到父节点,遍历查找 DOM 非常的方便
  2. 相关的 script 标签和 HTML 结合紧密,很清楚就能明白这段脚本需要做什么
  3. 统一调用,可以考虑懒加载
  4. 方便复制粘贴 :^)

当然,上面的代码仅仅是个想法而已,在实际编码中还需谨慎应用。滥用此方法可以预料到的 些问题,比如:

  1. 脚本执行顺序改变
  2. 弄乱作用域,如果你的代码严重依赖 this ,那么将会是个噩梦(当然,这本身也不是个好习惯)
  3. 让不了解此机制的其他开发者迷惑

正如原作者所言,在我们写代码的时候能「Thinking outside the box」,那才是最重要的 :^)

-- EOF --

Google Chrome Frame 的罗生门

距离 9 月 23 日, 刚好是 Google 的 Chrome Frame 发布一个月的日子 ,来自各方面对 Chrome Frame 的声音也逐渐的清晰。

微软

作为重点的当事人,我们自然首先会关注微软的反应。情理之中的,微软自然不会承认这款软件, 指责「Chrome Frame 让 IE很不安全」

其实,微软的指责明显没有多大的底气,IE 的安全性能在业界早已声名狼藉,微软此言一出贼喊捉贼难免让人贻笑。与其说 Chrome Frame 让 IE 的安全性变差,倒不如说是 Chrome Frame 让微软自己的安全感全无。

想象一下假设有一天,Google 对用户说「Windows 让 Chrome 很不安全」,那是何等的景象 -- Google 可以做到,Chrome OS 呼之欲出但微软无论如何都不想让它发生。

面对 Google 等公司带来的压力,加之 Vista 事实上的失败让微软已经没有退路,但微软当然不会坐以待毙。历史总是那么的巧合,就在 Chrome Frame 发布后的一个月,也就是 10 月 22 号, 搭载者 IE8 的 Win7 系统发布 ,对于微软而言荣辱甚至胜负在此一举。

Mozilla

原本和 Google 站在同一阵营的 Mozilla , 这次出人意料的抨击起 Chrome Frame ,称其「会干扰用户,破坏游戏规则」。

Mozilla 这举动虽在意料之外,但细想之下也在情理之中。以技术主导的 Mozilla ,继承了开源社区的基因,它们或多或少的流着理想主义的血液。

在我眼中,Mozilla 其实想要做的不仅仅是浏览器以及邮件客户端,他们的愿景是成为互联用户信息的入口。令 Mozilla 纠结的是,在用户的使用数量上稳坐二把交椅的 Firefox ,至今仍然没有找到如何将量转化为自己核心竞争力的突破口。

Mozilla 与 Google 的蜜月期已经结束,从 云编辑器 再到 拓展移动浏览器市场 ,下一步该走向何方 Mozilla 表现得非常的迷茫。相比微软、Google 以及在移动浏览器市场占领先机的 Opera,握在 Mozilla 中的筹码显得非常的单薄。

前有 Google、微软、后有 Opera、Apple,Mozilla 在浏览器市场得势不得分。因此,Mozilla 需要时间寻找契机作为自身的突破口,而此时 Chrome Frame 的出现明显打乱了 Mozilla 的计划。

Chrome Frame 在 Mozilla 眼中就像是个不听话的孩子,它随时都有可能拿着块石头敲邻居的窗。这次针对的是微软,那么下次呢?

开发者

似乎有了 Chrome Frame,开发者似乎有了更好的选择,甚至可以再有个充分的理由抛弃 IE。因此,对于 Chrome Frame 开发纷纷持肯定态度。

显然,开发者对 Chrome Frame 有些过于理想化。对于 Chrome Frame 的这种态度,其实是出于对 IE 的「恨铁不成钢」情绪,而真正对于 Chrome Frame 本身热衷者甚少。

在这一个月中,Chrome Frame 的新闻形成了长尾效应,同时开发者对于 Chrome Frame 的新鲜感逐渐的散去,这说明 Chrome Frame 的「满月酒」并不好喝。

Win7 的上市,最新相对兼容标准的 IE8 普及以后,开发人员对于 Chrome Frame 的热情是否还会有增无减?对开发者而言「日子还在继续」,就目前的情况看来,不可能因为 Chrome Frame 而完全抛弃 IE。

Google

正如 Mozilla 所言,Google 从来就是家「破坏游戏规则」的公司,恐怕只有 Google 自己知道推出 Chrome Frame 的真正用意。

妄自推测 Google 推出 Chrome Frame 并非是出于改造 IE 的目的,而是它整合「云」计划中的步骤之一。从搜索到软件、从产品到到平台,Google 正在逐步的完成自己的愿景 -- 整合全球信息。那么,效率以及兼容性低下的 IE 只不过是其计划过程中的绊脚石而已。

无论是 Chrome Frame、还是 Chrome 浏览器、还是 V8 JavaScript 引擎,Google 都采用了开源的策略,尽量使这些产品相对的中立。这充分说明 Google 其实并不是想依靠自身品牌推销这些产品,而是让想它们成为事实的标准。

一个月时间对于款软件而言仅仅是新生的开始,Chrome Frame 以后的航向如何?还是那句话,我们拭目以待。

「我们搬家喽」

公司人员增长速度很快,位置也越来越少,因此我们搬到了新的办公地点。我的运气不错,搬到了靠窗的位置,除了 下午吃饭时间从二楼食堂飘过来味道让人难以忍受以外,其他都感觉非常的满意。

在搬家前还是得合照纪念下。别看错了,下面的合照不是 整个 UED 人员 ,仅仅是部分 UED 前端成员。 现在如果要记录他们每人的 Blog ,得累死我了 :^)

想认识我们, 就到这里看下标注版吧

https://friable.rocks/_/2009_11_05/9474383bd9a5.jpg

https://friable.rocks/_/2009_11_05/8968883bd9bd.jpg

对比下当年 在北京举行 D2 的时候 拍的合照(很明显,我该减肥了):

https://friable.rocks/_/2009_11_05/77789578dd03.jpg

时间过得真快,两年多的时间前端从当时的五六号人,发展到了现在的二十多号人。这也 从个侧面说明公司正处于极速发展中。

顺便插播下广告:对淘宝 UED 前端职位感兴趣的同学, 可以来我们这里尝试下 ,说不定下张照片中就有你的身影。

-- EOF --

我的照片

嗨!我叫「明城」,八零后、码农、宁波佬,现居杭州。除了这里,同时也欢迎您关注我的 GitHubTwitterInstagram 等。

这个 Blog 原先的名字叫 Gracecode.com 、现在叫 「無標題文檔」 。 要知道作为码农取名是件很难的事情,所以不想在取名这事情上太费心思。

作为八零后,自认为还仅存点点可能不怎么被理解的幽默感,以及对平淡生活的追求和向往。 为了避免不必要的麻烦,声明本站所输出的内容以及观点仅代表个人,不代表自己所服务公司或组织的任何立场。

如果您想联系我,可以发我邮件 `echo bWluZ2NoZW5nQG91dGxvb2suY29tCg== | base64 -d`

分类

搜索

文章