[whatwg] Comments on <dialog>

[Matt Falkenhagen]

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?

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. 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.

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.