我有一对元素<file-location>和<file-location-dialog>. 如果用户单击 以<file-location>更改它，它会触发一个自定义事件，该事件正在由元素file-change-request在其 domHost 上侦听。<file-location-dialog>当它接收到这个请求时，它会存储event.path[0]刚刚收到的请求的值，弹出一个对话框，获取新位置，发送一个 ajax 请求以更新数据库，然后在存储的event.path[0]元素上触发一个file-location-updated事件。原始<file-location>元素收到此响应并相应地使用新位置更新屏幕。
我最初开发这个是因为我有一组搜索结果（可能多达 400 个），每个搜索结果都有这个文件位置。我认为我可以通过集中唯一偶尔使用的对话框和 ajax 元素来节省整体 dom 元素。这在搜索对话框中一切正常。
我最近来开发我的应用程序的另一个页面，其中<file-location>再次需要该元素。但是，没有考虑它，我将元素嵌入到<file-location>自定义元素的本地 DOM 中，<pas-appointment>而该<file-location-dialog>元素位于页面的自定义元素中，该页面使用<pas-appointment>内部的元素<template is="dom-repeat">
再次，这“似乎”工作正常。
显然，冒泡元素的层次应该没有问题file-location-request，但我突然意识到本质上file-location-updated是在刺穿shadow dom，因为它似乎无缝地穿过<pas-appointment>边界，就好像它不存在一样。
好的，所以它有效 - 那我为什么要问这个问题？我正在开发一些具有相似性质的其他元素。在我依赖这个设计模式之前，我可以确定它会继续工作，因为浏览器正确地实现了 shadow dom 规范。特别是当我们到达 Polymer 2.0 和 web-components v1 规范时可能会发生什么？