Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow elements with display:contents to be focusable. #9425

Merged
merged 4 commits into from
Jan 31, 2024

Conversation

dbaron
Copy link
Member

@dbaron dbaron commented Jun 14, 2023

This aligns HTML with the conclusion in
w3c/csswg-drafts#2632 that elements with CSS display: contents should be focusable just like normally-rendered elements. It fixes a piece of #1837.

(See WHATWG Working Mode: Changes for more details.)


/interaction.html ( diff )
/rendering.html ( diff )

@annevk
Copy link
Member

annevk commented Jun 14, 2023

I'm surprised it might be this simple. Would be nice!

As @emilio pointed out in mozilla/standards-positions#772 this creates an issue for focus outlines. @jcsteh and @cookiecrook come to mind as potential reviewers for that aspect.

And for the focus aspects maybe @rakina is willing to help or knows a suitable reviewer?

source Outdated Show resolved Hide resolved
Copy link
Member

@foolip foolip left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Editorially this looks good. @dbaron we try to land spec and test PRs close together, is https://chromium-review.googlesource.com/c/chromium/src/+/3910374 ready to land soon after this if I merge?

source Outdated Show resolved Hide resolved
This aligns HTML with the conclusion in
w3c/csswg-drafts#2632 that elements with CSS
`display: contents` should be focusable just like normally-rendered
elements.
@dbaron dbaron force-pushed the focusable-display-contents branch from dd6f2d6 to 9d23e07 Compare January 17, 2024 15:02
@dbaron
Copy link
Member Author

dbaron commented Jan 17, 2024

Editorially this looks good. @dbaron we try to land spec and test PRs close together, is https://chromium-review.googlesource.com/c/chromium/src/+/3910374 ready to land soon after this if I merge?

Probably not quite ready, since I need to finish the process about getting the intent approved (and also reply to Aaron's comments in the thread).

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Jan 24, 2024
Chromestatus: https://chromestatus.com/feature/6237396851228672

This lands support for allowing elements with display:contents to be
focused, behind a feature flag that is created with status:experimental.

This is as concluded (though without a group resolution) in
w3c/csswg-drafts#2632 and as discussed a bit
in whatwg/html#1837 and proposed in
whatwg/html#9425 .  Note that this diverges from
Gecko (see https://bugzil.la/1553549, https://bugzil.la/1791648, and
mozilla/standards-positions#772) and WebKit
(see https://bugs.webkit.org/show_bug.cgi?id=255149 and
WebKit/standards-positions#164).

This makes the <slot> element focusable when it has a tabindex.  Note
that this does not match Gecko and WebKit, which also require that its
'display' value is changed (away from 'contents') to make it focusable.

Note that the <slot> element is still not tabbable in Chrome; this is
https://crbug.com/1428419.  This also does not match Gecko and WebKit,
where it is tabbable whenever it is focusable.  The added test
slot-element-tabbable.tentative.html fails both tests as a result, but
is added anyway.  (Gecko and WebKit pass the display: block test but
fail the default style (display: contents) test.)

The added tests display-contents-focusable-001.html and
slot-element-focusable.tentative.html are partly fixed by this change,
but the style part is still broken due to https://crbug.com/1428420.

Fixed: 1366037
Bug: 1428419, 1428420
Change-Id: I46a8ad3b6442ce07f440c8f6a07210bac305600e
source Show resolved Hide resolved
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Jan 25, 2024
Chromestatus: https://chromestatus.com/feature/6237396851228672

This lands support for allowing elements with display:contents to be
focused, behind a feature flag that is created with status:experimental.

This is as concluded (though without a group resolution) in
w3c/csswg-drafts#2632 and as discussed a bit
in whatwg/html#1837 and proposed in
whatwg/html#9425 .  Note that this diverges from
Gecko (see https://bugzil.la/1553549, https://bugzil.la/1791648, and
mozilla/standards-positions#772) and WebKit
(see https://bugs.webkit.org/show_bug.cgi?id=255149 and
WebKit/standards-positions#164).

This makes the <slot> element focusable when it has a tabindex.  Note
that this does not match Gecko and WebKit, which also require that its
'display' value is changed (away from 'contents') to make it focusable.

Note that the <slot> element is still not tabbable in Chrome; this is
https://crbug.com/1428419.  This also does not match Gecko and WebKit,
where it is tabbable whenever it is focusable.  The added test
slot-element-tabbable.tentative.html fails both tests as a result, but
is added anyway.  (Gecko and WebKit pass the display: block test but
fail the default style (display: contents) test.)

The added tests display-contents-focusable-001.html and
slot-element-focusable.tentative.html are partly fixed by this change,
but the style part is still broken due to https://crbug.com/1428420.

Bug: 1366037
Bug: 1428419, 1428420
Change-Id: I46a8ad3b6442ce07f440c8f6a07210bac305600e
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Jan 25, 2024
Chromestatus: https://chromestatus.com/feature/6237396851228672

This lands support for allowing elements with display:contents to be
focused, behind a feature flag that is created with status:experimental.

This is as concluded (though without a group resolution) in
w3c/csswg-drafts#2632 and as discussed a bit
in whatwg/html#1837 and proposed in
whatwg/html#9425 .  Note that this diverges from
Gecko (see https://bugzil.la/1553549, https://bugzil.la/1791648, and
mozilla/standards-positions#772) and WebKit
(see https://bugs.webkit.org/show_bug.cgi?id=255149 and
WebKit/standards-positions#164).

This makes the <slot> element focusable when it has a tabindex.  Note
that this does not match Gecko and WebKit, which also require that its
'display' value is changed (away from 'contents') to make it focusable.

Note that the <slot> element is still not tabbable in Chrome; this is
https://crbug.com/1428419.  This also does not match Gecko and WebKit,
where it is tabbable whenever it is focusable.  The added test
slot-element-tabbable.tentative.html fails both tests as a result, but
is added anyway.  (Gecko and WebKit pass the display: block test but
fail the default style (display: contents) test.)

The added tests display-contents-focusable-001.html and
slot-element-focusable.tentative.html are partly fixed by this change,
but the style part is still broken due to https://crbug.com/1428420.

Bug: 1366037
Bug: 1428419, 1428420
Change-Id: I46a8ad3b6442ce07f440c8f6a07210bac305600e
aarongable pushed a commit to chromium/chromium that referenced this pull request Jan 25, 2024
Chromestatus: https://chromestatus.com/feature/6237396851228672

This lands support for allowing elements with display:contents to be
focused, behind a feature flag that is created with status:experimental.

This is as concluded (though without a group resolution) in
w3c/csswg-drafts#2632 and as discussed a bit
in whatwg/html#1837 and proposed in
whatwg/html#9425 .  Note that this diverges from
Gecko (see https://bugzil.la/1553549, https://bugzil.la/1791648, and
mozilla/standards-positions#772) and WebKit
(see https://bugs.webkit.org/show_bug.cgi?id=255149 and
WebKit/standards-positions#164).

This makes the <slot> element focusable when it has a tabindex.  Note
that this does not match Gecko and WebKit, which also require that its
'display' value is changed (away from 'contents') to make it focusable.

Note that the <slot> element is still not tabbable in Chrome; this is
https://crbug.com/1428419.  This also does not match Gecko and WebKit,
where it is tabbable whenever it is focusable.  The added test
slot-element-tabbable.tentative.html fails both tests as a result, but
is added anyway.  (Gecko and WebKit pass the display: block test but
fail the default style (display: contents) test.)

The added tests display-contents-focusable-001.html and
slot-element-focusable.tentative.html are partly fixed by this change,
but the style part is still broken due to https://crbug.com/1428420.

Bug: 1366037
Bug: 1428419, 1428420
Change-Id: I46a8ad3b6442ce07f440c8f6a07210bac305600e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3910374
Reviewed-by: Mason Freed <masonf@chromium.org>
Commit-Queue: David Baron <dbaron@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1252245}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Jan 25, 2024
Chromestatus: https://chromestatus.com/feature/6237396851228672

This lands support for allowing elements with display:contents to be
focused, behind a feature flag that is created with status:experimental.

This is as concluded (though without a group resolution) in
w3c/csswg-drafts#2632 and as discussed a bit
in whatwg/html#1837 and proposed in
whatwg/html#9425 .  Note that this diverges from
Gecko (see https://bugzil.la/1553549, https://bugzil.la/1791648, and
mozilla/standards-positions#772) and WebKit
(see https://bugs.webkit.org/show_bug.cgi?id=255149 and
WebKit/standards-positions#164).

This makes the <slot> element focusable when it has a tabindex.  Note
that this does not match Gecko and WebKit, which also require that its
'display' value is changed (away from 'contents') to make it focusable.

Note that the <slot> element is still not tabbable in Chrome; this is
https://crbug.com/1428419.  This also does not match Gecko and WebKit,
where it is tabbable whenever it is focusable.  The added test
slot-element-tabbable.tentative.html fails both tests as a result, but
is added anyway.  (Gecko and WebKit pass the display: block test but
fail the default style (display: contents) test.)

The added tests display-contents-focusable-001.html and
slot-element-focusable.tentative.html are partly fixed by this change,
but the style part is still broken due to https://crbug.com/1428420.

Bug: 1366037
Bug: 1428419, 1428420
Change-Id: I46a8ad3b6442ce07f440c8f6a07210bac305600e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3910374
Reviewed-by: Mason Freed <masonf@chromium.org>
Commit-Queue: David Baron <dbaron@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1252245}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Jan 25, 2024
Chromestatus: https://chromestatus.com/feature/6237396851228672

This lands support for allowing elements with display:contents to be
focused, behind a feature flag that is created with status:experimental.

This is as concluded (though without a group resolution) in
w3c/csswg-drafts#2632 and as discussed a bit
in whatwg/html#1837 and proposed in
whatwg/html#9425 .  Note that this diverges from
Gecko (see https://bugzil.la/1553549, https://bugzil.la/1791648, and
mozilla/standards-positions#772) and WebKit
(see https://bugs.webkit.org/show_bug.cgi?id=255149 and
WebKit/standards-positions#164).

This makes the <slot> element focusable when it has a tabindex.  Note
that this does not match Gecko and WebKit, which also require that its
'display' value is changed (away from 'contents') to make it focusable.

Note that the <slot> element is still not tabbable in Chrome; this is
https://crbug.com/1428419.  This also does not match Gecko and WebKit,
where it is tabbable whenever it is focusable.  The added test
slot-element-tabbable.tentative.html fails both tests as a result, but
is added anyway.  (Gecko and WebKit pass the display: block test but
fail the default style (display: contents) test.)

The added tests display-contents-focusable-001.html and
slot-element-focusable.tentative.html are partly fixed by this change,
but the style part is still broken due to https://crbug.com/1428420.

Bug: 1366037
Bug: 1428419, 1428420
Change-Id: I46a8ad3b6442ce07f440c8f6a07210bac305600e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3910374
Reviewed-by: Mason Freed <masonf@chromium.org>
Commit-Queue: David Baron <dbaron@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1252245}
@dbaron
Copy link
Member Author

dbaron commented Jan 25, 2024

FYI, the tests at web-platform-tests/wpt#39247 are now landed because I landed the Chromium CL but as status: experimental rather than status: stable.

moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this pull request Jan 29, 2024
…isplay:contents to be focused., a=testonly

Automatic update from web-platform-tests
Add support for allowing elements with display:contents to be focused.

Chromestatus: https://chromestatus.com/feature/6237396851228672

This lands support for allowing elements with display:contents to be
focused, behind a feature flag that is created with status:experimental.

This is as concluded (though without a group resolution) in
w3c/csswg-drafts#2632 and as discussed a bit
in whatwg/html#1837 and proposed in
whatwg/html#9425 .  Note that this diverges from
Gecko (see https://bugzil.la/1553549, https://bugzil.la/1791648, and
mozilla/standards-positions#772) and WebKit
(see https://bugs.webkit.org/show_bug.cgi?id=255149 and
WebKit/standards-positions#164).

This makes the <slot> element focusable when it has a tabindex.  Note
that this does not match Gecko and WebKit, which also require that its
'display' value is changed (away from 'contents') to make it focusable.

Note that the <slot> element is still not tabbable in Chrome; this is
https://crbug.com/1428419.  This also does not match Gecko and WebKit,
where it is tabbable whenever it is focusable.  The added test
slot-element-tabbable.tentative.html fails both tests as a result, but
is added anyway.  (Gecko and WebKit pass the display: block test but
fail the default style (display: contents) test.)

The added tests display-contents-focusable-001.html and
slot-element-focusable.tentative.html are partly fixed by this change,
but the style part is still broken due to https://crbug.com/1428420.

Bug: 1366037
Bug: 1428419, 1428420
Change-Id: I46a8ad3b6442ce07f440c8f6a07210bac305600e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3910374
Reviewed-by: Mason Freed <masonf@chromium.org>
Commit-Queue: David Baron <dbaron@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1252245}

--

wpt-commits: 83ac63c35c3c699dab5c8ec3b60377f52f59ca11
wpt-pr: 39247
ErichDonGubler pushed a commit to erichdongubler-mozilla/firefox that referenced this pull request Jan 30, 2024
…isplay:contents to be focused., a=testonly

Automatic update from web-platform-tests
Add support for allowing elements with display:contents to be focused.

Chromestatus: https://chromestatus.com/feature/6237396851228672

This lands support for allowing elements with display:contents to be
focused, behind a feature flag that is created with status:experimental.

This is as concluded (though without a group resolution) in
w3c/csswg-drafts#2632 and as discussed a bit
in whatwg/html#1837 and proposed in
whatwg/html#9425 .  Note that this diverges from
Gecko (see https://bugzil.la/1553549, https://bugzil.la/1791648, and
mozilla/standards-positions#772) and WebKit
(see https://bugs.webkit.org/show_bug.cgi?id=255149 and
WebKit/standards-positions#164).

This makes the <slot> element focusable when it has a tabindex.  Note
that this does not match Gecko and WebKit, which also require that its
'display' value is changed (away from 'contents') to make it focusable.

Note that the <slot> element is still not tabbable in Chrome; this is
https://crbug.com/1428419.  This also does not match Gecko and WebKit,
where it is tabbable whenever it is focusable.  The added test
slot-element-tabbable.tentative.html fails both tests as a result, but
is added anyway.  (Gecko and WebKit pass the display: block test but
fail the default style (display: contents) test.)

The added tests display-contents-focusable-001.html and
slot-element-focusable.tentative.html are partly fixed by this change,
but the style part is still broken due to https://crbug.com/1428420.

Bug: 1366037
Bug: 1428419, 1428420
Change-Id: I46a8ad3b6442ce07f440c8f6a07210bac305600e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3910374
Reviewed-by: Mason Freed <masonf@chromium.org>
Commit-Queue: David Baron <dbaron@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1252245}

--

wpt-commits: 83ac63c35c3c699dab5c8ec3b60377f52f59ca11
wpt-pr: 39247
Copy link
Member

@annevk annevk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please file an MDN issue, thanks!

@annevk annevk merged commit 921b688 into whatwg:main Jan 31, 2024
2 checks passed
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified-and-comments-removed that referenced this pull request Feb 1, 2024
…isplay:contents to be focused., a=testonly

Automatic update from web-platform-tests
Add support for allowing elements with display:contents to be focused.

Chromestatus: https://chromestatus.com/feature/6237396851228672

This lands support for allowing elements with display:contents to be
focused, behind a feature flag that is created with status:experimental.

This is as concluded (though without a group resolution) in
w3c/csswg-drafts#2632 and as discussed a bit
in whatwg/html#1837 and proposed in
whatwg/html#9425 .  Note that this diverges from
Gecko (see https://bugzil.la/1553549, https://bugzil.la/1791648, and
mozilla/standards-positions#772) and WebKit
(see https://bugs.webkit.org/show_bug.cgi?id=255149 and
WebKit/standards-positions#164).

This makes the <slot> element focusable when it has a tabindex.  Note
that this does not match Gecko and WebKit, which also require that its
'display' value is changed (away from 'contents') to make it focusable.

Note that the <slot> element is still not tabbable in Chrome; this is
https://crbug.com/1428419.  This also does not match Gecko and WebKit,
where it is tabbable whenever it is focusable.  The added test
slot-element-tabbable.tentative.html fails both tests as a result, but
is added anyway.  (Gecko and WebKit pass the display: block test but
fail the default style (display: contents) test.)

The added tests display-contents-focusable-001.html and
slot-element-focusable.tentative.html are partly fixed by this change,
but the style part is still broken due to https://crbug.com/1428420.

Bug: 1366037
Bug: 1428419, 1428420
Change-Id: I46a8ad3b6442ce07f440c8f6a07210bac305600e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3910374
Reviewed-by: Mason Freed <masonfchromium.org>
Commit-Queue: David Baron <dbaronchromium.org>
Cr-Commit-Position: refs/heads/main{#1252245}

--

wpt-commits: 83ac63c35c3c699dab5c8ec3b60377f52f59ca11
wpt-pr: 39247

UltraBlame original commit: 750cbf39a61f63ccdf2d1384fdf9c8ef8e7c98ec
gecko-dev-updater pushed a commit to marco-c/gecko-dev-comments-removed that referenced this pull request Feb 1, 2024
…isplay:contents to be focused., a=testonly

Automatic update from web-platform-tests
Add support for allowing elements with display:contents to be focused.

Chromestatus: https://chromestatus.com/feature/6237396851228672

This lands support for allowing elements with display:contents to be
focused, behind a feature flag that is created with status:experimental.

This is as concluded (though without a group resolution) in
w3c/csswg-drafts#2632 and as discussed a bit
in whatwg/html#1837 and proposed in
whatwg/html#9425 .  Note that this diverges from
Gecko (see https://bugzil.la/1553549, https://bugzil.la/1791648, and
mozilla/standards-positions#772) and WebKit
(see https://bugs.webkit.org/show_bug.cgi?id=255149 and
WebKit/standards-positions#164).

This makes the <slot> element focusable when it has a tabindex.  Note
that this does not match Gecko and WebKit, which also require that its
'display' value is changed (away from 'contents') to make it focusable.

Note that the <slot> element is still not tabbable in Chrome; this is
https://crbug.com/1428419.  This also does not match Gecko and WebKit,
where it is tabbable whenever it is focusable.  The added test
slot-element-tabbable.tentative.html fails both tests as a result, but
is added anyway.  (Gecko and WebKit pass the display: block test but
fail the default style (display: contents) test.)

The added tests display-contents-focusable-001.html and
slot-element-focusable.tentative.html are partly fixed by this change,
but the style part is still broken due to https://crbug.com/1428420.

Bug: 1366037
Bug: 1428419, 1428420
Change-Id: I46a8ad3b6442ce07f440c8f6a07210bac305600e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3910374
Reviewed-by: Mason Freed <masonfchromium.org>
Commit-Queue: David Baron <dbaronchromium.org>
Cr-Commit-Position: refs/heads/main{#1252245}

--

wpt-commits: 83ac63c35c3c699dab5c8ec3b60377f52f59ca11
wpt-pr: 39247

UltraBlame original commit: 750cbf39a61f63ccdf2d1384fdf9c8ef8e7c98ec
marcoscaceres pushed a commit to web-platform-tests/wpt that referenced this pull request Feb 23, 2024
Chromestatus: https://chromestatus.com/feature/6237396851228672

This lands support for allowing elements with display:contents to be
focused, behind a feature flag that is created with status:experimental.

This is as concluded (though without a group resolution) in
w3c/csswg-drafts#2632 and as discussed a bit
in whatwg/html#1837 and proposed in
whatwg/html#9425 .  Note that this diverges from
Gecko (see https://bugzil.la/1553549, https://bugzil.la/1791648, and
mozilla/standards-positions#772) and WebKit
(see https://bugs.webkit.org/show_bug.cgi?id=255149 and
WebKit/standards-positions#164).

This makes the <slot> element focusable when it has a tabindex.  Note
that this does not match Gecko and WebKit, which also require that its
'display' value is changed (away from 'contents') to make it focusable.

Note that the <slot> element is still not tabbable in Chrome; this is
https://crbug.com/1428419.  This also does not match Gecko and WebKit,
where it is tabbable whenever it is focusable.  The added test
slot-element-tabbable.tentative.html fails both tests as a result, but
is added anyway.  (Gecko and WebKit pass the display: block test but
fail the default style (display: contents) test.)

The added tests display-contents-focusable-001.html and
slot-element-focusable.tentative.html are partly fixed by this change,
but the style part is still broken due to https://crbug.com/1428420.

Bug: 1366037
Bug: 1428419, 1428420
Change-Id: I46a8ad3b6442ce07f440c8f6a07210bac305600e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3910374
Reviewed-by: Mason Freed <masonf@chromium.org>
Commit-Queue: David Baron <dbaron@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1252245}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

5 participants