*Contact emails*
re...@igalia.com
*Spec*
https://drafts.csswg.org/selectors-4/#the-focus-within-pseudo
The spec is an Editor Draft (ED) yet, but this pseudo-class
has been shipped into Firefox 52 and will be part of Safari 10.1
(about to be released).
*Summary*
The :focus-within pseudo-class applies to elements for which
the :focus pseudo class applies.
An element also matches :focus-within if one of
its shadow-including descendants matches :focus.
*Motivation*
Some excerpts to explain the reasons behind this selector.
First one by Fred Esch at www-style [1]:
"One common web accessibility problem is inaccessible menus and
multi level menus. A developer can use css hover to make the menus
and sub menus visible. This works because hover bubbles,
so when a sub menu gets the hover the parent menu still
has hover too. Developers are not so lucky when it comes
to keyboard users. CSS focus does not bubble so making
a multi level menu using focus is problematic.
The focus-within selector solves the focus doesn't bubble problem
so hover and focus-within can work the same way,
allowing keyboard users the same access as mouse users."
Second one by Lea Verou at Windows developer feedback site [2]:
"Tons of UIs include elements that are not visible unless
the user interacts with their parent or ancestor.
Think popup menus, delete or edit buttons, floating formatting
toolbars, copy buttons, editing popups and so on.
The list is endless. This is a good way to reduce visual clutter.
However, this is often done in an inaccessible way,
just by using :hover, because making it accessible requires JS,
since :focus does not apply to ancestors. However, 1 in 2 people
writing HTML/CSS are not comfortable with JavaScript
so keyboard accessibility (and usability, as many of us
are keyboard users by choice) goes out of the window."
*Interoperability and Compatibility risk*
It's a small feature and it has been already implemented
in Firefox 52 [3] and Safari 10.1 (in STP since July 2016 [4]).
Edge hasn't show any public signal about it yet.
There are already tests on the W3C test suite:
https://github.com/w3c/csswg-test/tree/master/selectors-4/
More tests will be added if the need is detected during
the development. On top of that, we'll verify that Gecko and WebKit
tests pass on Chrome too (importing or upstreaming to csswg-test
the new cases if needed).
*Ongoing technical constraints*
We already have the :focus selector, so this one will be similar,
but somehow working like :active and :hover (affecting ancestors too).
Regarding testing, I don't foresee any issue, as you can easily
test CSS selectors with our layout tests.
*Will this feature be supported on all six Blink platforms
(Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?*
Yes.
*Demo link*
https://developer.mozilla.org/en-US/docs/Web/CSS/:focus-within
*OWP launch tracking bug*
https://bugs.chromium.org/p/chromium/issues/detail?id=617371
*Link to entry on the Chrome Platform Status*
https://www.chromestatus.com/feature/5363834508279808
*Requesting approval to ship?*
Yes. This is a small change and it has been already shipped
in other browsers. I guess it's not worth to develop it behind a flag.
[1]
https://lists.w3.org/Archives/Public/www-style/2015Jan/0049.html
[2]
https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/11725071-implement-focus-within-from-selectors-4
[3]
https://developer.mozilla.org/en-US/Firefox/Releases/52
[4]
https://developer.apple.com/safari/technology-preview/release-notes/#r8