Events 为什么xforms选择和取消选择元素会冒泡？

根据大多数事件被称为“泡沫”

根据一个事件，“气泡”意味着与事件分派目标的祖先元素关联的该事件的处理程序也将接收该事件

对于指定为“气泡”的事件，这意味着xf:dispatch操作无法修改气泡行为以将其限制到目标

我不明白这么多xforms事件的好处是什么。例如，xforms选择和xforms取消选择。它们适用于xf:item（属于xf:select*）和xf:case（属于xf:switch，即在带有选项卡的表单中使用）

假设我有一个xf:case和一个xforms选择处理程序，它将在一个昂贵的呈现小部件上引起刷新，而不是每次更新模型时，才真正选择该选项卡。现在我在同一个选项卡中还有一个xf:select。现在，每当用户在该选择中选择另一项时，xf:case就会在冒泡阶段接收xforms select，每次都会执行代价高昂的更新操作

这似乎没有道理

事实上，xforms node attached是正确的：我们真的希望具体说明哪个表单元素连接了节点。但除此之外，据说大多数事件都是泡沫

---

如果我能理解这一点的原因，我就能更好地理解这个问题。否则，我会尝试更改我的XForms引擎，以更改XForms select和XForms deselect的定义，使其不冒泡。

这是为了允许所谓的事件委派：

“事件委派是指使用事件传播（冒泡）在DOM中处理事件的过程，其级别高于事件起源的元素。它允许我们为现在或将来存在的元素附加单个事件侦听器。”（来自旧版本的）

总的来说，这是一件好事：

• 您使用的事件侦听器更少
• 侦听器可以侦听多个目标
• 在添加/删除DOM元素时，不需要删除/添加侦听器

看起来，在HTML世界中，事情已经朝着让一切都冒泡的方向发展。例如，旧的

focus

事件没有冒泡，而新的

focusin

事件冒泡

如果您有一个事件处理程序，它被发送到多个目标的事件激活，在某些情况下，您需要能够区分。这就是事件上下文信息有用的地方。像jQuery这样的库还允许您关联由CSS选择器过滤的事件处理程序，这很简单

现在在

xforms-select

的情况下，您的问题是无法区分发送到

xf:case

的事件与发送到

xf:select

的事件。这可能意味着XForms对于这两种场景不应该只有一个事件，或者应该有足够的事件上下文信息来区分这两种场景。我不认为这是不让事件泡沫化的理由