The Ajax preview version of live preview doesn't echo the preview text as it occurs; rather, it takes all of the text when a Preview button is clicked, but instead of bringing up a separate preview page, the text is echoed in the preview area.
The advantage to this method is that the application isn't as CPU-intensive, since it doesn't have to catch all of the keyup events. It's also much friendlier from an XHTML perspective since the input can be formatted for proper XHTML handling before it's displayed. Live preview is just that: live. No real formatting can be done other than to strip out markup.
The page demonstrating Ajax preview is identical to that shown in Example 4-9 except for a few elements in the script and the addition of an identifier on the Preview button. Example 4-10 shows the page with these modifications highlighted.
// add preview var commentText = document.getElementById("comment").value; modText = commentText.split(/\n/).join("<br />"); var previewElem = document.getElementById("preview"); previewElem.innerHTML = modText; } //]]> </script> </head> <body> <form action="preview.php" method="post"> <fieldset> <legend>Comment</legend> <label for="comment">Comment:</label><br /> <textarea id="comment" name="comment" cols="50" rows="10"></textarea><br /> <input type="submit" name="button" value="Preview" id="previewbutton" /> <input type="submit" name="button" value="Save" /> // Should these buttons not have different values for name? // </fieldset> </form> <div id="preview"> </div> </body> </html>
The event that triggers the preview now is a click of the Preview button. To prevent the default behavior, submitting the form, from occurring, the event is terminated within the event handler function.
With Ajax preview, embedding XHTML elements in the comment won't trigger an error while the text is in an incomplete state like it does with Firefox 2.x (at least, at the time of this writing).
However, if you put in "bad" XHTML and you're using a browser that checks the content with innerHTML, you will get JavaScript errors when you do assign the text to the innerHTML element. Throwing an error isn't a bad thing, but throwing a JavaScript error is.
A better approach would be to place the code setting the innerHTML element within a try...catch block and provide an error message meant for the web page reader, not the developer:
modText = commentText.split(/\n/).join("<br />"); var previewElem = document.getElementById("preview"); try { previewElem.innerHTML = modText; } catch(err) { previewElem.innerHTML = "<p>An error occurred, please check your comment for (X)HTML errors.</p>"; }
Opera will just correct (or tolerate) the bad markup, as will Safari, IE, and OmniWeb, but Firefox and WebKit both trigger the error handling. Unfortunately, theres no way to pinpoint the error--not unless we want to attempt to create an XML document and then see what happens--a rather drastic approach, and one that goes way beyond the usefulness of this effect. A better technique is to avoid all errors by stripping out the markup and providing buttons to allow formatting of hypertext links and such.
Again, if you don't want the risk of XHTML in the comments, either escape the HTML characters or strip tags out altogether.
Another nice effect you can use with commentary and the like, especially if all comments are listed in the page, is using Ajax to update the data store and then "refreshing" the list without having to refresh the page. Throw in a color fade, and you've got a nice bit of polish without too much code.
JavaScript 
/ 9 
