| 11:13 | <ato> | annevk: $("html").focus() makes document.activeElement <html> in Firefox, but <body> in Chrome. Is this expected? |
| 11:48 | <Ms2ger> | Well, no |
| 11:49 | <ato> | I guess this is technically something a user could make happen through interaction with the Tab key. |
| 11:49 | <ato> | But it’s more a concern for automation, e.g. WebDriver. |
| 12:09 | <annevk> | ato: dunno, https://html.spec.whatwg.org/#focusing-steps looks broken as it changes the focus target to the viewport, but then nothing seems to really account for that (and the way it becomes the viewport also uses the wrong language) |
| 14:08 | <Domenic> | There's a mapping from viewport to document element somewhere |
| 14:09 | <Domenic> | https://html.spec.whatwg.org/#dom-documentorshadowroot-activeelement I think viewport -> Document -> body element |
| 14:09 | <Domenic> | This is extremely indirect and I suggested in https://github.com/whatwg/html/issues/4607 that we try to collapse everything to document element or body element and get rid of the "viewport' business. |
| 14:09 | <Domenic> | Although zcorpan pointed out "How should this work for viewports where there is no <body> element (like SVG)?" |
| 14:27 | <zcorpan> | saying that it's the Document that has focus could work, but doesn't map so well to the API, since it's window.focus() not document.focus() |
| 14:31 | <Domenic> | IMO activeElement is the more important API to match than the before-the-dot component of .focus() |
| 14:31 | <Domenic> | So I would probably define something like "the topmost focusable element" which for HTML is body and for SVG is ??? |
| 14:32 | <zcorpan> | Domenic: #focusing-steps sometimes sets |new focus target| to a document, sometimes to a viewport. Is that a bug? (Haven't checked if the focus PR changes this) |
| 14:32 | <Domenic> | (maybe "default focused element" I dunno. "topmost" is probably not right given <html tabindex="0">) |
| 14:32 | <zcorpan> | Domenic: but <body> itself is not focusable unless you set tabindex |
| 14:33 | <Domenic> | zcorpan: yeah so "default focused element" seems better then |
| 14:38 | <ato> | annevk: Thanks. I’ll file an issue later today. |
| 14:40 | <annevk> | Domenic: activeElement is 1:1 with :focus I hope? |
| 14:40 | <Domenic> | I hope so too! But now I'm wondering about body :/ |
| 14:42 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/7303 is different between chrome and firefox |
| 14:43 | <zcorpan> | <body> doesn't match :focus when the viewport/document/BC has focus |
| 14:48 | <zcorpan> | Domenic: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/7306 for svg |
| 15:36 | <Domenic> | Well, lovely. So is activeElement or :focus the source of truth as to whether something's focused, I wonder. |
| 15:36 | <Domenic> | (I mean, we kind of get to decide ourselves, since it's spec internal.) |
| 15:37 | <Domenic> | My instinct is that saying that the body is the currently focused element, and patching things at :focus, is going to be easier than maintaining the body <-> viewport correspondence, and patching things up at activeElement. |
| 15:37 | <Domenic> | But maybe that doesn't work given <body tabindex="0"> or some such. |
| 15:41 | <annevk> | Domenic: you'll have to consider documents without <body> too |
| 15:42 | <annevk> | Domenic: there's a lot of <body> special casing in specs so it might well make sense, but it can be removed or in case of SVG or something weird it might not be there to begin with |
| 15:42 | <Domenic> | Bleh |
| 15:43 | <Domenic> | Maybe document then. And patch up document -> body in the activeElement getter. The main thing I dislike is having non-nodes be focusable areas; it makes the model extra complicated. |
| 15:43 | <Domenic> | But maybe using non-element nodes isn't much better than using non-nodes. |