<dialog> element

[Alice Boxhall]

Does anyone know the current status of the <dialog> element in browsers other than Chrome?

• This is shipping by default in Chrome as of version 37 (https://www.chromestatus.com/features/5770237022568448).
• There is a Mozilla bug (https://bugzilla.mozilla.org/show_bug.cgi?id=840640) but I can't tell whether anyone is working on implementing it. Were there spec objections, or is it just a matter of it not having happened yet?
• Not clear what Microsoft's position is, but it has 356 votes as of right now on https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/6508895-dialog-element
• The chromestatus page links to this thread from WebKit: https://lists.webkit.org/pipermail/webkit-dev/2013-August/025357.html - I'm a little confused about why James Craig suggests that role=dialog is a reasonable alternative, since it has only a fraction of the functionality of <dialog>, unless I'm misunderstanding.

Thanks,

Alice

[Dominic Mazzoni]

I'd really love to hear from the folks on this list from Facebook, Twitter, etc. - would you use the <dialog> element if it was supported more widely? What if it also had a polyfill?

--
You received this message because you are subscribed to the Google Groups "Browser Accessibility Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to browser-accessibil...@googlegroups.com.
To post to this group, send email to browser-acce...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/browser-accessibility-dev/CAMQHGLychLzZ7URG200mW-_5e%2BV0hACZ5GQ_FE_Bxkr5EiTfFA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[David Bolter]

I don't think anyone is active on the Firefox bug unfortunately.

D

--

[David Bolter]

Yes, demand might help move things along.

D

To view this discussion on the web visit https://groups.google.com/d/msgid/browser-accessibility-dev/CAFz-FYxCU-G2C0_tkThHTeKcc5EfGQk5RUVX-hrxh6PfkWhQuQ%40mail.gmail.com.

[Marcy Sutton]

Both Adobe and the Angular team would use it if it were more widely supported. If there was a good standard polyfill, that would definitely help!

[Marco Zehe]

Hi all,

the first step for the <dialog> element to be supported is to properly specify it, IMO. The last time I checked, which was for my latest WAI-ARIA tip on my blog about exactly this topic, the spec was a mess, to put it mildly.

Marco

--
You received this message because you are subscribed to the Google Groups "Browser Accessibility Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to browser-accessibil...@googlegroups.com.
To post to this group, send email to browser-acce...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/browser-accessibility-dev/063ae6ca-1f71-46a3-b886-e37bf2f4dcd8%40googlegroups.com.

[Victor Tsaran]

Sorry for playing a devil's advocate, but what is the likelihood that 3rd-party developers don't turn on their nose on the native implementation the way they do with other native HTML5 stuff?

Anything beyond basic buttons is usually rewritten with custom implementations and patched up with ARIA.

Please note, I am not complaining or judging anyone here, just trying to be pragmatic...

2 cents.

Victor

To view this discussion on the web visit https://groups.google.com/d/msgid/browser-accessibility-dev/CAL%3DZazh6E%3D86QuHXmypXwyYcsoawf-u39FuTuW-EKy7ut1OM9Q%40mail.gmail.com.

[Domenic Denicola]

From: browser-acce...@googlegroups.com [mailto:browser-acce...@googlegroups.com] On Behalf Of Victor Tsaran

> Sorry for playing a devil's advocate, but what is the likelihood that 3rd-party developers don't turn on their nose on the native implementation the way they do with other native HTML5 stuff?
> Anything beyond basic buttons is usually rewritten with custom implementations and patched up with ARIA.
> Please note, I am not complaining or judging anyone here, just trying to be pragmatic...

I've thought about this question too, and I am at least a little optimistic in that <dialog> is 100% styleable, unlike every other control in browsers today. I can't find any aspect of it that isn't customizable, really.

[Alice Boxhall]

I just had a chat with Rob Dodson, and he raised some good points

- <dialog> implies a certain role, and while it's possible to override that role (e.g. <dialog role=menu>), it seems a bit misleading to create a semantic element only to admit that its semantics don't always make sense

- `inert` is less opinionated, but is a pain to use: you have to set it on everything _but_ the thing you want to be modal, and if you don't have the modal thing as a sibling of the main content this means a big tree walk (just ask Marcy) - plus you can't set it on any ancestor of the modal element.

It sounds like what we really need here is simply an attribute called something like `modal`, which works like <dialog> but can be used on any element and doesn't imply a role of 'dialog'. This could also explain how <dialog> works.

Thoughts? Objections?

[annevk]

On Wednesday, August 19, 2015 at 9:44:19 PM UTC+2, Alice Boxhall wrote:

- `inert` is less opinionated, but is a pain to use: you have to set it on everything _but_ the thing you want to be modal, and if you don't have the modal thing as a sibling of the main content this means a big tree walk (just ask Marcy) - plus you can't set it on any ancestor of the modal element.

What do you mean? You can't "use" inert, it's just a concept used to explain behavior.

What is the role <dialog> implies?

[Alice Boxhall]

I was referring to the now-defunct "inert" attribute, e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=921504

What is the role <dialog> implies?

http://www.w3.org/TR/2009/WD-wai-aria-20091215/roles#dialog

"A dialog is an application window that is designed to interrupt the current processing of an application in order to prompt the user to enter information or require a response." 

--
You received this message because you are subscribed to the Google Groups "Browser Accessibility Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to browser-accessibil...@googlegroups.com.
To post to this group, send email to browser-acce...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/browser-accessibility-dev/179a8c94-da18-4334-998b-97f7c89e5860%40googlegroups.com.

[Anne van Kesteren]

On Thu, Aug 20, 2015 at 6:56 PM, Alice Boxhall <abox...@chromium.org> wrote:
> I was referring to the now-defunct "inert" attribute, e.g.
> https://bugzilla.mozilla.org/show_bug.cgi?id=921504

Oh I see, as a potential alternative to <dialog>. Thank you.

I don't think either inert="" or modal="" are great. Global attributes
are very complex as you have to figure out their behavior for each
individual element. A dedicated element like <dialog> is much easier
to implement and support correctly. This is e.g., why we moved away
from something like <object> and towards <audio> and <video>.


--
https://annevankesteren.nl/

[Nektarios Paisios]

I don't think either inert="" or modal="" are great. Global attributes
are very complex as you have to figure out their behavior for each
individual element. A dedicated element like <dialog> is much easier to
implement and support correctly. This is e.g., why we moved away from
something like <object> and towards <audio> and <video>.

Don't we need to determine the behavior of role="dialog" for every
element, since it can be placed on any element and not only on <div>? Or
is <button role="dialog"> not supported.
Nektarios.

[Alice Boxhall]

On Thu, Aug 20, 2015 at 10:17 AM, 'Nektarios Paisios' via Browser Accessibility Development <browser-acce...@googlegroups.com> wrote:

I don't think either inert="" or modal="" are great. Global attributes are very complex as you have to figure out their behavior for each individual element. A dedicated element like <dialog> is much easier to implement and support correctly. This is e.g., why we moved away from something like <object> and towards <audio> and <video>.
Don't we need to determine the behavior of role="dialog" for every element, since it can be placed on any element and not only on <div>? Or is <button role="dialog"> not supported.

Quick clarification: we're talking about the <dialog> element rather than the ARIA dialog role. I can understand the confusion given I was talking about the implicit role a moment ago!

 

Nektarios.

--
You received this message because you are subscribed to the Google Groups "Browser Accessibility Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to browser-accessibil...@googlegroups.com.
To post to this group, send email to browser-acce...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/browser-accessibility-dev/55D60BA9.5000108%40google.com.

[Alice Boxhall]

That's a good point - `<button modal>` would be pretty weird.

However, we still have the issue that `<dialog>` only works for a subset of use cases, and developers working on other use cases need to either override the semantics of <dialog> (which as Victor pointed out is unlikely to happen - why would you think of using <dialog> to implement a modal menu?) or roll their own UI (in which case they invariably only consider pointing devices and leave keyboard and assistive technology users out in the cold until v1.1 or later).

 

--
https://annevankesteren.nl/

--
You received this message because you are subscribed to the Google Groups "Browser Accessibility Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to browser-accessibil...@googlegroups.com.
To post to this group, send email to browser-acce...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/browser-accessibility-dev/CADnb78j9eo9_rRYoqK5JTe6yzRUys6FPPksoXD8Hi3RLyPZFzQ%40mail.gmail.com.

[Anne van Kesteren]

On Thu, Aug 20, 2015 at 7:42 PM, Alice Boxhall <abox...@chromium.org> wrote:
> However, we still have the issue that `<dialog>` only works for a subset of
> use cases, and developers working on other use cases need to either override
> the semantics of <dialog> (which as Victor pointed out is unlikely to happen
> - why would you think of using <dialog> to implement a modal menu?) or roll
> their own UI (in which case they invariably only consider pointing devices
> and leave keyboard and assistive technology users out in the cold until v1.1
> or later).

We could update the specification to list more use cases, examples,
and make a modal menu a kind of dialog, "semantically". We have quite
a lot of freedom there.


--
https://annevankesteren.nl/

[Alice Boxhall]

I still don't think this solves the whole problem.

None of this changes the fact that the well-established semantic meaning of "dialog" does not apply well to all of these cases. We can't post-hoc change the semantic meaning of things - a menu is not a dialog, and pushing for using <dialog> in this way is only going to cause more problems when people (inevitably) leave off the ARIA roles. Plus, I suspect that the semantic mis-match is going to put people off using <dialog> in this way in general, regardless of what the spec says.

Moreover, there is an issue when people are trying to create custom elements - there is no way to express modality/inertness without using a <dialog> (or any other more specific semantic elements we come up with, if we did go down that road), so people wouldn't be able to create custom elements which have the same behaviour without having to, at best, create a meaningless container around the dialog itself.

Thanks,

Alice

[Anne van Kesteren]

On Fri, Aug 21, 2015 at 10:32 PM, Alice Boxhall <abox...@chromium.org> wrote:
> None of this changes the fact that the well-established semantic meaning of
> "dialog" does not apply well to all of these cases. We can't post-hoc change
> the semantic meaning of things

Why not? See how we changed <dl>. Semantics don't mean much, all that
matters is what effect elements have.

> - a menu is not a dialog, and pushing for
> using <dialog> in this way is only going to cause more problems when people
> (inevitably) leave off the ARIA roles.

I guess I need to see this modal menu in action since it's not
actually clear to me what such a thing is and how it's different from
a modal dialog.

> Plus, I suspect that the semantic
> mis-match is going to put people off using <dialog> in this way in general,
> regardless of what the spec says.

I don't know, folks tend to use <em> and <strong> for everything that
requires italics and bold.

> Moreover, there is an issue when people are trying to create custom elements
> - there is no way to express modality/inertness without using a <dialog> (or
> any other more specific semantic elements we come up with, if we did go down
> that road), so people wouldn't be able to create custom elements which have
> the same behaviour without having to, at best, create a meaningless
> container around the dialog itself.

Yeah, this is the same problem we have with form controls. We need a
way to expose features to classes/subclasses without exposing them to
directly to markup. You wouldn't want to require a global modal=""
attribute for your custom element. That'd be rather ugly. You'd want
that to be built-in and unobservable.


--
https://annevankesteren.nl/

[Rob Dodson]

I guess I need to see this modal menu in action since it's not
actually clear to me what such a thing is and how it's different from
a modal dialog.

Here's an example. Click the menu button in the top right of the screen and a drawer slides out which covers part of the page and fades the background.

To address Victor's point:

Sorry for playing a devil's advocate, but what is the likelihood that 3rd-party developers don't turn on their nose on the native implementation the way they do with other native HTML5 stuff?
Anything beyond basic buttons is usually rewritten with custom implementations and patched up with ARIA.
Please note, I am not complaining or judging anyone here, just trying to be pragmatic...

Trapping tab focus and the screenreader can be tricky depending on how your app is built. If your modals are mixed in with the rest of your main content you have to sprinkle aria-hidden's around the page to hide everything except your modal. Because a 3rd party developer doesn't know the structure of your app, they would need to crawl the DOM and apply aria-hidden attributes all over the page (I believe this is what the Angular Material Design dialog does, right Marcy?) Having the inverse behavior is incredibly beneficial. You can just say "this one thing is a modal" and suddenly the whole page behaves the right way. I think anyone who knew about the tradeoff would opt for the latter behavior if they could.

[Victor Tsaran]

I agree with you, Robert.

Perhaps the issue is then more about enforcing the modality on a number of widgets, not just dialogs. The word "dialog" has certain associations with it. I often hear from designers things like, "well, you know, it's not really a dialog", and then I have to go into lengthy explanations about the necessity of mapping their widget semantics to the roles that AT understands, and so on and so forth.

And designers are not entirely incorrect because these days traditional dialogs are used less and less.

Similarly, I could see other widgets benefiting from native browser modality, for example, menus, tab panels, radiogroups, etc. In some instances, the modality would have to be enforced for arrow keys, in others for the tab/shift+tab, yet in others for both.

I don't feel like proposing yet another ARIA attribute, but the behavior would have to be standardized in some way.

[Domenic Denicola]

From: Anne van Kesteren [mailto:ann...@annevk.nl]

> Yeah, this is the same problem we have with form controls. We need a way to expose features to classes/subclasses without exposing them to directly to markup. You wouldn't want to require a global modal="" attribute for your custom element. That'd be rather ugly. You'd want that to be built-in and unobservable.

+9001.

I imagine this group is traditionally used to looking for solutions in HTML. New elements, new attributes, new global attributes.

That is not an appropriate path forward. We need to expose the actual primitives, in ways that can be composed, reused, and mixed in, to the classes and subclasses that are part of library-defined widget libraries.

[Rob Dodson]

We need to expose the actual primitives, in ways that can be composed, reused, and mixed in, to the classes and subclasses that are part of library-defined widget libraries.

I'm cool with this as well. I think Alice and I started this discussion looking at dialog and thinking "well, if we just dig a little deeper, what we actually want is this magical behavior, then we could use it for lots of different components". We came up with the idea of an attribute, but if it's easier to dig even deeper and have this expressed as some other primitive (I'm guessing you mean in JavaScript?) then I think that's fine. The goal remains the same, let's help developers add this awesome behavior to their components so a11y across the web can get a nice boost.

So how do we expose such a primitive?

  

[Marcy Sutton]

Totally agree with the need for actual primitives.

On the topic of modals, including dialogs, overlays and popup menus, here are some things developers need built-in so we aren't reinventing them over and over and over:

• Inertness. The goal is to prevent interaction behind the modal, particularly with a keyboard and/or screen reader. As Alice and Rob mentioned, if a dialog-like element is inserted into the DOM anywhere but just inside the body, it requires managing `aria-hidden` by walking the DOM and keeping a clear path all the way up to the body, in addition to trapping focus with JS events or by modifying `tabindex` for every focusable element on the page. It's a pain, and likely to be left out or done wrong. 
  
  
• Focus management. Any native solution should handle focus on open and close.
  
  
• Role/Semantics. This will depend on what kind of UI pattern it is. We have all been hanging our hats on `<dialog>`, but that is only one kind of modal–there are also lightboxes/overlays, popup menus, sliding sidenavs and probably a bunch of other things that aren't alert or confirm dialogs. Perhaps a primitive for the modal window is needed, apart from the dialog or menu UI? 

There's probably more to consider here, just wanted to chime in. 

-Marcy

[Domenic Denicola]

From: Rob Dodson [mailto:robd...@google.com]

> So how do we expose such a primitive?

Marcy's email did a good job starting to separate out the primitives. It's also fruitful to look at the spec as-is [1], and say, "which of these concepts can I not participate in?"

For example, it looks like dialog's positioning is explicitly magical, in that it anchors to the element you show it at [2]. So one primitive would be the ability to anchor one element to another in similar ways, presumably some kind of function that takes two elements.

The centered alignment mode also uses the concept of "top layer", defined in [3]. A primitive might be allowing more direct access to the ordered set of elements in the top layer, so that you can do the same thing dialog does (which is actually quite a lot, layout-wise; see [4]).

What I'm seeing a lot of interest in in this thread is the specific piece of magic "blocked by the modal dialog" [5]. The primitive here is, at least in spec terms, fairly simple: at its simplest it's just something like `document.setBlockingElement(el)`. You could of course design that API in a variety of ways, some of which might be more user-friendly: for example, perhaps you want a stack of blocking elements, so that when one becomes un-blocking the next in the stack takes over. (Could be useful for nested modal menus!) But I think at its core, the primitive is just that.

There's also the issue of the "dialog focusing steps" [6]. It's not clear to me whether these use anything you can't already do---I haven't traced all the definitions down yet. But maybe they argue for easier focus-related functionality, such as isControlGroupOwner(el), isInert(el), or findChildControlToFocus(el).

As a counterexample, the "pending dialog stack" concept looks like a non-primitive. If you were given "blocked by the modal dialog", plus the ability to manipulate the top layer, you could implement such a stack yourself. (Although, maybe you'd want the browser to control such a "pending modals stack" for you, in order to avoid coordination issues...)

From: Marcy Sutton [mailto:ho...@marcysutton.com]

> Role/Semantics. This will depend on what kind of UI pattern it is. We have all been hanging our hats on `<dialog>`, but that is only one kind of modal–there are also lightboxes/overlays, popup menus, sliding sidenavs and probably a bunch of other things that aren't alert or confirm dialogs. Perhaps a primitive for the modal window is needed, apart from the dialog or menu UI?

I am not an expert in this area, but my understanding is that the technical issue here is largely about "what can we get accessibility technologies to announce?" For example, [7] explains how to map all existing HTML elements to specific constants used by popular accessibility software. There, we see that MSAA and ATK have specific dialog constants (ROLE_SYSTEM_DIALOG, and ATK_ROLE_DIALOG), so presumably they announce to their users that they are in a dialog, or similar. Whereas, UIA and AX do not have any such constants, and so there is no appropriate mapping.

If my understanding is correct, then I think the question here becomes, what other un-exposed accessibility software role constants are there? Are there ones for modal popup menus? Modal sliding sidenavs? Etc.? If so then we definitely would want to expose them---through role="...", if nothing else, although eventually we should allow custom elements to have built-in roles without the sprouting attributes.


[1]: https://html.spec.whatwg.org/multipage/forms.html#the-dialog-element
[2]: https://html.spec.whatwg.org/multipage/forms.html#set-up-the-position
[3]: https://fullscreen.spec.whatwg.org/#top-layer
[4]: https://fullscreen.spec.whatwg.org/#characteristics
[5]: https://html.spec.whatwg.org/multipage/interaction.html#blocked-by-a-modal-dialog
[6]: https://html.spec.whatwg.org/multipage/forms.html#dialog-focusing-steps
[7]: https://w3c.github.io/aria/html-aam/html-aam.html#html-element-role-mappings

[Dominic Mazzoni]

On Mon, Aug 24, 2015 at 4:59 PM, Domenic Denicola <d...@domenic.me> wrote:

What I'm seeing a lot of interest in in this thread is the specific piece of magic "blocked by the modal dialog" [5]. The primitive here is, at least in spec terms, fairly simple: at its simplest it's just something like `document.setBlockingElement(el)`. You could of course design that API in a variety of ways, some of which might be more user-friendly: for example, perhaps you want a stack of blocking elements, so that when one becomes un-blocking the next in the stack takes over. (Could be useful for nested modal menus!) But I think at its core, the primitive is just that.

I agree, from an accessibility perspective that's the "killer feature" of the dialog element.

The problem with a JavaScript API on the document object is that it affects the default behavior of the DOM so much, I feel like it needs a declarative API so that users can debug it using Dev Tools, write HTML snippets to play with that don't require inline scripting, etc. I wonder if we could just let any element have a level associated with it, with the default being level=0. At any time, only the highest level present in the DOM and its subtree is active; anything that's part of a lower level is inert.

There's also the issue of the "dialog focusing steps" [6]. It's not clear to me whether these use anything you can't already do---I haven't traced all the definitions down yet. But maybe they argue for easier focus-related functionality, such as isControlGroupOwner(el), isInert(el), or findChildControlToFocus(el).

In comparison, finding the right control to focus is relatively trivial for authors to implement, so maybe not as important.

> Role/Semantics. This will depend on what kind of UI pattern it is. We have all been hanging our hats on `<dialog>`, but that is only one kind of modal–there are also lightboxes/overlays, popup menus, sliding sidenavs and probably a bunch of other things that aren't alert or confirm dialogs. Perhaps a primitive for the modal window is needed, apart from the dialog or menu UI?

I am not an expert in this area, but my understanding is that the technical issue here is largely about "what can we get accessibility technologies to announce?" For example, [7] explains how to map all existing HTML elements to specific constants used by popular accessibility software. There, we see that MSAA and ATK have specific dialog constants (ROLE_SYSTEM_DIALOG, and ATK_ROLE_DIALOG), so presumably they announce to their users that they are in a dialog, or similar. Whereas, UIA and AX do not have any such constants, and so there is no appropriate mapping.

That spec is incomplete. AX has NSAccessibilityDialogSubrole and UIA uses the "Window" control type plus IWindowProvider.IsModal.

In my opinion, this isn't the major technical challenge. We have a fair number of roles now - for dialogs, menus, and so on - and they all get mapped to appropriate platform-specific native attributes that trigger the right screen reader announcements. What's challenging right now is to make it actually modal - i.e. to convey to the user that only this dialog is active and the rest of the page is hidden behind it.

[Domenic Denicola]

From: Dominic Mazzoni [mailto:dmaz...@google.com]

> The problem with a JavaScript API on the document object is that it affects the default behavior of the DOM so much, I feel like it needs a declarative API so that users can debug it using Dev Tools, write HTML snippets to play with that don't require inline scripting, etc.

I don't really understand this reasoning. The same argument could be made against fullscreen capabilities. And there's nothing wrong with inline scripting.

> I wonder if we could just let any element have a level associated with it, with the default being level=0. At any time, only the highest level present in the DOM and its subtree is active; anything that's part of a lower level is inert.

This is a different model than the one that exists for dialog, and doesn't reflect what's actually going on. There's only a single blocking element, and that should be reflected in the API.

What you can do if you find this kind of API appealing is write a library that uses mutation observers to listen for changes in the data-modal-level attribute on all elements, and uses that to call document.setBlockingElement. Having that functionality in a library, instead of making the browser do this extra work, seems more appropriate. This leaves the imperative API as the building block that custom element authors and similar can use, without having to decorate themselves with an attribute.

[Dominic Mazzoni]

On Tue, Aug 25, 2015 at 1:44 PM Domenic Denicola <d...@domenic.me> wrote:

From: Dominic Mazzoni [mailto:dmaz...@google.com]

> The problem with a JavaScript API on the document object is that it affects the default behavior of the DOM so much, I feel like it needs a declarative API so that users can debug it using Dev Tools, write HTML snippets to play with that don't require inline scripting, etc.

I don't really understand this reasoning. The same argument could be made against fullscreen capabilities. And there's nothing wrong with inline scripting.

Chrome apps and extensions don't allow inline scripting, for example. But I don't want to dwell on this point; I care most about solving the problem and if a JavaScript API is the best, that's okay.

 

> I wonder if we could just let any element have a level associated with it, with the default being level=0. At any time, only the highest level present in the DOM and its subtree is active; anything that's part of a lower level is inert.

This is a different model than the one that exists for dialog, and doesn't reflect what's actually going on. There's only a single blocking element, and that should be reflected in the API.

Well, the dialog element has a pending dialog stack. It seems to me like every one of the use-cases suggested (dialogs, menus, etc.) would want some sort of similar stack - so I think it should be part of the spec rather than requiring authors to implement that themselves.

It's possible to write an accessible dialog now, it's just cumbersome and tricky to get right. Adding support for a blocking element without the ability to keep them on a stack to support nested dialogs seems like it wouldn't solve enough use-cases.

What you can do if you find this kind of API appealing is write a library that uses mutation observers to listen for changes in the data-modal-level attribute on all elements, and uses that to call document.setBlockingElement. Having that functionality in a library, instead of making the browser do this extra work, seems more appropriate. This leaves the imperative API as the building block that custom element authors and similar can use, without having to decorate themselves with an attribute.

I understand you could implement support for an attribute on top of this API using mutation observers. That's fine.

But I think nested dialogs / overlays is so common that it'd be crazy to not support that case. What about document.pushBlockingElement and popBlockingElement or something like that?

[Domenic Denicola]

From: Dominic Mazzoni [mailto:dmaz...@google.com]

> Well, the dialog element has a pending dialog stack. It seems to me like every one of the use-cases suggested (dialogs, menus, etc.) would want some sort of similar stack - so I think it should be part of the spec rather than requiring authors to implement that themselves.

Right, I touched on this a bit a couple messages ago. But that last leap is tricky. Every time you make a decision like that for developers, moving away from the primitives, you are closing off choice, making a decision that might turn out to be wrong and preclude other use cases.

For example, should we have one big stack, or separate stacks for each type of thing? (Maybe so that all dialogs should be higher in the stack at all times than modal sidebar menus?) Should the stack API allow "stack jumping" to the bottom of the stack, or is it strictly LIFO, so that you can only put things on the top? Should you be able to un-inert the top of the stack temporarily, without actually popping off the entire stack?

It's a balance, of course. I lean toward giving people the primitive and letting them make decisions like this. It's not hard to build a stack in JS, after all. But there's definitely an argument in favor of building systems that enhance coordination by making everyone abide by the browser's decisions. If we go that route I'd suggest keeping it simple so that this doesn't get hung up forever designing the perfect coordination system. So I'd suggest one big stack, strictly LIFO, only push/pop supplied.

> But I think nested dialogs / overlays is so common that it'd be crazy to not support that case. What about document.pushBlockingElement and popBlockingElement or something like that?

Yeah, sounds good. You probably also want `document.blockingElement` getter so that code can tell whether there is currently a blocking element.

Another (even more restrictive) is to disallow popping the blocking element unless you are the one that pushed it; something like `const pop = document.pushBlockingElement(el)` where now the only way to pop the element is to call `pop()`, i.e. there is no global `document.popBlockingElement()`. This can avoid code that does something like `while (document.blockingElement) { document.popBlockingElement(); }`, which might be seen as unfriendly if the goal of this more restrictive API is to enhance coordination.

[Alice Boxhall]

On Tue, Aug 25, 2015 at 11:33 PM, Domenic Denicola <d...@domenic.me> wrote:

From: Dominic Mazzoni [mailto:dmaz...@google.com]

> Well, the dialog element has a pending dialog stack. It seems to me like every one of the use-cases suggested (dialogs, menus, etc.) would want some sort of similar stack - so I think it should be part of the spec rather than requiring authors to implement that themselves.

Right, I touched on this a bit a couple messages ago. But that last leap is tricky. Every time you make a decision like that for developers, moving away from the primitives, you are closing off choice, making a decision that might turn out to be wrong and preclude other use cases.

For example, should we have one big stack, or separate stacks for each type of thing? (Maybe so that all dialogs should be higher in the stack at all times than modal sidebar menus?) Should the stack API allow "stack jumping" to the bottom of the stack, or is it strictly LIFO, so that you can only put things on the top? Should you be able to un-inert the top of the stack temporarily, without actually popping off the entire stack?

It's a balance, of course. I lean toward giving people the primitive and letting them make decisions like this. It's not hard to build a stack in JS, after all. But there's definitely an argument in favor of building systems that enhance coordination by making everyone abide by the browser's decisions. If we go that route I'd suggest keeping it simple so that this doesn't get hung up forever designing the perfect coordination system. So I'd suggest one big stack, strictly LIFO, only push/pop supplied.

This sounds reasonable to me.

> But I think nested dialogs / overlays is so common that it'd be crazy to not support that case. What about document.pushBlockingElement and popBlockingElement or something like that?

Yeah, sounds good. You probably also want `document.blockingElement` getter so that code can tell whether there is currently a blocking element.

If they can't do anything much with the blocking element (per below), perhaps it makes more sense to expose a read-only 'inert' property (as opposed to attribute) on elements? In Blink, at least, this is already available on the Node API: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/dom/Node.h&q=inert%5C(%5C)&sq=package:chromium&type=cs&l=413

Another (even more restrictive) is to disallow popping the blocking element unless you are the one that pushed it; something like `const pop = document.pushBlockingElement(el)` where now the only way to pop the element is to call `pop()`, i.e. there is no global `document.popBlockingElement()`. This can avoid code that does something like `while (document.blockingElement) { document.popBlockingElement(); }`, which might be seen as unfriendly if the goal of this more restrictive API is to enhance coordination.

This is definitely worth considering. I'd be interested to hear others' opinions on this idea.

--
You received this message because you are subscribed to the Google Groups "Browser Accessibility Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to browser-accessibil...@googlegroups.com.
To post to this group, send email to browser-acce...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/browser-accessibility-dev/CY1PR0501MB13691AD105C54EAB8796FFA5DF610%40CY1PR0501MB1369.namprd05.prod.outlook.com.

[Domenic Denicola]

From: abox...@google.com [mailto:abox...@google.com] On Behalf Of Alice Boxhall

>> Yeah, sounds good. You probably also want `document.blockingElement` getter so that code can tell whether there is currently a blocking element.
>
> If they can't do anything much with the blocking element (per below), perhaps it makes more sense to expose a read-only 'inert' property (as opposed to attribute) on elements? In Blink, at least, this is already available on the Node API: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/dom/Node.h&q=inert%5C(%5C)&sq=package:chromium&type=cs&l=413

Hmm, I think both could be useful. But I think neither is necessarily part of an MVP. So I guess until we see more code that would use either, it's hard to say which would be better. Maybe you had some such code in mind.