DIV focus event details

Add the tabindex = '-1' attribute;

Default: Focus event not obtained (blur)

 

1	<div class="wl-product" id="wl-product"></div>

Get focus events (blur)

 

1	<div class="wl-product" id="wl-product" tabindex='-1'></div>

Details:

First look: W3C onfocus Section

The onfocus event occurs when an element has es focus either by the pointing device or by tabbing navigation.
This attribute may be used with the following elements: A, AREA, LABEL, INPUT, SELECT, TEXTAREA, and BUTTON.

Next Look: The Tabbing navigation Section

Those elements that do not support the tabindex attribute or support it and assign it a value of "0" are navigated next. These elements are navigated in the order they appear in the character stream.

The following are from the Internet:

[Focus and tabIndex]

 

In the KeyBind program, in addition to binding the object's keydown event, it is not enough. You can test the following code in ff:

<Div style = "width: 100px; height: 100px; background-color: # CCC;" onkeydown = "alert (1)"> </div>

In any case, the onkeydown event cannot be triggered (ie can be triggered), which is strange. It should be possible according to the general idea.
You can find the cause from the w3c section about KeyboardEvent:
Keyboard events are commonly directed at the element that has the focus.
That is to say, the keyboard button event generally points to the element that can get the focus, that is, the element that cannot get the focus cannot trigger the keyboard button event.

Does div not get the focus? Use the following code to test (ff ):

<Div id = "test" style = "width: 100px; height: 100px; background-color: # CCC;" onfocus = "alert (1)"> </div>
<Script> document. getElementById ("test"). focus (); </script>

The problem is how to enable the div to get the focus (of course, this is just coming out after a lot of turns ).

Finally, we found that setting tabIndex for the element will allow the element to get the focus. If you do not need to know more about it, you can skip it below.
First, let's look at the w3c onfocus section:
The onfocus event occurs when an element has es focus either by the pointing device or by tabbing navigation.
This attribute may be used with the following elements: A, AREA, LABEL, INPUT, SELECT, TEXTAREA, and BUTTON.
The onfocus event is triggered when the element gets the focus by specifying (click) or Tabbing navigation.
This attribute is used in the following elements (that is, the elements that can obtain the focus by default): A, AREA, LABEL, INPUT, SELECT, TEXTAREA, and BUTTON.
Test the following code:

<A href = "#" onfocus = "alert (1)" onkeydown = "alert (2)"> focus </a>

Both events can be executed.

Next, let's look at the Tabbing navigation Section:
Those elements that do not support the tabindex attribute or support it and assign it a value of "0" are navigated next. These elements are navigated in the order they appear in the character stream.
I don't quite understand it here. The key point is to set tabindex to 0 for the element to be navigated (focus can be obtained ).
Test the following code (ff ):

<Div tabindex = "0" style = "width: 100px; height: 100px; background-color: # CCC;" onfocus = "alert (1) "onkeydown =" alert (2) "> </div>

Both events can be triggered.

However, w3c is very vague, but it is clear on msdn:
An element can have focus if the tabIndex property is set to any valid negative or positive integer.
Elements that receive focus can fire the onblur and onfocus events as of Internet Explorer 4.0, and the onkeydown, onkeypress, and onkeyup events as of Internet Explorer 5.
As long as the tabIndex attribute of an element is set to any valid integer, the element gets the focus. After the element gets the focus, it can trigger the onblur, onfocus, onkeydown, onkeypress, and onkeyup events.

Different tabIndex values in tab order (Tabbing navigation:
Objects with a positive tabIndex are selected in increasing iIndex order and in source order to resolve duplicates.
Objects with an tabIndex of zero are selected in source order.
Objects with a negative tabIndex are omitted from the tabbing order.
The tabIndex value is a positive number. objects are selected based on the ascending order of values and the positional order in the code.
Objects whose tabIndex value is 0 are selected according to the order of their positions in the code.
Objects whose tabIndex value is negative will be ignored.

I don't know whether it meets the standards, but it seems that ff is the same as ie (different parts will be mentioned later ).
Set a negative tabIndex value.

Ps: if you are interested in ff's tabindex, we recommend you check Test cases for tabindex bugs in Firefox for more detailed and professional analysis.

If ie passes the first test, does it mean it is not necessary? Let's test another element:

<Ul style = "width: 100px; height: 100px; background-color: # CCC;" onfocus = "alert (1)" onkeydown = "alert (2) "> </ul>

If it is changed to ul, the event cannot be triggered again. How can this problem be solved.

Let's take a look at the msdn section:
The following elements can have focus by default but are not tab stops... applet, div, frameSet, span, table, td.
The following elements can obtain the focus by default, but cannot tab navigation: applet, div, frameSet, span, table, td.
It seems that Internet Explorer is really "for programmers", but other elements should not be missed. You should set tabIndex for all of them.

Finally, return to the program. First, set tabIndex:

O. tabIndex =-1;

After the ff element gets the focus, a dotted box will appear, which will look better:

IsIE | (o. style. outline = "none ");

Ps: If tabIndex is set to 0 or above, ie will also display a dotted box.

After keydown is bound, click the container (obtain the focus) And you can use the direction key to control the direction. However, if you click the slider (when the focus is not obtained), the event cannot be triggered.
Because the Mouse capture of ie in the slider dragging effect and the default action of ff are removed, the container cannot obtain the focus. Can this be set manually?
Yes. ff directly executes the focus Method of the container in the mousedown event of the slider to get the focus.
Ie is also acceptable, but when the object executes the focus Method in ie, if some of the object is outside the scroll bar, it will automatically scroll to the appropriate position (fortunately, it won't click like this ).
To reduce the impact, the slider is also bound to the keyboard control. When you click the slider, you only need to execute the Slider's focus method to get the focus:

Var oFocus = isIE? (This. KeyBind (this. Bar), this. Bar): this. Container;
AddEventHandler (this. Bar, "mousedown", function () {oFocus. focus ();});

Ps: the focus is not bubble (w3c standard), so you don't have to worry about the focus of the slider, causing the container to get the focus.
Ps2: w3c documents are really hard to read, but msdn is easy to understand.