Propose the new navbeforefocus UIEvent

[anawhj]

CSS Spatial Navigation specification has been developed in CSS WG. One of the proposed APIs is NavigationEvent as a new interface with two event types(navbeforefocus, navnotarget). https://drafts.csswg.org/css-nav-1/#events-navigationevent

Under reviews on how to implement them, I just wondered why focusin/focusout hadn't been defined as a cancellable. I found a related discussion on it at #88, but I couldn't see the reason at the thread.

Could someone explain the background or reason? Any question or concern on the proposed navbeforefocus event is welcomed as well. @dtapuska, @smaug----, @markelog

[smaug----]

focusin/focusout behave the way they behave just because how they got implemented at some point in one browser engine and then others had to follow that. They aren't particularly useful events atm. They would have been, had they been implemented the way the spec defined them at least at some point (the idea was that they'd be cancellable etc.) . I could be wrong, but I think no spec defines how focusin/out actually work, but there is some rough consensus between implementations (but there are differences too).

[anawhj]

I've noticed many requirements on the cancellable focusin/focusout events from JS developers, but it hasn't been supported yet. I guess there are some reasons in terms of browser engine implementation. I would like to propose a couple of expected issues on it as follows:

1. How to do rollback once focusin event is canceled. (preventDefault) Assume that authors can specify event.preventDefault inside a B.focusin event handler and it works. (A: current focus target, B: next focus target) In that case, browser engines might need to handle some rollback logics for what's already executed such as A.focusout for styling or JS execution. The reason is that the focus-related events works as a synchronized order as follows.

Event order: A.keydown -> A.blur -> A.focusout -> B.focus -> B.focusin -> B.keyup (Chrome v78) Event order: A.keydown -> A.focusout -> B.focusin -> A.blur -> B.focus -> B.keyup (UI Events spec) Reference: https://www.w3.org/TR/uievents/#events-focusevent-event-order Test page: https://codepen.io/anawhj/pen/pooPOZz

2. What's the difference between preventDefault in B.focusin and focus() in A.focusout Assume that authors want to override the next focus target when she presses a tab key. It can be supported by the cancellable B.focusin event handler, but also supported by the non-cancellable A.focusout event handler. I wonder some use case that needs the cancellable B.focusin. You could see an example code at the following link.

https://codepen.io/anawhj/pen/jOOmveg

Could someone explain any opinion on them above or provide a real use case that needs the cancellable focusin/focusout? For example, if we specify event.preventDefault() in A.focusout and B.focusin handler, what should it happen?

[smaug----]

I highly doubt we can change focusin/out implementations too much. They have been shipping for years now. IE used to have reasonable focusin/out behavior, but Edge (had to?) did switch to a model following what was shipping in Chrome/Safari, or at least quite similar model. And Firefox also had to follow what was shipping in Chrome. Unfortunately we might need to introduce new events with proper semantics. @NavidZ may have an opinion.

[anawhj]

I highly doubt we can change focusin/out implementations too much. They have been shipping for years now.

I agree on that. I thought the current focusin/out events seem to have coverage in which most of the requirements of the new proposed event (navbeforefocus) are supported except for the cancellable option.

I just wonder the common use cases on the cancellable focusin/out events from JS developers point of views. (@dmethvin, @timmywil)