24983 2014-03-09 21:06:09 +0000 Making document parts inert without using <dialog> 2016-05-20 01:49:58 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED WONTFIX https://groups.google.com/d/msg/browser-accessibility-dev/QinGGM_OM7Y/FHpxY_qfBgAJ P3 normal Needs Impl Interest 1 jonas ian annevk d erikcharlebois ian jcraig mike w3 zcorpan contributor oldest_to_newest 102126 0 jonas 2014-03-09 21:06:09 +0000 What are the use cases for the inert attribute? I can't think of any UIs I've seen where someone grays out a subsection of a page. It does seem quite common to gray out everything *except* a section of a page, in order to do dialog-like things. But that's already handled by the <dialog> element. 102141 1 ian 2014-03-10 17:21:12 +0000 Looks like inert="" was added just so you could do <dialog> without <dialog>, so there's no compelling use case. I've removed it. 102142 2 contributor 2014-03-10 17:21:20 +0000 Checked in as WHATWG revision r8536. Check-in comment: Drop the inert='' attribute since its use case is subsumed by <dialog>. http://html5.org/tools/web-apps-tracker?from=8535&to=8536 102714 3 ian 2014-03-20 22:28:46 +0000 Ok, I've collected some use cases for something like inert="". 1. If, instead of dialog boxes, you use multiple sections of the page, but instead of making them display:none, you make them opacity:0, you still need a way to prevent them from getting focused (and, indeed, clicked, while they're transitioning from opacity:1 to opacity:0). 2. Sometimes you might want to disable the whole UI without showing a dialog, e.g. because you want to show a spinner but only want to show the spinner once the delay has taken more than 100ms. #1 could be done with straight inert="". #2 can actually be done with <dialog>.showModal(); just make the dialog transparent and empty. But that's pretty ugly. If we don't force it to be done that way, it would probably also need a way to "uninertify" subparts, e.g. a single "cancel" button. This could be faked pretty well with inert="", though it wouldn't be perfect (consider the viewport itself for example, or interactive children of the <body> if you want to make something non-inert in the body also). 102716 4 jonas 2014-03-20 23:37:41 +0000 How common are these use cases? Do you have example of websites that do #1? Arguably using CSS seems like a better solution so that a single class change can affect both the rendering and the inertness. For #2 it sounds like you want something that is the opposite of the inert attribute. I.e. something that makes the page inert except a subtree under a specific element. I'm not actually sure that <dialog>.showModal() is that wrong for #2 if you want cancel buttons to be in there. 103232 5 ian 2014-04-01 16:44:24 +0000 #1 is pretty common in any Web app that has multiple "pages" where they're all in the same HTML page and you transition between them. Pretty much any app I've written in the past few years, for example the one I mentioned to you in a recent e-mail. Maybe #2 is indeed a dialog. Not sure how you'd use CSS to remove something visible from the tab order, but in any case, that seems like it wouldn't work well in non-CSS UAs. 103244 6 jonas 2014-04-01 19:52:32 +0000 Doesn't display:none satisfy the "multiple pages" UI? I know find-as-you-type doesn't search such content, and it seems like tabbing should too if it doesn't already. 103473 7 ian 2014-04-07 15:41:23 +0000 The problem with display:none is that you can't do an animated transition to it. You really want the panel to be inert as soon as it starts fading. 105347 8 ian 2014-05-07 20:58:10 +0000 Another way of doing #2 would be to have a way to control the whole page's default state, inert vs non-inert, and then having an attribute which handles #1 and #2 by overriding the default state to inert or non-inert. So then showModal() would just be setting the default to inert and setting the dialog to override it as non-inert. #1 would be just marking parts inert. #2 would be manually setting the default and making whatever parts of the UI should still be interactive be non-inert. 105351 9 jonas 2014-05-07 21:26:15 +0000 I have to say that solving the use case of making content inert as it's animating away doesn't seem like a high priority. I'd rather wait to see if CSS provides a way to animate to/from display:none (something which would make authoring much simpler too) 105549 10 ian 2014-05-09 17:37:29 +0000 Interesting idea. Is there a bug tracking the ability to do that? It would certainly be interesting. (Though, we'd have to define that the elements were inert in that situation, too.) 109512 11 erikcharlebois 2014-07-29 18:29:12 +0000 A non-dialog application of inert: disabling blocks of form elements or other custom widgets. The standard form elements have the disabled attribute, but there's no equivalent for custom and composite controls. For example, I have a 'page slider' widget that's a composite widget of a page left button, a range (custom implemented with role="slider" for styling reasons) and a page right button. To put the widget in a disabled state with the same semantics as form elements, I need to set tabindex=-1 to all focusable subelements. What I do today is polyfill inert by swizzling tabindex in and out: https://gist.github.com/erikcharlebois/01441554fee9ff4156aa This is quite hacky (I'm sure I've missed some default focusable elements) and doesn't handle elements being added dynamically (I'll add MutationObserver support at some point I guess). I think it's important that inert is available as a building block for keyboard support in custom elements. 109513 12 jcraig 2014-07-29 18:44:52 +0000 Some more cases: 3. Inert section of a checkout form. For example, the entire shipping address section is inert/disabled while the "Same as billing address" checkbox is checked. Often I see these displayed side-by-side for UI clarity. 4. Stack/Carousel/Card view such as a "cover flow" type view. Each "card" has several interactive elements but only the front-most is useable at the moment. You can see a portion of the rendered-but-inert card to either side of the front-most card, or stacked up behind the front-most card, but you are not able to click on those or tab to any of the controls inside those views. I believe inert="" is a good solution for both of these use cases. 109514 13 jcraig 2014-07-29 18:48:51 +0000 (In reply to Ian 'Hixie' Hickson from comment #10) > Interesting idea. Is there a bug tracking the ability to [animate > to/from display:none]? It would certainly be interesting. (Though, we'd > have to define that the elements were inert in that situation, too.) I doubt this is supported well if at all, but it seems like this should already be possible by adding display:none to the last keyframe of an CSS animation. 111195 14 ian 2014-09-08 21:15:12 +0000 We have use cases, and several possible approaches to resolve them. Do we have vendor interest in addressing these use cases? 111394 15 zcorpan 2014-09-11 17:50:34 +0000 5) Emulating showModalDialog with inert + window.open + postMessage While <dialog> arguably covers this use case, it is a bigger change than window.open. 125556 16 annevk 2016-03-17 05:40:04 +0000 It seems there is no interest in an inert="" attribute. 125569 17 annevk 2016-03-18 20:18:16 +0000 Note https://github.com/whatwg/html/issues/897 for a new proposal at a slightly lower level of abstraction. 126467 18 w3 2016-05-20 01:49:58 +0000 I've been writing some web applications recently, and I find that I'm encountering use case #2 a lot, so I would find something like inert to be really useful. Some of the JavaScript APIs are asynchronous-only. If the user triggers an action that involves reading some JSON configuration info from a blob, or converting some data URLs to images so that they can be composited on a canvas, then I have to do the actions asynchronously even if they're fast. During that wait time, I don't want the user mucking around the UI causing things to get into an inconsistent state--essentially a race condition. The whole point of the single-threaded UI is to let normal programmers be able to reason through UI logic. But with the asynchronous calls, I'm finding that I'm not smart enough any more to program it. What if the user double-clicks the button, submitting the action twice? What if they trigger a complete rewrite of the view? Do I need to add if-statements to all my event handlers to check whether I'm doing something asynchronously? The dialog workaround is ok, but I don't actually want a dialog. At most, I just want to switch to an hourglass cursor since the wait is pretty short. Sure, I could use a transparent dialog or something like that, but that just seems like I'm abusing a mechanism to do something that it wasn't intended to do.