The built-in user interface includes:
<input>controls to interact with the user.
Users are given a familiar, standard UI for a text editor:
The visual styles of elements is defined by your CSS, which you pass to the control.
The control just edits the structure of the document, not its style:
<font>, which affect only the appearance.
The output from the editor, the resulting document, is clean, semantic XHTML.
You can use the keyboard to type text, the cursor keys to navigate within the page, the Delete and Backspace keys to delete text, the Enter key to start a new paragraph, and hotkeys as shortcuts for the various toolbar commands.
You can use the mouse in the usual ways (click, click-and-drag, and double-click), to set the location of the insertion cursor, and/or to select a range of existing text.
While the control is being used as a WYSIWYM editor, it can display a toolbar. The various toolbar commands are as follows. You can also invoke these commands using the standard hotkeys, for example Ctrl+S for Save, etc.
This command notifies an event handler in your application: your application can then read the current HTML from the control, and save it somewhere.
These commands interact with the system clipboard: for details, see Using the Clipboard, below.
Unlike some editors which are built using browsers, ModelText's HTML edit control has robust support for Undo and Redo. An end user action like a keypress may cause a change to the DOM. If your application has used the API to install an event handler, the event handler which is triggered by this action might make a further change to the DOM. In this case the two actions (the built-in action caused by the keypress, and the supplementary action invoked by the application) are both handled as part of the same editor transaction. A subsequent Undo request by the end user will undo both actions. The result is that any extra functionality which your application adds via event handlers seems to be seamlessly integrated with the basic editing functionality.
This command notifies an event handler in your application: your application can then display a dialog, for example to let the end user select the target of the hyperlink. For further details, see Hyperlinks, below.
This command lets you set the heading level of a paragraph, to
"Body text" for a
or to "Heading 1" through "Heading 6" for
These commands let you specify that paragraphs are list items, of an ordered or an unordered list.
This command lets you insert a table. When you're editing a table, you can edit the text within the table cells, and/or you can edit the table itself, adding and/or removing rows and columns.
HTML contains hyperlinks, encoded using anchor (
There are various things that a user might want to do with hyperlinks:
These actions should be implemented by the application in which the edit control is embedded, because the action require access to external resources (e.g. to a collection of possible hyperlink targets).
An application uses the API which is exposed by the control, to detect when the user clicks on the
Insert Hyperlink item of the toolbar, and/or to detect when the user clicks on an
existing hyperlink within the text being edited.
The application can then for example pop a dialog which shows the target of the hyperlink;
if the user changes the target, make the corresponding change to the
href="" attribute in the DOM.
The edit control supports using the clipboard to cut, copy, and paste.
Text from within the document keeps its original formatting. So, for example, list items and table cells can be cut from one part of the document, and pasted in another part.
Text that's pasted from other applications is pasted as HTML paragraphs. The end user can then use the UI to apply further HTML formatting as necessary, for example to convert some pararaphs to headings or lists.
The .NET runtime environment restricts access to the clipboard, when the control is run in a partial-trust or untrusted environment. This is a feature of the .NET environment, to prevent untrusted applications from reading the user's clipboard. To enable clipboard access, you simply need to run the control with more permissions.
There's a separate utility, the Doc to HTML Converter, to convert Word documents to HTML. This utility is not integrated with the ModelText HTML edit control, but may be used by your users, or used by your application.
The control has an API which lets the application specify that certain elements in the DOM are read-only. The end user cannot edit read-only elements, nor even position the insertion cursor inside them (clicking on a read-only element results in the entire element being selected).
Having read-only sections may be useful for certain applications, for example if you want a machine-generated navigation list of hyperlinks within the document, which the user can click on but not edit.
The WYSIWYM user interface doesn't support the user's seeing or editing the underlying HTML.
The Toolbar Commands listed above can be used to implicitly create and edit HTML elements,
but there's no UI to edit element attributes (including for example, the
This encourages the end user to focus on creating content, instead of playing with the presentation. It also means that HTML documents and document fragments from the control are relatively "clean", and can for example be aggregated into other pages without conflict.
There are two scenarios however in which the HTML from the control may contain element attributes.
Instead of giving the end user an empty control and letting them create HTML from scratch, the application might prepopulate the control with an HTML document or fragment, and let the end user edit the existing HTML. In this case, if the HTML which the application originally inserted into the control contained attributes, then these attributes are preserved when the document is edited.
An example of how this feature can be useful is that the application might assign
id attribute values
to the original elements which it inserts into the control.
After the user edits the document, the original elements can be identified by their preserved
whereas newly-inserted elements can be identified by the fact that they have no
The application can use the .NET APIs to insert elements which contain attributes, or to edit the attributes of existing elements.
One reason for doing this is to edit an element's
to toggle the element's visibility.
The control can also be used as a web form, with web form controls like
<textarea> inside a
If the HTML (which the application loads into the control) contains a
then the control behaves like a web form instead of like a WYSIWYM editor:
The application can use the .NET APIs to extend the basic editing UI. Examples of a couple of things you can do include:
The control supports many of the CSS Properties. This allows the application developer (not the user) to define the appearance of the text which is rendered in the control.
It also allows the application to alter the appearance of elements within the control, to interact
with end users.
For example you can insert colored text spans which contain messages for the user;
and use the DOM APIs to alter elements'
to change elements' appearance at run time, or to make the elements visible or invisible.