This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
"The following events must always be stopped at the nearest shadow boundary:" Since we relaxed the lower boundary in regard to events, we should similarly not stop events there.
Also, this needs to account for the nodes, distributed to the insertion point. Events from those should be heard outside of the shadow tree.
And we need to write down the rationale behind stopping these events.
I am trying to come up with a general rule of thumb. I guess is something like: If the event is retargeted, does event's meaning change? For example, if a "load" event is heard at a shadow host, it conveys the meaning of shadow host somehow completing loading, which is not true, because all it means that some element inside of host's shadow tree has completed loading. Conversely, if an "click" event is heard a a shadow host, it says that the shadow host was clicked. Since shadow tree is how shadow host is rendered, the meaning of the event stays the same. WDYT?
But if the shadow tree actually did load something via XMLHttpRequest and wanted to convey that you're lost. I suppose the current set of events is based on what WebKit needed? It seems unclear that will match the needs of developers when this gets out in the wild.
(In reply to comment #4) > But if the shadow tree actually did load something via XMLHttpRequest and > wanted to convey that you're lost. Then just fire a "load" event on the shadow host? > > I suppose the current set of events is based on what WebKit needed? It seems > unclear that will match the needs of developers when this gets out in the > wild. We only wanted to stop a "selectstart" in WebKit. The rest of the list is based on Microsoft's experience with HTC: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15804
From a thread on whatwg: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-December/038283.html >It sounds though like you'd want a different approach to this. What if >I have a <video> as my implementation detail? Then you probably don't want the "load" events of <video> escaping out of the shadow tree, just as the spec provides. It's an interesting question, though. Along with "load", such implementation detail may dispatch a whole bunch of other events (http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#mediaevents). Most of these events--at least, following my reasoning--seem like they should just be kept in the shadow tree. I wonder if we would be better off reversing the condition and stopping ALL events, except a set of events whose meaning stays clear after retargeting (like "click").
*** Bug 20248 has been marked as a duplicate of this bug. ***
Also interesting comments in bug 20633.
*** Bug 20633 has been marked as a duplicate of this bug. ***
http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/thread.html#msg312 is how we should solve this imo.
Bug 21269 has a great discussion around use cases to arbitrarily control event stopping.
*** Bug 21269 has been marked as a duplicate of this bug. ***
*** Bug 21400 has been marked as a duplicate of this bug. ***
A polymer user had a question about this today which prompted some discussion (www.polymer-project.org). I think at the least the spec needs to be updated to explain the logic behind stopping events. Most of the events that are stopped are non-bubbling events (except 'change'). Since these don't bubble, why must they be stopped? Is this to prevent capturing? Stopping events poses some problems: 1. Are the events stopped entirely by name? For example, if a synthetic event is dispatched called 'load' will it be stopped? If so, that seems bad. 2. In the context of custom elements, the developer may want control over whether or not the event stops at the shadowDOM boundary. In light of this complexity, it seems like a more complex api would be needed to be able to hide shadow events effectively. Instead of introducing this complexity, perhaps we can remove the concept of stopped events entirely and instead rely on bubbling behavior. Non-bubbling events will naturally not propagate outside shadowRoot. Events that are captured would just be retargeted.
I've added a like to this issue to the spec: https://github.com/w3c/webcomponents/commit/aa322cb29c114f2886264e565043874996705aeb
(In reply to Hayato Ito from comment #15) > I've added a like to this issue to the spec: > > https://github.com/w3c/webcomponents/commit/ > aa322cb29c114f2886264e565043874996705aeb s/like/link/.
The solution here is to add a bit flag to the event dispatch algorithm whether or not the event needs to be scoped to the shadow tree. And then set it in specifications from all the relevant features, such as e.g. <img>'s load & error events.
Moved to https://github.com/w3c/webcomponents/issues/61