I am having problems with bullets in RadEditor - basically, the html code it creates is wrong.
I attach three images showing the steps to create the problem. The intention was to bullet the four lines starting with 'Item'. The same happens with a numbered list.
Prior to bulleting/numbering, the html view shows this (which is correct):
This is the course information for the course. It contains:<br />
<br />
Item1<br />
Item2<br />
Item3<br />
Item4<br />
<br />
This text is below the bullet points
When the bullet button is pressed, Bullets3.jpg happens. The corresponding html view shows:
<ul>
<li>This is the course information for the course. It contains:<br />
<br />
Item1<br />
Item2<br />
Item3<br />
Item4<br />
<br />
This text is below the bullet points</li>
</ul>
For numbering, it shows:
<ol>
<li>This is the course information for the course. It contains:<br />
<br />
Item1<br />
Item2<br />
Item3<br />
Item4<br />
<br />
This text is below the bullet points</li>
</ol>
Looking at this, the ul /ul and ol /ol have been inserted in completely the wrong place. This actually makes the bullet/number features completely unusable because there doesn't seem to be any logic in how it screws up the html.
Any ideas on how to fix this ?
I am using 2014.1.403.40 with .NET 4.0 under VS2010 and Chrome, although it also does it under IE.
Thanks
7 Answers, 1 is accepted
Rank 1
Since posting, I have found other threads about this, specifically referring to the newline mode needing to be changed from BR to P.
I have made this change and it does indeed work, but what I don't understand is: why can't the bullet/number code be a bit more intelligent and strip out BR's and handle the whole thing more gracefully ?
The described behavior is not a matter related to how intelligent is the command creating lists, but to the normal editing behavior.
There are significant differences between paragraph (in HTML <p> tag) and a carriage return (in HTML <br> tag) when it comes to text editing. Paragraphs are considered as block elements (like in HTML) and thus, they can be formed as separate list items. Whereas, carriage returns are inside a block element, where and the lines separated by carriage returns from one block element, which is nested inside a list item.
The same can be observed in every text editing engine, e.g, MS Word, by using Shift+Enter to add a carriage return. See this screencast—http://screencast.com/t/10o9ka9c6.
Regards,
Ianko
Telerik
Rank 1
Hi Lanko,
Having programmed this sort of thing in thick client applications myself in the past, I'm afraid I have to disagree with you on the 'intelligence' issue. I agree that paragraphs are different to BR's, but at the end of the day, I look at it like this: run the editor in BR mode and tell me that the resulting output of bulleting is acceptable ? It is a complete mess, it doesn't work in any way that one might logically expect and our clients don't like it.
There is a way to resolve this, simply by enhancing the 'intelligence' of the current algorithm:
1) When the block of text highlighted by the user is extracted, check to see if it contains <P></P> and if so, do what you do now ie effectively convert each <P></P> into an <LI></LI> and then wrap a <UL></UL> around the whole lot.
2) If it doesn't contain <P></P>, then check for <BR>. If it doesn't contain any, then it is a single line bullet (probably the first line), so put <LI></LI> around it and then wrap it in <UL></UL>.
3) If it does contain <BR>, then treat each line ending in <BR> as a separate bullet line, remove the <BR> and wrap the line in <LI></LI> and the whole highlighted block in <UL></UL>.
If you do this, then it wouldn't matter whether the editor is in <P> or <BR> mode - it would operate sensibly in both situations and give the user what they expect.
Just because some other product doesn't make a sensible fist of this either doesn't mean you should copy it - this is about making it work and making it work in a way that makes sense to users. Currently, it does not.
Hello,
Thank you for the feedback.
I would like to firstly point out that we both agree on the matter that P and Br tags are different in semantics in both HTML-editing and text-editing situation and as this is so, they are expected to lead to a different output when it comes to interaction with them.
Now, as per to the suggestion provided, it is clearly visible that such a logic would unify the Br and the P tags. Which will lead to even more harm than use. Changing the semantics and the native understanding of these elements will cause plenty of confusions among end-users. As RadEditor is a rich-text editor, it is strongly forbidden to change programmatically the way an HTML element behaves, and moreover to change the behavior to one that is not encountered in the common sense of text-editing experience. MS Word was just an example, however, I am not aware of a commonly known editing engine that would unify the behavior of a plain carriage return and the paragraph.
Just from personal experience, I can point out several pitfalls by implementing such a behavior:
- What happens when text is being pasted over/in the content? P tags can be easily added that way, then the logic fails;
- Also, pasting content from different source can fetch a very complex structure of HTML, scenarios where there is mixture of P and BR tags should be considered as a valid scenario, as it is valid XHTML;
- Users are capable of editing the HTML inside, again, they are free to add any content, and thus, programmatically deciding how a command to act based on a certain structure or predictions could fail. There is no strict rule, whether P tag can be added in LI or not, but both should be supported. And thus, BR tags should act the same in both cases, as per to W3C specifications.
Previously, RadEditor was designed to work similarly to the described suggestion (i.e., lines spit by BR to be added as multiple list items). In time, there was numerous of reports and requests to change this behavior. As a result, the new line behavior have been re-designed and now it produces more effective, more accurate and a cross-browser behavior. You can read more about that here—http://www.telerik.com/help/aspnet-ajax/editor-inline-and-block-commands-behavior-change.html.
As a result, if it is expected inline elements to be considered as block ones and to create list items, or to be treated properly as inline elements and to act as ones, no matter if it is HTML or a text-editing app, is a matter of requirements. On our end, using logic to programmatically force one element to act as another based on specific predictions is considered as a very bad practice and always lead to issues that are merely difficult to be handled in complex situation when complex text structures are being used in RadEditor.
However, RadEditor is flexible enough to change the new line behavior as per to your exact requirements, although, this is a matter of personal consideration, and should be implemented manually. Also, I should warn you that such customization is not officially support, and all side effects from that should be again handled manually.
Best regards,
Telerik
Rank 1
That screencast URL is a dead link ("Page not found"). Do you know if it's still available?
For your convenience I recorded a new video and added it to my reply as attachment. I've also attached the Word file.
The video shows how the bullet is applied to the paragraph but not on the the new line with a carriage return.
Best rdegards,
Rumen
Progress Telerik
Rank 1
Thank you!