Re: [w3c/uievents] Should an element remain focused and receive key events if it's display:none-ed? (#236)

Firefox and [WebKit](https://trac.webkit.org/changeset/201471/webkit) don't fire `blur` event when the element is removed from the DOM either. For consistency, it's probably better if we didn't fire `blur` event in the case.

Also, firing `blur` event in this scenario poses a question as to when the event needs to be fired. We definitely don't want to expose the timing at which the style resolution had happened so that would mean the event needs to be dispatched when the [rendering is updated](https://html.spec.whatwg.org/multipage/webappapis.html#update-the-rendering).

I'm pretty sure Chrome sets up some kind of 0s timer to fire `blur` event in this case. But this approach is problematic in that it would mean we'd have to update the style immediately after running each task to detect that the focused element is no longer [rendered](https://html.spec.whatwg.org/multipage/rendering.html#being-rendered). Ideally, we want to delay such a style resolution up until the next [rendering opportunity](https://html.spec.whatwg.org/multipage/webappapis.html#rendering-opportunity) occurs.

```html
<!DOCTYPE html>
<html>
<body>
<pre id="log"></pre>
<script>

log = (text) => document.getElementById('log').textContent += text + '\n';

window.onload = () => {
    const input = document.createElement('input');
    document.body.appendChild(input);
    input.focus();
    input.addEventListener('blur', () => log('blur event fired'));
    input.style.display = 'none';
    setTimeout(() => {
        log('setTimeout fired');
    }, 0);
}

</script>
</body>
</html>
```

@rakina @tkent-google @domenic 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/uievents/issues/236#issuecomment-506549850

Received on Thursday, 27 June 2019 23:47:09 UTC