When the events are fired seems strange

[w3c]

When the events are fired seems strange

[annevk]

That sentence is almost certainly wrong.

[annevk]

We don't want the timing of mutation events for any new events.

[johanneswilm]

@annevk: What is your alternative proposal?
@garykac: I wonder if we actually need any sentence here? Given that the order of the events is in the UI Events spec, and this sentence also is there, we should likely not have anything here.

[annevk]

I don't know. But this is wrong. They need to come from their own task or maybe microtask. Definitely not dispatched with the mutation.

[johanneswilm]

@annevk: Would you agree that this prose text should be in the spec where the event order is defined? If yes, I think this sentence should be deleted entirely here and the new model for how to describe when such events should be fired should go into the UI events spec.

[annevk]

This prose should be in the specification that defines the action that causes the event to be dispatched. (UI events is rather bad in that it doesn't actually define actions, it just defines some events, some ordering between them, but nothing that amounts to a model.)

[johanneswilm]

Well the exact "action" is undefined for now as this will be user agent specific.

The UI Events spec says something about the order of events if the action happens to involve keyboard clicks. For other actions (drag/drop, etc. ) this still needs to be added to other specs.

So yes, maybe this should be here. But then it shouldn't additionally have a contradictory descrption in UI events. Or what do you think, @garykac?

[annevk]

Well the exact "action" is undefined for now as this will be user agent specific.

You will need to say something about it as otherwise you have nothing to queue a task from from which you can dispatch events and such.

[johanneswilm]

Closing as it was determined that these events cannot be reformulated in terms of task/microtasks, https://www.w3.org/2016/09/22-webapps-minutes.html#item14

[domenic]

That discussion did not contain anything that resolves this issue. Just because you can't use microtasks, that doesn't solve the problem that when these events are fired is not well-defined. This should be left open.

[johanneswilm]

@domenic: right, but that discussion is to be taken in ui-events. Are you ok with that and can we close this?

[annevk]

If you still plan on defining the event in some form, it seems like UI events needs to provide you with a hook that you'd use to fix this issue, no?

[domenic]

No, I think it's important to have a tracking issue on what's wrong with this spec, since it is a separate spec from UI events.

[johanneswilm]

This point was discussed at the F2F and this seems to have been the conclusion. Do we need to put this on the schedule of another F2F? If so,could you please deliver more concrete input as what you want us to do with this spec on this point, @domenic?

[domenic]

I don't think F2F discussions are what's needed here. What's needed is actually fixing the model. Maybe that needs support from UI events, in which case this issue will remain open until UI events gets fixed and that support is in place. Or maybe it can be fixed independently---I am hopeful that since this spec is smaller, it can stand independently with its own smaller model. But regardless, this issue should remain open, not until more discussions are had, but until more work is done.

[johanneswilm]

@domenic the event order and the entire discussion around that isin ui events, not here. This spec only defines some extra attributes on an event defined in ui events.

[domenic]

OK, if this spec has no intention of standing alone, then this issue needs to remain open until UI events provides the appropriate framework to fix the issue.

[johanneswilm]

Ok. I think there is some comfusion here. This spec is merely an extension on ui events explaining a few attributes of this event which is specced in ui events. This division is something three browsers came up with in January. Event order, etc. should not be here.

Or maybe I don't get what you are proposing. In that case, could you reformulate it as a concrete proposal so that we can agree on a resolution saying whether or not we want to do this (btw, I am planning on deleting the sentence in question here as it's a duplication from ui events, let me know if you are not ok with this).

[annevk]

Even if you only add some attributes, you still need to initialize those attributes before the event is dispatched. So that requires participation in an algorithm that UI events may or may not define at some point in the future. Either through some kind of hook, or through UI events taking over this space. Either way, I agree with @domenic that you cannot really resolve this without the larger issue being addressed.

[domenic]

I am proposing that this spec have an issue list that accurately reflects the problems with it, that make it impossible to faithfully implement. My concrete proposal is that this issue is left open until it becomes implementable in a compatible way across browsers. I understand from you that this will depend on work in UI events. That is fine.

[johanneswilm]

Ok, but can we move the issue to ui-events?

[domenic]

No! It is important to have an issue on this repository which reflects the outstanding issues with the spec! I am having a hard time understanding how I can make this clearer.

Having zero issues is not a virtue, if your spec is not actually implementable. It seems you are more concerned with the issue count reaching zero than with ensuring that the issue count accurately reflects the status of the spec.

[johanneswilm]

@domenic: ok, but concretely, what sentences in this spec should be changed or what should be added or deleted, considering that the sentenve this issue was originallyabout only was here by mistake and the original really is in ui-events.

[domenic]

but concretely, what sentences in this spec should be changed or what should be added or deleted

From what you've said, it sounds like this issue will not be solvable by changing sentences in this spec, or at least, that's the direction the WG has chosen to go. That's fine. The spec still has an open issue that needs to be reflected in the issues list, even if that issue cannot be solved by changing sentences in this spec.

[annevk]

As I pointed out in #9 (comment), you likely do need to change this specification once UI events has figured out a model (or alternatively this specification becomes obsolete).

[johanneswilm]

Ok. I don't get what you guys are saying nor do I see a concrete proposal here. So we keep it open and then you can present at the next F2F or other meeting of editing taskforce or ui events meeting what it is you are proposing for us to do.

[annevk]

https://lists.w3.org/Archives/Public/www-dom/2014JanMar/0064.html is a basic description of the problem. It requires adjustments to UI events (to start defining actions), but it also requires adjustments here (to take the input from those actions and translate to the correct attribute values). So you can't just move it, since it affects both specifications. There's no processing model that ties everything together.

[johanneswilm]

@annevk Ok, how about opening an issue at ui-events additionally (if this hasn't been done yet), and then linking the two issues together? That way we can more easily track here if those changes in ui events have taken place, which would mean that we can start working on this here.

Also, how about closing this issue and replacing it with a new issue on this that is more specifically addressing what you mention. Otherwise new readers have to wade through a lot of initial comments that no longer seem relevant.

In the meantime I will add the tag "future" to signal that this is something that depends on other things to happen in other places and isn't something that will be fixed in the very near-term. Hope you guys are ok with that.

[annevk]

w3c/uievents#23 is that issue.