Add a native dialog element to deprecate the jQuery UI dialog

Why not first introduce a new dialog API based on native dialog element? We don't have to drop all jQuery UI usage in the same patch.

Native dialog is not supported on Safari still https://caniuse.com/dialog

Native dialog is not supported on Safari still https://caniuse.com/dialog

That's not what I'm seeing, perhaps I'm overlooking something?

I was wrong, so only default styling prevents the issue

Adding WCAG SC 3.2 5.

fwiw two elements seems like a good approach here, then we can switch things over in core and deprecate the jQuery UI version. It would be more like 'Add a native dialog element', 'Use the native dialog element', 'Deprecate the jQuery UI dialog'.

Late to the party here but agree with the approach in #78, came looking for this after watching IO videos and realising we no longer need the polyfill 🎉

I've tried updating the issue summary and title, it's a bit tricky since there's a fair amount of change of direction in this issue over time.

Just to expand on #78, by providing a new element, I think we should completely ignore bc for anything jQuery UI provides, whether it's the js API or markup. We will need to figure out styling in Claro/Olivero/Umami which is probably the main bit of work this creates compared to the previous approaches.

I created a new fork and did a bit of work on this – it's a rough WIP but there's a few native dialogs now :) (added 2 screenshots)
- created a new library dialogNative with the idea to have both in parallel and switch over bit by bit
- changed editor and field_ui to use the new library:
editor: on a wysiwyg field, change the text format between basic_html and full_html
field_ui: on a content type, manage fields and attempt to delete one
in both cases a native dialog should pop up and the buttons should work

Notes/questions/next steps
- The existing Drupal.dialog.showModal() and the native showModal() function have the same name, which gets slightly confusing.
- showModal() and show() seem to be doing mostly the same thing, just one with and one without backdrop? What did I miss?
- Atm I've just set app/core/lib/Drupal/Core/Render/MainContent/DialogRenderer.php and app/core/lib/Drupal/Core/Render/MainContent/ModalRenderer.php to use the new native library but if we want both in parallel, this probably needs another solution. Too backend-y for me.
- Currently ajax response data is just put out again as is, this probably needs some checks.
- There's currently nothing for focus, tabbable, or the whole button change thing, I assume we need some of that back in.
- Needs tests
- Needs styling

showModal() and show() seem to be doing mostly the same thing, just one with and one without backdrop?

They have different use cases. Modal dialog requires user action. It blocks interaction with other parts of the page. Also keyboard navigation is captured within a dialog.

Very cool to see work on this again!

1. - The existing Drupal.dialog.showModal() and the native showModal() function have the same name, which gets slightly confusing.

   That was intended, sort of like there shouldn't be an intermediate API between Drupal and the dialog API. Drupal.dialog() should just return the native dialog DOM element. The return of the Drupal.dialog() function was made to mimick the native dialog DOM API. So something along the lines of the following should be enough:

   Drupal.dialogNative = function () {
     return createDialog(element, settings);
   }

   We can figure out events later (if needed), maybe we won't need them since we'll need to call attachbehaviors somehow on the dialog contents and contrib should need to worry whether the content is in a modal or on a page. We had to do that before since jQuery has a lot of options that can be set, but that is not the case for native dialogs.

2. - showModal() and show() seem to be doing mostly the same thing, just one with and one without backdrop? What did I miss?

   yep, same-ish. When openning a modal the rest of the content is not supposed to be "interactable": https://html.spec.whatwg.org/multipage/interaction.html#blocked-by-a-mod...

3. - Atm I've just set app/core/lib/Drupal/Core/Render/MainContent/DialogRenderer.php and app/core/lib/Drupal/Core/Render/MainContent/ModalRenderer.php to use the new native library but if we want both in parallel, this probably needs another solution. Too backend-y for me.

   That's ok, just need a way to test things out for now :)

4. - Currently ajax response data is just put out again as is, this probably needs some checks. see the original Drupal.AjaxCommands.prototype.openDialog function. it uses the insert command to add html to the dialog so that behaviors are run automatically and all.
5. - There's currently nothing for focus, tabbable, or the whole button change thing, I assume we need some of that back in. I'd test as-is for now. Seem like the focus is handled automatically by browsers and set it back to the triggering element when closing, probably nothing too bad to fix.

Make sense to have a look in `inert` html attribute https://html.spec.whatwg.org/multipage/interaction.html#the-inert-attribute to improve keyboard navigation

Hello all!

I want to propose another approach that seems reasonable to me.
One of the main problems with the current implementation of the dialog in Drupal is the strong binding to jQueryUI styles and markup. This leaves the developer with few options, such as changing the order of dialog elements or adding new elements to the markup.

Currently, browser support for Web Components is the same as Drupal. https://developer.mozilla.org/en-US/docs/Web/API/Web_components

This way we can create a web component drupal-dialog which will
1. Create events when opening and closing.
2. Have an extremely flexible template, easily customizable via Drupal.theme.dialogTemplate
3. Support custom CSS properties
4. Save element styles in dialog slots. Example with claro buttons: https://gyazo.com/b8cb363cb5854415f0b023dcbf5d7fd1

This merge request is quite crude, but it does give some insight into the future benefits of this approach.

Currently tested is the confirmationDialog for changing the text format on the node edit page. For the test, add content to restricted HTML and change the format to basic. https://gyazo.com/e7a6f36d8b8e96e0f7719efdbeddfed9

Please review, Thanks!

Thanks, #88 might be combined with https://caniuse.com/dialog
How can we proceed here and make the required decisions?

@Anybody

This drupal-dialog already contains HTML dialog inside.

I think the rework order should be as follows. We have to:

1. collect all usage of https://api.jqueryui.com/dialog/ API in the core.
2. Make a list of options, events and methods that the new component should/can support.
3. Write a temporary Drupal.DialogComponent that will provide this API and gradually switch Drupal to use the new component. Rewrite tests. And so on

I think the way forward here is what was agreed above by nod_ - start with an implementation that is based of a native dialog element and has less features than jQueryUI, add that alongside the jquery UI one and deprecate it.

If there are missing features, we can look to implement them in follow up issues, otherwise we risk making no progress at all.

I would encourage you to open a new issue @finnsky listing the features that native dialog doesn't provide that we may need to consider once we have a working alternative.

Added subtask
https://www.drupal.org/project/drupal/issues/3390549 📌 Get rid of jQuery in dialog events. Needs review

Current Functional Javascript Test failure seems related to core/modules/block/js/block.js:139
Not to this MR

Hi gang, I thought I had commented here, but it looks like I haven't.

I worked on an idea for replacing some of the behaviors of the off-canvas dialog with the Popover Api. Firefox still doesn't have a full implementation but hides it behind a flag.

https://www.loom.com/share/0dde75887f884ff3be3e4980601dccb9?sid=72085fcf...

@rkoller & I were talking. This advent calendar article came up You don't need JavaScript for that. Most browsers support the dialog element now.

Not that this would be a trivial shift, but it does seem like this might be a good time to consider it.

For sure jQuery UI dialog becaime one of the most annoying things when handling the (on the other hand) super useful and genius use-ajax class functionality.

This is definitely something we (the community) should push forward! Totally agree and changed the title accordingly.

OK, to summarize the current state of this issue, it seems, that we agreed on using the native "dialog" element through adding an additional js library called "dailogNative". And slowly but surely deprecated the use of the jquery "dialog" library in the future. @TinaRey created a first draft with many of the required changes implemented ( see MR !4187, great work btw!). @catch and @larowlan agree with that approach in #78 and #79 respectively, and many others suggest a similar approach.

MR !397 by @bnjmnm and @_node is quite impressive but replaces the library instead of adding a new one. We might be able to use some of the for MR !4187

The web-component approach by @finnsky also looks very promising. But should be added on top of the native dialogue library in a follow-up issue (if I understood that correctly).

I guess we can close these two MRs then for visibility’s sake and solely focus on MR !4187.

Reposting questions by @TinaRey in comment #83 📌 Add a native dialog element to deprecate the jQuery UI dialog Needs work

• The existing Drupal.dialog.showModal() and the native showModal() function have the same name, which gets slightly confusing.
• showModal() and show() seem to be doing mostly the same thing, just one with and one without backdrop? What did I miss?
• Atm I've just set app/core/lib/Drupal/Core/Render/MainContent/DialogRenderer.php and app/core/lib/Drupal/Core/Render/MainContent/ModalRenderer.php to use the new native library but if we want both in parallel, this probably needs another solution. Too backend-y for me.
• Currently ajax response data is just put out again as is, this probably needs some checks.
• There's currently nothing for focus, tabbable, or the whole button change thing, I assume we need some of that back in.
• Needs tests
• Needs styling

A few of these questions were already answered by @_node in #85 📌 Add a native dialog element to deprecate the jQuery UI dialog Needs work shortly after. So let's get to it! :)

Is there a specific Slack channel where we're meeting to discuss this work?

@cosmicdreams I don't think there is one yet! Just saw your comment in #94 📌 Add a native dialog element to deprecate the jQuery UI dialog Needs work didn't even though about off_canvas using jquery ui as well!

Alright everyone, so based on the work done by @TinaRey and inspired by the jquery dialog adapter:"dialog.core.es6.js" by @bnjmnm. I worked on a contrib module the last couple of days, which "bridges" all existing Drupal.dialog() calls to use the new dialogNative library, called Dialog Native → . It is still very much in a very early alpha stage and needs major testing, but creating dialog links such as:

<a class="use-ajax" 
    data-dialog-options="{&quot;width&quot;:400}" 
    data-dialog-type="modal" 
    href="/node/1">
    First article displayed in modal dialog.
</a>

And the examples by @TinaRey:

editor: on a wysiwyg field, change the text format between basic_html and full_html
field_ui: on a content type, manage fields and attempt to delete one
in both cases, a native dialog should pop up, and the buttons should work

Already work. Although stuff like the off_canvas library is unfortunately broken, so no proper layout_builder for now...

Eventually, we could work on the module together, until it is solid, and we are able to merge large parts into core! I can also give out maintainer ship to speed things up, if necessary! Also I am very much in favour of a dedicated slack channel. Switching out the native dialog element with implementations of the popup API mentioned by @cosmicdreams, shouldn't be a problem, but we should discuss, what benefits it would bring us!

I created a dedicated Slack channel, to discuss further work on Dialog Native → and whether future issue work should be moved there instead: https://drupal.slack.com/archives/C06EYQU1F98

I dm'ed @_node, @bnjmnm and @larowlan, concerning future plans on this issue and maintainer ship for https://www.drupal.org/project/dialog_native → .

I created a dedicated Slack channel, to discuss further work on Dialog Native

Joined.

concerning future plans on this issue and maintainer ship

Feel free to add me.

On the horizon:

• :open and :closed selectors supported in browser: https://drafts.csswg.org/selectors-4/#open-state
• Allow top layer elements to be nested within popovers
• Improvements to how dialog events fire

There's related 📌 Removal :tabbable usage in dialog.js Fixed
which should unblock 📌 Deprecate jquery.tabbable.shim Active