Modal dialogs

Noah Botimer botimer at
Thu Jul 24 19:14:35 UTC 2008


I haven't done it for the jQuery plugin, but I did this "breakout"  
work with SimpleModal in Sakai.  I'm pretty sure I detailed the  
specifics earlier in this thread, so I won't go over them all again.   
But there is definitely some maneuvering required.

Probably the most painful thing is that the CSS for the dialog is  
generally not available in the portal frame where it has to launch.   
I worked around it by doing inline styles via jQuery's .css() stuff.

There may be a mechanism for a tool to inform the portal of a  
required CSS resource, but I think that's edging some brittle work.   
The portal frame may persist while the needs for tool resources  
change -- not a pretty or workable situation since you can't load or  
unload CSS dynamically with any level of reliability.


On Jul 24, 2008, at 2:43 PM, Jim Eng wrote:

> Thanks, Colin.  That helps a lot.
> The jquery dialog looks good.  It doesn't entirely solve the  
> problem, but it looks like it might be better than the simplemodal  
> we are using now.
> I put the URL for the sample page you sent ( 
> functional_demos/#ui.dialog) into the web-content tool in sakai and  
> set the frame height to 2400 pixels.  That simulates the case we  
> have for the SRG authoring context.
> The modal actually shows up off the screen in that case, centered  
> in the 2400-pixel tall space, but the tool frame scrolls so the top  
> bar of the dialog is visible at the bottom of the frame.    I had  
> to scroll the frame manually to see the content of the dialog, but  
> at least I could see the top bar of the dialog box.  Also, it  
> seemed to be modal for everything inside the iframe but I could use  
> buttons in the top-level of sakai (the iframe's parent).  And when  
> I used the modal dialog with overlay, the overlay covered the  
> iframe only -- not the entire browser window.
> These results are not surprising.  To get it tow work otherwise,  
> we'd need the contents of the page in the iframe to invoke  
> javascript and manipulate the DOM in the top-level browser window.
> It seems to me that we will need this capability unless we dump the  
> iframes entirely (a good goal even without this additional  
> motivation).  Maybe we'll want to figure out a way to make the  
> modal dialog appear in the top-level sakai window even though it's  
> launched by a script inside an iframe.
> Jim
> Quoting Colin Clark <colin.clark at>:
>> Jim,
>> Apologies for responding to this thread so late. It got lost in  
>> the whirlwind of conference travel and preparation.
>> Fluid is using the Dialog widget from jQuery UI 1.5 for our  
>> Uploader component.  It seems to work pretty well for us, and it  
>> has some nice features. You can try out a working demo here:
>> At the moment, we're working on adding keyboard navigation and  
>> ARIA support to Uploader for the Infusion 0.4 release. As part of  
>> this work, we're going to make the jQuery UI Dialog accessible,  
>> too. If all goes well, I hope these improvements will be included  
>> in an upcoming release of jQuery.
>> As for your specific issues, I don't know how it would work within  
>> an iFrame, but I suspect this is a common problem.
>> Noah had mentioned problems with some dialog where they weren't  
>> truly modal, allowing users to navigate via keyboard outside the  
>> document. The jQuery UI Dialog does seem to correctly swallow both  
>> mouse and keyboard events outside of the dialog, so it functions  
>> in a truly modal way.
>> Hope this helps,
>> Colin
>> On 22-Jun-08, at 4:18 PM, Jim Eng wrote:
>>> In the authoring environment for Sakaibrary's Subject Research  
>>> Guide tool, there are a few places where we need a modal dialog.  
>>> We have been using the jquery.simplemodal.js plug-in for that  
>>> (  It works  
>>> pretty well but there are some open issues.  In another project,  
>>> Noah Botimer is using the SimpleModal plug-in and has outlined  
>>> some changes he made to fix some of the issues we're having.  I  
>>> haven't had a chance to look at Noah's work yet.
>>> I am writing to inquire whether anyone else is working on similar  
>>> issues in sakai or implementing modal dialogs in other ways.  My  
>>> hope is that we can agree on a standard approach to modal dialogs  
>>> across sakai that will not have the problems we've encountered.
>>> Here's a brief description of the issues we are having:  When  
>>> launched, SimpleModal covers our current document with a grey  
>>> overlay (in a div) and shows the modal dialog in the center of  
>>> that overlay.  There are two problems with the way we have  
>>> implemented that using the SimpleModal plug-in.  First, our  
>>> document is in an iframe, so only that part of the UI is greyed- 
>>> out.  Ideally the entire sakai UI would be covered to make the  
>>> dialog more fully modal (i.e. the user would need to dismiss the  
>>> modal dialog before initiating some action within sakai but  
>>> outside the modal dialog).  Also, the modal dialog is centered in  
>>> the overlay, which may extend well beyond the visible portion of  
>>> the document in the browser window.  The user may need to scroll  
>>> up or down to see the modal dialog. I think it's likely that this  
>>> is a problem in our configuration of the plug-in, but I haven't  
>>> yet seen a way to fix that (still need to look at Noah's work to  
>>> see whether this is addressed there).  Our most immediate need is  
>>> to fix the positioning of the modal dialog so the user doesn't  
>>> need to scroll to find it.
>>> My major question is whether anybody else is working with  
>>> SimpleModal or other methods of implementing modal dialogs in  
>>> sakai.  Is there already a preferred way to do this in sakai?  If  
>>> not, does anybody have suggestions about how we should decide on  
>>> a preferred way to do this?
>>> Thanks.
>>> Jim

More information about the fluid-work mailing list