A test demo is visible here.

Cool, thanks for the thoughtful write up. I like it 👍

I think the backwards-incompatible consequences are minor and are worth it:

.blocker can't be styled in JS only, because of the ghost technique. So it has to appear in the plugin stylesheet. Also, we can't apply opacity on it anymore, now that it contains the modal, so this has to be replaced with CSS rgba(). That also means we can drop the overlay and opacity options.

I think this makes the library better :) I prefer moving as much of the styling into plain CSS as possible, and am all for removing configuration params.

since centering is performed using CSS instead of JS, the plugin will probably fail to work on IE<8. That also mean the center() method can be dropped.

Sounds good to me — we'll just make a note of the compatibility in the README.

If you decide to go with this solution, some extra cleanup should follow (mainly remove center(), overlay and opacity from the docs and the examples). I can take care of it if you need.

That would be MUCH appreciated — thank you!

Here it is. You should be able to merge now. The latest commits include the following changes:

• entire styling has been moved to the CSS file
• overlay, opacity and zIndex have been removed from the library and the docs
• the resize() method has been removed
• example 3 has been reworded

Is there plans to write a breaking changes section?

That's a good idea. It could fit either in a changelog file or in the releases page.

Awesome :) Yeah I've actually been meaning to add a CHANGELOG.md file but haven't gotten around to it. We can use semver to indicate that there is a backwards-incompatible change, and then document the details in the changelog.

We're currently at version 0.5.10, so presumably this would bump it to 0.6.0. @xfra35 Would you mind preparing a changelog file? I think then this is good to merge 👍

@kylefox: Increasing to 0.6.0 is satisfying semver as the first zero indicates the software must be considered unstable. 👍

Are we only waiting for the CHANGELOG.md? If so, would something automated like https://github.com/stevemao/gulp-conventional-changelog be OK?

Thanks for bumping this — yes, this is basically just waiting for the CHANGELOG.md. Conventional changelog looks good, however I don't have much time to investigate / set it up right now, so PRs welcome.

I included the machine-generated CHANGELOG.md, I think you could merge that pull-request and if you wish, make a commit where you strip information you feel is not necessary per each version change (I do not have such a vision of the project history to do that). The script will only append to the beginning of file since last released version, so those changes will then stay.

Including the right magic words in the commit messages in future will require less cleaning up after running gulp changelog.

Hey @joonas-lahtinen, thanks for digging into this! 👍
I really couldn't find time for it these days.

Thanks, #133 has been merged! 🍔