[whatwg] Comments on <dialog>

[Ian Hickson]

On Mon, 22 Apr 2013, Matt Falkenhagen wrote:
> 
> 1. Browsers that don't support <dialog> will show the content by 
> default, unlike browsers that do. Should the spec be changed to make 
> dialogs open by default (and use a "closed" instead of "open" 
> attribute)? Or is there another easy way to degrade gracefully for older 
> browsers?

Putting:

   dialog { display: none }

...in the style sheet is enough, as far as I can tell. That or just not 
putting the element in the DOM until you need it. (In practice, on the 
short term, you're unlikely to use this in situations without CSS and JS.)


> 2. Would naming the methods open/close or show/hide instead of 
> show/close be more natural?

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.


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

Note that getComputedStyle() doesn't return the computed value for 'top', 
it returns its used value (unless the element is display:none). 
Technically it returns the "resolved value". For details, see:

   https://dvcs.w3.org/hg/csswg/raw-file/tip/cssom/Overview.html#resolved-value


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


> 5. For centering, the spec may need to be more detailed about what 
> happens in different writing modes. Probably we want to center 
> horizontally in vertical writing mode, in which case we don't set 'top'.

Yeah, good point. I've filed this bug to track this:

   https://www.w3.org/Bugs/Public/show_bug.cgi?id=21770


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

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