It has been a long time, but these days I'm going to try to push a new stable release of Write Area. It will be mostly an upgrade to the current CKEditor 3.6.1, but at the same time I'm gonna try to finish some code that it's available in the betas and provide a simplified version.
The main change will be the removal of the option to select whether to open the editor in a bottom pane or in a dialog. My plan is to finish the behavior of the new "integrated" mode, so that whenever you select to use Write Area with a normal textarea then it will be replaced by a CKEditor instance integrated in the same page. This is similar to what the "bottom pane" provides, but with the advantage of being able to create more than one instance, and the rest of the scripts of the page can get direct access to the contents as if nothing had happened.
If you try to use instead an existing editor that isn't too compatible with the current Firefox or it's missing features, then the editor will be launched in dialog mode. The plan is to do this automatically without the need to select a preference.
Why?
First: Simplify options.
More options means more testing, harder for the user as he has to think about what's better. I can't claim that I know better than him what's better for him, but I know what's more job for me.
Second: Try to avoid future problems due to changes in Firefox.
The bottom pane is a "XUL overlay", that means that it's somehow quite integrated with Firefox, and in the future the plan is to try to move as much extensions as possible to the Addons-SDK. That means that such integrations might be harder or just impossible. If I start removing these blocks I can try to test if it's possible to port the extension to this new world. Anyway that goal is quite far away as I've stated previously that I won't start using the Addons SDK as long as they require to install Python or any other third party libreary/compiler/whatever.
Third: Other browsers.
By using a simpler approach it's possible to create a Write Area version for Chrome, and although I don't use it I understand that other people do, so if there are just a few differences then I can provide a port of the extension. It won't be as feature rich as the Firefox version, but at least is something that people can use.
Conclusion
If you have a strong reason to believe that I'm making a mistake the I would like to hear your concerns. Otherwise I'll go ahead and release the update when it's ready
9 comments:
I just got updated to version 1.0.1beta6 and the changed make it so I can no longer use it in certain situations.
I noticed that the option to have it pop up in a new window was removed. I actually liked that and thought it was useful. Also, with the pop up, it is possible to exit out of the pop up *without* saving your changes, which has saved me many times in the past. The embedded one does not give that option.
And the second problem I have is it rewrites code that I need to stay. For example, we have an internal tag that is processed server side before releasing the HTML. This allows everything between and to only appear when accessing from certain IP addresses (such as the office). Write Area does not delete the tags, but moves them so they no longer surrounds the text that is for employees only, hence causing problems.
Is there some way to specify as a valid tag and prevent Write Area from rewriting those tags incorrectly?
Blogger edited by post. Let's try again.
And the second problem I have is it rewrites code that I need to stay. For example, we have an internal tag <employees> that is processed server side before releasing the HTML. This allows everything between <employees> and <employees> to only appear when accessing from certain IP addresses (such as the office). Write Area does not delete the tags, but moves them so they no longer surrounds the text that is for employees only, hence causing problems.
Is there some way to specify <employees> as a valid tag and prevent Write Area from rewriting those tags incorrectly?
I meant lt;employees> and lt;/employees> of course.
Also, is there any way to specify which style sheet it uses in the editor? It would be nice if the content looked the same in the editor as it would on the page. Thanks,
Um, sorry. The new close button at the top right should have removed the instance and leave the contents untouched. I've been more focused on getting it displayed correctly at the right place instead of checking that it was working as expected.
With regards to custom tags, I'm sorry but I think that you might be wrapping some content in a way not expected by the browser or CKEditor, and that's why you get the problem. In some cases it's possible (with a CKEditor plugin/modification) to allow certain new tags, but others it's much harder.
Anyway, allowing such custom tags it's not one of my goals at the moment as it might require some extra knowledge about the tags used.
Allowing or somehow guessing the correct stylesheet it's indeed something that I would like to add, but I just need to think about how it can be done so it's easy to use and it works most of the time or always.
I've uploaded right now a version that cancels the changes when the integrated version is closed and also now it can save/load the contents.
Following the comment at a previous post, I've canceled the current 1.1.0 that was waiting to be reviewed as stable (I guess that it might have reached the top of the revision queue tomorrow or Monday), and have published a beta 10 to warn if the close button is used, and allow to use the Save command to update the textarea closing the editor.
If no one reports any other problem I'll upload this one as the new 1.1.0 stable.
Will you be updating the product so it works in the latest version of Firefox? I find that currently if I make a lot of changes, I can't save them.
I'll try to verify it, but I think that it's working fine for me (and I'm using Aurora, so that's 2 versions ahead of the normal one)
That comment about "lot of changes" makes me thing that your problem might not be related to something slightly harder to debug, so it would be great if you could provide me a set of steps to understand your problem
This weekend I added a new beta that it's updated to CKEditor 3.6.5 and adds back the option to launch the textarea replacement in a separate dialog.
I'll add that option in the preferences and if everything is right I'll push it as a general update.
If you don't state some steps to reproduce your current problems, I won't be able to fix them and they will remain there.
Post a Comment