BlockUI instead of popup windows.

[Lafriks]

It would be great to have overlay dialogs using BlockUI ( http://malsup.com/jquery/block/) instead of popup windows.

[jf.hovinne]

MSIE looses selection if you don't use popups, so we firstly need to save it. Planned for 0.5.

[naneau]

I would like to vote for this future, the windows add unnecessary clutter to the user's desktop, and may easily lead to unintended behaviour of the editor. Also, modal windows within the browser are just... cool ;)

[jf.hovinne]

Actually we just found an effective way to save selection in MSIE and other browsers - popups will be suppressed in the next major version (0.6).

[mh]

Dont know if this is the right place to ask this, anyways: Is there a schedule for the release of 0.6? If not (or if it wont happen in the near future - which is what i suspect), what is the solution to save selections in IE? Is there already some code i could use with 0.5? Or at least some links that would push me into the right direction?

[litzinger]

Any update on this? I have a plugin using jQuery UI Dialog that is working really well so far, but it fails in IE. It would be nice if the fix for this could be released if you have one.

Is the change so drastic that it can't be included in the 0.5?

[mr_lundis]

I don't know what jfh is referring to, but Tim Down has a working "fix" for the loss of selection/saving it.

 http://www.timdown.co.uk/code/selections/

There's also a (F)CKeditor ticket regarding this - their solution might be of interest as well...

 http://dev.ckeditor.com/ticket/3001

For the insertion of content into the editor take a look at the insert method, if you haven't already done so.

Regarding your last question the only thing standing in the way for the release of 1.0 (prev. 0.5) is our Github migration. There are no more open tickets. Forcing this in now would risk braking something, it's a rather major change just like you say... So I think we should include this in the first 1.x release.

Is that okay with you?

Cheers, and thank you for making an effort with this. :)

[litzinger]

I tried Tim Down's method and not having any luck. I keep getting this error:  http://www.google.com/search?aq=f&sourceid=chrome&ie=UTF-8&q=Incompatible+markup+pointers+for+this+operation. on this line of his code: range.pasteHTML('<span id="' + markerId + '">' + markerTextCharEntity + '</span>');

I don't know enough about this range stuff to figure this out... would be nice to have modals :(

[jf.hovinne]

Hello, what about  http://code.google.com/p/rangy/ ?

[mr_lundis]

Rangy looks really interesting, it also looks like Rangy contains a newer version of the save/restore code. Any luck trying it out Brian?

If I understand  this correctly the cause of your error is that there's an input field that has focus somewhere on the page. You need to store the user selection as the first thing you do - before even opening the dialog. You might also need to make the buttons unselectable if they aren't so already, otherwise you will loose the selection...

[litzinger]

I am not getting that error anymore, but it is returning a null object when I try to restore the selection and close the modal. It's like it can't find the textures because it is in an frame. I will post the plugin code tomorrow... maybe you guys might be able to figure it out quickly.

[litzinger]

jQuery UI Dialogs plugin

[litzinger]

Attached is my plugin thus far. I'm loading it in the postInit callback, and you need to have the jQuery UI Dialog library loaded prior to all this getting called. As mentioned, it works pretty well in all browsers except for IE :( If this can be made to work in IE, then the plugin can be open sourced and be used as a viable option until WYMeditor 2.0 is released.

Sure you guys are busy, but it would be great if you had a few minutes to take a peek at this.

[litzinger]

Also, I'm interested in helping out with the 2.0 version as much as I can. I doubt my JS skills can be used to help with the core architecture, but I can try to contribute where possible, and can certainly help with the UI redesign too. Email me at litzinger at gmail dot com.

[mr_lundis]

I've taken a quick look at your code and I have two thoughts.

1. Are you sure your ".wym_tools a" click event fires before the "original"? Otherwise the dialog will open before you save the selection.

2. You will most likely need to use rangey inside the iframe. You can include it using conditional comments and then check for it in the source (if (wym._iframe.contentWindow.rangey && wym._iframe.contentWindow.rangey.saveRestore) and so on.) All this trouble is one of the reasons we're getting rid of the iframe in the future.

Also feel free to improve upon the dialog API, making it more flexible, etc. You could for example move out the dialog specific parts from the dialog and init methods into separate dialog objects to make it easier to modify them and/or add your own custom dialogs.

Also any help with 2.0 is appreciated, I'll drop you a line or two some time soon. The most imminent thing on my todo list is to get our Github migration going, I think that'll make contributing in the future a lot easier. :)

[sanhammer]

The  roulette sniper review has everything you need.

[samuelcole]

Hey guys,

I did a quick little port of the plugin here to my modal dialog implementation ( https://github.com/samuelcole/modal_dialog), and attached it here.

While I'm probably the only person who uses my modal dialogs, I also brought the code up to date with WYMeditor master in github, and cleaned up all the lint ( http://www.javascriptlint.com/).

I commented out the rangy plugin (I'm not targeting IE, at the moment), which probably defeats the whole purpose of this effort. However, I can confirm '.wym_tools a' click fires after the dialog opens.