I think in theory it might make sense for focus outlines to use something like an aggregation of child bounds. (The specifications even allow focus outlines on regular elements to expand to contain the bounds of children.)
However, in the case of display:contents, it would be hard to implement in all browser engines (need to figure out responsibility for painting and invalidating it), hard to specify (need to describe how it interacts with visual effects... and also implement that interaction), hard to explain to developers (doesn't fit with the normal model around how outlines are drawn and how display:contents works), and probably hard to get standards consensus around (for those same reasons). So my current preference is to allow display:contents elements to be focusable and to make visual indication of the outline the developer's problem (but perhaps still somewhat discourage having to go down that path). -David On Tue, Jan 9, 2024 at 12:49 PM Aaron Leventhal <alevent...@chromium.org> wrote: > Would an option for focus outlines to be to use the same idea we're > discussing for AT bounding boxes? Namely, to use an aggregation of child > outlines? > > On Tue, Jan 9, 2024 at 12:33 PM David Baron <dba...@chromium.org> wrote: > >> I think accumulating the rectangles of children seems like a good option >> if we need to report a bounding box. It sounds like that's something else >> where I need to test, and possibly change, our current behavior for >> elements with display:contents. >> >> Regarding focus outlines: these elements won't draw focus outlines. >> This is definitely a tradeoff. As I wrote in >> https://github.com/WebKit/standards-positions/issues/164#issuecomment-1708822339 >> : >> >> So I think my preference for outline is that we say that if a developer >> is going to depend on focusability of something with display: contents, >> they need to add appropriate styles to draw the focus outline (for example, >> by drawing it on an appropriate descendant or descendants). >> >> I admit that developers aren't going to get that right all the time. But >> the same is true of the current situation. That is, I think developers will >> sometimes not do what we want if we say either of: >> >> >> - developers shouldn't use display: contents if they need an element >> to be focusable, or >> - developers should add appropriate focus styles if they use display: >> contents on something that is focusable. >> >> (Note that needing an element to be focusable is often a need for users >> using keyboard navigation or similar, that may not apply to users using a >> mouse. So developers may well miss it.) >> >> Then the question is which problem is worse: is it worse to have an >> element that the user needs to get to but that can't be focused at all, or >> worse to have it be focusable but without a good indication that it's >> focused. The latter at least gives a keyboard user a chance to figure out >> what's going on, whereas with the former they're out of luck. So my >> inclination is that having the element be focusable but without an >> indication of focus is less bad than having it not be focusable at all when >> it should be. I admit that this is just my instinct and I haven't attempted >> to confirm this. And there's also the confounding factor that the two >> problems might occur at different rates. >> >> -David >> >> On Tue, Jan 9, 2024 at 11:46 AM Aaron Leventhal <alevent...@chromium.org> >> wrote: >> >>> And (duh to myself), we need to compute a bounding box for our own focus >>> outline. >>> >>> Apologies if this is answered elsewhere. >>> >>> On Tue, Jan 9, 2024 at 11:45 AM Aaron Leventhal <alevent...@chromium.org> >>> wrote: >>> >>>> Interesting. How will the bounding box be reported via a11y APIs? >>>> >>>> Examples of where this is used: >>>> 1. ATs for low vision users that draw a box around the focus and/or >>>> move the focus onscreen (especially for a magnifier that is only showing >>>> part of the actual screen's contents in a virtual viewport). >>>> 2. Voice Input: used to show numbers next to the item when several >>>> things have the same name, e.g. a bunch of links labelled "click here". >>>> 3. Single switch ATs: for highlighting an item that the user can select >>>> >>>> One answer might be to accumulate the rectangles of all children and to >>>> use that. Not sure what the algorithm would do for out-of-flow children. >>>> >>>> Aaron >>>> >>>> On Tue, Jan 9, 2024 at 11:39 AM David Baron <dba...@chromium.org> >>>> wrote: >>>> >>>>> Contact emailsdba...@chromium.org >>>>> >>>>> ExplainerNone >>>>> >>>>> Specification >>>>> https://github.com/w3c/csswg-drafts/issues/2632#issuecomment-438851770 >>>>> >>>>> 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. >>>>> >>>>> >>>>> *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 bug >>>>> https://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 Status >>>>> https://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/CAG0MU3irORkF9G%3Dkr-KJF0hvoYbTpdpmYordQ1qi6w3s2jd5Fw%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG0MU3irORkF9G%3Dkr-KJF0hvoYbTpdpmYordQ1qi6w3s2jd5Fw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >> 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/CAG0MU3gOw1Bmzv0mVsA-PeYRyJDRWYEgShedyErcktooY0jovw%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG0MU3gOw1Bmzv0mVsA-PeYRyJDRWYEgShedyErcktooY0jovw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/CAG0MU3j5FWfq%3Dk2apAAHgMnGu_xacc9gpcCzu4OM%2BgQLhxUF1g%40mail.gmail.com.
