search

w3c / input-events

Input Events
https://w3c.github.io/input-events/
Other
23 stars 16 forks source link

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

Closed domenic closed 7 years ago

domenic commented 7 years ago

That spec is obsolete and should not be built upon. Probably you want https://dom.spec.whatwg.org/#events instead.

garykac commented 7 years ago

"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 commented 7 years ago

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 commented 7 years ago

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

johanneswilm commented 7 years ago

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

johanneswilm commented 7 years ago

@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 commented 7 years ago

DOM4

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

johanneswilm commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

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

johanneswilm commented 7 years ago

@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 commented 7 years ago

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

johanneswilm commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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