New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 16 users

Issue metadata

Status: Fixed
Closed: Apr 2017
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Feature

Blocked on:
issue 704902

issue 747818

Sign in to add a comment

Issue 617371: Implement :focus-within pseudo-class from Selectors Level 4

Reported by, Jun 4 2016

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.79 Safari/537.36

Steps to reproduce the problem:
1. Open the attached testcase in Chrome.
2. Click/tap into the text <input> so as to focus it.

What is the expected behavior?
The <div> should turn green since the <input>, which is a descendant of the <div>,
has become focused, thus causing the :focus pseudo-class to match the <input>,
which should cause the <div> to match :focus-within,
because it now has a descendant which matches :focus.

What went wrong?
The <div> remained white, indicating that the :focus-within pseudo-class in the webpage's CSS didn't start matching the <div>.

Did this work before? No 

Chrome version: 51.0.2704.79  Channel: stable
OS Version: OS X 10.11.5
Flash Version: Shockwave Flash 21.0 r0

455 bytes View Download

Comment 1 by, Jun 4 2016

Components: Blink>Focus Blink>CSS
Labels: -Pri-2 -OS-Mac OS-All Pri-3
Status: Untriaged (was: Unconfirmed)

Comment 2 by, Jun 6 2016

Status: Available (was: Untriaged)
The version of Selectors Level 4 that focus-within appears in is still an editor's draft.

Comment 3 by, Jun 30 2016

Components: UI>Accessibility
FYI WebKit already have this

Comment 4 by, Sep 26 2016

Firefox 52 has implemented this:

Comment 5 by, Jan 25 2017

Labels: Needs-BlinkIntent

Comment 6 by, Feb 10 2017

Per this will ship in Firefox 52 and Safari 10.1.

Comment 7 by, Feb 12 2017

Labels: Update-Quarterly

Comment 8 by, Mar 24 2017

Status: Assigned (was: Available)
I'll give it a try.

Intent thread at:!topic/blink-dev/V3RNBhQelSg

Comment 9 by, Mar 24 2017

Blockedon: 704902

Comment 10 by, Mar 27 2017

Labels: Objective
Since this is a high-level tracking bug, adding the label Objective. Per Blink>CSS bug protocols, for clear responsibility, any concrete work on this issue should take place on a dependent bug that is filed under one component only.

Comment 11 by, Mar 27 2017

Is the spec include anything aboout Shadow DOM?

How Safari 10.1 treats shadow tree?

Comment 12 by, Mar 27 2017

The spec explicitly says (
"An element also matches :focus-within if one of its shadow-including descendants matches :focus."

This is pretty similar to the text for for :active or :hover pseudo-classes.

And about "shadow-including descendants" the spec says (
"An object A is a shadow-including descendant of an object B, if A is a descendant of B, or A’s root is a shadow root and A’s root’s host is a shadow-including inclusive descendant of B."

In Safari they have a test like this:
Which adds a green border to all the elements on the page including <body> and <div id="root">.

Also the W3C suite has 5 tests testing Shadow DOM too:

Comment 13 by, Mar 27 2017

rego@ thanks for the checking!

I've tried Safari TP25 myself, and it passed my casual tests of using :focus-within.
The behavior about Shadow DOM looks reasonable and the specs sound Shadow DOM-ready.

BTW the csswg tests use Shadow V0 API - I'll find time to convert them to V1 APIs :)
23.5 KB View Download
25.0 KB View Download

Comment 14 by, Mar 27 2017

@kochi, yeah I realized about that. We should change it to V1, I can do it too.
But note that the csswg-test is merging into wpt tomorrow,
so it's probably better to wait a few days. :-)

Comment 15 by, Mar 27 2017

rego@ it's good to know, and feel free to take it :)

BTW, the screenshot in comment#13 was for what I was playing with on Safari TP25.,css,output (without <slot>),css,output (with <slot>)

Notice the difference that the latter <input> gets green border, as it matches
the :focus-within in the document stylesheet. In the former <input> didn't
get green border, even though it is focused, because it is inside a shadow tree
and the style rule in the document tree didn't reach there.

Comment 16 by, Mar 27 2017

Labels: NewComponent-Accessibility-Blink NewComponent-Accessibility

Comment 17 by, Apr 4 2017

Status: Started (was: Assigned)
The intent thread still lacks 1 LGTM, but an initial patch is ready at:

Comment 18 by, Apr 12 2017

Project Member
The following revision refers to this bug:

commit ffc655c99fef91f49ad7906344d51678c3853b74
Author: rego <>
Date: Wed Apr 12 11:31:29 2017

[selectors4] Implement :focus-within pseudo-class

This patch adds support for the new ":focus-within" pseudo-class.
Most of the patch is basically the regular boilerplate code
to add a new selector. Then the interesting changes happen
on ContainerNode.

The patch is covered by a bunch of tests imported from
the W3C test suite (which includes generic tests in addition to
the tests from Firefox and WebKit implementations too).
Apart from some minor changes on current tests to add
the new selector.

Intent-to-ship thread is available at:!topic/blink-dev/V3RNBhQelSg

BUG= 617371 

Cr-Commit-Position: refs/heads/master@{#463992}


Comment 19 by, Apr 12 2017

Initial support for :focus-within has just landed behind a runtime flag.

The next steps would be (as described in the CL):
* Fix the test on WPT:
* Investigate the common ancestor approach deeply (the same we currently use for :hover).

Comment 20 by, Apr 17 2017

Project Member
The following revision refers to this bug:

commit a51a79c74201875de7299e5daf61e0c297d64647
Author: rego <>
Date: Mon Apr 17 17:34:37 2017

[selectors4] Remove :focus-within test from TestExpectations

The test is passing since r463992 but was marked as Failure
in TestExpectations file.

BUG= 617371 

Cr-Commit-Position: refs/heads/master@{#464944}


Comment 21 by, Apr 21 2017

Components: Blink>Accessibility

Comment 22 by, Apr 21 2017

Components: -UI>Accessibility
Labels: -newcomponent-accessibility-blink -newcomponent-accessibility

Comment 23 by, Apr 25 2017

Project Member
The following revision refers to this bug:

commit 8789e1ce7cc6848e0cb4ba4bb546828df4fe7ca2
Author: rego <>
Date: Tue Apr 25 12:06:44 2017

[selectors4] Use common ancestor strategy for :focus-within

Following the same approach than what we do for :active and :hover
pseudo-classes, it seems a nice optimization to use the common ancestor
strategy for :focus-within too.

The use case would be for example that you've a from with several inputs
in a deep part of the DOM, and in the body element you've :focus-within
to show some warning while editing the form.
When you switch focus from one input to the next one, we don't need
to invalidate the whole chain up to the body, but it'd be enough
to just do it up to the common ancestor of the old and new focused elements
(in this example the form).

To achieve that Document::SetFocusedElement() has been modified to look
for the common ancestor and then pass it to
This new helper method is also used from FocusController to set
:focus-within flag when the window loses/gains focus.

A new unit test has been added to AffectedByFocusTest.cpp
verifying that we only recalculate styles up to the common ancestor.

BUG= 617371 

Cr-Commit-Position: refs/heads/master@{#466949}


Comment 24 by, Apr 25 2017

Common ancestor patch has landed, and I've added a new WPT test in: (still pending to review).

@rune do you think we're still missing something else?
Or could we mark the Runtime Flag as stable for shipping this in M60?
Thanks for your feedback.

Comment 25 by, Apr 25 2017

IIUC, the test is about clearing :focus on elements becoming display:none, so it's not really directly a question about :focus-within as :focus-within is just kept in sync with :focus, right?

Comment 26 by, Apr 26 2017

> IIUC, the test is about clearing :focus on elements becoming display:none, so it's not really directly a question about :focus-within as :focus-within is just kept in sync with :focus, right?

Yeah that's true, I've splitted it into 2 different tests. Anyway that should be reviewed and merged first on WPT and then they'll be imported into Blink.

@rune my question about enabling the runtime flag still stands. Are you missing anything else regarding :focus-within before we ship the feature? Thanks.

Comment 27 by, Apr 26 2017

Nope, I think you can ship.

Comment 29 by, Apr 27 2017

Status: Fixed (was: Started)

Comment 30 by, May 2 2017

Project Member
The following revision refers to this bug:

commit 004ddc7b1a8b2c907f31179020ed17186b6639eb
Author: rego <>
Date: Tue May 02 11:40:55 2017

[selectors4] :focus-within test when iframe loses focus

This test should be part of
but at that time I didn't find the way to focus/unfocus an iframe.
The solution was to use internals.setFocused() for that purpose.

This patch adds a new test pretty similar to the one for windows
but checking what happens when an iframe loses and regains focus.

BUG= 617371 

Cr-Commit-Position: refs/heads/master@{#468601}


Comment 31 by, May 5 2017

Project Member
The following revision refers to this bug:

commit 29a9ed148cf67932faa0868735ab9a405ad81c97
Author: rego <>
Date: Fri May 05 07:12:13 2017

[selectors4] Remove :focus-within test that is now duplicated

This patch removes the following test:

The test was upstreamed into the WPT repository and it's imported as:

The new test includes the old checks and some more, so we don't need
our own test anymore.

BUG= 617371 

Cr-Commit-Position: refs/heads/master@{#469610}


Comment 32 by, Jul 24 2017

Blocking: 747818

Comment 33 by, Sep 13 2017

Project Member
The following revision refers to this bug:

commit f2c4d52d5ac4acec983b370ef4258b9fb57b915e
Author: ericwilligers <>
Date: Wed Sep 13 12:25:28 2017

CSS: Retire flag CSSSelectorsFocusWithin

The :focus-within pseudo-class shipped in Chrome 60.

The runtime flag is no longer needed.

BUG= 617371 

Change-Id: I12db298d40df458c24987e7928d85aea179e6046
Reviewed-by: Manuel Rego Casasnovas <>
Reviewed-by: Kent Tamura <>
Commit-Queue: Kent Tamura <>
Cr-Commit-Position: refs/heads/master@{#501599}

Comment 34 by, Sep 29 2017

Components: Blink>HTML>Focus

Comment 35 by, Sep 29 2017

Components: -Blink>Focus

Sign in to add a comment