System popups (modals) need a technical redesign (architecture). Discussion about possibilities.

[Fedik]

Let's discuss Joomla! system popups for a content selection and editing. And how it can be improved in future releases (not about 4.0)

As I guess everyone is aware a current state of system popups is an endless well of bugs.

The reason is that the modals not designed to work with complex dynamic content, but rather for simple dialog popups to replace a native alert() and confirm().

What exactly wrong with current approach?

1. Current approach does not allow to build a popup dynamically, on client side (easily).
2. The interaction buttons (save, save & close etc.) is detached from the frame document. Only look in modal-fields.js can show all horror.
3. Let face the true: it does not fix a main framework compatibility issue. It hardly depends from Bootstrap, and people cannot easily use it with "own" framework.

What is good in current state?

1. It looks nice and styled.

Which approach is good?

1. The popup script need to be independent (standalone) from any framework, responsive and customizable. The script should allow to display any kind of content: frame, inline, images, etc. And should allow to do it dynamically (like this one magnific-popup.js but without jquery) (yes, something like it was in 1.5, 2.5 with SqueezeBox )
2. The interaction buttons (save, save & close etc.) should be within the document. This actually is very important.
3. The interaction between the iframe content and the parent document need to be event based, without hardcoded callbacks, that often missed somewhere. Basically enough just 2 event: joomla:close-popup, joomla:select-content (with data to select).
4. Reduce use of popups where it possible. Ideally every complex popup should be a new window, however it hard to achieve.

The script that we need

Turns out it a bit hard to find a good script that fit all these requirement 😄
For now I found glightbox, that seems working good, and does not have licensing problems (if I nothing missed).
If someone know a good one, please tell.

Okay, and now?

Well, I hope to hear a practical ideas and suggestion about the topic.
And again it is not for 4.0 version.

[brianteeman]

The way I see it we have multiple different types of content all being displayed in some popup/dialog/modal and they are all using the same code which is resulting in compromises.

Type 1 - Messages that just need to be dismissed
Type 2 - Choices where something has to be accepted or denied
Type 3 - Full views as seen in menu manager
and probably more

[Fedik]

Yeah, Type 1, Type 2 is a kind of a simple dialog. I not sure if Joomla even use "Type 2" somewhere.
Type 3 most used, and most complex thing in Joomla. It everywhere: menu content select, menu content edit, media select, batch popup, language association, user select.

I think the compromises is a bit to hard here, and Type 3 need to be separated somehow.

[brianteeman]

Type 2 is used in the template and media managers and other places

[dgrammatiko]

fwiw there is also https://github.com/joomla-projects/custom-elements/blob/master/src/js/modal/modal.js which could be modified to fit any requirements, it's not 3rd part code 😉

[dgrammatiko]

Create a new Joomla.createPopup({buttons: [{text: 'confirm', onclick: someFn}, {text: 'cancel', onclick: someOtherFn}]})

That will translate the object to the innerHTML of <joomla-modal>

Job done

[Fedik]

All the needed buttons is a "Close" one, no more, but can be less :)

This one of part I have noted:

2. The interaction buttons (save, save & close etc.) should be within the document.

[dgrammatiko]

Current approach does not allow to build a popup dynamically, on client side (easily).

Actually, this is not accurate. We could render one <template> element with the basic bootstrap modal structure and fill the title, content client-side. So basically changing the modal layout to actually add the needed data in the storageOptions through addScriptOptions and adjusting the Joomla.initialiseModal should be a straight forward task. Of course, some instances will break (eg article select, esp for the add, edit, etc buttons) but those cases are already broken in my book

[Fedik]

This sounds opposite to what I think is easy :)

[dgrammatiko]

I didn't say that it's easy, I said that it's possible with the current modal script. To get something simple and doing exactly what you want, you have to write your own version of the modal. Scripts that are supposed to cover a range of requirements are either falling short in some requirements or are bloated, you don't want either of these. So, own your UI so you could shape the UX the way you wanted, there are no shortcuts here

[krileon]

Web Components (which we already have for Modals) for each case would make most sense. I don't think anybody wants to deal with yet another popup or lightbox like monolithic JS library with its own goofy strict HTML structure again. Most of which stop being maintained within a year. Improving the web component would make most sense.

When it comes to popup JS libraries the only 2 I trust or would bother with is tippy (for the actual popup) and popper (for positioning API). I've seen way too many of these libraries show up and vanish in a year to trust anything else. Neither have opinions on your content and the hardest part about modal windows is positioning so really the only thing you need for them is Popper.

Since Bootstrap 5 is already using Popper we're set. Basically there's no reason to switch to glightbox for modals.

[dgrammatiko]

Bootstrap is using popper only for tooltips, popover and dropdowns. Modals are extremely easy to position with CSS (that's also what BS is doing)

[dgrammatiko]

One more thing, https://caniuse.com/dialog is behind a flag for some time on Safari. Dialog can be polyfilled and once natively supported there's way less js needed. Github has a nice wrapper around dialog iirc

Edit: sorry they're using details for dialogs: https://github.com/github/details-dialog-element

[krileon]

Bootstrap is using popper only for tooltips, popover and dropdowns. Modals are extremely easy to position with CSS (that's also what BS is doing)

My mistake thought they were using it for modal windows as well. Regardless my opinion still stands as far as JS libraries are concerned for anything related to popups, dialogs, modals, etc.. in that those are the only 2 libraries I would trust to accomplish it and remain maintainable. Too many JS libraries for these sort of things just die off and are no longer maintained in under a year. A 3.5k line 104 KB JS file just for modal windows seams entirely unnecessary.

Edit: sorry they're using details for dialogs: https://github.com/github/details-dialog-element

This looks significantly better and is just a web component which is entirely what I'm advocating for.

[dgrammatiko]

This looks significantly better and is just a web component which is entirely what I'm advocating for.

Exactly, this is shippable right now. Also because it supports both light DOM and shadow DOM it just fits extremely nice the project needs. Just add some css and drop the BS thing

[dgrammatiko]

BTW, there are plenty of custom elements or web components for almost every interactive component that Joomla uses. If someone creates the needed HTMLHelpers and the bridge code basically Joomla becomes significantly less dependant on Bootstrap. Actually, that was my plan when I created the custom-elements repo, not necessarily roll my own code but roll code that is working correctly with every CSS framework...

[joomleb]

Hi guys,
personally I like simplicity and practicality, to be used very well on small screens (independent from screen dimensions). This is why I hope the choice will be on something like Tassos Marinos' "Fullscreen Popup"

[dgrammatiko]

Just wanted to add that since March 2022 Dialog is supported in all major browsers, so basically no JS library or script is needed for the creation of a modal (still some JS is needed for opening/closing, etc). Also there's a polyfill so modals this could be done without too much pain and without shipping another external dependency

[laoneo]

Just for the record, here was a first approach for a modal field refactoring.

[dgrammatiko]

@laoneo here is a PR with that code for 4.3: #39351
But I think it introduces a B/C break. It would be nice if someone could help there (on the PHP side, I could the JS and remove the XSS)

[dgrammatiko]

I intend to prototype a new modal based on the dialog element (as a wrapper with support for both declarative AND imperative use). I intend to implement all of @Fedik 's recommendations/specs but maybe few have to be postponed for 5 as there might be B/C breaks (eg moving the buttons inside the frame, etc).

Are there any other considerations/specs that I should be aware?

[dgrammatiko]

I've landed the PR: #39344 but comments either here or in the PR are ok

[dgrammatiko]

Moving the buttons inside the frame is an important part actually, to trash this horror modal-fields.js

moving the buttons for the core is not a problem but as Dmitris said its probably a b/c issue for extensions

I have an idea how we can move the buttons inside the modal WITHOUT breaking any existing code. Here are the main points:

• templates get another entry, let's call it iframed.php which is the same as component.php (should be deprecated) with one simple addition: a <jdoc:include type=modules name=toolbar>. This will render the toolbar at the top position of the iframe.
• Decouple the toolbar generation from the HTMLView files and add them in the actual layout of the component, eg https://github.com/joomla/joomla-cms/pull/32896/files#diff-ba62e523f10453ad6713f076bec4b34d74a2fce8bed9c8ec4beadb30f0f978ebR26-R74 This actually serves 2 purposes, one to render whatever is appropriate per layout (using JLayouts so not much repeated code) and another to give front end devs true freedom on customisation.
• so the old iframe src's with tmpl=component will render the existing functionality and the tmpl=iframed will render the new with the buttons inside the iframe.

@Fedik @brianteeman in short this is doable, in a progressive style, without hard breaks

[Fedik]

I thought about a simple inline buttons, but can be toolbar I guess. I would not complicate it with Layout, it something diferent.
Maybe a good way is to write down all "modals" we have, and all buttons we have, it porbably only few: save, save&close, cancel, select.

I have an idea how we can move the buttons inside the modal WITHOUT breaking any existing code

I do not know what you have in mind, but I think the intercation should be "event driven", instead of "callback horror". But this need to planning and trying, to find what will work.

[dgrammatiko]

There are 3 ways to have an event driven system:

• events bubble up to parent window
• window.postMessage
• window.opener() (actually it's a callback, but since it supports structured data to be passed around it might work)

I don't think I'm liking any of these as all of them come with drawbacks but I'm also not against them, just pick one and let's make the API's needed...

The idea for the toolbar will work fine as it's a standardised way to render buttons and it's familiar to everybody in the community. Less friction is always better imo

[Fedik]

In one of my projects I have used event bubble. But the postMessage also look good, need to check if it work in the same window also.

In one of my projects I used it like:

popup.onOpen(() => {
  // ... wait on frame load (for iframe popup), then listen for `content-select` event from the popup content,
  // set selected value and close the popup
  $frame.contentWindow.addEventListener('blabla:content-select', function(selectEvent){
    const data = selectEvent.detail;
    setValue($field, data.id, data.title);
    popup.close();
  });
});

The content inside iframe triggers 'blabla:content-select' event, with content details: id, title etc.

postMessage looks safer for it, need to test.