We have been users of the Sourceforge system for a long time now, and personally I think that is has been going downhill for quite some time, more ads, more downtime, site is slugish and at the same time, nice alternatives have been poping up. For example, Google Code and if your brave, the Trac system that you can run on your own servers, been keeping an eye on that for some time and it seems very nice really. Only problem is that its made in Python, not to fond of that.

Spocke planned to make a release of TinyMCE today, but Sourceforge has been down almost all day and now the site is up, but the SVN isn’t, so we will see.

There are lots of fuzz around the ability to store contents offline these days. Using Google gears, local storage in the browser, Flash or Silverlight storage. I can see how these storage technologies can be useful for local applications to store user data without using some backend and having things like a local SqlLite database is really neat and handy.

But there have been lots of examples where the scenario is that you for example write to your blog when your laptop is in offline mode then commit the contents ones you get online. I think this problem is short lived since who will ever be offline in the future. We will have full 3G coverage, local Wifi spots all over, Internet connections on planes (some airlines have this already) so I ask my self when will we ever be “offline”.

I thought I might report a bit on the status of the browsers regarding WYSIWYG support and ContentEditable, watching the bugs we have reported, there have been quite a lot of fixing going on the last few days, both on Safari and Firefox.

Firefox
The features that they have implemented is quirky, but on the upside, they are further along than most other browsers in terms of functionality, if only the things they had worked properly, it would be great. One major problem with Firefox, that goes through many of their features, is the cursor handling, it jumps around and does not perform as expected.

Safari
On the complete opposite of Firefox, the things in Safari that they have implemented works very well, but the browser lacks certain important features. Overall, its looking very good, but its slow progress.

Opera
These guys are very fast as fixing bugs, there are some minor known issues with the back button at the moment, but other than that it’s very nice. We enjoy working closely with the Opera team.

Internet Explorer
We do not have as much overview of the current status of MSIE 8 development as we would like (if anyone at MS reads this, get in touch). Most of the stuff seems broken now in the latest 8 version, so we are basically waiting for the next Beta before we start to look into it more. But on the positive side, in MSIE 7, the things that work works flawlessly, there are a very low number of quirks compared to other browsers. It’s tough to report bugs and get them noticed however, so for any problems that does exist there isn’t much hope in getting them fixed.

So there you have it, our status report on current development in the WYSIWYG area of browsers.

Since we do quite a lot of HTML development from time to time, we come across quite a few companies that offer “Search Engine Optimizations”. I can’t say I haven’t met one that I don’t think is nothing more than a scammer, its simply a profession that should not exist, instead, hire good developers. We have come across SEO companies that got clients banned from several search engines during the whole “doorpages” area of optimization, and “optimizers” that didn’t know how to view the HTML of the website (hello view source?).

I mean, what is the point of actually coming in after the project to review the HTML/Layout/Content for Search Engine Optimization? What if we had our HTML totally wrong, are we going to redo the whole website? No, any optimization should be done during development, and any good HTML/CSS coder knows how to do a decent optimization.

I wish clients would spend their money on hiring a good copy to help them with some text instead, that is probably better for the indexing and usability of the website.

Except for coding good HTML and having good value content, there isn’t much you can do, except for links! Getting others to link to your website is very important in order to get anywhere in today’s searches.

So, as a conclusion… if you use TinyMCE or any of our stuff, we would appreciate any links you can give us

We have been working on project for minification, concatenation and gzip compresson of JavaScript and CSS files for a while. It started as a part of our commercial products but it has over time matured into it’s own project.

Since we do a lot of JavaScript development and the code base tends to be very large overtime we where forced to come up with solutions to reduce the download size for the users. We started this as a project for TinyMCE and there is a compression package available for that product but that was just the seed for these classes and we will in time replace the TinyMCE compression package with this one.

We have by intention not made it possible to for example send in the files you want to compress from the page level in a query string. This is to make the script more secure and it wouldn’t be that nice if there are like 30 scripts to compress. You can always make your own simple switch statement in the compression page to send out different sets of files depending on input.

Below is an example of a usage scenario it basically compresses a few files together into one request it will also cache the file to disk to reduce the server workload. The compression ratio is about 70% depending on content so it really makes a difference on bandwidth and overall traffic from the client to the server.

// Setup compressor
$compressor = new Moxiecode_JSCompressor(array(
   'expires_offset' => '10d', // 10 days
   'disk_cache' => true,
   'cache_dir' => '_cache',
   'gzip_compress' => true,
   'remove_whitespace' => false,
   'charset' => 'UTF-8',
   'patch_ie' => true // Fixes an IE bug
));

// Add files
$compressor->addFile("jquery.js");
$compressor->addFile("thickbox.js");
$compressor->addFile("syntax/shCore.js");
$compressor->addFile("syntax/shBrushPhp.js");
$compressor->addFile("syntax/shBrushJScript.js");
$compressor->addFile("functions.js");

// Output minified and gzipped contents
$compressor->compress();

So if you haven’t compressed your contents before we recommend that you give it a try since it will improve your clients user experience with a more fast loading site or system.

You can download the package and find more details about this project at moxieforge.net

No matter how much we test ourselves, it is impossible to predict all the various ways the editor can be used, I guess thats why Open Source is so great. Spocke started a while ago to setup UNIT testing and it has proved to be a very nice timesaver and removes a lot of those “oops” errors that happen sometimes, some code left behind or some change affecting more than was intended.

The problem with unit testing is that it can not test visual problems, like if the cursor doesn’t show up correctly after some action is taken. That is really where we need the help of the brave souls who try out the latest versions.

Another thing that we have to admit, is that we don’t use the editor ourselves enough, I mean for writing posts and articles the way our users does. We do a lot of CMS systems, and educate our clients etc, but we do not actually have time to sit down and write articles the way they might do it. This blog is nice for that, we already fixes one annoyance with the 3.0.7 version that we found while using it with this Wordpress blog.

I guess what we wanted to say was, thank you everyone for helping us with testing and suggestions, in the end making TinyMCE the best WYSIWYG editor.

That is a good question, a website we did several months ago and that we haven’t really officially released yet, don’t know exactly why, busy I guess. But we have been putting up some projects there, stuff we have made ourselves and thought we could share with others. But mostly, the website is for us, to have a repository of the things we use every now and then in projects etc.

By releasing these various scripts etc, we also force ourselves to write a bit of documentation and comment our code a bit better so that other ppl actually can use them. We where also thinking of inviting 3rd-party developers to post their things on this website, with a focus on high-quality code (not just anything).

So go ahead, visit www.moxieforge.com

We spend a lot of time on the bugtracker systems of Opera, Safari, Firefox and Internet Explorer, most seem to have a very casual approach to fixing the issues that we and other developers find regarding the support for WYSIWYG editors. It feels like we are annoying them when bumping and commenting on various bugs and issues.

Why is this not higher on the agenda? Behind most websites are some form of Content Management System, and most of them have some form of WYSIWYG editor for handling normal text content, if the tools we have where better and the bugs fewer, these systems would produce better code, and in the long run improve the web as a whole.

There are certainly other tools/filters that can help improve the code before its actually published, but you would think, that the very browser that is suppose to parse and understand the code, could actually produce understandable code themselves when it comes to editing.

We recently found a serious bug in IE where the unload event wouldn’t fire on a specific page we had on a site. After some bug tracking we found out that the unload event never fired since all the contents of the page hadn’t finished loading before we navigated to another page.

This is a major problem since the unload event is commonly used to clear circular references etc in IE to prevent memory leaks. So this bug makes all Ajax libraries/frameworks out there that depend on the unload event on IE to fail if the page is unloaded before the contents of the page finished loading.

Here is an example of the bug, run the page in IE and follow the instructions on the page. Below is JS source code that is used on that page.

function unload() {
	alert('Unload event occured.');
};

window.attachEvent('onunload', unload);

After some digging around we finally found a solution for the problem. The beforeunload event is fired correctly in IE but since this event can be blocked by setting the returnValue to an string value we couldn’t just add the memory cleanup logic there since the user might press cancel on the beforeunload event confirm dialog and then we would have removed all events on the page. So we needed to detect when the page was unloaded and we found out that the stop event can be used to detect this. It fires when the page is unloaded but unfortunately it also fires when the user pressed the stop button in the browser so we needed to add a fix for that as well.

Here is an example of the fixed version. You notice that this will fire the unload event correctly. Below is JS source code that is used on that page.

function fixUnload() {
	// Is there things still loading, then fake the unload event
	if (document.readyState == 'interactive') {
		function stop() {
			// Prevent memory leak
			document.detachEvent('onstop', stop);

			// Call unload handler
			unload();
		};

		// Fire unload when the currently loading page is stopped
		document.attachEvent('onstop', stop);

		// Remove onstop listener after a while to prevent the unload function
		// to execute if the user presses cancel in an onbeforeunload
		// confirm dialog and then presses the stop button in the browser
		window.setTimeout(function() {
			document.detachEvent('onstop', stop);
		}, 0);
	}
};

function unload() {
	alert('Unload event occured.');
};

window.attachEvent('onunload', unload);
window.attachEvent('onbeforeunload', fixUnload);

The only problem we still have is that if you hit F5 and force a refresh the unload event will still not fire. So if anyone has some good ideas on how to fix that it would be more than welcome.

Oh what pain memory leaks are. Normally these are pretty easy to battle just clean up everything after your self but yesterday I found a new one that produced leaks all over the place.

If you attach an beforeunload event handler to the document it will start leaking in all event handlers even if you make sure to unregister them on page unload so basically if you use beforeunload on the document you are screwed.

It didn’t matter if you unregistered the beforeunload event on unload it just leaked and it only happened when TinyMCE was placed in a frame or iframe oddly enough.

We have been focusing a lot on memory management for TinyMCE the latest couple of days since users tend to do Ajax stuff these days and never leave the page it’s important do remove all references when a editor is removed dynamically from page there are still things to do here but it’s a lot better now.

I guess all browsers leak a bit of memory but on IE the whole browser will get very very slow if it starts to leak. It’s like every DOM API call needs to first loop though the old references before finding target elements.