Small tips: JS processing of element focus page not scrolling or positioning

1. The origin of the problem

Sometimes we hope that the page will not scroll when the element is focused. For example, we click a button to open a pop-up box. At this time, click the close button in the pop-up box to hide the pop-up box. We hope that the keyboard focus will return to the previous button. The following JavaScript code will be executed:

button.focus();

But sometimes it will bring another more serious experience problem, that is, if our page scrolls after the pop-up is displayed, the originally clicked button ran out of the screen display area. At this time, the button will be triggered when the button is focused again. The button element scrollIntoView is repositioned, and the browser scrolls, showing a sudden jump, and the experience is very bad.

Our expected goal is: the button focus, and then no matter whether the button is in the screen display area, the browser's scroll repositioning will not be found.

How to achieve it?

2. The new API parameter preventScroll

If you want to focus without scrolling, it is actually very simple, just use a new API parameter preventScroll, for example:

button.focus({ 
    preventScroll: true 
});

preventScrollIs an optional parameter, the default value is false, which means that focus scrolling is not prevented. If the preventScrollparameter value is yes, trueit means only focus and not scroll.

Let's take a look at an example, you can click here hard: JS focus preventScroll parameter use demo

The demo page has two buttons, one button is clicked to focus directly, and the other is set {preventScroll:true}.

The final result is shown in the following GIF recording screen:

The effect of focus and scrolling not positioning

compatibility

preventScrollThe parameter compatibility is as follows:


64+ ✔	68+ ✔	✘	✘	51+ ✔	❓

There is no Safari browser on hand, so the compatibility is unknown. Feedback is welcome.

3. Processing under IE browser

Internet Explorer does not support this awesome API. What if we want this browser to support it?

Method 1: Give up IE/Edge

IE/Egde even gave up and went to Chrome. What reason do we have to support him!

Method two: polyfill

Here is a person who wrote a focus polyfill: https://github.com/calvellido/focus-options-polyfill

However, according to my field use under IE browser, there are pits and the effect is very strange. Therefore, the above polyfill is not recommended.

Method 3: Temporary Patch

Take the vertical scroll distance, we can deal with JS like this:

var y = window.pageYOffset; 
button.focus({ 
    preventScroll: true 
}); 
// IE browser processing 
if (window.pageYOffset != y) { 
    setTimeout(function () { 
        document.documentElement.scrollTop = y; 
    } , 0) 
}

But this method is not perfect, there is a certain probability that the page will shake.

The way I deal with the actual project is method one, Ignore the IE browser directly, even if the project is compatible with IE browser, after all, it is an experience enhancement thing. The bad experience that users using IE browser can tolerate is greater than we expected Many, because IE browser itself is a product with bad experience.

Fourth, the essay should also conclude

focus()The method API is written as HTMLElement.focus() in the document, which means that all HTML elements have a focus method, because although ordinary elements cannot be focused by default, if we set appropriate tabindexattribute values, the situation will change , Can be focused, more in-depth and interesting knowledge can be found in this article: " HTML tabindex attribute and web page keyboard accessibility ".

Therefore, we will not report an error if we use it directly below:

document.body.focus();
document.createElement('div').focus();

But if it is other methods, for example, an submiterror will be reported:

// An error will occur, 
document.body.submit() is not supported ; 
document.createElement('div').submit();

Submit error prompt

Okay, just say that. It took half an hour to write more than originally expected.