Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

对WebComponents相关API的一些看法

  目前的WebComponents包含了4个部分:ShadowDOM、CustomElements、HTMLImport以及TEMPLATE。从用途上分析的话,它们确实是神器,因为在此之前这些功能是难以实现的。但从API封装的角度分析的话,ShadowDOM这部分确实是个很糟糕的接口。
  TEMPLATE和HTMLImport的部分大家基本上都可以接受,而ShadowDOM和CustomElements就有点争议了。
  CustomElements我是挺喜欢的,比起使用一大堆DIV用class去区分,不如直接在标签名上做区分,但这只是我的观点。反对者认为这会破坏HTML的语义,使文档阅读起来更困难。其实我觉得,HTML的语义化能力本身就很弱,虽然在HTML上尽可能的符合语义是理所应当的,但毕竟HTML提供的标签非常有限,不能把语义化的任务完全交给HTML。如果要在HTML中嵌入语义的话应该考虑使用微数据
  document.registerElement也是属于CustomElements这部分的,里面的一堆callback定义也是原先没有的东西。我觉得这些callback很有用,它可以监控元素的基本状态(虽然MutationObserver也可以实现部分功能,但概念不同),实现ElementReady之类的功能。但目前只对自定义元素生效,我希望这些callback的定义能对普通HTML元素也生效。
  比起WebComponents的其它部分,ShadowDOM这部分API的设计确实让人爱不起来。我不是说ShadowDOM这个概念不好,这个概念对第三方内容开发是非常有用的。它是一个隔离的概念,比起传统的IFRAME隔离方式,这种方式显然更科学。但它的API太混乱了,我之前好像用了很大的篇幅才把整个ShadowDOM介绍完。特别是使用CONTENT标签来关联数据的地方,我觉得这个设计非常不科学。其实最初给任意元素提供createShadowRoot方法就感觉有点不对劲,如果所有元素都可以作为ShadowDOM,那比CustomElements的破坏语言要严重多了。还有“/deep/”之类的穿透ShadomDOM的选择器我也纠结了很久,一开始我觉得既然是隔离的概念,那就不该存在这些东西嘛。后来在一个ChromeOnly的项目中使用ShadowDOM封装了一套控件后才觉得,这东西还真有必要。因为控件是复用的,如果CSS没有穿透ShadowDOM的能力就要在每个ShadowDOM中重新定义一次相应的样式。
  总之,对于目前WebComponents的四个部分,我希望CustomElements扩展API,ShadowDOM修改API,其它两个保持现状。
网名:
3.80.32.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^