Move focus section to HTML

[annevk]

Given that HTML already defines almost everything around focus events, it seems better to uplift this section there and not have the existing split. Does that make sense?

HTML should first define dispatch of the focus events other than focus/blur though. See https://github.com/whatwg/html/issues/3514 for the tracking issue on the HTML side.

[plehegar]

if you move FocusEvent into the html spec, would you move the UIEvent interface as well?

[annevk]

No, that has other dependencies such as mouse events (though I'm not sure why load and some other events are defined to use it, that seems like a mistake).

[plehegar]

one other thought: if we move focusin/out in HTML, what would that mean for specs like SVG? We'd probably expect the focus behavior to be comparable when standalone and when embedded. I would think that having a general algorithm for focusin/out in UIEvents while allowing hooks for HTML and SVG handling would seem a better approach.

[annevk]

You need a single algorithm since you can mix the two arbitrarily. In general a lot in SVG already needs to be redefined to reference concepts only defined in HTML so I don't think that's a big deal per se. (E.g., only HTML defines browsing contexts and focus depends on that.)

[AmeliaBR]

The SVG 2 spec already references HTML for pretty much everything related to focus handling, including the tabindex attribute and focus() and blur() methods.

The only unique aspects defined for SVG in the focus section are:

• listing which SVG elements should be focusable by default
• adding backwards compatibility for the SVG 1.2 focusable attribute, as a limited synonym of tabindex
• mentioning focusability of use-element shadow content (although that is now covered by general shadow DOM "flattened tree" concept)

Consistent cross-browser support for the SVG-specific details is still not great, but that's a separate matter.

If moving things to the HTML spec means that they aren't defined generally for all DOM elements, then we may need to add an extra paragraph here or there saying that SVG follows the HTML model. But I don't expect that to be a problem.

[travisleithead]

So, looking through the UIEvents Focus section, there's really not all that much there.

• We define the IDL for FocusEvent and it's member
• We define the relative order of focus events focusin, focusout, focus and blur (though with the note that leaves interaction with focus()/blur() undefined--which is unfortunate). Back in 2014 I propped adding focusin and focusout to HTML's model. I'm glad to see that re-opened.
• We offer some prose explaining to authors about the difference between OS focus, application focus, and document focus.
  • The litany of deferrals to a host language in the final paragraph is interesting and points to the need for extensive host language integration...but the question I'm faced with is: do different host languages really want different focus models? Specifically we're talking about UI-based markup languages like SVG, MathML, and HTML. Given @AmeliaBR's comments, it looks like there's already some good alignment there. I'm not sure how much value this is adding in UI Events
• Finally, all the event types are listed.

Given that HTML already defines almost everything around focus events, it seems better to uplift this section there and not have the existing split. Does that make sense?

Truthfully, I don't see much of a split here. @garykac is there any of the above sections that would make sense to stay put? Any strong objections?