This is Part II of a two-part series on WYSIWYGs. In Part I, we covered what WYSIWYGs are and how they work. In this article we'll look more closely at what happens when you save your changes and why they butcher/maim/ruin your code.
As mentioned in Part I, when it is time to save your document, the DOM gets translated to HTML and can then be saved to file or database. The document is typically an inline frame (iframe) located within another web page. Let's assume the iframe has the following HTML:
<html>
<body>
<p>this is a test paragraph 1</p>
<p>this is a test paragraph 2</p>
</body>
</html>
There's a few different ways to translate the DOM rendered by the browser to HTML which can be saved. One way is to get the frame's innerHTML. Assuming the WYSIWYG is in the first inline frame, you can use the following javascript:
alert(window.frames[0].document.body.innerHTML);
Executing the above javascript in Internet Explorer would show a dialog like the one to the right.
This method is handy for most situations. The problems begin when you care about the markup that you originally wrote. For example, notice any differences between the dialog to the right and the HTML snippet above? One big difference is the paragraph elements are capitalized in the image even though they weren't capitalized in the HTML. What the heck?!? Another difference is the white space gets ignored when getting the innerHTML. The second paragraph should be indented when compared to the first paragraph. Annoying!! Firefox is guilty of changing the markup too. While Firefox is better at retaining white space, it changes all HTML tags from uppercase to lowercase.
This can be a nightmare. Image you've spent some time developing a website with an IDE like Visual Studio or Dreamweaver. Want your clients to be able to update the content themselves? Well as soon as they do an update with the WYSIWYG, they're going to completely destroy your code's readability. When you try to look at the code after your client's update, it could be completely different. This is unacceptable.
I've decided to design a WYSIWYG that is friendly to both technical and non-technical users. Whenever the client makes a change in the WYSIWYG, the change also gets reflected in the code without messing up the code. This is done by maintaining a copy of the code along side the WYSIWYG. Formatting stays the same. Capitalization stays the same. The code actually looks the same before the WYSIWYG update as after. Imagine that? No patience necessary :)
To see it in action, check out v1.6 of ePortfolio, the CMS for ASP.Net developers (coming soon!).
Be the first to rate this post
- Currently 0/5 Stars.
- 1
- 2
- 3
- 4
- 5