[whatwg] Comments on <dialog>

[Tab Atkins Jr.]

On Wed, Aug 21, 2013 at 3:58 PM, 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?
>
>
>> 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.

Hmm, specifying the static position probably does work, at least from
the spec standpoint.

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

Yes, "it's complicated" would be an understatement.  Let's leave it
out for now.  (We're intending to.)

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

Yes, fit-content <http://dev.w3.org/csswg/css-sizing/#fit-content>.

~TJ