- From: Carlos Lopez via GitHub <sysbot+gh@w3.org>
- Date: Tue, 06 Sep 2022 19:27:10 +0000
- To: public-css-archive@w3.org
clshortfuse has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-contain][inert]: inert and hidden containments should share common logic == I'm talking about these two specifications: https://html.spec.whatwg.org/multipage/interaction.html#inert https://drafts.csswg.org/css-contain/#skips-its-contents `inert` seems very similar to the conditions for [css-contain] skip its contents. It seems as though these terms may be able to joined. It may also allow expression of inertness over CSS rules with something like `container-visibility: inert`. The reason behind this is because when `HTMLDialogElement.showModal()` was implemented, none of the optimizations as we see in `container-visibility` were available at the time. All modern browsers (eg: Chrome, FireFox, Safari and Edge) all perform heavy restyle calculations on `#document`. This is likely because `inert` will update interactive elements as `:disabled`. This causes real-world implementation of `HTMLDialogElement.showModal()` to be questionable. If `showModal()` will guarantee frame drops on average sized DOM heavy pages on average consumer devices, then it's unlikely to be adopted in practice. If browsers are to target this performance issue, being able to use the already optimized procedure of `container-visibility` may prove helpful. The challenges between both are figuring things such as: * Are inert elements hidden from accessibility or not? If they are, then hidden containments share this as well. See: https://github.com/whatwg/html/issues/7796 * Should inert elements have explicitly skip tab-order? * If find-in-page not being available for `content-visiblity: hidden` is a requirement, should it also be a requirement of `inert`, instead of its current state of optional? * Inert enforces a disabled state for certain elements. Should this also apply to elements inside hidden containments (which aren't focusable or selectable by spec)? If an interactive element is within a hidden containment, how does a dev detect this over JS, if at all? Some solutions: * Relax inert to update elements as disabled (remove tree-walking) * Enforce [inert] to be reflected as an attribute, allowing CSS styles calculations * Create a new term for "not-focusable", "exclude from tab-order", "exclude from find-in-page" and have both `inert` and `css-contain` reference that. * Change nothing in spec and let each user agent decide best procedure for implementing `inert` optimally, if at all. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7703 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 6 September 2022 19:27:12 UTC