[whatwg] Comments on <dialog>

[Ian Hickson]

On Wed, 18 Dec 2013, Brian Blakely wrote:
> On Wed, Dec 18, 2013 at 2:13 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Wed, 18 Dec 2013, Brian Blakely wrote:
> > > On Tue, Dec 17, 2013 at 3:14 PM, Ian Hickson <ian at hixie.ch> wrote:
> > > >
> > > > I've added a rule to the spec that says that viewports have to be 
> > > > pannable so you can see all of a dialog, but I don't know how 
> > > > feasible that really is.
> > >
> > > I could see implementations using shadow <div>s to satisfy this It 
> > > might be beneficial to even codify kind of element as ::modal, 
> > > representing a modal layer acting as an ancestor for both the 
> > > ::backdrop and <dialog>.
> >
> > Not really sure how this would work. Can you elaborate?
> 
> This is what the shadow DOM would look like for modal dialogs:
> 
> ::modal
> -  ::backdrop
> -  <dialog>
> 
> ::modal is <dialog>'s ancestor, and is available when showModal is 
> called. This allows authors to set CSS overflow to whichever value suits 
> their use-case, and for user agents to establish overflow: auto as the 
> default, making the dialog inherently pannable when it exceeds the 
> viewport.

That seem somewhat novel, from the CSS perspective. I'll have to defer to 
implementors as to how feasible something like that is. So far, the 
feedback doesn't seem positive:

On Thu, 19 Dec 2013, Elliott Sprehn wrote:
>
> We can't implement that inside Blink. It requires <dialog> to have two 
> parents, the real one in the DOM and ::modal. The only way I can see 
> this working is if we special case the Shadow DOM projection logic for 
> <dialog> so that it is always projected into ::modal, but we don't want 
> any special cases in projection.

I've not put this ::modal model in the spec.


On Wed, 18 Dec 2013, Brian Blakely wrote (continuing from above):
> > > > > > > 3. When the modal dialog's height changes, either due to CSS 
> > > > > > > or content changes, the vertical position of the dialog 
> > > > > > > should change (unless the height exceeds the viewport 
> > > > > > > height).
> > > > > >
> > > > > > That's an interesting idea, but I'm not convinced it's the 
> > > > > > right answer. Having the dialog move up and down when stuff is 
> > > > > > added at the bottom would be quite weird. You can always 
> > > > > > implement this manually from script.
> > > > >
> > > > > To go back to hacky and rather difficult-to-maintain JS 
> > > > > techniques for something so simple seems antithetical to the 
> > > > > intention of <dialog> to me. Modern modal implementations don't 
> > > > > require that.
> > > >
> > > > My point isn't that we shouldn't offer the feature because it is 
> > > > already possible. My point is that this feature is actively bad. 
> > > > I'm saying I don't think it's good UI for the dialog position to 
> > > > change when it increases in height.
> > >
> > > It looks like Blink's implementation will recenter the modal when 
> > > show/showModal are called.
> >
> > That's per spec, yes. The suggestion above was regarding when the 
> > dialog changes size while it's already visible, I believe.
> 
> You're correct. I was pointing out that there is already a means of 
> recentering, albeit indirectly.  I could see this being abused by 
> "clever" hackers, with dialog.close() and dialog.showModal() being 
> called in rapid succession, simply for the purpose of recentering.

Sure. As noted above, you could do it from script if you wanted. I was 
only objecting to supporting it directly, since it doesn't seem like a 
good user interface. Obviously, authors have found many ways to create 
poor interfaces over the years, even without explicit support. :-)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'