Mike Alsup wrote:
> - for proper positioning in ie6 you'll need to use the (ie only)
> setExpression method on the style object.  This is a pain, but it
> works well.
>
> - for proper modality in ie6 you'll need to use an iframe.  A div
> won't overlay some form elements on the underlying content, regardless
> of the z-index.
>
> - for proper modality on all platforms you'll need to bind more than
> just the click event.  With a modal window open on your demo page I
> can still tab around and activate other links.  See blockUI for an
> example of suppressing key events.
Mike,

  As ever, your advice is invaluable. Last night I looked over the 
blockUI code & was amazed by its efficiency. I never knew;

var f = $('<iframe 
style="z-index:1000;background-color:#fff;border:none"></iframe>'); ..
this.g  = $([f[0],w[0],m[0]]).appendTo('body');

  was possible! One day, I hope jqModal will be succinct enough to 
resemble your script ;)

  I'll work on integrating a wrapping iFrame for the overlay & modal 
content -- and will include some <select> elements on the demo page.

  Concerning 'proper modality'; A means to lock focus on the window is 
necessary (although jqModal inherited *box's behavior of click overlay 
to close ). I'd like to integrate some of your methods. I think this may 
become quite complex, however.

  The blockUI code executes;

function() { return !impl.vis }

  On key press, key down, and mouse down. 

  impl.vis is set in the show function;

function(s) { s ? this.g.show() : this.g.hide(); this.vis = s },

  From this I gather that *ALL* clicks & presses are blocked when the 
wait message is showing, and allowed when it is not. This is useful for 
AJAX requests.. e.g. unblock/hide wait message on callback, but will be 
harmful if employed verbatim to a modal window. It will bar clicks, etc. 
within the modal window.

  It would be nice to allow clicks & presses ONLY if originating from 
within the modal window. Perhaps this could be accomplished by examining 
focus & parent? Would this block users from typing in the browser's 
address bar? The goal would be to allow a form within a modal window to 
be populated & submitted using keyboard or mouse, and to block 
everything outside of the *currently active* modal.

  I don't think it will be possible to prevent the user from using tabs 
to access links and inputs/buttons in the background page, but the block 
code should intercept the call (<enter>, key press) to execute or 
populate these links/inputs.

  I'd like to find out if I can examine current focus. Doing a little 
research brought me to

window.event.srcElement

  However it seems to be IE proprietary?

  Do you think it is worth the extra complexity? ;)

~ Brice

_______________________________________________
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/

Reply via email to