Events whose composed flag should be true

[hayatoito]

We have decided to use Event.composed flag (false by default), instead of Event.scoped, negating its meaning. See the context: whatwg/html#1160.

That means we should have a list of exceptional events whose composed flag should be true,
instead of the current list.

Eventually, instead of having a list in one place, each event's definition should mention its composed flag should be true in each place, but I would like to have a rough consensus here.

I have made a list of events whose composed flag should be true by default, I think. The list is basically made from UIEvent spec: https://w3c.github.io/uievents/.

• Focus Events: blur, focus, focusin, focusout
• Mouse Events: click, dblclick, mousedown, mouseenter, mousemove, mosueout, mouseover, mouseup
• Wheel Events: wheel
• Input Events: beforeinput, input
• Keyboard Events: keydown, keyup
• Composition Events: compositionstart, compositionupdate, compositionend

I am going to update Blink's implementation, however, what do you think about Composition Events? I am not 100% sure what should I do for Composiition Events. Should we exclude Composition Events from here?

[hayatoito]

@sorvell, I would like to hear opinions from Polymer folks too. Does the decision affect Polymer's implementation?

[hayatoito]

TouchEvents and PointerEvents are also candidates.

Given that, instead of enumerating every candidates,
can we just say: "Every UIEvents, except for load, unload, abort, error and select"?

Is that okay?

[annevk]

We really have to update the relevant specifications that dispatch UI events. And if you really want to create a monkey patch first, I think it's better to be exhaustive than to hope implementations will do the right thing.

[rniwa]

We should explicitly enumerate every event.

[hayatoito]

I agree that we should explicitly enumerate every event. Let me try to enumerate every event here before updating the relevant specifications.

[hayatoito]

Here is the exhaustive list. This should be a good starting point, hopefully.

I think it is important that we can know the rationale how we can make the list.
So here is how to reproduce the list.

1. Go to https://un5gnp8dyv5rcyxcrjjbfp0.julianrbryant.com/uievents/.
   Get every event types from Chapter 5, excluding events in Chapter 5.1
   -> We got:
      Focus Events:
        blur
        focus
        focusin
        focusout
      Mouse Events:
        click
        dblclick
        mousedown
        mouseenter
        mouseleave
        mousemove
        mouseout
        mouseover
        mouseup
      Wheel Events:
        wheel
      Input Events:
        beforeinput
        input
      Keyboard Events:
        keydown
        keyup
      Composition Events:
        compositionstart
        compositionupdate
        compositionend
2. Go to https://un5gnp8dyv5rcyxcrjjbfp0.julianrbryant.com/touch-events/
   -> We got:
      Touch Event:
        touchstart
        touchend
        touchmove
        touchcancel
3. Go to https://un5gnp8dyv5rcyxcrjjbfp0.julianrbryant.com/pointerevents/
   -> We got:
      Pointer Events:
        pointerover
        pointerenter
        pointerdown
        pointermove
        pointerup
        pointercancel
        pointerout
        pointerleave
        gotpointercapture
        lostpointercapture

[hayatoito]

Yeah, I think per interface basis might work well here because I could not find any exceptional case.

However, I do not agree the rationale you mentioned :)
For synthetic events, we should always honor the EventInit dictionary.
I meant:

let e = new FocusEvent('focus');
console.assert(e.composed == false);

let e = new FocusEvent('focus', { composed: false });
console.assert(e.composed == false);

let e = new FocusEvent('focus', { composed: true });
console.assert(e.composed == true);  <== true only if it is specified in EventInit dictionaly

[domenic]

It's worth checking to see if https://html.spec.whatwg.org/multipage/indices.html#events-2 has any events you'll want to include. My guess is that most of them that could be considered "UI events" are already in those other specs but some might be missing. E.g. I think change or copy or cut or paste might be worth considering.

[annevk]

Drag-and-drop too probably. Drag-and-drop and cut/copy could be tricky with the user leaking nodes from shadow trees. Maybe that's okay...

[rniwa]

However, I do not agree the rationale you mentioned :)
For synthetic events, we should always honor the EventInit dictionary.

I agree in the case author specified a value but we should just change the default value for EventInit for those special constructors when the value is missing.

[hayatoito]

I agree in the case author specified a value but we should just change the default value for EventInit for those special constructors when the value is missing.

Can we do that? I am afraid that it is confusing if EventInit's default value depends on Event's interface.

dictionary EventInit {
  boolean bubbles = false;
  boolean cancelable = false;
  boolean composed = false;
};

I prefer not changing the default value, per Event interface.
Rather, I would like to think as if UA set it to true explicitly, like the following:

// This is *imaginary* code, which is happening in browser's engine for UA events.
let e = new FocusEvent('xxx', { composed: true });

Thus, I would like users to specify it explicitly as UA does.

[hayatoito]

It looks that DragEvent inherits MouseEvent. Thus, this can be automatic if we use per-interface basis.

[hayatoito]

cut/copy/paste are defined in https://w3c.github.io/clipboard-apis/

Its interface is

interface ClipboardEvent : Event

I have taken a look at the spec, however, I do not have any preference whether to add ClipBoardEvent or not. I guess there are different opinions on ClipboardEvent.

It might be good to exclude it as a starting point. If web developers find that it is inconvenient, we can add it without a significant risk, I think.