edit-on Pro allows you to define read-only areas and read-only elements using CSS. Style sheets are also used to dynamically populate the context menu, and to specify whether custom elements should always be visible and how they are represented.
Read-only content parts of the document inside the editor are write protected. Any editing actions such as typing, deleting, changing the font size etc. executed on read-only content or on a selection overlapping it is ignored. You can declare the content inside an element as read-only area by using the ro-readonlycontent style property. Elements with the ro-readonlycontent style property are automatically also treated as read-only elements.
Example II.6. Declaring the content inside an element as read-only content
Style definition:
.readonlycontent { ro-readonlycontent:true; }Using this style in the document:
<mycustomtag class="readonlycontent">
This content can not be modified.
</mycustomtag>
In the example above, the content within any element using the style class "readonly" is considered as read-only content.
Read-only elements can not be removed from a document. However, the content within a read-only element may be modified. For example when your users are not allowed to remove certain parts of the document, such as news headlines, but are allowed to edit them, you could employ read-only elements.
Example II.7. Declaring read-only elements
Style definition:
customtag { ro-readonlyelement:true; }Using this style in the document:
<customtag>
This element can not be removed.
</customtag>All elements available in the context menu are defined in the contextmenu section of the user interface configuration file. Whether or not a specific context menu item is available for a certain element is handled using style sheets. The TABLEPROPERTIES action for example is only available in the context menu when the cursor is inside a table because this action is only declared for the element table .
Example II.8. Enabling the TABLEPROPERTIES action in the context menu
The TABLEPROPERTIES action must be defined in the context menu:
<menu localeid="Table">
<menuitem actionid="INSERTROW"/>
<menuitem actionid="INSERTCOLUMN"/>
<separator/>
<menuitem actionid="CELLPROPERTIES"/>
<menuitem actionid="ROWPROPERTIES"/>
<menuitem actionid="COLUMNPROPERTIES"/>
<menuitem actionid="TABLEPROPERTIES"/>
</menu>Linking this action to the table element using the style ro-action :
table { ro-action:TABLEPROPERTIES; }As you can see, the table element is the only element having the style ro-action:TABLEPROPERTIES . Thus, the TABLEPROPERTIES action is only available in the context menu when the caret is inside a table.
By default custom elements not recognized by the editor (e.g. elements added using a custom DTD) will not be rendered in WYSIWYG mode. They will only be displayed when the SHOWNALLCHAR action is fired. However you can use the style ro-alwaysshowtags causing edit-on Pro to always display elements having this style. You can even specify images to be used to display the opening and closing tags of unrecognized elements using the styles ro-starttagicon respectively ro-endtagicon . For example, if we wanted the editor to display text input fields differently, we'd define styles as follows:
Example II.9. Using Styles Controlling the Display of Elements
input[type=text] {
ro-alwaysshowtags:true;
ro-starttagicon:"icons/start.gif";
ro-endtagicon:"icons/end.gif";
}