So, we’ve had rich text editing in browsers for more than ten years now. Problem solved? We’re not even close. Have you seen the HTML that is output from these editors? Let’s start with a really simple task: making text bold. In IE and Opera you’ll generate this HTML:
In Mozilla, Safari, and Chrome, this is the result:
In Mozilla, Opera, Safari, and Chrome there’s a scriptable property called
styleWithCSS. While it makes no difference in Opera, if this is enabled then Mozilla will generate:
<span style="font-weight: bold;">some text</span>
Safari and Chrome will generate:
<span class="Apple-style-span" style="font-weight: bold;">some text</span>
But, it gets even worse. If you make the text bold in Mozilla, Safari, or Chrome with
styleWithCSS enabled, IE and Opera will be unable to remove the bold. If you make the text bold using IE or Opera, and then try removing the bold in Firefox, incredibly the
<STRONG> tag will become
<strong style="font-weight: normal;">.
There are so many examples of horrendous HTML it’s hard to know what to pull out as an example. Visit the rich text tests on Browserscope and test a bunch of browsers; it’s very enlightening. You’ll see the use of the font tag, a mixture of uppercase and lowercase letters within the same tag, some attributes quoted and some not,
<br><br> used for paragraph breaks, and the use of blockquotes for indenting. You’ll find that browser implementations are wildly different. There’s even a set of circumstances that can lead to this piece of unspeakable horror:
<SPAN style="BACKGROUND-COLOR: rgb(255,0,0)" class=Apple-style-span><FONT style="BACKGROUND-COLOR: #0000ff">foo bar baz</FONT></SPAN>
Being in this state in 2010 is appalling. What’s HTML5 going to do about it? The following phrase is repeated throughout the section on
“The exact behavior is UA-dependent, but user agents must not, in response to a request to wrap semantics around some text, or to insert or remove a semantic element, generate a DOM that is less conformant than the DOM prior to the request.”
While it’s good that the standard emphasizes that user agents should first do no harm, it’s still quite vague and the implementation details remain UA-dependent. I’d settle for a little consistency between browsers. There’s a case for adding a “rich text field” to the list of standard form controls and user agents could display a default toolbar for standard editing tasks.
iOS Developer, sometimes web developer and Technical Editor.
Jump Start Git, 2nd Edition
Visual Studio Code: End-to-End Editing and Debugging Tools for Web Developers
Form Design Patterns