Outer Court

Tech - DOM/ DHTML - Sample

Intranet page editor

I made an Intranet page editor for IE5. There is a navigation frame which "grabs" the page node of the content frame (which is HTML4 Strict) and loads the editor in the content frame.
On body load the editor now shoves the page node into itself. The trick is, the editor links an external stylesheet which attaches "editable" behaviors to all paragraphs, headers, addresses, table cells, etc. which are contained inside the page node. All the dialog boxes are contained within the editor, but outside the page node.

When the user wants to save the page, the page node overwrites the old one using ASP. Since just the page node, and not the header links or onload events, things like scripts or special styles still work.

Dialog boxes

The dialog boxes contain buttons, textareas and other form type of elements. They are opened after a behavior tag event call fired. The Ok button later triggers a certain sendDlg event in the main JS. For info on how to simulate things like Windows Dialog Boxes, see DHTML popup-folders

IE5 changing HTML

As soon as you apply text to the page, either by changing it's content textually (the IE4 inner- and outerHTML) or via DOM, IE5 changes it. For example, it creates upper-case text. HTML's DOM is by standard expected to return tags as upper-case, like you get a "DIV", even if you put a "div" into the page a second ago. Also, it changes sources of linked data... like images src's or links href's... as soon as you assign new sources or shove the page node from one place to another, the links will be made absolute (http://...etc). You got to actually parse the node in ASP textually and replace back this stuff (or you know a better way).

From dynamic to static styles

If the original page contained dynamic style changes (in this case it was the highlighting of the current weekday table row), these will now be hardcoded into the new one... saving back over the original, you end up with unwanted inline styles! Workaround was to use explicit redundant "de-hiliting" of the whole week.

Leaving lists open

A perfectly closed list of the type:

    <li>Sample text 1</li>
    <li>Sample text 2</li>
    <li>Sample text 3</li>

was sometimes changed to:

    <LI>Sample text 1
    <LI>Sample text 2
    <LI>Sample text 3</LI>

The important difference is not the case, but the missing closing tags (yes, they're optional).

Unquoted attribute values

To get further away from any XHTML type of writing, values where quotations are optional (like, not href's, but other stuff) are trashed...

Easy editable markup

Structured content, form/content seperated HTML4 Strict (which is the Simple HTML), and no use of inline styles/ scripts made it relatively easy to transfer the page to the editor. Also, it was a plus to wrap up every body inside an additional "page" node (originally to control width).

Hardly editable markup

Similar content which is marked up a little different can make for lots of extra work... since you don't want to parse every node the user wants to edit and present a fitting dialog... think twice before creating special-case styles, or write down where you used them if the site's getting bigger. I think streamlined mark up (like by copying similar tag constructs) makes for easier DOM processing afterwards.

Uploading files

To change a source of a picture, you have to scroll to different input type "file" boxes... displaying a new box each time a new pictures is inserted... and adding an ID to the image and keeping count and so on. Since I didn't keep count of images in manually created pages, I had to increment an image pointer, inserting ID's. Maybe not the easiest way? These input boxes had to be wrapped up in a form element (the name of which has to be used in your DOM referencing, as opposed to normal ID's). The final upload was done with a File Artisan Upload tool which makes for simple multi file upload once you know how it works.

Strange body unOnload event calls

Using a security message box when the page is left (code copied from somewhere)...

function unloadMess()
  return "You're leaving the editor...";

function setBunload(on)
  window.onbeforeunload = ( on ) ? unloadMess : null;


...caused strange behaviours when A HREF is pressed... any kind. , a href="mailto:...", a href="javascript:..." and so on.
A workaround for page links (a href="#name"):

  <span onClick="topic.scrollIntoView()">Go to Topic 1</span>


  <a name="#topic1">Here's Topic 1</a>

Another unwanted effect: the unLoad dialog box always puts in some browser default text before and after your text ("do you really want to leave the page" etc.)


Make a donation