Open annevk opened 6 years ago
if you move FocusEvent into the html spec, would you move the UIEvent interface as well?
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).
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.
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.)
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:
focusable
attribute, as a limited synonym of tabindex
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.
So, looking through the UIEvents Focus section, there's really not all that much there.
FocusEvent
and it's memberfocusin
, 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.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?
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.