WYSIWYG Cross Browser Editor
I came across this pretty nifty in-page HTML editor tonight called openWYSIWYG. The claim it was the ultimate cross-browser editor, but it didn't support Apple's Safari browser. Go figure. I liked it though. It's small and light and so far it seems like you can modify it fairly easily. Compared to FCKEditor or TinyMCE, which seems like brain surgery whenever I poke around in their code.
Well as of tonight, the Safari limitation has been changed. I have successfully modified the source to allow my brethren to enjoy it as well.
I fixed the bugs, now what?
Well, I'm back, relaxed and dove straight into working on the Safari fix for openWYSIWYG. I figured out the issue when attempting to insert a new TABLE into a blank editor window. That little bug has been squashed. You can grab the the Safari version by visiting this CJBoCo Brew House.
So, what next? Well, that's a darn good question. I still think this editor needs some improvements to make it more cross-browser friendly, make improvements on the some of the core functions (especially some of the node functions), improve how it handles the HTML code and a few other things that I think it needs help on.
Improving Upon Wiki
I've been working on a little ColdFusion side project to improve my site for the past couple of days. I wanted to create a Wiki-Like portal that would allow me to post most of my ColdFusion and JavaScript snippets and also give the users the ability to add their own or make improvements by using a wiki like environment. I took a look at Canvas ColdFusion Wiki and I have to be honest, I really don't like working with the ModelGlue framework. I think it's great for some people, but I like to keep things simple.
Revisiting SES's
If you read my last post on Search Engine Safe (SES) URL's, you may have noticed that it was pretty basic. But like everything I post, it's kind of a work in progress.
Anyways, I've been working on a project and I had to revisit using SES's and I discovered another trick. Basically what I had before, using a URL parameter, should still be valid. If you don't remember, it looked something like this:
http://www.whatever.com/products.cfm?id=2369/accessories/gloves/Fuzzy+Pink+Mittens/
Safari Caching Problem
Boy, I don't know how long this one has been a thorn in my side, but if you have ever tried dynamically creating or changing the content of an iFrame and you use Apple's Safari browser, then I'm sure you have run into this issue. For what ever reason, Safari caches the source (url) of an iFrame and whenever you try to change it's content, it wants to use the old data.
Well, not anymore. I came across a great little trick tonight and I though I would share. All you have to do is change the ID of the iFrame and Safari will update it with no problems. So if you're creating iFrames on the fly, just use this little JavaScript snippet:
iFrame.id = "IF_" + new Date().getTime(); // prevent Safari from using old data.
This can easily be modified for other languages. And if needed, you can update the SRC and then change the ID back to another name. (Useful if your using a custom CSS style for the element).
Hope this saves you a headache!
