- From: <bugzilla@jessica.w3.org>
- Date: Sun, 21 Dec 2014 00:57:03 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20713 --- Comment #9 from Philip Jägenstedt <philipj@opera.com> --- (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()" -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Sunday, 21 December 2014 00:57:12 UTC