根据XForms specification，大多数事件被称为“冒泡”。
根据DOM Level 2 Event Specification，“冒泡”事件意味着与事件分发目标的祖先元素相关联的该事件的处理程序也将接收此事件。
对于要指定为“气泡”的事件，这意味着xf：dispatch操作无法修改气泡行为以将其限制为目标。
我不明白这么多xforms事件冒出来的好处是什么。例如，xforms-select和xforms-deselect。它们适用于xf：item（属于xf：select *）和xf：case（属于xf：switch，即用于带有标签的表单）。
比方说，我有一个带有xforms-select处理程序的xf：case，它将在昂贵的呈现窗口小部件上进行刷新，仅在实际选择选项卡时才更新，而不是每次更新模型时。现在，我在同一标签中也有一个xf：select。现在，只要用户在该选择中选择另一个项目，xf：case就会在冒泡阶段收到xforms-select，每次都执行昂贵的更新操作。
这似乎没有道理。
实际上xforms-node-attached正确：我们真的想具体说明哪个form元素将节点附加。但是除此之外，据说大多数事件都会冒泡。
如果我理解此问题的原因，我可以使自己更好地适应这个问题。否则，我很想更改XForms引擎，以使xforms-select和xforms-deselect的定义不冒泡。
答案 0 :(得分：1)
这是为了允许所谓的事件委托：
“事件委托是指使用事件传播（冒泡）在DOM中比事件起源于元素的更高级别处理事件的过程。它使我们可以为现在存在的元素附加单个事件侦听器或将来。” （来自旧版this jQuery doc page）
总的来说，这是一件好事：
在HTML世界中，似乎事情已经朝着让一切腾飞的方向发展。例如，旧的focus事件没有冒泡，而新的focusin事件却冒泡。
如果您有一个事件处理程序，该事件处理程序被调度到多个目标的事件激活，则在某些情况下，您需要具有区分能力。这是事件上下文信息有用的地方。 jQuery之类的库还允许您关联一个由CSS选择器过滤的事件处理程序，它很简洁。
现在特别是在xforms-select的情况下，您的问题是，您无法区分发送给xf:case的事件与xf:select的事件。这可能意味着XForms不应在这两种情况下都具有单个事件，或者它应该具有足够的事件上下文信息来区分这两种情况。我不认为这为不让事件冒泡提供了理由。