# Can panels and dialogs be more flexible?

**URL:** https://discuss.wordgard.net/t/can-panels-and-dialogs-be-more-flexible/33
**Category:** General
**Created:** [August 5, 2026, 8:45pm UTC](https://discuss.wordgard.net/t/can-panels-and-dialogs-be-more-flexible/33 "2026-08-05T20:45:12Z")
**Posts on this page:** 2
**Page:** 1

<div class="post-metadata">

### Author: ![thesmartwon](https://discuss.wordgard.net/user_avatar/discuss.wordgard.net/thesmartwon/32/22_2.png) [@thesmartwon](https://discuss.wordgard.net/u/thesmartwon)
#### Post date: [August 5, 2026, 8:45pm UTC](https://discuss.wordgard.net/t/can-panels-and-dialogs-be-more-flexible/33/1 "2026-08-05T20:45:12Z")

</div>

For panels, [the docs state](https://wordgard.net/docs/ref/#h-panels):

> Panels are interface elements displayed above or below the editor. They use sticky positioning to stay in view even when the editor is partially scrolled out of view. They are a good way to display things like dialogs, status bars, and menu bars.

Excellent! Is there value in:

1. `left` and `right` positioning in addition to `top`?
2. an option to stack multiple panels and tab between them?
3. a way to access open panels to dynamically determine layout? I went down the rabbit hole to see how to do this, but it looks like you need access to `panelPlugin` or the panel’s constructor.
4. a way to override panels rendering, similar to menubar?

For dialogs, the docs state:

> Dialogs are panels opened as a side-effect, and closed by user action.

…

> The result should contain at least one `<form>` element.

Why? I can see uses for inspecting attributes like blame tracking. Closable status bars seem good to me.

Looking through the source to try to understand, I see a lot of inflexible form handling code – like adding `wg-*` classes, input names, buttons, and event handlers for keydown and onsubmit.

Extensible form builders are nearly impossible to get right. Is there really a need for a form builder, or can it be left to the user? Removing this code could allow for the `form` constraint to be lifted.

---

<div class="post-metadata">

### Author: ![marijn](https://discuss.wordgard.net/user_avatar/discuss.wordgard.net/marijn/32/7_2.png) [@marijn](https://discuss.wordgard.net/u/marijn)
#### Post date: [October 8, 2026, 12:26pm UTC](https://discuss.wordgard.net/t/can-panels-and-dialogs-be-more-flexible/33/2 "2026-10-08T12:26:03Z")

</div>

> [@thesmartwon](#):
>
> Is there value in:

I could complicate this endlessly, but I don’t think it’s a good idea to ship a an endlessly complicated UI framework to the user, and I don’t want to maintain such a thing. Panels provide a simple abstraction for a single useful thing, and I think that’s the right scope.

> [@thesmartwon](#):
>
> Extensible form builders are nearly impossible to get right. Is there really a need for a form builder, or can it be left to the user?

It _is_ left to the user, except in trivial cases (single input element with a caption and a button), where it can be practical to get your dialog as a one-liner.