Firefox OS 开发:Web Components 和 Mozilla Brick

在本期的“Firefox OS:HTML5 应得的平台”(前六个视频已发布在此)中,Mozilla 首席布道师 Chris Heilmann (@codepo8) 采访了 Mozilla 的“高级 HTML5 工程师 Angle Bracket 协调员”Matthew Claypotch (@potch),探讨了 Web Components 为 Web 应用开发者带来的激动人心的新可能性,以及 Mozilla 的 Brick 库(一个用于构建应用程序的自定义元素集合)如何帮助开发者进行过渡。你可以在 YouTube 上观看访谈

Web Components 的意义

作为应用平台,Web 存在一个问题:HTML,这种用于标记文档并赋予其意义的语言,没有足够的元素来构建应用。HTML5 规范中有一些新的元素,但它们在各个浏览器中的支持参差不齐,并且仍然缺少其他平台(如 Flex 或 iOS)直接提供给开发者的许多小部件。因此,开发者使用非语义 HTML(主要是 DIV 元素)构建自己的“小部件”,例如菜单栏、滑块控件和日历,并使用 JavaScript 使其交互,并使用 CSS 使其主题化。

这是一种很好的解决方法,但问题在于我们是在浏览器的功能之上添加内容,而不是扩展它们现有的功能。换句话说,浏览器需要显示 HTML,并且至少能够以每秒 60 帧的速度出色地完成这项工作。然后,我们在此基础上添加我们自己的小部件功能,并对其进行动画处理和更改显示,而不会通知浏览器。我们不断地协调浏览器的性能和我们自己代码在它之上的性能。这会导致界面滞后、耗电和闪烁。

为了解决这个问题,一些公司和标准机构成员正在开发 Web Components 规范,该规范允许开发者使用自己的元素来扩展浏览器对标记的理解。与其编写滑块控件并在浏览器已经显示完文档后使其工作,不如定义一个滑块元素并使其成为正常显示流的一部分。这意味着我们的窗口小部件将变得更加响应,不会与浏览器的渲染流程冲突,并且总体上性能更好。特别是在低规格移动设备上,这将是一个巨大的胜利。整个过程已经开始:例如,如果你在文档中添加一个 video 元素,你将看到一个带有计时滑块条、播放按钮和音量控件的视频控制器。所有这些都是 HTML、CSS 和 JavaScript,你甚至可以在调试工具中看到它们。

Anatomy of a video element

Firefox OS 的目标是低端设备,因此它可以从作为渲染流程一部分的小部件中获益良多,这就是 Mozilla 创建 Mozilla Brick 的原因,它是一个用于构建应用程序的自定义元素集合。之前,我们使用名为 XTags 的库引入了这个概念,该库为 Brick 提供支持。使用 Brick,创建一个例如 基于卡牌的应用程序布局 很简单,使用以下标记


  
    0I'm the first card!
  
  
    1
    
      These cards can contain any markup!
2

生成的应用程序由三个卡牌组成,可以将其动画化到另一个卡牌中,而无需执行任何操作,只需调用 deck.shuffleNext(); 函数即可。

Web Components 目前是一个热门话题,每个星期都会出现许多库和框架。我们希望通过使用 Brick,我们可以使开发者能够快速干净地为 Firefox OS 构建非常响应的应用程序,并将让应用程序表现良好的痛苦留给操作系统。

关于 Chris Heilmann

HTML5 和开放网络的布道师。让我们修复这个问题!

更多 Chris Heilmann 的文章…


10 条评论

  1. Ivan Dejanovic

    我刚运行了 Brick 网站上的几个演示,它们看起来非常棒。

    我在文章中注意到,如果我理解正确的话,X-Tags 是 Brick 的基础。所以我去 X-Tag 网站查看了支持的浏览器。引起我注意的是它兼容 IE9+。

    我在公司提供的计算机上使用 IE8(我的工作计算机上的默认浏览器)尝试了 Brick 演示,发现它们无法运行。

    作为开发者,我的工作计算机上安装了最新的 Firefox 和 Chrome,但公司(一家大型的美国公司)的所有非开发者都只使用 IE8。我们的一些客户(国际金融机构)明确要求我们向他们交付的产品必须能够在 IE7 中运行。

    我不确定每个 IE 版本的当前市场份额,但我发现很多公司在采用新版本方面很慢。是否计划让 X-Tag 和 Brick 在 IE8 和更低版本上运行?仍然有一些用户必须使用公司安装的浏览器,他们无法更改或升级它们。

    感谢您精彩的演示,请继续开发 Brick。它看起来很有前景。

    2013 年 9 月 27 日 凌晨 1:59

    1. Chris Heilmann

      您好,Ivan,

      目前没有动力让基于 Web Components 的解决方案向后兼容旧版本的 Internet Explorer,主要是因为该浏览器的架构与 Web Components 的整个理念所基于的已达成标准不兼容。我理解你的沮丧,最好的解决方法是让 Brick 回退到更简单的界面。例如,卡牌可以是一个带有锚点的列表,用于跳转。

      对旧版 IE 的支持在测试任何新应用程序时都会带来巨大的开销,在大多数情况下,考虑到用户数量,这种努力是得不偿失的。在你这个案例中,公司有政策原因不进行升级,但令人悲伤的真相是,在连接到网络的计算机上运行任何类型的过时软件都是危险的。旧版 Internet Explorer 不仅是 Web 开发人员的麻烦,而且也是黑客和恶意软件分发者的非常有趣的攻击媒介。即使是微软也放弃了 IE6 (http://www.ie6countdown.com/)。

      2013 年 9 月 27 日 凌晨 2:25

    2. Doug Reeder

      正如 Chris Heilman 指出,支持旧版浏览器(主要是 IE)会消耗 Web 开发人员大量的时间(而且在预算中很少被提及)。

      支持旧版浏览器的常见方法是使用一个框架来弥合差异。如果你想要一个支持 IE8 及更高版本的组件式框架,Dojo (http://dojotoolkit.org/) 是一个流行的选择,而 Enyo (http://enyojs.com/) 则更适合你想要同时支持移动端和桌面端的场景。

      如果你需要支持 IE6 和 IE7,Dojo 1.8 及之前版本支持它们。

      2013 年 9 月 27 日 下午 1:52

  2. pd

    不再需要从子菜单中打开伪元素样式的显示,就像 Firebug 中一样,这是一个改进。响应式设计工具是一个 Firebug 还没有的改进。

    对于所有那些 Firebug 用户,Mozilla 似乎已经将重点转移到了其他地方,为了开放网络的未来,请优先关注以下错误

    https://bugzilla.mozilla.org/show_bug.cgi?id=815603

    毕竟,人们已经使用 Firebug 多年了。Mozilla 鼓励人们支持开放网络,从而支持 Firefox。开发者是确保遵循标准的人,多年来我们一直在敲打键盘,点击 Firebug 标签,试图构建你的开放网络。我们应该拥有一个功能正常的 Firebug。

    2013 年 9 月 27 日 上午 7:13

    1. pd

      抱歉,上面发错了地方,应该是这里:https://hacks.mozilla.ac.cn/2013/09/new-features-in-the-firefox-developer-tools-episode-26/

      2013 年 9 月 27 日 上午 7:15

  3. nadrimajstor

    一个新手问题
    如何在 FxOS 中访问影子 DOM 元素(如上图/视频标签元素所示)?

    2013 年 9 月 28 日 下午 2:13

  4. Aras

    我对 Brick 和 Web Components 非常兴奋,我认为它们让开发 Web 应用变得更加容易和有趣。

    我想知道是否会有一个 CDN 用于 Brick 的最新版本,或者也许它会被添加到 jsfiddle 中。虽然演示页面是展示可用组件的绝佳方式,但我认为如果人们可以立即开始与代码交互,将会更好。

    我的另一个问题是关于 Brick 的路线图。如何才能了解路线图上的组件,以及开发人员最需要哪些功能和组件?

    非常高兴看到这篇文章,继续努力!

    2013 年 9 月 28 日 下午 4:01

    1. Fred

      它很可能被添加到 JSFiddle 中。这是一个很棒的想法。我们与作者是好朋友,可以请他考虑一下!

      2013 年 10 月 1 日 下午 1:43

  5. niutech

    是否可以在一个应用程序中混合使用 X-tags、Bricks 和 Polymer 元素?它们兼容吗?X-tag 可以依赖或包含 Polymer 元素吗?
    为什么官方 Firefox OS 构建块不是用 Web Components 制成的?

    2013 年 9 月 29 日 上午 11:37

  6. DL

    虽然 Web Components 在结构方面提供了巨大的优势,但 Web Components 在性能方面为什么更好尚不清楚。传统小部件是在浏览器之上实现的,这一点没错,但 Web Components 也使用 HTML/CSS/JavaScript 定义,这一点也成立吗?

    传统小部件可能需要更多时间来初始化,但一旦小部件创建完成,它的工作方式与 Web Components 基本相同:一些 JavaScript 代码操作 DOM,浏览器渲染它。换句话说,我不太理解你所说的“动画和改变显示而无需通知浏览器”或“与浏览器的渲染流程作斗争”是什么意思。

    2013 年 10 月 2 日 上午 4:41

本文评论已关闭。