Dialog Component Ideas #168
taufik-nurrohman
started this conversation in
Ideas
Replies: 3 comments
-
I am considering to use the name proxy instead of dialog as this is mainly used to load resources from another web page: <a href="#element-id" target="proxy"> $_['proxy']['element-id'] = [ /* Local dialog element */ ]; |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
For a front-end designer, making dialog mechanism is easy. You just need to make a HTML box with absolute position, then hide it by default. Then, with a click of a button, you display the box. You can use JavaScript or CSS
:target
selector to toggle the dialog visibility. Easy. The challenge is how to make it controllable from the HTML markup level.The Bootstrap Way
Bootstrap has been able to handle it well. By linking the dialog markup as the target on the trigger element via
data-bs-target
attribute. Then, thedata-bs-toggle
attribute can be used as a selector so that the JavaScript library can select all elements with that attribute and add a click event to them to display the dialog as referenced to the associateddata-bs-target
attribute.I can illustrate it simply like this:
Mecha’s Panel don’t want to achieve that kind of complexity. Especially about the need to manually add the dialog element for each trigger. I can’t imagine I have to have 100 dialog markup to accompany triggers that appear on 100 list item.
We could indeed simplify it by making just one dialog element where the content in it can be dynamically loaded based on the clicked trigger data, but that would require manual handling. We need to select those elements specifically and handle those events specifically as well. This is not concise, especially if something makes it unable to display the dialog.
Our Way
I’m more inclined to think of a dialog as a window for loading pages that are specially made to be displayed within that window. Think of it as a window manager on an operating system. The job of a window manager is just to manage windows, nothing more. About how the content in it will be displayed all depends on the maker of the application. You could display GTK or Qt application, or even load a web page.
URL Pattern as Solution
I think that URL pattern is one of the simplest solution to properly display a dialog with dynamic content. It doesn’t require any additional attributes, and you can make a single hidden dialog element to be used by all triggers.
The way it works is, we use a special hash name on an anchor so that it can be selected as a trigger, then the existing link can be loaded in the window body. If the link is local, we will use AJAX to load the page. If the link is external, we will use
<iframe>
to load the page:Target Value as Solution
We can also use the
target
attribute with a specific value. For HTML, the value of thistarget
attribute is commonly used to determine where the link will be opened. If the target is not found, then the link will usually open in a new tab. Which means that without the dialog feature, this HTML markup won’t introduce any significant side effects on the whole system. Makes it possible for us to make this dialog system as a separate extension.My main focus on this feature is how we can make the HTML markup specification as natural as possible to take advantage of the existing conditions to improve the features without disrupting the original functionality.
Beta Was this translation helpful? Give feedback.
All reactions