SharePoint Rich Text Editor from a Developer perspective

In this post I wrote down some of the pitfalls I’ve noticed, regarding the SharePoint Rich Text Editor, when dynamically manipulating HTML. It is written with SharePoint developers in mind.

Rich Text is everywhere

You may want to build a solution that concerns the Rich Text Editor (RTE) in SharePoint, for a specific use case. However, you should always remember that the RTE is used in many locations. So whatever you build, should be generic, so it does not break other use cases.

Just a few examples: A RichHtmlField control (on a page layout), a Rich Text Editor web part, a Rich Text site column. Then again, a site column can be used in a list, which can have all sorts of list views, that in turn can be shown using a web part. And this list of examples might not be complete at all.

Only manipulate editable HTML

If you manipulate the HTML, you do need to be careful when you are near the RTE. The RTE should not be confused between HTML that can be edited by the user, and HTML that is static. If this distinction is affected by HTML manipulation, the entire content of the RTE might be reverted to a previous state when saved. So even changes that the user applies might not be saved in this scenario.

ms-rtestate-read CSS class

Basically, the css class “ms-rtestate-read” tells the RTE that the element that bears this class, including all it’s children, should be accounted for one atomic instance. All of its content (nodes, attributes, text) should be treated as one “thing”. A good example for this would be a web part inside the rich text. Nothing about the html of the web part can be modified, so it is marked with the “ms-rtestate-read” class. Although it is contained in Rich Text, this atomic HTML is no Rich Text on it’s own.

Collaborate with the other players

Client side, there is no point in time where you are the owner of the HTML in the Rich Text Editor. In fact, besides you, there are at least two other parties who can manipulate this HTML: SharePoint (the RTE) and the end user. But also keep in mind that third party code (besides your own) might want to join the party.

rterangecursor markings

Something the RTE will do for example, is insert span elements at the start and the end of your selection. These span elements will have respectively the CSS classes “ms-rterangecursor-start” and “ms-rterangecursor-end”. It might be that these elements are helpful to you, and then it’s good to know they exist too.

Obviously these markings are not part of the content that SharePoint will save when the Rich Text is saved. So you need to keep in mind, that the HTML in the Rich Text Editor is not necessarily the same as the current content intended to be saved. So reading the HTML is in no case the same as reading the Rich Text value.

Textnode fragmentation

Since the RTE does insert temporary elements inside the text, this can actually fragment the HTML inside the RTE. In the example below a part of the text is selected:

When the text is not selected anymore, the rterangecursor markings are removed. However, this does not necessarily join the text surrounding the selection into one text node. In stead, there may be multiple text nodes as siblings in the HTML.

This effect usually is not important to the end user, but it is important if you analyse the HTML using JavaScript. For instance, the example above, would be split into three sibling text nodes: “The “, “exam” and “ple”. If we where to search for the word “example”, we would not find it, if our code did not take fragmented text nodes into account.

 Only insert phrasing content

The RTE may have some formatting issues when using certain types of elements. It is therefor better to only use phrasing content, when dynamically inserting HTML.

For more information about this behavior, check out my other blog post: SharePoint Rich Text Editor creates additional new lines.


Leave a Reply

Your email address will not be published. Required fields are marked *