This post is intended for SharePoint professionals who want to know why the Rich Text Editor in SharePoint sometimes shows unexpected behavior when pressing Enter.
Expectations
If I press enter while editing Rich Text content in SharePoint, I’d want the following things to happen:
- The text following the cursor should start at a new line
- The new line has the same markup as the previous line
- There are no other side effects to my content
You’ve probably noticed that these expectations are not always met.
Work around
If you press Shift + Enter, a <br/> element is inserted. In most cases this would meet the expectations as described before.
The <br/> element is “phrasing content”, intended to be used at an “intra-paragraph level”. In other words: if it is valid to use text somewhere in HTML, it is just as valid to insert a <br/> element in that text.
More details can be found at:
http://www.w3.org/TR/2011/WD-html5-20110525/content-models.html
About the actual issue
As you may have guessed, if you do not press shift while pressing enter, the HTML will be manipulated in a more complex fashion. In stead of inserting a <br/> element, which would keep valid HTML in any scenario, SharePoint will try to create a new paragraph, and meeting the expectations about markup at the same time.
Mind you, SharePoint customers can apply all sorts of branding to their sites. CSS can be applied to the content in the Rich Text Editor (RTE) as well, and on top of that, all sorts of custom html can be inserted inside of the Rich Text. So if you need to take all the possible scenario’s in account, it would be very difficult to get it right every time.
For instance, SharePoint will determine based upon the parent HTML, which nodes would cause a newline when they are inserted. So if your text is inside a <div> element, SharePoint will know to insert a new <div> element to create the new paragraph on a new line. Unless there is a CSS rule that makes the <div> element to behave as an inline element.
An inline <div> element is interpreted by SharePoint to be markup, and the same markup is to be applied to the text in the new paragraph. So in this scenario, SharePoint will not use the <div> element to create a new paragraph, but it will be copied into the new paragraph to ensure the same markup is applied.
Unfortunately the RTE will pick the <p> element to create a new paragraph, if SharePoint thinks that re-using existing HTML structures will not do the trick. However, the inline <div> element (for example) will be copied into this new <p> element. And this is where the problem starts.
Fun fact about HTML:
If <p> is not closed with </p>, the browser may interpret the <p> element to be closed before the first invalid child. The <div> element is not a valid child for a <p> element.
As you can conclude from the fact I stated above, the RTE would generate invalid HTML if a <p> element is wrapped around an inline <div> element. Basically, if you would execute the JavaScript below in your browser console, you’ll see what I mean in action:
|
1 2 3 |
var element = document.createElement("div"); element.innerHTML = '<p>paragraph<div style="display:inline">something</div>test</p>'; console.log(element.innerHTML); |
Basically the browser will assume the first <p> element to be closed before the <div> element. Then when it encounters the “</p>”, it will assume it to be a self closing element, so it will be replaced with “<p></p>”. Finally the browser will assume the following html was meant:
|
1 |
<p>paragraph</p><div style="display:inline">something</div>test<p></p> |
This all would have been prevented if the RTE would be better in estimating the type of parent that would be valid for the next paragraph, if markup is maintained. It should have wrapped the paragraph with something like: <div style=”display:block”>, but because the paragraph (<p>) element is used, the extra new lines are assumed by the browser, simply to generate valid html from the invalid result of the RTE.
Conclusion
Unfortunately, we can not just change the behavior of the Rich Text Editor, so when we create CSS in SharePoint or add HTML to Rich Text content, we need to keep this behavior in mind.
Since the scenario’s to which this behavior may apply are diverse, I feel like there would not be a universal solution to this problem, unless Microsoft fixes this themselves. However, feel free to prove me wrong in the comments :-)
