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://w3c.github.io/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://w3c.github.io/touch-events/
   -> We got:
      Touch Event:
        touchstart
        touchend
        touchmove
        touchcancel
3. Go to https://w3c.github.io/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.

[hayatoito]

In summary, so far:

Inheritance hierarchy:

• UIEvent
  • FocusEvent
  • MouseEvent
    • WheelEvent
    • PointerEvent
    • DragEvent
  • InputEvent
  • KeyboardEvent
  • CompositionEvent
  • TouchEvent

If we use per-interface basss, FocusEvent, MouseEvent, InputEvent, KeyboardEvent, CompositionEvent, and TouchEvent are the candidates.

[rniwa]

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.

The thing is, FocusEvent doesn't take EventInit. It takes FocusEventInit, which inherits from UIEventInit, which in turn inherits from EventInit. In the case of MouseEvent and its derived classes, MouseEventInit doesn't even inherit from EventInit (this is presumably a spec bug though). In general, there should be a minimal difference between UA created events and author created events.

If we're not going to the route of initializing based on the interface, then we absolutely need to enumerate every single event for which composed flag must be set to true by UA instead of vaguely relying on the interface being used.

[hayatoito]

If possible, I would like to adopt per-interface basis for synthetic events too, but my conern is its feasibility.

Suppose the following cases:

 let e1 = new FocusEvent('xxx');
 let e2 = new FocusEvent('xxx', { bubbles: true });
 let e3 = new FocusEvent('xxx', { bubbles: true , composed: true });
 let e4 = new FocusEvent('xxx', { bubbles: true , composed: false});

If we adopt "default changes per-interface" for synthetic events too, I think user's expectations are:

 assert(e1.composed === true);
 assert(e2.composed === true);
 assert(e3.composed === true);
 assert(e4.composed === false);

However, since FocusEventInit inherits EventInit, we can not distinguish case e2 and e4 nicely in our binding layer. In both cases, FocusEventInit.composed was already set to false. We can not tell the difference.

[rniwa]

I don't understand how that works. You're invoking a different constructor. Surely you ought be able to distinguish that FocusEvent rather than Event constructor is invoked. Then, in each constructor, you can specify the appropriate default value for composed when it's missing in the dictionary specified by the author.

[hayatoito]

I have found that Blink's Web IDL binding generates the following for EventInit:

https://cs.chromium.org/chromium/src/out/Debug/gen/blink/core/events/EventInit.h

Nullable<bool> m_composed;

It is not bool. It is Nullable<bool>! I did not realize it. It looks that we can distinguish e2 (missing (m_composed == null , hopefully) and e4 (m_composed == false).

However, does WebIDL guarantee this third state? Do every user agents can tell whether the value is missing, false or true, strictly?

[domenic]

I don't have a very strong opinion here but I wanted to say that the direction this discussion is going seems rather strange to me. My mental model is that the composedness of an event is similar to whether it bubbles or is cancelable. That is, it is a property of an individual firing of the event. Saying that there should be a per-interface default for composedness seems very strange to me given that there is no similar concept for bubbles or cancelable.

As far as I can tell every input event fired by the platform bubbles. But we don't say that InputEvent should have a default of bubbles: true. We don't say that new InputEvent("input", {}) should be equivalent to new InputEvent("input", { bubbles: true }). Instead we explicitly specify the value of the bubbles flag at all places in the platform that fire input events.

I can see some value in providing non-normative guidance that in general events which use the InputEvent interface when fired by the platform will bubble, not be cancelable, and be composed. Maybe there could be a table listing this matrix for all event types and/or interfaces. But I don't think that should be part of the definition of InputEvent or InputEventInit, and should not affect the developer-facing defaults, which IMO should be the same for all events.

Yes, it will be a lot of work to update all the places that fire events to correctly set composed. But it is doable, and would be consistent with how the platform already works for other flags on events. I don't think we should try to take a shortcut here.

[hayatoito]

Yeah, regarding UA events, I think "per-interface basis" is just a syntax sugar which is only valid in this discussion.
In updating the relevant specs, we should update each place where an event is fired.

Enumerating interfaces here should be just a guide which tells us where we should update.

[rniwa]

@domenic : That's a fair point. Let's go with explicitly enumerating every single that UA fires as composed=true then.

[hayatoito]

Thank you, folks. I think the conclusion is:

1. For each relevant spec:
   1. For each place where an event is fired:
      1. If the event's interface is (or inherits) one of the enumerated interfaces here:
         1. Set composed=true

In terms of implementation, I think this conclusion is implementor-friendly because we do not have to update many places in our engine.

[hayatoito]

I have filed an issue for UIEvents specification: w3c/uievents#89

[hayatoito]

I think we have to reflect our conclusions to the following specifications. I have filed issues:

• For UIEvents: Support Event.composed w3c/uievents#89
• For PointerEvent: Support Event.composed in Pointer Events w3c/pointerevents#91
• For TouchEvent: Support Event.composed in Touch Events w3c/touch-events#66

[hayatoito]

Thank you for the feedback.
In such a user interaction, a composed event is always fired, isn't it? e.g. "mouseover" or "click" event.
Is it difficult for component consumers to do the right thing at the right timing only by listening these composed events?

[ebidel]

Sure, you could listen for something like "click", but I'm not sure how you'd accurately know when the animation/transition is done. Plus, the last thing you'd want is user code (potentially) running during your animation.

A couple of more useful examples from the Google I/O 2016 PWA (we waited for several components to fire a transitionend event for internal animations, to delay work and make sure animations were smooth).

• a photo gallery - manages a11y behavior when a new photo is transitioned to.
• <countdown-timer> that fades itself out when the time is up. User code hooks into the transition and sets state when it's finally invisible.

[domenic]

It seems really bad to be reusing animation events for those kind of domain specific "done sliding" things. I would expect you would fire control-specific events like "toggle" or "open" or "close".

Otherwise you are tying your consumers to the implementation detail of your component, which is that it currently animates. What happens when in v2 you implement a "low power mode" that stops doing animations when the battery level is low? Or in v13 when the industry has moved away from animations as a method of signifying transitions (like Apple has largely done from OS X 10.0 to the current macOS versions)?

Transition/animation events definitely feel like the kind of internal-to-a-control, implementation-choice-specific, presentation-related events that should not go outside the shadow tree by default.

[hayatoito]

@ebidel Thanks.

Could components authors catch these animation events in their shadow tree, and fire a component specific custom event for component consumers?

As the example does it, "on-countdown-complete", in https://github.com/GoogleChrome/ioweb2016/blob/41bdeb6ad3a41fe675f2b49dfa343121f720c135/app/elements/io-live.html#L270

Does it make an interface between component authors and component users more stable one?

[ebidel]

This was my earlier point:

The component could fire a custom event, but that requires more boilerplate for its author (has to add listeners, catch it, forward a different name, and do cleanup work in detached). It's more natural to use the animation events already being fired.

IMO, that's all more complicated than it needs to be.

What happens when in v2...

Events are part of a component's public API. I'd expect well authored components to clearly document changes. Real example: https://elements.polymer-project.org/elements/paper-button#events

[domenic]

Right. I think the concern is exactly about making it easy to accidentally expose implementation details as part of a component's public API. Doing so should be intentional.

[hayatoito]

Thank you for the feedback.

For compatibility issues, a naive way of not breaking public API might be "catch an animation event in the shadow tree, and fire a new synthetic (the same kind of) animation event for the host". I am aware that this is all more complicated that it needs to be. :(

Could it be an acceptable work around???

I am not sure what is the best solution to address this issue. I would like to hear opinions from other browser vendors.

[rniwa]

This was my earlier point:

The component could fire a custom event, but that requires more boilerplate for its author (has to add listeners, catch it, forward a different name, and do cleanup work in detached). It's more natural to use the animation events already being fired.

IMO, that's all more complicated than it needs to be.

I could imagine adding some sort of a hook in v2 to make this easier. That is, add some API to specify whether a given event should propagate out of the current shadow tree.

But in general, the same argument could be used to make almost every event composed, and we don't want to do that at least for v1.

[annevk]

I agree with @rniwa. A v2 API where you can override some of this on the shadow root sounds interesting and might be worthwhile.

[jsilvermist]

The fullscreenchange event (and fullscreenerror) which is a part of the Fullscreen API and is currently implemented in most browsers behind a prefix is not being fired with composed, making the Fullscreen API much harder to use.

[annevk]

@jsilvermist you're looking for #614.

[jsilvermist]

@annevk Yes... Yes I was... Thanks!