"This specification builds on the Document Object Model Events Level 3."

[w3c]

"This specification builds on the Document Object Model Events Level 3."

[garykac]

"DOM Level 3 Events" was the old name for the "UIEvents" spec - it was renamed to avoid confusion like this.

References to "DOM Level 3 Events" should be updated to point to UI Events. In any case, the input event spec was not built upon the DOM spec linked above.

[johanneswilm]

Hey @garykac. I suspected that, so I already updated it that way yesterday. Are there other parts in the spec that need to be changed?

[annevk]

Without DOM Standard there is no event dispatch or composed events so you need both (if you need UI Events).

[johanneswilm]

@annevk: What are you proposing? What should the exact wording be? (as a diff from what it currently is)

[johanneswilm]

@annevk: Given that the UI Events spec extends parts of DOM4 [1], wouldn't this spec automatically inherit all that is needed? Do we need to additionally specify that also in this spec?

[1] https://www.w3.org/TR/dom/

[marcoscaceres]

DOM4

Please don't reference that spec - it's non-normative and obsolete. Please only reference: http://dom.spec.whatwg.org/

[johanneswilm]

Given that the reference to DOM4 is in the UI Events spec and not here, should we maybe move this bug report to the UI Events spec instead? :)

[annevk]

@johanneswilm you don't really import all definitions like that. If you need to use "dispatch" somewhere, you would reference the DOM Standard directly and not some other specification that happens to reference the DOM Standard.

[johanneswilm]

@annevk Just like I reference the DataTransfer Interface in the particular place where it is needed, right? But the main spec this builds upon and that is the UI Events spec. Or should I list all specs that are referenced to in the abstract?

[annevk]

Just where you use them. Ideally an "Abstract" doesn't have any references or links and stands on its own.

[johanneswilm]

@annevk How about I link "dispatch" link to the UI Events glossary definition of that term? I don't think the word "composed" shows up anywhere, does it?

I guess the reason there has been a link in the abstract is that this spec has been so tightly connected to the UI Events spec that it really just looks like an extension of it. Also, some things have first been moved from UI Events here and recently back again. That's why there could still be some things left here that really also are in the UI Events spec and that really don't need to be in two places.

[annevk]

UI Events shouldn't contain a glossary definition for "dispatch". It's not a term it gets to define.

[johanneswilm]

Ok, I see the word "dispatch" shows up only in those lines that also are in the UI Events spec. So likely we should figure out whether these lines should be here or in UI events first. It would seem to make very little sense to have a different version of these lines here than in UI Events.

Btw, I am nots sure that the division between the "UI Events" spec and the "Input Events" spec as we currently have is the best possible division. But this is what most seemed to agree on about half a year ago, so we should probably stick with this for now.

[annevk]

Given that it seems most of the dispatching and behavior and initializing seems to belong in UI Events per your comments here and elsewhere, I agree that you likely made the wrong choice half a year ago and should reconsider.

[johanneswilm]

Before that we had the event definitions entirely in the "Input Events" spec and the "UI Events" spec just had links to the beforeinput/input events in its list of order of events. That would made it somewhat clearer where what should go, but it also meant that one needed to consult the "Input Events" spec to see the event definition for these two events. So there are advantages to both approaches. There seems to have been consensus about the change among the browser vendor representatives present, and the arguments are probably still the same, so changing this again now may just open more controversies again.

But we definitely need to figure out what to do about this. We shouldn't have the same text in two specifications, nor should this spec modify the conditions under which the event is triggered if it's already defined in the UI Events spec. And most of the bugs currently open here seem to be related to things that really are defined in the UI Events spec.

[annevk]

If they are really defined there, you getting issue reports about them implies you have normative statements that duplicate UI Events and/or the relationship is not explained well.

[johanneswilm]

@annevk Could you write a new ticket for that? This doesn't seem to be much connected with the original intent of the bug.