Hi, I'm Ron Cormier. I'm the owner of a small software company where I design websites and build reusable web applications.

This blog is a work in progress but I plan on writing about website development, software design, information technology, and some of the projects I'm working on for Communicate Solutions. Check out my company's website, Communicate Solutions.com.
Sign in

Tags


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);

innerHTML using Internet Explorer

 

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

In today's article, I'll begin a two-part series on WYSIWYGs.  In part I, I'll explain what a WYSIWYG is and how they work.  In Part II, I will explain a shortcoming of the current implementation and my goal of improving the WYSIWYG for my content management system. 

What is a WYSIWYG?

WYSIWYG stands for What You See Is What You Get.  Pronounced wiz-ee-wig, it is a control which is used for creating rich text documents.  When you make a change to the document, that is how the finished document will look.  You don't have to write any code to make the document look like you want.  Almost all WYSIWYGs claim to have an interface similar to Microsoft Word.

Most WYSIWYGs are found on websites.  Even if you didn't know what a WYSIWYG was, you've almost certainly used one.  Most web-based email clients like Gmail, Hotmail, and Yahoo mail have WYSIWYGs for creating email.  

WYSIWYGs Under the Hood

Most web-based WYSIWYGs store the document as HTML code.  They make heavy use of javascript to manipulate the document DOM.  For example, when you highlight a word with your mouse and click the Bold icon, essentially what is happening internally is that the WYSIWYG finds that word in the DOM, removes it, and creates a new child node for the bolded text.  You can think of it like this:

Before:
<p>This is some text in my paragraph</p>

After:
<p>This is some <b>text</b> in my paragraph</p>

Of course you don't have to worry about the <p> and <b> tags, the WYSIWYG does it all for you.  You just type, click, highlight, and format to get the content to look how you want.

When you're finally done editing, you need to save the document.  As I mentioned above, the WYSIWYG stores the document as HTML code.  So, what happens is that the DOM gets translated to HTML.  To do this in Internet Explorer is to use the innerHTML property.  This property returns an element's inner HTML.  The HTML can be written to file or database.  The next time one wants to edit the document, the HTML gets rendered into the DOM and we are back where we started.

HTML to DOM, DOM to HTML.  This cycle can be repeated as needed.

That's it!

WYSIWYGs allow people to quickly and easily create content without having to write code.  Now that we know what a WYSIWYG is and how it works, we can talk about strengths and weaknesses.  Tune in next time for Part II where I'll discuss why this implementation won't due and how we're trying to improve it for ePortfolio.

Check It Out

As I've mentioned before, marketing is not my strong point.  It would be an understatement to say that marketing is Seth Godin's strong point.  Seth's blog is very highly regarded.  The topics of the daily posts about marketing and the way ideas spread are really insightful.  They always make me think.  Definitely addicting and worth it :) 

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5