Actually incorporating the Rich Text Editor

Posted on Saturday 12 January 2008

May be more difficult than building it..

The rich text editor is built into an ASP ‘control’ so it can be re-used and customized server-side, currently all of the HTML for the textarea, iframe and toolbars are put into the page through this control depending on it’s properties. A script tag is embedded into the page just below this HTML and links to an ASP page and the js is customized depending on variables in the session.

<script type=“text/javascript” src=“functions.asp”></script>

This is a fairly hefty script and I imagine, not being able to cached would slow down the pages considerably.

Putting the new editor into this control was pretty straightforward, include the link to the javascript if the control is used. Edit the Draw() function to output:

<textarea name=“{id}”, id=“{id}” style=“height: {height}; width: {width};” class=“PURichText”>{content}</textarea>

Simple, change those things and correct the links to the css and images and it should just work..

And it did, in Firefox, Safari and Opera.. IE had soiled it’s undergarments though.
Ahhh, Quirks Mode!

The admin system was designed to work in Internet Explorer only, it was probably first built at a time when IE5.5 was the most widely used browser - And of course when IE6 came out it didn’t make much sense supporting two separate box models.

Don’t add a doctype and the page will continue to look the same in IE6 and any future releases of IE - it was probably the most logical choice at the time. But of course now, we know better :)

The only way to get cross-browser consistency and some of the more advanced features out the browser - you must render the page in standards-mode. So it seems incorporating the editor has put another task on my agenda. Fixing the styles across the whole admin system to work in standards-mode. This is a fairly big undertaking as the stylesheet is about 4000 lines and some of the styles are rendered out inline by the controls, so there will be lots of digging to fix all of the styling that was relying on IE’s buggy implementation.

It was interesting to see how badly the page broke just by adding the doctype.

After fixing the styling issues to work in Standards-mode and incorporating the editor, I will continue to make the rest of the controls and pages cross-browser compatible. It’s not a goal too unrealistic - The system as a whole is not all too far off being cross-browser, just A Lot of little things that are sometimes hard to get to.

document.all[] is used all over the place, so I just need to go through and add id’s to all the elements that were being referenced by name attribute alone - and change the document.all’s to document.getElementById()

Any traces of Active X controls need to be killed, burned and holy water sprinkled on the ashes.

Any attachEvent’s will need to become a cross-browser alternative.

Dialogs are opened using IE’s showModalDialog functions these all need to be replaced with the standard window.open method.

The innerText property is used to get just the textNode’s values from within an element, being IE only i’ll need to change any uses of this to a little DOM walking.

Just lots of little things.. may the force be with me.


No comments have been added to this post yet.

Leave a comment

(required)

(required)


Information for comment users
Line and paragraph breaks are implemented automatically. Your e-mail address is never displayed. Please consider what you're posting.

Use the buttons below to customise your comment.


RSS feed for comments on this post | TrackBack URI