[whatwg] Modal dialogs in HTML5

[Ian Hickson]

On Mon, 28 Apr 2008, João Eiras wrote:
> 
> What happened to the 3rd parameter (sFeatures) ?
> http://msdn2.microsoft.com/en-us/library/ms536759.aspx
> This parameter is needed to specific the window features (size, position,
> ...).

I couldn't find any features that I could justify specifying, so I omitted 
it. IMHO the UA should determine the size and position automatically; why 
would the author specify them? The author has no way to know what a 
reasonable value is.


> Also, IE supports the properties dialogLeft, dialogWidth, dialogTop and 
> dialogHeight. Two of these can be read from innerWidth and innerHeight, 
> while the other two are irrelevant, and hardly useful for a webpage. 
> But, omitting these from the spec will create implementation 
> discrepancies. Probably you could add an extra section with features 
> that were purposely left out of the spec ?

These are issues for Anne's CSSOM draft (along with innerWidth, etc). I 
recommend raising these issues with him. (I'm not sure which working group 
is the appropriate one for that draft.)


> I've built some time ago a comprehensive testcase (it's attached), to 
> test IE's showModalDialog implementation, and besides what is common 
> sense, IE drops hashes from the url which is passed to showModalDialog, 
> and IE truncates, on purpose, the dialogArguments parameter to 4096 
> chars, if it's a string. I see no possible reasoning for these design 
> choices.

Fair enough. I've not required these in the spec.


> Regarding the spec:
>  - about step 1. : you could mention that showModalDialog might be blocked by
> popup blockers too, which is easier to understand for the crowd.

Done.


>  - about step 3. : there's this clause "from running scripts". Well
> showModalDialog blocks so all script execution must be halted while
> showModalDialog does not return. So is this wording correct ?

It doesn't block scripts in other windows or workers.


>  - about step 8. : you could add "the browing context can signal the UA to
> terminate, e.g. calling window.close()"

I haven't defined window.close() yet, but hen I do, I'll mention it here 
too.


> Another thing: while the use cases for showModelessDialog can already be
> covered by window.open(), there is a difference in behavior:
>  - window.open creates a new window, which can be lose focus, and go behind
> it's opener window.
>  - showModelessDialog creates a new popup window, which can too lose focus,
> but will never go behind it's opener. It'll say always in front of it.

That seems to be up to the user agent. For example in Chrome new windows 
don't go behind the window that opened them by default.


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