W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2013

Re: [whatwg] Comments on <dialog>

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 22 Apr 2013 13:10:35 -0700
Message-ID: <CAAWBYDDKkdm391eXM5S9uQ_Q5qW9oZND1G0E9i5oho_W6PEA0g@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: Matt Falkenhagen <falken@chromium.org>, WHATWG <whatwg@lists.whatwg.org>
On Mon, Apr 22, 2013 at 12:38 PM, Ian Hickson <ian@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.)

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.

>> 6. If I understand the spec correctly, a dialog doesn't escape its
>> iframe and particularly a modal dialog in an iframe doesn't block the
>> iframe's parent browsing context's document. Is that accurate? I wonder
>> if there are use cases we should support for escaping an iframe (perhaps
>> just seamless ones).
>
> Yes, it's intentionally that way (they don't escape) for non-seamless,
> cross-origin iframes, since that would be a security risk.
>
> 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.

~TJ
Received on Monday, 22 April 2013 20:11:20 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:57 UTC