Indeed, we would need to lock also the Address Books list, which it's fairly trivial to do.
> Just having it as a modal overlay center of the page could be an alternative worth exploring as well, since basically modality is what we're after here.
I'm really not sure about this.
We're trying to remove the use of dialogs as much as possible, and moving these things into HTML dialogs feels like a partial solution.
I'm not against it as a solution, but I see some problems:
- **Limited space.** Instead of using the whole scrollable page height, we're once again cramping a very long section inside a smaller child element.
- **Visual consistency.** We still don't have a common reusable HTML dialog style, so more CSS will be needed to properly style this area, adding unnecessary repetition.
- **Nested modals.** Geoff implemented the photo upload and crop feature, which it correctly lives in a modal dialog. Having a modal opened from another modal should be a strict "no" in terms of solutions.
- **Keyboard a11y.** It would be harder to control and outside the natural focus ring of the content page. Also we should account for accidental modal closing from an `Esc` keypress.
All the things I listed above are obviously fixable, but I think we should focus on the current implementation and improve that since it gives us more flexibility, less limitations, and it was specifically built for this purpose.
Also, having the view and editable state in the same panel makes our life way easier when adding the needed responsiveness to support smaller screens.
Bug 1751290 Comment 5 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Indeed, we would need to lock also the Address Books list, which it's fairly trivial to do.
> Just having it as a modal overlay center of the page could be an alternative worth exploring as well, since basically modality is what we're after here.
I'm really not sure about this.
We're trying to remove the use of dialogs as much as possible, and moving these things into HTML dialogs feels like a partial solution.
I'm not against it as a solution, but I see some problems:
- **Limited space.** Instead of using the whole scrollable page height, we're once again cramping a very long section inside a smaller child element.
- **Visual consistency.** We still don't have a common reusable HTML dialog style, so more CSS will be needed to properly style this area, adding unnecessary repetition.
- **Nested modals.** Geoff implemented the photo upload and crop feature, which it correctly lives in a modal dialog. Having a modal opened from another modal should be a strict "no" in terms of solutions.
- **Keyboard a11y.** It would be harder to control the natural focus ring of the content page. Also we should account for accidental modal closing from an `Esc` keypress.
All the things I listed above are obviously fixable, but I think we should focus on the current implementation and improve that since it gives us more flexibility, less limitations, and it was specifically built for this purpose.
Also, having the view and editable state in the same panel makes our life way easier when adding the needed responsiveness to support smaller screens.