This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
+++ This bug was initially created as a clone of Bug #25877 +++ Presumably, focusin fires immediately before focus in the algorithm, and focusout fires immediately before blur in the algorithm (neither are cancelable).
Apparently Chrome/IE support these, and Firefox is considering implementing it: https://bugzilla.mozilla.org/show_bug.cgi?id=687787 If we could get away with removing this from Chrome, it seems like that would be a win. It's not clear what focusin/focusout add that focus/blur don't.
Pinged Chrome devs about maybe dropping this: https://code.google.com/p/chromium/issues/detail?id=378163
Travis, is there a compat need for these?
(In reply to Ian 'Hixie' Hickson from comment #3) > Travis, is there a compat need for these? I had data years ago (when I asked to have them added to DOM L3 Events in 2009 [1]), but don't have recent data. I can see about gathering that for you though... :) [1] https://dvcs.w3.org/hg/dom3events/rev/6d85eb1847a4
Do you recall what your 2009 data said?
No, but I just re-tested on 2014 data. In a relatively small sample size of "top sites" in world-wide geographic areas I found the following data for focusin and focusout usage (e.g., registration of these events): focusin usage: 117,588 / 569,726 (20.6%) focusout usage: 117,430 / 569,726 (20.6%) jQuery looks to be one of the major contributing factors... In the jQuery 1.11.1 uncompressed file, the following is quite telling: (function() { var i, eventName, div = document.createElement( "div" ); // Support: IE<9 (lack submit/change bubble), Firefox 23+ (lack focusin event) for ( i in { submit: true, change: true, focusin: true }) { eventName = "on" + i; [...]
So if we remove support, jQuery would keep working?
This is pending UseCounter data from Chrome. However, I'm not sure that data is going to be that useful. We know the events are used. The question is would pages break if the support was removed, given that many pages fall back to focus/blur.
foolip: You're king of the feature removal, any interest in removing these redundant focus events? If I can't convince you, then I should just add them to the spec.
The use counter for focusin/focusout reached stable a few weeks ago: http://www.chromestatus.com/metrics/feature/timeline/popularity/433 At 3-4%, removal does not seem feasible. There's also a use counter for DOMFocusIn/DOMFocusOut: http://www.chromestatus.com/metrics/feature/timeline/popularity/211 That's currently around 0.2%, and if nobody else implements it and most content listens to both just to be safe, eventual removal seems possible.
I doubt this is a "good first bug", given that focusout/in may change focus or remove to-be-focused element from DOM and whatnot.
FWIW, looks like focusin/out have been implemented in Blink (at least) totally differently to what the spec says (and what IE does), so we may need to change the spec :/
This is now tracked by https://github.com/whatwg/html/issues/3514.