Editor buttons place wrong HTML code

6 posts, 0 answers
  1. Peter
    Peter avatar
    4 posts
    Member since:
    Sep 2015

    Posted 06 Nov 2015 Link to this post

    Hi,

    My first post here. I'm using the Telerik Editor that is build into the Sitecore interface, though I see from the demos that this problem applies to the default Telerik Editor also.

    The problem is that the toolbar buttons don't insert the expected HTML code. For example, using the B (bold) button, inserts the HTML tag <strong> (for strong emphasis), instead of either the <b> (bold) HTML tag or better the style="font-weight:bold" attribute.

    <strong> is *not* equal to displaying bold text. It is by default displayed as bold in *most* browsers, but any stylesheet can easily redefine <strong> to be displayed with other formatting, in which case the connect with the "bold" button is totally invalid.

    The same goes for the I (italic) button, which doesn't insert code for italic text but an <em> for emphasized text.

    Following this pattern, I would have expected the U (underline) button to insert an <a> tag, because anchors are underlined by default, but this is not the case. The U button actually inserts <span style="text-decoration: underline;">. However, in an unrelated complaint, the use of underlining in webpages is bad user experience, since many visitors will misinterpret underlined text as a hyperlink, and try to click it. An underline button should not be offered in a web editor. My suspicion is the only reason for that button being there, is because it is also available in Microsoft Word. A web page is *not* the same as a Word document, and the Telerik Editor should honor this difference, instead of trying to mimic something it is not.

  2. Ianko
    Admin
    Ianko avatar
    1535 posts

    Posted 09 Nov 2015 Link to this post

    Hi Peter,

    First I would like to welcome you in the Telerik community. 

    I really can understand the confusion about  the different results from these three formatting tools. However, I would like to assure you that the logic behind them is quite solid and reasonable. 

    What <b>,<i> and <u> tags do is to inform the browser that the text should be bold, italic or underlined. This is fine when it comes to documents and HTML compliance. Although, you should note that with HTML5 specification these tags are deprecated. You can also read this useful discussion on the topic—http://programmers.stackexchange.com/questions/255366/why-are-the-b-and-i-tags-deprecated.

    With HTML5, semantics take place and with that: <strong>, <em>, <del> and other tags have deeper meanings in HTML, where SEO and search engines are involved. As soon as they support everything from both worlds (old browser engines and semantics) RadEditor utilize them in order to format text and retain HTML5 specifics for semantics.

    As for why there are tools that use tags and others that use inline styles, RadEditor is created with the concept to always add tag formatting. However, this is not always possible. The Underline tool is the best example. There is no HTML5-compliant tag for that. Plus, <u> tag is deprecated. Therefore, the last and the only possible valid decision for that tool is to add an inline style. I can definitely say that <a> tag is not proper for underline formatting.

    Anchors are typically added via the Hyperlink Manager and their concept is far different from underline formatting. Anchors are used to create links or anchors. Their purpose is to link other documents or sections in web pages—https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a. Therefore, their usage for a simple underline formatting will be rather harmful in terms of semantics and W3C specifications. 

    Still, RadEditor is quite flexible and you can customize it with custom tools and content filters of your own in order to achieve the results required. Here you are some demos that showcase how to implement such custom solutions:

    Also, you should be aware that there are built-in content filters that take care of transformation of <b> to <strong> and <i> to <em> tags—ConvertTags and MozEmStrong filters. You can read more about how to enable/disable content filters here—http://docs.telerik.com/devtools/aspnet-ajax/controls/editor/managing-content/content-filters.

    I hope this clarifies the situation with these tools and answers to your question about why these HTML generation is considered as the most proper one in terms of HTML content editing.

    Regards,
    Ianko
    Telerik
    Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Feedback Portal and vote to affect the priority of the items
  3. UI for ASP.NET Ajax is Ready for VS 2017
  4. Peter
    Peter avatar
    4 posts
    Member since:
    Sep 2015

    Posted 10 Nov 2015 in reply to Ianko Link to this post

    Hi Ianko,

    I am really sorry, but a lot of what you are saying here is incorrect. The <b>, <i> and <u> tags are ***NOT*** deprecated in HTML5. They were deprecated in HTML4, but they have been re-introduced in HTML5. Interestingly enough, your second link to Stack Exchange, confirms this. Quote from the chosen answer: "In HTML5 i and b are no longer deprecated. Instead, they are given semantic meaning."

    Semantics is not new in HTML5, this has always been an important factor for HTML, although HTML5 makes the separation between semantics and layout more obvious. This has very little to do with SEO (or search engines, which is the same thing), and more with accessibility. Try to answer this question: how would a speech engine (as used by blind people) "render" underline, or bold or italic text?

    You are saying "[the concept of anchors] is far different from underline formatting". That is correct, and I completely agree. However I would like to add that the same goes for italics versus emphasis and bold versus strong emphasis: the concept of emphasis is far different from italic or bold formatting. Just like bold and italic are a *choice* for formatting emphasis, in the same way underlining is a choice for formatting hyperlinks. But neither of these can be turned around: hyperlinks can not be used when underlining is requested, and emphasis can not be used when bold or italics is requested.

    The RadEditor toolbar offers buttons for bold, italic and underline formatting. I don't think this is a wise decision for a web editor, these are not semantic functions, limiting accessibility (think again of the speech engine). However, given this requirement, bold italic and underline should produce either <b>, <i> and <u> tags, or font-weight: bold, text-style: italic and text-decoration: underline.

    Please understand that <em> and <i> are to very different tags, and have very different meanings. You can't just mix these.

  5. Ianko
    Admin
    Ianko avatar
    1535 posts

    Posted 10 Nov 2015 Link to this post

    Hello Peter,

    Thanks for getting back and for your feedback. 

    Indeed, HTML4 deprecates <b>, <i>  and <u> tags and HTML5 brings them back. This is my mistake and I am sorry for that.

    Still, this is a reason for not using these tags as default options for formatting, Note that RadEditor is created to support XHTML, HTML4 and as much as possible HTML5 content. As a UI control, your suggestion would involve to have different tools for applying <b>, <strong> and <span> with inline font-weight: bold style. Also, the same should be applied with the other mentioned tools. 

    Also, note that the end-user should have greater knowledge and use the proper tool at the correct place with the correct semantics. In case where the user has such advanced knowledge on HTML, there is the HTML mode and also, there is the possibility for custom tools and filters that can be used in order to achieve the goal.  

    The decision to use these tags as default formatting is not plainly made up from nowhere. There has been greater demand for these tools to produce the described result. And it has been decided these results to be the default ones.

    Further, it is quite clear that an HTML editor cannot stick with only one possibility for text formatting. And again, here comes the possibility of RadEditor to be customized with various of tools and commands. 

    Finally, I understand that upon different requirements the results should be different and I can suggest you to customize that as per to your exact needs.

    If you can think of a feasible way to improve these tools so that they can fit the discussed requirements, it would be highly appreciated to put your suggestion here—http://feedback.telerik.com/Project/108/. That way you will be able to use our official channel for such suggestions, so that they are estimated and discussed by Telerik community and Telerik Developer team.

    Regards,
    Ianko
    Telerik
    Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Feedback Portal and vote to affect the priority of the items
  6. Peter
    Peter avatar
    4 posts
    Member since:
    Sep 2015

    Posted 18 Nov 2015 in reply to Ianko Link to this post

    Hi Ianko,

    I understand your point about not wanting to use tags that are deprecated in HTML4 (and invalid in HTML4 Strict). And I also understand the requirement (even though it is misguided) from your users to have Bold and Italic buttons.

    The solution then is to use the inline style code, such as already is done with the Underline button.

    Yes I understand that advanced administrators can configure the editor to insert the codes I request. However, my problem is that the defaults, which are used by 99% of your users, are incorrect. These should be fixes by Telerik, not by the users.

    Regrettably, hardly any user of the editor component (writers/editors) has advanced knowledge of HTML. Most don't even know what an HTML tag is. Yet, it is the disadvantaged end-users (visitors) of websites, that require accessible and semantically correct HTML code, that pay the price.

    I just discovered one situation where the Telerik editor already has made a comparable change. In older versions, there was an Indent button on the toolbar which inserted the <blockquote> tag. This is the same semantic mistake, "indent" and "blockquote" are not the same, even though they often look the same. Thankfully, that mistake has been corrected, and in current versions the indent button inserts style code that really formats indenting. Hopefully Telerik will do the same for the bold and italic buttons.

    Thank you for the link to the feedback page. I have posted a bug report at http://feedback.telerik.com/Project/108/Feedback/Details/175620-bold-italic-buttons-should-produce-style-not-strong-and-em-tags

  7. Ianko
    Admin
    Ianko avatar
    1535 posts

    Posted 19 Nov 2015 Link to this post

    Hello Peter,

    Thank you for posting your feedback in our public portal. I can assure you that this is the right channel for such reports. 

    I would like also to mention that the change of the <blockquote> usage for indentation has been done mostly due to inconsistent behavior through browsers. And HTML specifics due to which this tag cannot include <p> tag as child element(s).

    Regards,
    Ianko
    Telerik
    Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Feedback Portal and vote to affect the priority of the items
Back to Top
UI for ASP.NET Ajax is Ready for VS 2017