On Tuesday, January 9, 2024 at 5:39:19 PM UTC+1 David Baron wrote:
Contact emailsdba...@chromium.org ExplainerNone Specificationhttps://github.com/w3c/csswg-drafts/issues/2632# issuecomment-438851770 Is this actually defined in the spec? Should the spec be more explicit about it? Summary This change means that elements that have CSS display:contents can be focusable. In other words, if they would have been focusable without display:contents, display:contents will no longer change that. Before this change, elements with display:contents could never be focused. Developers making elements with display:contents that can be focused need to ensure that such elements have appropriate styles to make the focus visually apparent, since they will not have a default focus outline. Blink componentBlink>HTML>Focus <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EHTML%3EFocus> Motivation Elements with display:contents are exposed to assistive technology as having their normal roles (as though they had their default display). The contract for the meaning of accessibility roles includes support for certain role-specific keyboard interactions which often include focusability. So it's important that the exposure to AT match the focusability. The CSS Working Group has concluded that both AT exposure and focusability should be as-normal. Prior to this change, AT exposure was interoperably as specified, but such elements were interoperably not focusable. Search tagsCSS <https://chromestatus.com/features#tags:CSS>, a11y <https://chromestatus.com/features#tags:a11y>, accessibility <https://chromestatus.com/features#tags:accessibility>, focus <https://chromestatus.com/features#tags:focus> TAG reviewNone TAG review statusNot applicable Risks Interoperability and Compatibility This is proposing to change a currently interoperable behavior. This has some risk that other engines won't match the change and we'll end up with less interoperability. However, I think there is probably enough support from other engines at this point that we should take the lead and hope that other engines will soon follow. What about compat? Would existing users of `display: contents` have their keyboard flows disrupted by this change? *Gecko*: Positive (https://github.com/mozilla/standards-positions/issues/772 ) *WebKit*: No signal (https://github.com/WebKit/ standards-positions/issues/164) No official position but https://github.com/web-platform-tests/interop/issues/568 does show Safari interest in the topic. *Web developers*: No signals *Other signals*: Positive advocacy from users / user advocates such as in https://bugs.chromium.org/p/chromium/issues/detail?id=1366037 and https://github.com/web-platform-tests/interop/issues/568 Activation This fixes what appears to be one of the obstacles for developers to use display:contents in a way that is accessible. While in the short term it reduces interoperability (since engines agree on the current "bad" behavior), the long term goal is that engines will converge on the new behavior, and this will lead to increased developer confidence in and increased usability of CSS display:contents. WebView application risks Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications? None Debuggability None Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?Yes Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ?Yes https://github.com/web-platform-tests/wpt/pull/39247 Flag name on chrome://flagsNone Finch feature namekDisplayContentsFocusable Requires code in //chrome?False Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1366037 Estimated milestones No milestones specified Anticipated spec changes Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way). None Link to entry on the Chrome Platform Statushttps://chromestatus.com/ feature/6237396851228672 This intent message was generated by Chrome Platform Status <https://chromestatus.com/> and edited by hand. -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/aaabc541-832c-4c47-89f6-0d6bab35bf98n%40chromium.org.