Starting from the browser's focus blur

Focus events play a vital role in improving user experience. However, using focus events often brings us some troubles...

 

Let's talk about an alternative solution to solve the problem of a pop-up menu with focus.

In the past, we had the following solutions to disable the pop-up menu.

 

1. When the mouse leaves the current Div, the menu is hidden or setTimeout hidden. If the mouse returns to the menu in time, the setTimeout timer is cleared.

 

2. register the document. onclick event and disable the Click Event bubbling of the Div. You can also determine whether the event source is a subnode of the Div or Div.

 

3. When the menu div is displayed, insert a mask layer before the DIV to overwrite the client area of the entire browser. Register The onclick hidden Div of the mask layer.

 

These methods have their own advantages and disadvantages. solution 1: poor user experience. solution 2: Once an element disables Click Event bubbling, it will become invalid. solution 3 obviously, the user experience is slightly faulty. That is, the mask layer blocks all events of other elements, which is sometimes intolerable..

 

So here we propose solution 4 to get it through Div. onblur... but some problems also come along...

First, because Div does not support the focus (non-ie) status by default, we cannot talk about blur. (Although ie supports it by default, blur is still not supported by default)

 

An interesting method is to set tabindex to a natural value for div (of course, it should not exceed math. max seems to be the same as the maximum value of Z-index .. not tested... so that all mainstream browsers can have the focus and blur capabilities. in this way, we can give the div. onblur = function () {This. style. display = 'none';} is OK!

But things are far from complete... one problem is that once Div supports focus, after obtaining focus. in addition to opera, other mainstream browsers will see outline Firefox and IE. dotted line safari Chrome is their special luminous effect of blue or yellow outline... this is obviously intolerable... fortunately, except for IE6 and IE7 and even IE8, we can use Div {outline: none;} to solve the problem.

How can we solve IE6 and IE7? The answer is a unique attribute of IE --- hidefocus = "true", that is, we only need divelement. hidefocus = true; done...

 

Next is the fatal weakness of this solution. when you press the tab key, the DIV may get the focus. (especially for non-ie browsers, even if the element. style. display = 'none' can also maintain focus .)

Or the loss of focus is obviously not expected to be seen ....

The solution is to register the keydown for the document... (the reason why opera wants to register keypress is that opera's keydown is not a persistent event. it is different from other browsers .) then use the current document. activeelement (WebKit engine does not seem to support... therefore, we have to register onfocus for the first element with tabindex for the DIV and use a variable to save its focus state. Or we can consider that all browsers should do this without using document. activeelement) Determine whether the next element is our Div. Then, let the next element of the DIV with tabindex get the focus.

Although it looks good, we may eventually need to traverse the tabindex values that all form elements on the current page will be able to exist. automatically determine whether the element with tabindex exists before the DIV and find it .. in this way, this scheme can be encapsulated as a control. I suggest divelement. tabindex = math. max; in this way, we no longer need to consider whether the form elements have tabindex values or whether they are all default 0 .. instead, you only need:

VaR Len, ELEM;

Document. Forms [0] & (LEN = Document. Forms [0]. Length)> 0 &&

(ELEM = Document. Forms [0] [len-1]). onfocus = function (e) {... maintain this element with focus variable = ture ;});

ELEM. onblur = function (e) {. variable for maintaining the focus of this element = false ;};

Then, don't forget to judge whether our divelement has a focus if keycode = 9. If so, disable the default browser behavior to make the tab fail to change the focus. Keep our focus.

 

At this point, it seems that we have solved the problem, but don't forget that some elements such as anchor can still get the focus through the tab key. Do we have to deal with all the anchro <A> labels? Obviously this is not good enough. another good idea is our divelement. style. display = 'block... then we set its tabindex to delete this attribute when 'none. this is the best way, isn't it?

 

Various solutions have their own shortcomings. Maybe you will find the most suitable solution for your needs. Or find a more perfect solution... OK.

 

This is a typical example of how to solve the problem with focus blur... for now, let's talk about it next time.

 

Next, let's talk about the optimization of the focus blur. This solution was mentioned by my friends wait. I think it is very valuable to come up with it.

If I have dozens of textbox in my current page form, I want to listen to them onfocus and onblur... and then do some things.

At this time, we just don't need to register these dozens of documents, but just register them with the document... but the problem is that focus and blur are both non-bubble events. unable to upload to document...

The non-ie solution is document. the third parameter of addeventlistener is true. that is, the capture mode is switched instead of the bubble mode .. that is, let the event stream back to the event source from the document... in this way, we can monitor the focus event by registering the onfocus event on the document...

But IE does not support the capture mode... however, ie supports two special events, focusin focusout, which correspond to focus and blur, but they support bubbling .... all that's left here is

The function can determine whether the event source is what we expect and write the corresponding logic. Is it good?

 

Finally, an interesting phenomenon in most browsers is element. onblur () {here is not allowed to make yourself this. focus ....} the reason is that when an event causes other nodes to obtain the focus, the element will occur before that. then, otherelement occurs. focus so in element. setting focus () When blur occurs does not prevent events that cause otherelement to get focus... then he will still put the focus room on the otherelement at the end .... solution: setTimeout... delay processing...

 

The focus event is also very meaningful for the window object... for example, when we need the draganddrop function, when drag is used, we switch the window to anotherProgramRelease the mouse key and return to the webpage .. you will find that the previous mouseup is not captured, and then you will find that the dragged layer keeps running with the mouse... the solution is window. onblur = function () {obj. drop ();}

 

Then... sometimes we don't want an annoying outline border next to the anchor element in IE to be attacked .... if you know why this border appears, it is also because <A> you must know how to solve this problem if you get the focus .... you will also understand why some sites use a {outline: none; Star: expression (this. onfocus = This. blur ();} to solve this problem? In fact, it is forced anchor to get the focus immediately after blur...