[whatwg] Comments on <dialog>

[Ian Hickson]

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?


> It's important that this centering happen exactly once, at the moment 
> the dialog is shown.  Whatever mechanism we come up with for this has to 
> fit this constraint, so that authors can manipulate the offset 
> themselves afterwards.

As soon as the authors sets the top explicitly, the static position is no 
longer used, so it just works.


> > It's true that for seamless iframes we could change that, but the 
> > usual use case for seamless iframes is something like blog comments, 
> > so it's not clear that there's a use case for dialogs there. If there 
> > was to be one, we could consider it. It sounds like a lot of work to 
> > do if there's not a compelling need though.
> 
> Hm, I was given to understand that it *was* intended that dialogs be 
> able to escape iframes through some mechanism.

That isn't specced currently. I'm not 100% I understand how it would work 
(I guess it would need a lot of infrastructure from CSS?), but I'm happy 
to do it if there's demand and if the CSS side is figured out.


On Tue, 23 Apr 2013, Matt Falkenhagen wrote:
> On Tue, Apr 23, 2013 at 4:38 AM, Ian Hickson <ian at hixie.ch> wrote:
> > On Mon, 22 Apr 2013, Matt Falkenhagen wrote:
> >> 4. Why isn't the dialog horizontally centered in the viewport? The 
> >> spec just mentions vertical centering and 'top'.
> >
> > The horizontal centering is done via the default CSS. The vertical 
> > centering can't be done with CSS, hence all the prose about it.
> 
> The default CSS gives the dialog a 'left' and 'right' of zero. I think 
> this means that to achieve horizontal centering without actually filling 
> the viewport horizontally, you must set 'width' to something other than 
> 'auto'. Would it be useful for the width to be shrink-to-fit if it is 
> 'auto' and then the dialog be centered horizontally? Or is that not a 
> common use case?

Hm, yeah, what I really meant was width:shrink-to-wrap. Is there a CSS 
value to explicitly select that yet?

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