Feature Request: Include `<dialog>` Element for Modals in Tag List

[0yeifer]

What is the feature request? Please describe.

Frappe Builder currently lacks to allow selecting the HTML <dialog> element from the list of tags for a block. Users might implement modal windows and interactive dialogs through non-semantic <div> structures with manual JavaScript handling, but, this approach complicates accessibility, increases code complexity, and limits the use of native browser features like built-in focus management and backdrop styling.

How would I like the solution to work?

1. Native Integration: Add <dialog> as a selectable tag for a block in the Frappe Builder UI, allowing users to configure its owns javascript methods if they want to handle interactions.
2. Zero-JS Templates: Provide a prebuilt dialog template demonstrating native functionality (e.g., a modal that opens via <button onclick="dialog.showModal()"> and closes via <button onclick="dialog.close()">).

Why have I considered this request?

As an alternative, I’ve used <div>-based modals with custom JavaScript for focus trapping and styling. However, this approach introduces accessibility risks, conflicts with Frappe Builder’s low-code philosophy, and requires unnecessary maintenance. The native <dialog> element aligns with Frappe’s performance goals by leveraging browser-native features and reducing third-party dependencies.

Who can contribute or support this request, and how?

• My Contribution: I’ve already prototyped the integration logic and template structure. I will submit a PR soon and wait for feedback.
• Official Documentation: MDN Web Docs (official <dialog> documentation) provides detailed guidance on <dialog> usage, including keyboard navigation, focus management, and styling. This resource can inform Frappe Builder’s native dialog implementation.

When and where would the solution be available?

There doesn't seem to found any specific constraints on the availability of this feature. Maybe it can be available in the next release of Frappe Builder. I will address these issues in the PR and collaborate with the team to refine the solution.

Additional context

Why <dialog> Matters for Frappe Builder:

• ✅ Native browser focus management improves Lighthouse accessibility scores.
• ✅ Eliminates redundant JavaScript for basic modal interactions.
• ✅ Accessible by default, supporting keyboard navigation and screen readers.

I will share progress in comments and propose template designs for review.

[0yeifer]

Need technical feedback on Dialog Visibility Handling
My current approach removes display from base styles to preserve native browser behavior (display: none when closed). However, this creates a WYSIWYG mismatch:

RefCommit

• Editor: Dialogs are always visible (unless manually hidden via toggle, and when manually hidden the native behavior is broken because it will always be hidden, so requires JavaScript for dynamic visibility changes)
• Publish: Dialogs are hidden by default (without open attribute).

Key Trade-offs:

1. Default open Attribute: Not adding it to customAttributes avoids forcing dialogs to be open-by-default on publish, but breaks visual parity.
2. Style Removal Logic: The removeStyle("display") in getStyles() prevents Frappe Builder from overriding native behavior with fb-* classes.

Unresolved Concern:
If users expect dialogs to be closed-by-default, the editor's always-visible preview might confuse them. Conversely, adding open in not hardcoded via could align WYSIWYG but requires UI controls.

Request for Feedback:
@surajshetty3416 I have three possible final scenarios on mind:
a) Keep current visibility behavior (editor ≠ publish),
b) Add an open attribute UI controller in the properties panel (but this is very specific to this tag), or
c) Implement conditional CSS (dialog:not([open]) { display: none }) maybe in the reset.css ?

If there's anything else I don't see, please let me know, I think Frappe Builder team input is needed to balance consistency and native behavior.

[0yeifer]

Update on Dialog Visibility Implementation
After further testing, I've revised the approach to prioritize code cleanliness:

1. CSS Reset Strategy:
   Added dialog:not([open]){display:none} to reset.css (line change appears large due to minification, but only contains this rule). This enables native browser behavior without intrusive Block class modifications.

2. Editor-Specific Z-Index:
   Kept isDialog() check to force z-index: 1000 on Editor View. This ensuring dialogs remain visible/editable above other elements. Removed display manipulation in Block class.

   z-index only applies in the Editor View. On published web page, dialog elements are displayed in top-layer by default.

Key Implications:

• ✅ Cleaner component logic: No special display handling in Block class
• ⚠️ Persistent editor/published view mismatch: Dialogs remain editor-visible without explicit open attribute

Open Question:
Is the remaining WYSIWYG discrepancy acceptable given the technical tradeoffs, or should we explore additional solutions?
Feedback welcomed on direction, I will continue implementing dialog templates based on the current approach.

[0yeifer]

New Dialog Block Templates Added
Two native <dialog> templates are now available:

1. Dialog Show:
   • Contains a trigger button with onclick="<dialogId>.showModal()"
   • Modal includes a simple form and three action buttons and one required text input:
     • Validate and Close (form submission via method="dialog" validating input required)
     • Non-Validate Close (submit without validation using attribute formnovalidate)
     • JS Close (native call to close() method via onclick="<dialogId>.close()")
   • Supports native features:
     • Esc key cancellation

2. Dialog Modal:
   • Open-by-default dialog (open attribute) with confirmation button
   • Demonstrates attribute-driven visibility

Key Implementation Notes:

• Zero external JS dependencies - uses native HTMLDialogElement methods via ID references
• Templates maintaining Frappe Builder low-code philosophy

Next Steps:
Will submit PR shortly. The editor/published view visibility discrepancy remains unresolved
Awaiting feedback, I will keep an eye on the PR for any necessary changes.