[Solved] Kendo editor changes to HTML?

[Bob]

In the case where this HTML is entered into the Kendo editor:

<p style="text-indent:24px">Some text</p>

I can see in the body of the editor that the style is unchanged.  However, when I get the HTML back from the editor without making any changes (typing or other button functions) using the kendoEditor value() function, the style is changed to this:

<p style="text-indent: 24px;">Some text</p>

A space has been injected after the colon, and a semicolon has been appended to the end of the style.

This is not a breaking change by any means, but the problem becomes that when I compare the HTML to the initial HTML, it is now different, and it may be difficult to determine if this was an intended user change or not.

What is the best practice to determine what is an actual user change vs. a system change that modified/normalized the HTML in some way?  Is it possible to know all the modifications that may be made to the HTML by the editor?

Thanks for any insight,

Bob

[Rumen]

Hi Bob,

Thank you for the detailed report. What you're seeing is expected behavior, it is not a bug in the Editor itself, but a side effect of how browsers handle inline styles.

Why this happens
The Kendo Editor doesn't manually rewrite your style attribute. Instead, when the HTML is inserted into the editor's content-editable <iframe>/element, the browser parses it into the DOM. Browsers normalize inline style strings when they're serialized back out via element.style.cssText or outerHTML, this is standard CSSStyleDeclaration behavior, consistent across Chrome, Firefox, and Edge. That's where the added space after the colon and the trailing semicolon come from. When value() is called, the Editor reads the current DOM content (via innerHTML of the editable area), so any browser-level normalization that already happened when the content was parsed is reflected in the output, the Editor itself doesn't add or strip that formatting on its own.

Best practice for diffing user changes vs. normalization
Since this normalization is deterministic and happens at parse time (not on every value() call), a reliable approach is:

1. On initial load, set the HTML into the Editor as you normally would, then immediately call value() once and store that "normalized baseline" instead of your original source HTML.
2. Compare future value() calls against that baseline rather than against the original pre-editor HTML.

This way you're always comparing DOM-normalized-to-DOM-normalized output, so the diff reflects only actual user edits, not browser serialization quirks.

On enumerating all possible modifications
Unfortunately there isn't a definitive, exhaustive list of every normalization a browser may apply, this includes things like:

• style property reordering/reformatting (your case)
  
• attribute quoting style
  
• collapsing/expanding self-closing tags
  
• entity encoding differences
  
• reordering of attributes in some browsers

These come from the browser's HTML/CSS parser and can vary slightly between browser versions, so it isn't something the Editor controls or can fully document. The "normalize-then-diff" approach above avoids needing that list altogether, since it sidesteps normalization entirely rather than trying to predict it.

Regards,
Rumen
Progress Telerik

[Bob]

Thank you Rumen for this very fast excellent response!