search

WICG / webcomponents

Web Components specifications
Other
4.38k stars 375 forks source link

Events whose composed flag should be true #513

Closed hayatoito closed 8 years ago

hayatoito commented 8 years ago

We have decided to use Event.composed flag (false by default), instead of Event.scoped, negating its meaning. See the context: https://github.com/whatwg/html/issues/1160.

That means we should have a list of exceptional events whose composed flag should be true, instead of the current list.

Eventually, instead of having a list in one place, each event's definition should mention its composed flag should be true in each place, but I would like to have a rough consensus here.

I have made a list of events whose composed flag should be true by default, I think. The list is basically made from UIEvent spec: https://w3c.github.io/uievents/.

I am going to update Blink's implementation, however, what do you think about Composition Events? I am not 100% sure what should I do for Composiition Events. Should we exclude Composition Events from here?

hayatoito commented 8 years ago

Thank you for the feedback.

For compatibility issues, a naive way of not breaking public API might be "catch an animation event in the shadow tree, and fire a new synthetic (the same kind of) animation event for the host". I am aware that this is all more complicated that it needs to be. :(

Could it be an acceptable work around???

I am not sure what is the best solution to address this issue. I would like to hear opinions from other browser vendors.

rniwa commented 8 years ago

This was my earlier point:

The component could fire a custom event, but that requires more boilerplate for its author (has to add listeners, catch it, forward a different name, and do cleanup work in detached). It's more natural to use the animation events already being fired.

IMO, that's all more complicated than it needs to be.

I could imagine adding some sort of a hook in v2 to make this easier. That is, add some API to specify whether a given event should propagate out of the current shadow tree.

But in general, the same argument could be used to make almost every event composed, and we don't want to do that at least for v1.

annevk commented 8 years ago

I agree with @rniwa. A v2 API where you can override some of this on the shadow root sounds interesting and might be worthwhile.

jsilvermist commented 7 years ago

The fullscreenchange event (and fullscreenerror) which is a part of the Fullscreen API and is currently implemented in most browsers behind a prefix is not being fired with composed, making the Fullscreen API much harder to use.

annevk commented 7 years ago

@jsilvermist you're looking for #614.

jsilvermist commented 7 years ago

@annevk Yes... Yes I was... Thanks!