So what about window.event?

("event" in window) is true in Chrome and in Opera too I believe. Adding event.srcElement without window.event seems risky.

SVG also contributes to this: https://bugzilla.mozilla.org/show_bug.cgi?id=854213

Chrome is going to investigate removing this: https://code.google.com/p/chromium/issues/detail?id=223749

The WindowEvent counter in Chrome was 7.641600241 :-( However, we still haven't added anything to Gecko...

Event.srcElement is around 20%:
https://www.chromestatus.com/metrics/feature/timeline/popularity/343

It's just an alias of target, so adding that seems like the only way to go.

Window.event is around 4% now:
https://www.chromestatus.com/metrics/feature/timeline/popularity/69

https://code.google.com/p/chromium/issues/detail?id=223749#c3 says that "Inline event handlers have a local `event` binding in scope." but I'm not sure if that's how it works in Blink. However it works, stuff like onclick="event.target.style.color='red'" has to work.

(In reply to Philip Jägenstedt from comment #6)
> Event.srcElement is around 20%:
> https://www.chromestatus.com/metrics/feature/timeline/popularity/343
> 
> It's just an alias of target, so adding that seems like the only way to go.

This seems very similar to the isSameNode() situation as Mozilla never added it. If Mozilla wants to add this, we should probably define it, along with window.event as I believe they cannot be decoupled.


> Window.event is around 4% now:
> https://www.chromestatus.com/metrics/feature/timeline/popularity/69
> 
> https://code.google.com/p/chromium/issues/detail?id=223749#c3 says that
> "Inline event handlers have a local `event` binding in scope." but I'm not
> sure if that's how it works in Blink. However it works, stuff like
> onclick="event.target.style.color='red'" has to work.

event.target can work by putting that in the local scope, you don't need a global property for that to work per se.

(In reply to Anne from comment #7)
> (In reply to Philip Jägenstedt from comment #6)
> > Event.srcElement is around 20%:
> > https://www.chromestatus.com/metrics/feature/timeline/popularity/343
> > 
> > It's just an alias of target, so adding that seems like the only way to go.
> 
> This seems very similar to the isSameNode() situation as Mozilla never added
> it. If Mozilla wants to add this, we should probably define it, along with
> window.event as I believe they cannot be decoupled.

I haven't heard recently anyone asking us to add  window.event or Event.srcElement.
I'd expect adding window.event to actually break things (when using Gecko), since at least at some point there were pages doing 
if (window.event) {
  // some more IE-style stuff
}
Not sure how blink copes with that.

(In reply to Anne from comment #7)
> (In reply to Philip Jägenstedt from comment #6)
> > Event.srcElement is around 20%:
> > https://www.chromestatus.com/metrics/feature/timeline/popularity/343
> > 
> > It's just an alias of target, so adding that seems like the only way to go.
> 
> This seems very similar to the isSameNode() situation as Mozilla never added
> it. If Mozilla wants to add this, we should probably define it, along with
> window.event as I believe they cannot be decoupled.

What's the connection between Window.event and Event.srcElement other than being IE-isms?

> > Window.event is around 4% now:
> > https://www.chromestatus.com/metrics/feature/timeline/popularity/69
> > 
> > https://code.google.com/p/chromium/issues/detail?id=223749#c3 says that
> > "Inline event handlers have a local `event` binding in scope." but I'm not
> > sure if that's how it works in Blink. However it works, stuff like
> > onclick="event.target.style.color='red'" has to work.
> 
> event.target can work by putting that in the local scope, you don't need a
> global property for that to work per se.

It looks like window.event is undefined in Blink/WebKit/IE when no event is firing, but 'event' in window is always true. What does it mean to put event in the local scope? Something like "arguments" in function calls?

I have no data to back this up, but it seems wise to ensure that this works:

function handle() {
  event.target.style.color = 'red';
}

onclick="handle()"

I think it means that if you lookup "event" that it's found on the environment record. So yes, that example should work. As for srcElement and window.event, I remember a conclusion that they were coupled based on some examination of code. Perhaps that changed...

(In reply to Philip Jägenstedt from comment #9)
> I have no data to back this up, but it seems wise to ensure that this works:

Why it would be wise?

> So yes, that example should work.

Why would it?  It doesn't work in Gecko, and we have no evidence that the web depends on it.

I share Olli's concern about adding window.event.  I expect it's common for people to pull in other nonstandard stuff that IE had and WebKit copied if that's defined.

I have some questions about the data here, though.

> Event.srcElement is around 20%:

How many of those are:

  var target = event.srcElement || event.target;

?

> Window.event is around 4% now:

Again, do we have any data on what the uses look like?

> This seems very similar to the isSameNode()

No, it's very different, because we know for a fact people use at least window.event for browser detection, so implementing it in Gecko carries huge compat risks which are not present with implementing isSameNode.

(In reply to Olli Pettay from comment #11)
> (In reply to Philip Jägenstedt from comment #9)
> > I have no data to back this up, but it seems wise to ensure that this works:
> 
> Why it would be wise?

It's a mutation of the code in comment #6 that seems almost certain to have happened. If others don't share that hunch, then we'd need actual data.

(In reply to Boris Zbarsky from comment #12)
> > So yes, that example should work.
> 
> Why would it?  It doesn't work in Gecko, and we have no evidence that the
> web depends on it.
> 
> I share Olli's concern about adding window.event.  I expect it's common for
> people to pull in other nonstandard stuff that IE had and WebKit copied if
> that's defined.

Which specific other IE-isms are you concerned about? We should either standardize or remove them, and if deemed necessary due to entanglement they could be done in a batch.

> I have some questions about the data here, though.
> 
> > Event.srcElement is around 20%:
> 
> How many of those are:
> 
>   var target = event.srcElement || event.target;
> 
> ?
>
> > Window.event is around 4% now:
> 
> Again, do we have any data on what the uses look like?

The use counter data can't answer either of these questions. My only idea for answering questions like these would be to check how often Event.srcElement but not Event.target is accessed in a script run (event handler, setTimeout, etc.) Even that wouldn't be conclusive, so I haven't tried to add the scaffolding to make it possible.

> It's a mutation of the code in comment #6 that seems almost certain to have
> happened.

It has, in the past, but it's common knowledge that this doesn't work in Firefox, so people are a bit more careful now.

> Which specific other IE-isms are you concerned about?

I've seen people assume all sorts of things if window.event over the years.  What they assume right now is something we'd need data on.

> We should either standardize or remove them

Sounds nice, depending on what they are.  Just watch out for the assumptions being ones we can't do either one with, like some of the irreconcilable differences in ES behavior (e.g. around handling of function declarations inside conditionals).

What's needed is data.  Assuming we want to go in this direction, of course.  It may actually be simpler to remove window.event from all UAs than to get sufficient data on what breaks if it's added and what other crud then has to become part of the web platform forever.

Note that we haven't even started the conversation about what behavior window.event should have, which is not at all obvious to me either.

Some things from the Blink bug:
https://code.google.com/p/chromium/issues/detail?id=223749

First, the use counter is over 3%:
https://www.chromestatus.com/metrics/feature/timeline/popularity/69

That cannot be an accurate estimate of the risk of removing window.event in Blink, so we need better data. Is the only case worth measuring when window.event is non-undefined while accessed from a non-inline event listener, like in this following?

x.addEventListener('click', function() {
  if (event.type == 'foo')
    bar();
});

Also, I learned that there's a difference between SVG and HTML:
https://code.google.com/p/chromium/issues/detail?id=223749#c10

Of the three end states mentioned there, does any seem more worth aiming for, or are there other, better, end states?

It's not clear to me what the constraints are on SVG (perhaps both "evt" and "event" can be exposed as variables in the event handler scope?), but I don't think it should have any bearing on whether or not to keep window.event.

It does add the risk things like onload="StartAnimation(event)" in SVG into the mix.

If we assume that nothing about inline event handlers will change, what kind of data do we need to move this along? To put it another way, what kind of breakage is most likely if Gecko adds window.event and if Blink removes window.event, respectively?

I'm still not sure about the connection between Window.event and Event.srcElement, see comment #9. It sounds like IE-sniffing on the form `'event' in window` or `window.event` (inside an event handler) are the main concerns.

I found the source of window.event in WebKit/Blink:
https://projects.kde.org/projects/kde/kdelibs/repository/revisions/f7067e7d6d17aeece5d8bf4b12b73ae8af7c8f9a

"""
Discussing with tobias, we found a nice and easy way to implement "window.event".
JSEventListener::handleEvent simply sets the event in the Window object,
and from there we use Peter's magic (getDOMEvent()).
This would fix #30780 if there wasn't a bug in the script itself :(
"""

The bug was https://bugs.kde.org/show_bug.cgi?id=30780 with reference to this site:
http://web.archive.org/web/20010813082633/http://azzuma.com/HTML/antinea.html

I don't know if the local binding for inline event listeners existed at the time.

All in all, this didn't reveal anything interesting about the compat situation.

Now discussing this here together with other Microsoft extensions: https://github.com/whatwg/dom/issues/334.