[blink-dev] Intent to Implement and Ship: CSS Selectors Level 4: :focus-within pseudo-class

[Manuel Rego Casasnovas]

*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

[TAMURA, Kent]

> it has been already implemented in Firefox 52 [3] and Safari 10.1

It sounds very safe.  LGTM1.

--

TAMURA Kent
Software Engineer, Google

[Takayoshi Kochi]

Non-owner LGTM, the :focus-within spec takes care of Shadow DOM.

(crbug.com/617371 comment#12 by rego@ has details)

--

Takayoshi Kochi

[Rune Lillesveen]

On Fri, Mar 24, 2017 at 10:33 AM, Manuel Rego Casasnovas <re...@igalia.com> wrote:

*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.

That sounds wrong, spec-wise. I would expect the :focus-within to match flat tree ancestors. I see that this is also how :hover is spec'ed in the same spec. It does not match what Blink is currently implementing for :hover. Consider the example below:

<div id="host">

  <span>Hover me</span>

</div>

<script>

  host.attachShadow({mode:"open"}).innerHTML = "<style>div:hover { border: 5px solid green }</style><div><slot></slot></div>";

</script>

Blink renders the green border on the shadow div when the span is hovered, yet the span is not a shadow-including descendant of the shadow div.

--

Rune Lillesveen

[Manuel Rego Casasnovas]

On 28/03/17 11:22, Rune Lillesveen wrote:
> On Fri, Mar 24, 2017 at 10:33 AM, Manuel Rego Casasnovas

> *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.
>
>
> That sounds wrong, spec-wise. I would expect the :focus-within to match
> flat tree ancestors. I see that this is also how :hover is spec'ed in
> the same spec. It does not match what Blink is currently implementing
> for :hover. Consider the example below:
>
> <div id="host">
> <span>Hover me</span>
> </div>
> <script>
> host.attachShadow({mode:"open"}).innerHTML = "<style>div:hover {
> border: 5px solid green }</style><div><slot></slot></div>";
> </script>
>
> Blink renders the green border on the shadow div when the span is
> hovered, yet the span is not a shadow-including descendant of the shadow
> div.

Yeah the text on the spec sounds strange to me too.
I believe current behavior in Blink is the expected one,
but I've opened an issue on CSS WG GitHub repo to clarify this topic:
https://github.com/w3c/csswg-drafts/issues/1135

Thanks,
Rego

[Chris Harrelson]

LGTM2

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Jochen Eisinger]

what's the expected timeline for the spec issue to get addressed? Should the resolution be that we need to change Blink's implementation, will we be able to change the implementation without causing compat issues?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Rune Lillesveen]

I've cc'ed Tab an Elika on the issue.

On Fri, Mar 31, 2017 at 11:53 AM, Jochen Eisinger <joc...@chromium.org> wrote:

what's the expected timeline for the spec issue to get addressed? Should the resolution be that we need to change Blink's implementation, will we be able to change the implementation without causing compat issues?

I've cc'ed Tab an Elika on the issue[1]. I wouldn't be surprised if changing our implementation to match the current spec text breaks existing Polymer content, for instance.

--

Rune Lillesveen

[Manuel Rego Casasnovas]

On 31/03/17 13:24, Rune Lillesveen wrote:
> On Fri, Mar 31, 2017 at 11:53 AM, Jochen Eisinger <joc...@chromium.org
> <mailto:joc...@chromium.org>> wrote:
>
> what's the expected timeline for the spec issue to get addressed?
> Should the resolution be that we need to change Blink's
> implementation, will we be able to change the implementation without
> causing compat issues?
>
>
> I've cc'ed Tab an Elika on the issue[1]. I wouldn't be surprised if
> changing our implementation to match the current spec text breaks
> existing Polymer content, for instance.

Thanks Rune.

The spec issue [1] has been clarified and the spec will be modified.
The prose for ":focus-within" would talk about the *flat tree* instead
of *shadow-including descendants*.

Also I wrote a WPT test [2] to explicitly check this behavior.
That will be imported as part of the Blink implementation.

Bye,
Rego

[1] https://github.com/w3c/csswg-drafts/issues/1135
[2] https://github.com/w3c/web-platform-tests/pull/5271

[Jochen Eisinger]

cool, thx, lgtm3