@emilio thanks for that pointer to the `inert` conversation. It was enlightening, and I agree with the arguments you made there (except for the one about punting on `user-focus` 😜). I don’t find it regrettable that we have things like user-select and pointer-events (and display, visibility, overflow, ::content, animation, transition, etc. that dip into behavior and content). I think CSS and CSS authors are better off with these sort of capabilities and the ability to set them with selector-based rules, rather that by modifying DOM attributes or relying too much on scripting to achieve things. With regard to @dbaron’s “philosophical” comments in that thread, which I also agree with, I would like to draw the line further into the realm of more specifying of non-visual presentation qualities and behavior via CSS, with things like `nav-next`, `::a11y-content`, `visibility: visible aria-hidden`, `display: none aria-inline`, `aria-describes: <custom-identifier>`, `aria-described-by: <custom-identifier>`, etc. (all theoretical and unspecified at this time). But `user-focus` (or adding focus values to `user-select`) would be a great start. -- GitHub Notification of comment by bradkemper Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5283#issuecomment-653987587 using your GitHub accountReceived on Monday, 6 July 2020 02:51:03 UTC
This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:11 UTC