Update HA dialog guidelines and implementation

[marcinbauer-ohf]

Context

#39
#47

To-do

• Update https://design.home-assistant.io/#components/ha-dialogs

[marcinbauer-ohf]

Met up with @mbb365 and we've defined two areas to work on:

Dismissal mechanics

1. We want to amend this rule) from:

"Dialogs can't be closed with ESC or clicked outside of the dialog when there is a form that the user needs to fill out. Instead it will animate "no" by a little shake."

to:

"Dialogs can't be closed with ESC or clicked outside of the dialog when there is a form that the user had made changes to. Instead it will animate "no" by a little shake."

This rule is too generic, and doesn't work well when a user just opens a dialog that contains some form elements.
Proposed fix: This would use some sort of a "dirty" form flag internally when there are real changes made by the user.
Example where there is no user input, but we already block:

CleanShot.2026-05-28.at.10.42.47.mp4

2. Check (manually?) if in some cases it's even needed to display a dialog with an optional blocking mechanism, or to change it to for example a simple toast.

Confirmation dialog consistency

This is mainly a translation task where we need to look at the whole picture and align the text to a pattern when possible. Working on the dismissal mechanics and optional removal or swtiching of the dialogs in some cases is advised so that we don't fix copy for dialogs that were removed.

[timmo001]

I agree with this.

One other question I have is would we need a prompt when trying to discard or is the X/Cancel (< back if working in a subview) button enough to denote that?

---

More on the technical side but we need a standard way to flag a dialog is in a dirty state (probably by the base dialog mixin), recently I added a dirty flag to the more info settings dialog (to control when the update button is enabled, not whether to lock the scrim area), but this was custom and relied on a compare function (JSON stringified A-B comparison).

[marcinbauer-ohf]

I'm not sure about adding a "Unsaved changes" dialog everywhere there is a slight change from the user. Could we start with just tracking if it's dirty and staying with the pulse pattern @timmo001 ?

[timmo001]

Created tasks and sent copilot on the guidelines update.

The implementation is a little more complex, I also added a brain dump on potential change in the future after design/ux input here for more info settings

[mbb365]

Wait wait wait!

Before doing anything we still need to know -

1. How many workflows this touches
2. Are each of these going to be made better by having an 'escape / pulse / popup / dialogue' (if doing it en masse is the route)
3. Do we still need to keep an 'x' and a 'close' AND have an escape key?

This work here does not touch the initial problem set out of inconsistencies in this issue. the dialogue pattern issues in general.

Is it ok to separate this out? Keeping this one as the escape action and using the other one for just the text and patterns.

That would make me feel a lot more comfortable that nothing would get left behind.

[timmo001]

OK! I'll do this in my initial investigation on how much needs to be touched, right now I'm mainly doing the investigation/wiring part for a dirty state provider + consumers