Re: [w3c/webcomponents] Events whose composed flag should be true (#513)

> Yeah, I think it could happen that developers forget to add 'composed=true' when they should specify it, but that should not be a significant problem for developers, I think. They can learn, and fix it easily.

But would they typically need to?  I guess my position would be that if we're really going to ask developers to ALWAYS specify `composed=true` for their synthetic input events, then we should further explore @rniwa's idea of just making that happen for them by default.  But if it really doesn't matter in most cases (`false` would typically produce unsurprising behavior), then I'm fine with the plan as-is. 

Two main classes of use cases I can think of for synthetic input events:

1) Dispatching a synthetic input event for testing / UI automation purposes.  In these cases I think the developer typically knows the exact target / abstraction layer and doesn't generally on bubbling.  So I _think_ that getting `composed=false` would be fine in these cases.  Right?

2) Dispatching a synthetic input event of one type based on another event.  Eg. some libraries generate synthetic `MouseEvent` instances for `TouchEvents` they receive (or `TouchEvent` for `PointerEvent`, etc.).  In those cases, all the event properties (including `bubbles`, `composed`, etc.) should be copied into the new event, so this makes sense for new code.  But that won't be happening today.

In particular, imagine a complex site that added `TouchEvent` support by installing a general purpose library that fired synthetic `MouseEvent` instances for `TouchEvent`s seen.  Somewhere else on the site they start using custom elements.  Now touch events that hit that custom element will not work correctly (since the synthetic mouse events won't propagate across the shadow boundary) without also updating the synthetic event generation library.  Maybe that's OK, but it's certainly an easy developer trap, which @rniwa's proposal would avoid.  Incidentally, this would have worked fine with chromium's V0 ShadowDOM.


---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/513#issuecomment-227828814