scoped and relatedTargetScoped attributes are useless in Event, so remove then from Event interface

[smaug----]

They are useful for calculating event path, but I can't see any use case for them in JS.

[TakayoshiKochi]

One reason that scoped and relatedTargetScoped exist is to expose the internal property to event consumers.

If it is writable, maybe another use case is that when you create and dispatch your own event (e.g. "myXYZgesture" event), you can specify the behavior by setting these flags (though they are marked "readonly" now).

[hayatoito]

@SmauG Do you mean scoped and relatedTargetScoped should exist in only EventInit dictionary, right? If so, I tend to agree that we should remove these from Event interface.

@annevk , @rniwa WDYT?

[annevk]

I don't know. I initially thought these would be arguments to the dispatch algorithm, but perhaps it makes sense to have them be members of event instead. If they are members of events, we should probably also expose them (so a tree can see whether the event has leaked the tree or not).

[smaug----]

What is the use case for the flags? I mean real world use case.
In XBL world we haven't had anything like them and no one has ever asked such to be added.
In Gecko we have similar-ish flags in C++, but those haven't ever been exposed to JS.
(and in fact in Gecko the flags are more about content<->chrome and preventing content to see some events, yet let chrome to see them, not about scoping events withing content.)

I'm not strongly against them, mostly just wondering whether we're adding something no one will ever use.

[hayatoito]

Yeah, AFAIK, we have never heard any real use case.
I think the most safest approach is not to expose these properties via Event interface.

[annevk]

@smaug---- I think the idea behind these flags is to explain the behavior of certain events. The alternative is special casing certain event names, but that seems horrendous (the specification suggests it's using this pattern, but that's meant to be updated by setting these flags where necessary instead). And if there's a need for the platform to dispatch events that are scoped in some way, is it not reasonable for developers to have the same need?

[smaug----]

"explain" the platform tends to be a buzz word ;)

But ok, I think there is a use case for these. It is when dealing with nested shadow DOMs.
The inner one may want to dispatch for example a load event to its host and mark that event scoped, so that it doesn't propagate to the light DOM (or shadow DOMs higher up in the hierarchy)

Closing. Sorry about the noise.

[hayatoito]

I am okay to close this issue.

Just for clarification, even if we remove scoped and relatedTargetScoped properties from Event interface, developers still can dispatch an event that is scoped unless we remove these from EventInit dictionary. I thought this was the original proposed change here.

One more thing:
Since these properties in Event interface are readonly, developers can not change the behavior dynamically while the event is being dispatched.

[annevk]

I think we should keep the properties and we should indeed not let them be changed dynamically (due to capturing existing that would not make much sense, since if you wanted to prevent leaks during dispatch it would already be too late).

Thanks everyone for going through this one more time. I'll try to incorporate these into the DOM Standard soonish.

[rniwa]

Yeah, both of these properties on Event interface are implemented as readonly attribute boolean in WebKit.