- From: SelenIT via GitHub <sysbot+gh@w3.org>
- Date: Thu, 03 May 2018 09:11:56 +0000
- To: public-css-archive@w3.org
To me, `display: contents` and `display: none` for the interactive element with visible content (e.g. `button`) are very different. While `display: none` really removes the element from the presentation, `display: contents` leaves its children on-screen, they still response to activation via click/tap, and the author most likely wants to preserve all the aspects of their interactivity. The interactive element with `display:contents` looks very similar to the common pattern for creating custom controls with native functionality: visually-hidden normal `<input>` element + its sibling (usually a `<label>` element or a `<span>` inside it) that gets custom styling and changes it according to the state of the invisible `<input>`. The focus state is no different: the `<input>` elements perfectly gets focused by tabbing despite being off-screen, its visible siblings react to this and the user gets the decent UX. >From `display:contents`, I expect the behavior similar to that. I also expect that the primary use case for applying it to interactive elements would be similar — working around browser limitation of native control styling (e.g. inability to make the `<button>` non-atomic inline element) while preserving as much native functionality as possible. It's extremely unlikely that authors _expect_ such elements, which are perfectly visible (through content) and reachable to users, to disappear from tabbing sequence and accessibility tree. -- GitHub Notification of comment by SelenIT Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2632#issuecomment-386234845 using your GitHub account
Received on Thursday, 3 May 2018 09:11:59 UTC