Customizing the Styles Drop-down
Customization of the Styles drop-down allows the developer or administrator of the site to allow for specific style selectors to applied in the WYSIWYG Editor by a user. The class selectors can be specified as block-level elements or not. In addition, these can be used in conjunction with “In-context Editing” (aka “Third-level Tagging”) to create a view in the WYSIWYG Editor that mimics that of the published site.
The customization can be accomplished with the use of the Editor element and the csspath and cssmenu attributes. For example, a style named “Header 2” can be added to apply a header-like style defined as a class for block-level <p> tag. Another example is the use of a style named “Bold Red” that can be applied to text inline with the use of a <span>. The CSS file should not contain any layout CSS for the actual site.
Tag, File, and Path Details
When editing existing files and pages to customize the Styles drop-down, the following elements are utilized:
- Page tagging for the region using either the com.omniupdate.editor tag or ouc:editor tagging style.
- csspath attribute for the Editor tag, which defines the path to the CSS stylesheet.
- cssmenu attribute, which is the path to the text file that contains the styles and style names, and if necessary the word “block” to specify it is a block-level element.
The CSS and TXT files typically used for customization can be placed anywhere. Typically, they are located in the _resources/ou/editor directory.
This example uses two classes. One is named “.header2” and is a block-level style that is applied to a <p> tag.
The second is “redbold” and is applied inline with a <span>.
In this example, users would see the following Styles drop-down in the WYSIWYG Editor:
And after the bold, red formatting has been applied:
1. Create an editable region using editor, csspath, and cssmenu, or edit the existing page tagging. For example:
Note: The Editor tag is contained within the opening Div tag. For example:
<!-- com.omniupdate.div label="twocolumn_content" group="Everyone" button="700" break="break" -->
<!-- ouc:editor csspath="/_resources/ou/editor/onecolumn.css" cssmenu="/_resources/ou/editor/styles.txt" width="1050"/ -->
<p>Here are the proposed edits:</p>
<p><span class="redbold">Change "food-born" to "food-borne"</span></p>
<p class="header2">List of Edits</p><!-- /com.omniupdate.div -->
For more information about tagging:
2. In the stylesheet specified by the csspath attribute (e.g., csspath="/_resources/ou/editor/onecolumn.css"), define the CSS class selectors for the Styles drop-down. Note that only class selectors (e.g., .redbold), not ID selectors (using a #), are allowed.
3. For purposes of in-context editing; that is, having the WYSIWYG graphically resemble the published site, use the same classes in the stylesheet as the website uses. Any classes that the users selects from the “Styles” drop-down should exist both in this editing CSS and the live CSS. Ensure that these two stylesheets are always in sync.
4. Create a blank .txt, or use the existing styles.txt file. For each drop-down, include the class selector, then an actual Tab key generated tab-space, then the friendly name to appear in the drop-down. Note:
- Tabs must be used, not spaces.
- List as many selectors as desired, each on its own line.
- For block-level elements, after the friendly name add another tab and the word: block
The following shows the class selectors for .header2 and .redbold as defined in the text file:
Make sure that the TXT file is referenced correctly in the Editor tag > cssmenu attribute:
Note: The .txt file does not need to be published to the production server; it need exist only on the OU Campus staging server.
Note: Some implementations might use the @import rule (as shown below) to define the CSS for the Editor from the CSS for the published site. In this case, it would only be necessary to update the CSS in the main file.