- From: SelenIT via GitHub <sysbot+gh@w3.org>
- Date: Fri, 04 May 2018 08:29:55 +0000
- To: public-css-archive@w3.org
Well, `display:contents` might be not intended for this, but the problem of styling limitations of native controls still exist and any option to strip off all the "dark magic" from these elements is too tempting. Until browsers offer the better way for this (some new `appearance` value?), authors would likely use all the available valid CSS means to solve this problem — including `display:contents`.
I'm OK with `button:focus { display:contents }` not being highlighted, and with its plain text content not highlighted as well. But I'm not OK with the `span` inside this button not applying the `button:focus > span` styles. And I'm very not OK with visible and interactive element that can't be keyboard-activated at all just because of its styling. As an author, I see the focus state as a property of the DOM element, not of a box in a render tree. It's the DOM element, not the box, that fires `focus` and `blur` events. And if something is interactive, it's expected to be focusable.
After all, in #2355 we added the following text:
> Aside from the none value, which also affects the aural/speech output [CSS-SPEECH-1] and *interactivity of an element* and its descendants, the display property *only affects visual layout:* its purpose is *to allow designers freedom to change the layout behavior* of an element *without* affecting the underlying document semantics.
Doesn't this imply that the interactive element with no box but visible children is just the element that can't be styled on focus itself, not the element that magically became not focusable?
--
GitHub Notification of comment by SelenIT
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2632#issuecomment-386536612 using your GitHub account
Received on Friday, 4 May 2018 08:29:58 UTC