I've been using this (as well as helping give feedback on it after I developed my own and realized this one is better). This is by far a much better solution because it handles responsive resizing, z-index and smaller devices a lot better.
Issues have been opened referencing this modal and there has been no response from @mdo or @fat on it other than to say that they were working on it themselves for a future version.
This is pretty awesome, I'm going to be using it for sure. As the title suggests I definetly think it is much better than the standard bootstrap modal. You should try to get this implemented into bootstrap. Good work.
I have found one case where it makes sense. Say you have a modal popup with an 'editor' widget in it. If that widget then needs to popup another modal for adding a link, it makes sense. Here is a screenshot of what I'm talking about...
True, I could resize the modal to be a lot larger, but it hasn't been a big issue so far. I do like it in a modal because it allows me to enable/disable the Save button depending on if things change (although this doesn't work now that I've switched to Redactor since they don't support figuring out that info yet... feature request has been submitted). All of my UX does editing of form fields in a modal, for consistency, it is nice to keep things the same.
It's a very common pattern in desktop software (complicated config panels, for instance). I don't think that makes it "good" but at least it's well understood. It's dumb that most existing modals can't do it.
I think we agree, at least in principle. Bootstrap is meant to facilitate quick prototyping, though--quick prototypes for complicated flows will include sub-optimal UI.
Desktop solutions I'm talking about: anything in Windows control panel (people still use that OS, God help them), any configuration panel in Ubuntu (go modify your network settings, for example), all sorts of horrible-to-use and yet somehow magically-useful simulation/CAD programs, etc. (A common theme here is that Apple software and most software created for Macs does not have this UI pattern, because it is indeed suboptimal. The rest of the world still sees it a lot.)
I think it's a terrible UX the way it's presented, but there is definitely a use-case for the functionality.
Say you have a modal that contains a step-by-step process. Now you can load multiple modals, and dismiss them one at a time. To a user, it will look like s/he is moving through the steps.
Is this a good use? Ehh...maybe not, but it's possible.
Just brainstorming here.
You know what's really awesome about this Modal? Unlike built-in one, this one works on iPhone without issues! Long window scrolls just fine. You just made me so happy :) Definitely using in something I am currently working on. Thanks!
"If you want to prevent the background page from scrolling (see demo for example) you must wrap the page contents in a <div class="page-container">.
The reason for doing this instead of just simply setting overflow: hidden when a modal is open is to avoid having the page shift as a result of the scrollbar appearing/disappearing."
This is fantastic, I will definately be replacing my bootstrap modal code to use your library. This would be great if this got committed into bootstrap.
Definitely prefer this to the default modal, which blacks out the screen around it. I'll have to run some tests to see if any version of IE can handle this.
Is it really worth installing an entirely new library just to achieve something a simple line of CSS could do?
.modal-background { background:white; }
For me, Twitter Bootstrap's components have been the right tradeoff between flexibility and functionality. It doesn't have too many bells and whistles which makes it way easier to integrate into my own code.
Maybe I just haven't run in to the use cases for Bootstrap's modal that causes the pain that this fixes, but most of these "features" seem like "it would be cool if..." product cruft.
That isn't the question. The question is if jschr's modal implementation is more (or less) bug free than bootstrap's. Based on my analysis and many others, it is more bug free. Feel free to read through the issues. https://github.com/twitter/bootstrap/issues/search?q=modal
The first that I personally have seen so far that doesn't screw up when zooming in on a mobile device (actually resizes and re-positions itself), so great job! I'm sure there are others, but this one is now the best in my opinion solely based on that regard.
It suffers from the same bug as the stock bootstrap modal; focus is not contained in the popup window. Press tab a few times and soon your keyboard focus is on elements on the page behind the modal.
Well, I actually submitted a pull-request almost a year ago but it was rejected for "complexity"...
I didn't understand that decision back then and I don't understand it today. The patch weighs in at about 100 lines which doesn't seem heavy to me. Especially when you consider that without the patch the bootstrap-"modal" is not a modal...
Anyway, here's the fixed bootstrap-modal.js for the version that was current back then:
Line 23-82 is the important bit, that snippet is lifted nearly 1:1 from jquery.ui.dialog which fixed this issue ages ago. Beyond that there's only a couple lines of glue code.
Feel free to port this forward to the current version (or better-modal). Personally I've stopped using the javascript parts of bootstrap because I don't want to maintain forks for basic bugs like that.
Thanks for this. Currently I have a workaround by using data-tabindex instead of the standard tabindex but I've been trying to find a more robust solution to this problem so I'm going to take a look at implementing something like this.
That:
1 - enables focus on the modal div
2 - hides focus visual indicator on the modal (because it's not an interactive element, just a wrapper)
3 - sets focus on the modal
The user's next tab keypress will select the first focusable element inside the modal.
Restricting tab keypress to just elements inside the modal (ie cycling through only modal content) doesn't return significant benefit and it's a whole lot more work. It's easy for a user to error-correct by simply clicking back inside the modal, but it's hard for a developer to manage enabled/disabled states for native behavior.
72 comments
[ 1.7 ms ] story [ 134 ms ] threadIssues have been opened referencing this modal and there has been no response from @mdo or @fat on it other than to say that they were working on it themselves for a future version.
After checking out the live demo, I have no idea how "stacking" modals could make a good user interface.
http://www.evernote.com/shard/s178/sh/003f6b5e-0869-44af-ab9...
This is also using the bootstrap modal solution referenced in this article. Redactor is the editor widget.
Just because you can get away with doing something poorly, doesn't mean you should.
Desktop solutions I'm talking about: anything in Windows control panel (people still use that OS, God help them), any configuration panel in Ubuntu (go modify your network settings, for example), all sorts of horrible-to-use and yet somehow magically-useful simulation/CAD programs, etc. (A common theme here is that Apple software and most software created for Macs does not have this UI pattern, because it is indeed suboptimal. The rest of the world still sees it a lot.)
Say you have a modal that contains a step-by-step process. Now you can load multiple modals, and dismiss them one at a time. To a user, it will look like s/he is moving through the steps.
Is this a good use? Ehh...maybe not, but it's possible. Just brainstorming here.
Similarly for adding any foreign key item which could be multiple levels.
Django admin does this now by opening a "new" in a different window.
There's a solution available which avoids wrap and page shift too. Take a look at: https://github.com/atirip/bodyscrollkiller.js
also see my other comment with regards to patching it for abs positioning
edit: current alternative is http://fancyapps.com/fancybox/
you might want to take a look at grabbing what you can from my project for abs positioning:
http://niftylettuce.github.com/twitter-bootstrap-jquery-plug...
Maybe I just haven't run in to the use cases for Bootstrap's modal that causes the pain that this fixes, but most of these "features" seem like "it would be cool if..." product cruft.
I didn't understand that decision back then and I don't understand it today. The patch weighs in at about 100 lines which doesn't seem heavy to me. Especially when you consider that without the patch the bootstrap-"modal" is not a modal...
Anyway, here's the fixed bootstrap-modal.js for the version that was current back then:
https://gist.github.com/0d04646ab6cf4df50610
Line 23-82 is the important bit, that snippet is lifted nearly 1:1 from jquery.ui.dialog which fixed this issue ages ago. Beyond that there's only a couple lines of glue code.
Feel free to port this forward to the current version (or better-modal). Personally I've stopped using the javascript parts of bootstrap because I don't want to maintain forks for basic bugs like that.
modal.attr('tabindex','1').style('outline','0'); modal.focus();
That: 1 - enables focus on the modal div 2 - hides focus visual indicator on the modal (because it's not an interactive element, just a wrapper) 3 - sets focus on the modal
The user's next tab keypress will select the first focusable element inside the modal.
Restricting tab keypress to just elements inside the modal (ie cycling through only modal content) doesn't return significant benefit and it's a whole lot more work. It's easy for a user to error-correct by simply clicking back inside the modal, but it's hard for a developer to manage enabled/disabled states for native behavior.