Decide which form events need to be scoped

[annevk]

@rniwa @hayatoito @smaug---- @inscriber @travisleithead

So far in #1135 I've marked "submit", "reset", and "invalid" as needing to be scoped. I tend to think we should scope "input" and "change" too, but @smaug---- suggested otherwise. What do other people think?

[smaug----]

Actually, maybe input and change should be scoped too, and if a shadow dom thingie wants to expose input and change to the outer world, it could itself dispatch non-scoped input and change events.

[annevk]

Yeah, I was thinking that might be more logical.

I think the main thing we don't want scoped by default is UI events, such as mouse input, keyboard input, focus(?). Cannot really imagine other kind of events that should escape.

[ojanvafai]

Why is the input event special?

[rniwa]

What would be the criteria of deciding which events will be scoped?

[smaug----]

I think the question is other way round, "which events dispatched in shadow DOM shouldn't be scoped?". In general it is stuff like mousemove.

Hmm, I wonder if the flag should have different name, like unscoped, and default to false.

[rniwa]

Yeah, I was gonna about to suggest that re: flip the question. It seems that we want most events to be scoped.

[ojanvafai]

Why is mousemove special?

I'm not agreeing or disagreeing. I'm just trying to get at what the principle underlying your intuition is.

[smaug----]

Because mousemove is user input to the page, not some shadow DOM internal thing being dispatched.
mousemove was just an example, also other user input should propagate (I think stuff like key/mouse/touch/pointer events, but of those not events like mouseover when moving mouse within shadow dom)

[annevk]

@smaug---- mouseover should be unscoped (if you come from the side of the viewport directly over a shadow tree), but due to relatedTarget it would end up being scoped most of the time.

But I think the principle is mostly that externally generated events are unscoped, whereas events part of some feature or API are scoped. Since feature/API events are much more common than external events, I tend to agree we should change the default here.

[rniwa]

Why don't we call the flag crossShadowBoundary or escapesShadow instead of unscoped if we're flipping the meaning to avoid double negations like !unscoped.

[annevk]

Good suggestion. If we go with flatPath we could even name this flatten too...

[rniwa]

flatten doesn't seem to match the semantics here though. How about piercing or pierces and piercingPath (for shadow piercing events)? That literally hits zero code on Github.

[annevk]

piercing and piercingPath seem fine. (composed and composedPath would be too.)

[smaug----]

piercing sounds odd to my non-native-English-speaker ears, also from semantic point of view. What are we piercing here? I'd prefer composed or something similar to that.

[annevk]

Piercing through the shadow tree root to the shadow host. I'm happy either way. @hayatoito?

[rniwa]

(Japan is having a week long holiday this week so we might need to wait until next Monday to get proper responses)

[hayatoito]

Given that:

1. A set of all kinds of UA events
2. A set of events which are listed in https://w3c.github.io/webcomponents/spec/shadow/#scoped-flag, (plus form events??)

We are assuming that |Set(2)| > |Set(1) - Set(2)|, right?
If so, for UA events, it might be reasonable to rename a flag, flipping its meaning, keeping the default value being false. I tend to agree. This change should not affect developers.

However, for synthetic events,

But I think the principle is mostly that externally generated events are unscoped,

We are assuming that developers would set true to the flag explicitly, mostly, right?
This might be a burden for developers, but I do not think this is a serious issue.

[annevk]

That entirely depends on how developers use events. If they use them in the same way that the platform does, than for them the common case should also be to not set that flag. But if usage as a communication mechanism from a component starts to dominate, they might very well mostly set that flag. Hard to say.

I also don't think libraries use synthetic events much, other than for testing events normally dispatched by the user agent.

[hayatoito]

Yeah, that's a good point. AFAIK, Polymer uses custom synthetic events as a communication mechanism between components. I guess that's unscoped in most cases.

Even if that's true, I do not oppose to flipping a flag. Setting true to the flag should not be a serious burden for developers.

Thus, the renaming problem is its naming?

• Event.crossShadowBoundary
• Event.escapesShadow
• Event.unscoped
• Event.piercing
• Event.piercingPath
• Event.composed
• Anything else?

Hmm. I am fan of neither of them. :) However, I can not think of better name, as of now...

[annevk]

The idea was that if we did composedPath() which we seem to have rough consensus on, to rename this to composed. I have a PR ready for the DOM Standard that makes this change.

[smaug----]

Not surprisingly I prefer 'composed'.

[a2sheppy]

I'm working on documenting this on MDN, and during the discussions there is a lot of confusion about the name Event.composed. It doesn't really mean anything obvious. Yeah, it's related to composedPath() but if you don't already know that, you're likely to assume it means something like "the event was automatically created" or who knows what.

A name more like Event.bubblePastShadowRoot would be more descriptive of what this property actually seems to do based on my reading of the spec and some code. FWIW.

// cc @annevk, @smaug----

[rniwa]

I think that ship has already sailed. Safari and Chrome have shipped Event.prototype.composed for a while now. I doubt we can remove it at this point.

[smaug----]

.composed has quite little to do with bubble, but plenty to do with propagation.
.composed will ship in FF52.

And to be consistent with composedPath, .composed makes sense to me.

[hayatoito]

Yeah, chrome has already shipped composed.
I guess we are not a big fan of the name of composed, but we could not think of any better name.