Last Updated: 09 Jun 2016 14:46 by ADMIN
Created on: 18 Nov 2015 15:07
Category: Editor
Type: Bug Report
Bold, Italic buttons should produce style, not <strong> and <em> tags
The default action for the Bold and Italic buttons ([B] and [I]) on the toolbar, is to insert the <strong> and <em> tags. However, this is not the same, and may insert the wrong semantic information.

Bold and Italic are used in far more contexts than just emphasis. For example, many people use these functions to create headlines. (While not semantic, this is not incorrect because they choose to apply a styling.) Italic is also commonly used in quotes and references. None of these applications are correct with <strong> and <em> tags.

Also, remember that <strong> and <em> only render as bold and italic in the default settings for the most common browsers. There are many browsers that don't/can't render these as bold and italic, and a website's stylesheet can also easily override the rendering of <strong> and <em>. This is not what the writer expects, as they have simply used the Bold and Italic buttons in the editor.

Instead, the Bold and Italic buttons should insert style code, such as <span style="font-weight: bold"> and <span style="text-decoration: italic">. The Underline button is already doing this.

If the preference is to use tags instead of inline style, then the <b> and <i> tags should be used instead. Please note that, even though these were deprecated in HTML4, they are now again valid for HTML5.

If the goal is to produce semantic HTML, then the Bold and Italic buttons should be replaced with Emphasis and Strong buttons.

I *know* the editor can be configured to do this. It is the default setting (which is used by 99% of your users) that is wrong.

A similar situation was previous the case for the Indent button, which inserted the <blockquote> tag. Thankfully, this has been changed to insert the style="margin-left: 40px;" code instead.


(This is not a new situation, many of the references are over 5 years old.)
Posted on: 09 Jun 2016 14:46
I want to thank you for that you raised my awareness for the bold and italic commands. If more users vote for this item, we will definitely think of providing a new filter to switch those commands to work with inline styles instead of tags.

I do appreciate your useful feedback and I've added 1000 Telerik points to your account.

Posted on: 07 Jun 2016 12:15
Thanks for the links, they provide some interesting starting point for further research.

It's sad, to be locked into invalid behavior because of historical reasons and compatibility, but I agree that such is working with browsers in the wild. Just don't maintain the wrong stuff because end users "expect" it this way. We can only hope that things will become better in the near future.

But I hope that my post has helped raise awareness within Telerik that bold/strong and italic/em are not interchangeable, even tough my change request has been declined.
Posted on: 07 Jun 2016 10:52
I have nothing against the usage of inline styles and CSS for replacement of the bold, italic and underline related tags. I just listed some of the constrains that apply to them.

Actually, the default behavior of the underlying rich text editing engine of Firefox is to produce <b> and <i> tags, however, due to x-browser content  consistency, we convert those tags to <strong> and <em>. This behavior is controlled by built-in content filters, which can be disabled:

You can test them at
Posted on: 07 Jun 2016 07:23
Sorry Rumen, but your answer does not make sense. If CSS can not be used (for whatever reason), then why is CSS used for underline and indent?

Also, your answer does not explain why you're not using <b> and <i> tags. Are these tags not familiar for end users? (And I am wondering what kind of end users you are talking about, that are familiar with HTML code but not with CSS?)
Posted on: 07 Jun 2016 06:21
Hi Peter,

Thank you for opening this interesting topic.

Right or wrong the production of <strong>, <b> and <i>, <em> tags is on purpose:
- the rich text editing engine of the browsers work exactly with those tags - yes, we are getting away from using the browsers execCommands but, still:
- many reporting and converter apps still work with those HTML tags
- the end users are more familiar with the HTML specification than the CSS one
- historical reasons

Even more, if you would like to use inline styles, you can write a custom content filter that can convert the tags to styles: