- From: Ian Hickson <ian@hixie.ch>
- Date: Sat, 1 Feb 2014 00:31:29 +0000 (UTC)
- To: Brian Blakely <anewpage.media@gmail.com>, Elliott Sprehn <esprehn@chromium.org>
- Cc: Matt Falkenhagen <falken@chromium.org>, "whatwg@lists.whatwg.org" <whatwg@lists.whatwg.org>, Scott González <scott.gonzalez@gmail.com>, Ojan Vafai <ojan@chromium.org>
On Wed, 18 Dec 2013, Brian Blakely wrote: > On Wed, Dec 18, 2013 at 2:13 PM, Ian Hickson <ian@hixie.ch> wrote: > > On Wed, 18 Dec 2013, Brian Blakely wrote: > > > On Tue, Dec 17, 2013 at 3:14 PM, Ian Hickson <ian@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. `._.-(,_..'--(,_..'`-.;.'
Received on Saturday, 1 February 2014 00:32:01 UTC