[whatwg] Comments on <dialog>

[Ian Hickson]

On Mon, 26 Aug 2013, Matt Falkenhagen wrote:
> On Thu, Aug 22, 2013 at 7:58 AM, Ian Hickson <ian at hixie.ch> wrote:
> > On Mon, 22 Apr 2013, Tab Atkins Jr. wrote:
> > > On Mon, Apr 22, 2013 at 12:38 PM, Ian Hickson <ian at hixie.ch> wrote:
> > > > On Mon, 22 Apr 2013, Matt Falkenhagen wrote:
> > > >> 3. For centering in the viewport, the spec mandates that the used 
> > > >> value of 'top' be specially calculated. I found it more 
> > > >> convenient to implement by mutating the computed value rather 
> > > >> than the used value. This has the added benefit that it's 
> > > >> straightforward for the page author to implement dragging using 
> > > >> getComputedStyle.
> > > >
> > > > The computed value can't rely on layout, since it's used for
> > > > inheritance, which can happen without layout, if I'm not mistaken.
> > >
> > > Matt means that we, the browser, explicitly set the computed value to
> > > whatever's appropriate, based on layout values at the time that .show()
> > > is called. (Done either by setting values in the override stylesheet, or
> > > by manipulating the style attribute on the element. Probably the latter,
> > > because there's no guarantee we can uniquely target the dialog via a
> > > selector.)
> >
> > I don't really think this makes any sense. For example, it wouldn't handle
> > viewport video changes as it's currently described.
> >
> > The way the spec is defined now, it's the static position that is set --
> > the 'top' property is unaffected except indirectly by its dependency on
> > the static position. What's wrong with that?
> 
> Can you elaborate on what viewport video changes are and what the 
> problem is?

I think I meant viewport width changes, sorry. As in, when you resize the 
viewport, it would either fail to move the dialog, or it would override 
the user's move, depending on how we implemented this, without the author 
really being able to do anything about it.

The way the spec is written now, you can still trivially implement 
dragging; you just set 'top' appropriately based on the element's 
position. Then, onresize or whenever you want to revert to the default 
position, you remove the 'top' property. It all just works. I don't really 
see the problem here.


> It may not be a strong reason to change the spec, but in my experience,
> implementing this in terms of static position in WebKit/Blink was very
> challenging. As an example of the challenge, normally static position
> is computed for a box during its layout, which is too early for dialog:
> the dialog's dimensions must be known in order to center it, so it must
> have been laid out already.

How does this differ from, e.g., computing 'auto' margins of 
shrink-wrapped blocks?


> Changing the static position after layout breaks much assumptions in the 
> code and would seem to require invasive work across the render tree, 
> layer tree, possibly painting, etc. In contrast, if CSS is manipulated 
> after the first layout pass, the layout engine just works. So I found it 
> convenient and stable to mutate CSS 'top' directly.

I don't think mutating attributes is a sane approach to doing this. It 
feels like a hack, it interferes with author affordances, it makes it 
harder for us to distinguish script-set property values from UA-set 
property values, it makes it harder for authors to specifically override 
the UA, etc.


> That said there have been some spec changes since my last attempt that 
> may make this easier, such as the dialog's cb is the icb. That also 
> means you can just use offsetTop/Left to implement dragging so perhaps 
> it's no longer helpful for getComputedStyle to return the centered top.

Please do let me know if it is too difficult with the static position as 
defined. We could maybe consider other options like having a special 
computed value just for 'top', etc, the way we do for 'position'.


On Tue, 27 Aug 2013, Ian Hickson wrote:
> On Mon, 26 Aug 2013, Ryosuke Niwa wrote:
> > On Apr 22, 2013, at 12:38 PM, Ian Hickson <ian at hixie.ch> wrote:
> > > 
> > > The current naming is based on window.showModalDialog() and 
> > > window.close(). I agree the naming is weird, but being consistent is 
> > > probably going to be more helpful on the long run.
> > 
> > But that's because we have window.open but not an equivalent of 
> > window.close for window.showModalDialog, right?
> > 
> > It seems more consistent to use show/hide or open/close as Matt 
> > suggested.
> 
> Consistent with what? We have window.open()/window.close, and 
> window.showModalDialog()/window.close(). We also have 
> document.open()/document.close(), and so on (EventSource, etc). I 
> suppose we could change show() to open(), but then we'd be inconsistent 
> with showModalDialog() for openModal()...

On Mon, 26 Aug 2013, Ojan Vafai wrote:
> 
> IMO, showModalDialog is the legacy broken API we're stuck with. Better 
> to name the new thing in a way that's self-consistent and consistent 
> with everything else (i.e. openModal).

I started doing this, since several people have asked about this and it 
seems the consistency between showModalDialog()/close() seems less 
interesting to people than the consistency with "open" everywhere else. 
However, it turns out this would make the show() method clash with the 
"open" IDL attribute on <dialog>, which we want since it matches the name 
of the open="" content attribute which matches <details open>.

Note that window.open() and document.open() don't really do the same as 
this method does, either. window.open() creates a new Window, or navigates 
and existing one; document.open() resets the document. dialog.show() just 
changes the dialog to be visible.

Also, there's an interesting mix in other APIs. (Disclaimer: I don't know 
many of these APIs personally, so I may be misinterpreting their 
documentation wildly. I basically looked for terms like "open" and "close" 
in the docs and tried to see what the right methods were in each case. I 
only included methods for modal dialogs if there was a trivial method; 
many APIs have to be configured to make dialogs modals separately.)

 Android uses show() and dismiss()
 Closure uses setVisible()
 Cocoa uses makeKeyAndOrderFront:, orderOut:, close, and performClose:.
 Delphi uses Show(), ShowModal(), Hide(), and Close().
 Ext JS uses show(), hide(), and close().
 jQuery uses "open" and "close".
 Gtk uses gtk_widget_show(), gtk_dialog_run(), gtk_window_close().
 .NET uses Show(), ShowDialog(), Hide(), and Close().
 Win32 uses ShowWindow() and CloseWindow().
 X11 uses XMapWindow() and XUnmapWindow()

Most of the APIs I looked at use "close". Most use "show". So I think 
we're in ok company here.

I've left the spec as is.

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