Intent to Ship: Updated dialog initial focus algorithm
Joey Arhar
Contact emails
jar...@chromium.orgSpecification
https://github.com/whatwg/html/pull/8199Summary
Some changes are being made to which element is selected to get focus when a dialog element is opened: 1. Make the dialog focusing steps look at keyboard focusable elements instead of any focusable element. 2. Make the dialog element itself get focus if it has the autofocus attribute set. 3. Make the dialog element itself get focus as a fallback instead of focus being "reset" to the body element.
Blink component
Blink>HTML>DialogTAG review
NoneTAG review status
Not applicableRisks
Interoperability and Compatibility
If a website affected by this change absolutely needs the old element to be focused, they would likely need to add the autofocus attribute to it. If by some chance this causes a really bad breakage, I can disable it via finch. I don't believe negative effects are likely since this new behavior was thoroughly thought out over the last year by accessibility experts.
Gecko: No signal (https://github.com/mozilla/standards-positions/issues/734)
WebKit: No signal (https://github.com/WebKit/standards-positions/issues/123)
Web developers: No signals
Other signals:
Ergonomics
This change will not be used in tandem with other platform APIs.
Activation
It will not be challenging for developers to take advantage of this change, and no polyfills/outreach is needed.
Security
This change has no security considerations/risks.
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?
Debuggability
Dialog initial focus doesn't have any special DevTools support and I don't think it needs any.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
YesIs this feature fully tested by web-platform-tests?
YesFlag name
--enable-features=DialogNewFocusBehaviorRequires code in //chrome?
FalseTracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1193482Estimated milestones
111
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).
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/4675914745511936
Rick Byers
--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwKVyLctXm%2B7UNenRyKsRNpY%2BrxWF_4LuYn6rJdYbu_bQQ%40mail.gmail.com.
Philip Jägenstedt
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9baok4j46gxQeJDJNLpHqEO3KLeEvFarCeKWj_XYj-JA%40mail.gmail.com.
Joey Arhar
Yoav Weiss
Summary
Some changes are being made to which element is selected to get focus when a dialog element is opened: 1. Make the dialog focusing steps look at keyboard focusable elements instead of any focusable element. 2. Make the dialog element itself get focus if it has the autofocus attribute set. 3. Make the dialog element itself get focus as a fallback instead of focus being "reset" to the body element.
Blink componentBlink>HTML>Dialog
TAG reviewNone
Risks
Interoperability and Compatibility
If a website affected by this change absolutely needs the old element to be focused, they would likely need to add the autofocus attribute to it. If by some chance this causes a really bad breakage, I can disable it via finch. I don't believe negative effects are likely since this new behavior was thoroughly thought out over the last year by accessibility experts.
Gecko: No signal (https://github.com/mozilla/standards-positions/issues/734)
WebKit: No signal (https://github.com/WebKit/standards-positions/issues/123)
Web developers: No signals
Other signals:
Ergonomics
This change will not be used in tandem with other platform APIs.
Activation
It will not be challenging for developers to take advantage of this change, and no polyfills/outreach is needed.
Security
This change has no security considerations/risks.
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?
Debuggability
Dialog initial focus doesn't have any special DevTools support and I don't think it needs any.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?Yes
Is this feature fully tested by web-platform-tests?Yes
Flag name--enable-features=DialogNewFocusBehavior
Requires code in //chrome?False
Estimated milestones
111
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).
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwKVyLctXm%2B7UNenRyKsRNpY%2BrxWF_4LuYn6rJdYbu_bQQ%40mail.gmail.com.
You received this message because you are subscribed to the Google Groups "blink-dev" group.
Joey Arhar
Chris Harrelson
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwKjekCKGnnHnke8Sqx5f4m0MM0R_qp%2BN%3D2jQyToxh59rQ%40mail.gmail.com.
