jQuery Forum

I've started work on this for discussion.

I'm using .live() for event delegation so that the implementation is efficient even with large doms.

Have a look here:

http://github.com/pete-otaqui/jquery-ui/blob/master/ui/jquery.ui.dialog.js

The key part is:

1. lockFocus: function($el) {
2.   var focusables = $(':focusable',$el),
3.     firstFocusable = focusables.first()[0],
4.     lastFocusable = focusables.last()[0];
5.   $(':focusable').live('focus', function(event) {
6.     if ( $.inArray(event.currentTarget, focusables) == -1 ) {
7.       firstFocusable.focus();
8.     }
9.   });
10. }

This is very much a first-pass, and I'm currently working on adding support for varied tabindexes in the dialog tabbable elements, and also for shift-tabbing backwards.

This works across all the browsers I've tested it in (Chrome, Firefox 3, Firefox 4, Safari 5, IE 6).

The biggest issue is that, since it uses .live(), it suggers from all the same potential pitfalls that the original method does - however I feel that this is at least worth considering that the current implementation is broken everywhere except firefox.

Hey Pete,

Hi Scott,

thanks for replying.  Taking your points in order:

You bind with .live() on every open

Yes - although I am also die()ing on every close

You don't account for the contents of the dialog changing after open

Also true.  This had occured to me but I was a little dubious about the cost of getting :focusables on every focus with complex dialog doms.

I'll definitely think about binding to blur and checking event.activeElement.

For the reverse tabbing, I am looking at binding to keypress on all :tabbables within the container, returning if the key wasn't tab, and then checking for event.shiftKey.  This is then used when an external :focusable item gets focus (which I think is only possible by using tab) to decide which way to go.

Fortunately we have some screen reader users in our organisation and we can run some user testing for accessiblilty which (almost) always brings up some more issues to code around.

Hi Scott,

I've been putting some time into this, and you can see how I'm getting on here:

http://github.com/pete-otaqui/jquery-ui/blob/master/ui/jquery.ui.modal.js

There are a couple of visual tests too, for example:

http://github.com/pete-otaqui/jquery-ui/blob/master/tests/visual/modal/modal_large_internal_dom.html


Some notes:

* I've moved to using .bind() instead of .live(), and to using the 'focusin' event since that bubbles.

* I've copied some some code (overlay size & content positioning) over from jquery.ui.dialog.js

* I've added in capturing tabbing out of the first and last (in source order) tabbables to stop focus going around the browser's chrome.  This mimics the current modal dialogs behaviour in FF.

* All event callbacks are their own methods, so that unbinding is safer.

* There's a bug in Opera 10 on OS X (and possibly others) where some loop-around tabs are doubled, skipping a field.  You can shift-tab back in to the skipped field.

* The "overlay" part is still internal to "Modal", but as with dialog this could probably be pulled out nicely into its own class.

* Some of the methods (e.g. _lockFocus, nextItemByTabIndex, _trackFocusedElement, _trackShiftKey and _captureTabOutOfEdgeElements) are effectively "static".  I did this so that they are easy to refactor and re-implement.

* There must be a cleaner, and probably more efficient, way of sorting focusable elements while maintaining source-order in cases of equal tab index values.


There are some things that I have consciously not addressed yet:

* Instance re-use
* Multiple modal elements (e.g. something in a modal opens another modal)
* Modal content larger than the viewport
* Proper theming


I'd be interested to know what you think!

Pete

I'm gradually moving this work over to the team's fork of the project on guthub, rather than my own one.

In our terms, a "modal dialog" is called an "overlay", and since all our work is currently called "GEL" (which I gther stands for Global Experience Language) we've prefixed our widget names.

You can see our "gelmodal" and "geloverlay" here:

http://github.com/bbc-frameworks/jquery-ui/tree/geloverlay

We've moved this to a new branch, which contains both our "gelmodal" and will host other widgets we develop for our "gel" set:

http://github.com/bbc-frameworks/jquery-ui/tree/gel

We have an "overlay" in our set (called "geloverlay") which is similar to the modal mode of dialog (but doesn't have quite a lot of dialog's chrome around it).  Because for us the name "overlay" was already in use, we've now called the grey background widget a "gelscreenmask".  We would have used "mask" directly, but that is something you are using for input fields.  This gets a little confusing in our discussions, but we're mostly there now.

If you look at our gelmodal widget, you can see that it now contains gelscreenmask to manage the backgound layer.  This manages instances and zIndexing in a similar way to the current "dialog.overlay" setup, with the extra feature of hiding elements that cannot be masked (the theory here is that the bgIframe is actually not quite enough in all cases, and we can add more to the list of the things to hide like flash in Opera).