The control is fast, well tested, extensible, and competitive.


The HTML edit control is smaller and faster than a typical WYSIWYG editor, which loads a whole unmanaged browser with extensive JavaScript.

There are three performance metrics, as follows:

Time Required to Load a Document

The HTML used for performance testing includes 30 KB of text, with over 1000 HTML elements: it's 16 pages long if it's printed, so it's bigger than any typical web page.

Testing on an older laptop, with a dual-core 1.9 GHz CPU, the edit control loads and renders the test document in three quarters of a second:

  • Parsing the document, parsing the CSS, computing the style for every element, and measuring the size of every word
  • Doing the layout: line-wrapping words into blocks (paragraphs and table cells)
  • Measuring the total length of the document (in order the set the scroll bar correctly)
  • Rendering one page (the first visible page) of the document on the screen.

This "less than a second" responsiveness is measured in a "warm" performance test, which excludes any one-time startup costs e.g. for the just-in-time compiler.

Time Required to Edit a Document

The control's responsiveness to the end user appears to be instantaneous.

Most (about 75%) of the time required to load a document is spent measuring the size in pixels of each rendered word, in order to layout words on the page. Because the control caches the measured size of each word, this cost is incurred only once: when the document is loaded, and not subsequently while the document is being edited.

Furthermore, every other measurement is cached as well: for example the way in which words are line-breaked into lines; the height of each paragraph; etc.

When the DOM is edited (via the UI or via the API) the control only recalculates what it must recalculate (for example the word being edited, and the length of the line which contains that word), and only repaints what it must repaint. Because there's no unnecessary repainting, there's no noticeable screen flicker when the user is typing.

Time Required to Render a Form

The performance is good even in forms which contain many form controls: because to avoid performance problems it avoids instantiating an O/S control for each web control.


The control's reliability has three causes: it uses the managed run-time, it's carefully coded, and it's well tested. Testing is crucial.

The control has a suite of functional tests, which exercise the control's functionality:

There are also some Coding Techniques which improve the control's reliability.

Test Strategy

The test suite is created and run within a testing framework, which works as follows.

  • The test case author exercises the control's UI, to test specific features. After each edit, the author inspects the appearance of the rendered document on the screen, and inspects the contents of the document's DOM, to verify that the appearance and the contents of the document are as expected after each edit.
  • The test framework captures each step of the test, and saves it in a test case definition file. The data that's associated with each test includes the user's input via the UI; the control's output to the screen; the resulting nodes in the DOM; and the locations of the rendered blocks.
  • The test framework is used again later to 'play back' the captured test case definition data. It injects the same user input, and verifies that the control responds with the same output, and that the DOM and locations and contents of the rendered blocks within the control show the same internal state.
  • The framework is especially good at testing the Undo/Redo functionality: after every edit action, it automatically invokes the Undo and Redo functionality, to verify that the appearance and the internal state of the control are restored as expected.


The advantages of this test strategy, instead of for example writing unit test code to exercise internal APIs of the various implementation components, are as follows:

  • It's easy to create new tests: the test case author simply uses the UI to exercise the control, and visually inspects the resulting output for correctness, while actions are monitored and captured by the testing framework. Because it's relatively easy to develop new tests, the test suite is extensive with good coverage of each feature.
  • The software which is exercised during capture and playback includes the UI layers.
  • Having an automated test suite allows for regression testing, and helps to detect and prevent any problems when new features are developed.

List of Test Cases

The following is a list of the test case filenames, to give you an idea of the scope and coverage of the test suite. Each test case file contains several tests, to test the regular case and all the 'corner cases': for example "Edit table delete row" tests deleting the top row, bottom row, middle row, several rows, and all rows of a table.

Backspace after space
Backspace around edges of inline textrun
Backspace at beginning of paragraph
Backspace near end of line
Backspace normalize within paragraph
Backspace selected word and both spaces
Backspace selected word and space
Backspace selected word
Backspace selection spans two paragraphs
Backspace several words
Backspace space and selected word
Backspace to far edge of other block
Change heading level
Changed crosslinked heading level
Clone selected document fragment
Copy and paste entire table
Copy and paste more than entire table
Copy and paste table cells
Copy and paste table into table
Copy and paste table plus text
Copy and paste text plus table
Create list in new document
Cursor control left and control right with table
Cursor left and right near readonly block
Cursor left and right
Cut and copy while nothing is selected
Delete at end of paragraph
Edit list items
Edit table delete column
Edit table delete row
Edit table delete table
Edit table insert column
Edit table insert row
Enter at end of document
Enter at start of paragraph
Enter in inline text run
Enter in mid paragraph
Enter on new paragraph
Form control resize screen
Form hot and pressed on mouse move
Form input radio and checkbox
Form input text cut copy and paste
Form input text loses focus
Form input text maxlength
Form input text paste Russian
form label used to focus
Form move captured mouse beyond control
Form select and edit input text
Form select
Form textarea changes height
Insert erases selected inline element
Insert hyperlinks and crosslinks
Insert inline hyperlink
Insert into empty list item
Insert into list item
Insert new attribute type
Join paragraphs with flattening required
Join paragraphs
Keypress with hyperlink at edge of block
Line break at end of paragraph
Line break delete line breaks
Line break in heading for which allowInline is false
Line break in list item
Line break in table cell
Line break inside inline text run
Line break select empty lines
Line break selection in middle of paragraph
Load complicated list
Load document from disk
Load empty fragment with whitespace
Load empty fragment
Load entities and whitespace
Minimum width of form control
New document
No exception if user code leaks a IDomRange instance
Paste blocks into div
Paste blocks into list items
Paste duplicate id attribute
Paste inline text runs
Paste into end of block before table
Paste into end of block within table cell
Paste into middle of block within table cell
Paste into start of block within table cell
Paste list items into div
Paste text into list paragraph
Paste text into simple blocks
Resize simple table
Right caret of multiple selections
Script changes a style attribute at run-time
Script undo a style attribute change
Select control home and control end with shift key
Select control left and control right with shift key
Select readonly with cursor and shift key
Select readonly with mouse and cursor
Select readonly with mouse and shift key
Select table cells with shift key
Select with double click at end of line
Select with mouse and double click
Selection changing and repainting
Selection moved over readonly fragment
SelectionMemento around save
SelectionMemento supports removed whitespace on save
Style with inline-block and text-align and style
Table anonymous text block with inline element
Table caret location
Table carriage return to insert new row
Table cell and row height on insert and delete
Table column width on insert and delete
Table insert char
Table Insert tables
Table press Enter at start of text cell
Table single caret backspace
Table single caret delete
Table split first block containing multiple nodes
Toggle list collapse final list paragraph
Toggle list collapse two list paragraphs
Toggle list empty list item
Toggle list final empty paragraph
Toggle list in multiple table cells
Toggle list in table cells
Toggle list merge lists
Toggle list simple cases
Toggle list split anonymous block
Toggle list two items
Type at boundaries of inline text runs

Coding Techniques

There a few coding techniques which help to improve or guarantee the reliability of the control:

The HTML loaded into the control, and retrieved from the control, is validated against the XHTML schema.
Fail Fast
The control's implementation includes many run-time assertions (link to a PDF), which throw an exception if the control or document is in an unexpected state.


The usual WYSIWYG editors consist of a standard browser, in contenteditable mode, with a lot of JavaScript to interact with the browser and/or to post-process the resulting output document. If a .NET application embeds an editor like this, the application will find it difficult to extend the editor's functionality, because:

  • The implementation of the core browser cannot easily be changed
  • The browser's native "API" is more for JavaScript running inside the browser than for a .NET application running outside the browser
  • It can be difficult to change the extensive JavaScript, which customizes the browser's editing.

In contrast, the ModelText edit control is designed to be extensible, to make it easy to implement additional, application-specific features:

  • The control exposes a native .NET API: so that the application can monitor the user's actions, display additional user interface elements, and make additional edits to the document (as mentioned in the WYSIWYG Editing UI section).


Why use HTML in your application:

  • Applications support text from users: including wikis, documentation, etc.
  • Users want rich/formatted text: section titles, hyperlinks, lists, tables, etc.
  • XHTML is standard, portable, easy to process, reusable in web pages.

There are several other ways to edit HTML:

  • Other WYSIWYG editors
  • Markdown syntax; and BBCode, wiki markup, and other markup languages
  • Raw HTML

For many applications, ModelText is better than alternatives.

Other WYSIWYG editors ModelText
HTML which has embedded formatting information (for example, <font> tags and style= attributes) can be difficult to reuse: because it conflicts with display styles which are defined by the target page or web site.

The output from some WYSIWYG editors is difficult to process, because it's 'tag soup': the output is only intended to be rendered by a browser, not to be readable using other software.

ModelText has Clean XHTML Output
  • ActiveX components
  • A browser in contenteditable mode with a toolbar and a JavaScript wrapper
  • ?
ModelText has 100% Managed Code
Markdown syntax; and other markup languages ModelText
Some of these languages aren't as expressive as HTML (for example, BBCode doesn't support headings). For other elements like tables the markup isn't really much easier than raw HTML.

The various markdowns and markups each have their own syntax, which casual and non-expert users may not know.

There's no immediate visual feedback about whether the markup is correct (uness you implement a live preview, synchronized to the user's edits).

ModelText has a WYSIWYG Editing UI
Raw HTML ModelText
End users may not know HTML, or not want to think about it when they're concentrating on writing content.

Raw HTML can easily introduce markup bugs, for example elements without an end tag. Raw HTML can even introduce malicious behaviour, for example if the users types in <script> tags.

ModelText has Clean XHTML Output

ModelText's editor was designed from scratch with WYSIWYM editing in mind:

  • Clean, XHTML output;
  • Lightweight;
  • Familiar, already well-known editing GUI;
  • Extensible, using convenient .NET APIs.