Dialog type="modal" or else(and deprecate showModal())

HTML
1

problems

Continuing from this GitHub issue, the current dialog’s APIs seem a bit ugly. if the spec can be slightly fixed, it makes more pretty and consistent.

proposals

when opening modal without showModal(), you just type this:

<dialog type="modal" open>
   <!--something content...-->
</dialog>

or with show() method, you just type this:

show( { type : "modal" } )
3 Likes
2

but one question, is non-modal dialog necessary? Are there any situations where non-modal must be used?

3

Are there any situations where non-modal must be used?

Non-modal may be used in applications where you are building a set of components that can be individually moved around the page without stacking context. That way the user can see the contents of another dialog while working in the current one.

On the note of type="modal", I do think this is a useful addition. This would mean the JS API and HTML can both achieve the same result. Also I really dig the show({type:'modal'}) setup vs having two separate methods of showing state in JS. This uses an extensible config option and allows for showModal to be safely deprecated encouraging the use of the object config on show to get the same result in JS without affecting compatibility with any existing sites.

1 Like
4

Since there is such a lack of implementations and it involves so much, is there a reason that this can’t be written as a custom element that implements precisely what you propose and then, if you can get that widely used, this is kind of easy?

5

It’s still only shipping in the open in Blink based browsers. I think this is good feedback to digest and look into before other implementations (like Firefox’s currently behind a flag) get shipped. That way as few people are revisiting the element later to address any changes to the spec that may come from the discussion.

It actually raises an interesting API consistency issue for future elements as well. How do we try to make sure triggers by JS APIs can be handled in markup as well to keep the markup reflective of expectations on display and controls?

6

Also it seems more imperative to have a discussion around the API now rather than later. There is talk of another method being added to show without focus. This is a slope of adding methods to solve configuration options for everything that may be needed. Chromium is looking at a config option now for the new requested feature. However expanding that config to deprecate the showModal method as well could be critical at this juncture.

References:

7

Without any other types even being discussed, I think making modal the property of a boolean value is better for the API.

show({
  modal: true
});

showModal() can then just proxy show({modal:true}) easily enough and have a log statement that showModal is deprecated to encourage people to move to show directly.

2 Likes
8

It would be nice to be able to use the type html attribute as the overrideable default for the modal option in show().

9

Or you just could use:

<dialog>
    <!--something content...-->
</dialog>

and then:

element.setAttribute('type', 'modal');
element.show();
10

revive it