In WICG/webcomponents#513 (comment) the idea of making the change event use composed: true was raised but I didn't see any further discussion on this and now I think there is inconsistency with respect to input vs. change events. The former uses composed: true whereas the latter does not yet they are very similar events, at least on text <input>s. I can't think of a reason why it would be desirable to have this discrepancy between the two. It seems like this was an unfortunate oversight unless this was discussed in a meeting and didn't make it back into the issue.
The MDN page for Event.composed currently states:
All UA-dispatched UI events are composed (click/touch/mouseover/copy/paste, etc.).
which I would consider incorrect given that many would consider the change event a UI event (lowercase e).
I assume the main reason why the change event isn't part of the UI Events specification is because it doesn't use a subclass of Event for historical compat. reasons but it seems like it should be treated like a UI event for most purposes.
Is there any chance of fixing this inconsistency at this point? It's not uncommon to use both events in a single library and this issue leads to incorrect behaviour with Shadow DOM.
In WICG/webcomponents#513 (comment) the idea of making the
changeevent usecomposed: truewas raised but I didn't see any further discussion on this and now I think there is inconsistency with respect toinputvs.changeevents. The former usescomposed: truewhereas the latter does not yet they are very similar events, at least on text<input>s. I can't think of a reason why it would be desirable to have this discrepancy between the two. It seems like this was an unfortunate oversight unless this was discussed in a meeting and didn't make it back into the issue.The MDN page for Event.composed currently states:
which I would consider incorrect given that many would consider the
changeevent a UI event (lowercase e).I assume the main reason why the
changeevent isn't part of the UI Events specification is because it doesn't use a subclass ofEventfor historical compat. reasons but it seems like it should be treated like a UI event for most purposes.Is there any chance of fixing this inconsistency at this point? It's not uncommon to use both events in a single library and this issue leads to incorrect behaviour with Shadow DOM.