Deleting Links from Text + Odd Attribute Re-Arranging

[Ulrich Ruffiner]

We've got a couple of oddities with RadEditor (Q1 2010 version).

Links:

1) In Design mode, the user enters a line of text
2) The user marks a single word in the text they just entered
3) The user sets a hyperlink on the word via the Hyperlink Manager.
4) User continues adding text
5) The user marks the word previously hyperlinked and presses "Delete" on the keyboard

Result:
In HTML View, there's an empty anchor <a href></a> tag where the word used to be.

Things we tried:
- If the user selects the word plus the whitespace character preceding the word, the anchor tag is properly removed
- If the user "backspaces" the word out, the anchor tag is also properly removed
- If the user marks the word and instead of pressing "Delete" starts typing a replacement text, the anchor tag is kept around the new text

It's our opinion that marking the word (shift + cursor keys) and pressing the "Delete"-Key should also remove the underlying anchor tag (if present).

Changing Attributes:

Scenario:
 We've got a Rad Editor on a page. The content is set from the Database. On postback, the application should check whether the user changed the content, and if yes, do some processing and update the database.

Observation:
We were setting the Rad Editor from the database with text containing a single anchor tag as follows:

.... <a href="http://www.sample.com" class="XYZ">Sample</a> ...

Without changing anything in the editor and forcing a postback, RadEditor gave us the following content back:

.... <a class="XZY" href="http://www.sample.com">Sample</a> ...

Being the good fellows we are, we take that, write it back into the database and load the page again. So this time we set the content of our rad editor to:

.... <a class="XZY" href="http://www.sample.com">Sample</a> ...

Again, without changing anything in the edtior, we cause a postback and lo and behold what do we get from Rad Editor:

.... <a href="http://www.sample.com" class="XYZ">Sample</a> ...

We've determined that this due to one of the default CONTENT FILTERS that Rad Editor uses. We managed to fix the problem by setting the ContentFilters property to "None", however this "fix" is less than perfect. Maybe you guys could look at which part of your javascript is flipping tag attributes around and make it stop?

Thanks.

[Rumen]

Hi Ulrich,

Straight to the points:
1) Links: The observed issue is a browser behavior and it is not controlled by the control. You can reproduce the same behavior in an editable IFRAME element as well as in our competitors' editors.

You can try to instruct your users to firstly unlink the links by pressing the Unlink button or clicking at the end of the link and hitting the backspace key.

2) The odd attribute rearranging is an IE behavior. You can reproduce it with the attached editable IFRAME html page.

Here is some additional important information for your scenario:
IFRAMEs (such as the editor's content area) do not havea onchange event as textareas and inputs do. This is one major problem when determining whether content actually changed. 2) HTML is not text. Text can be easily compared - HTML cannot. Factors such as element attribute sequence, CSS settings, whitespace - can afect the editor "decision making process" and have it raise the "text changed" event even if the content was not actually changed. And the most important reason #3) is that browsers, most importantly IE make a great deal of changes to the content automatically when it is loaded in the browser. For example, IE would covnert all tags to upper case (which is not XHTML compliant). Many browser commands also produce non-XHTML compliant content - which the editor then needs to fix. It is not by chance that the editor features 20+ content filters that get executed automatically by default to correct for browser deficiencies and produce well-formed, valid XHTML. For more information please examine the following demo:
http://demos.telerik.com/aspnet-ajax/editor/examples/builtincontentfilters/defaultcs.aspx

Sincerely,
Rumen
the Telerik team

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 Public Issue Tracking system and vote to affect the priority of the items.

[Mohit]

Hi ,

i am also facing the same issue that the anchor tag Attribute get Rearrange automatically. to set Content Filter to none will work for the Firefox & the chrome but it is not working for the IE,
another problem at same place i am facing is the color is showing in rgb value, but originally i add it as hex value
original &lt;<a style="color: #000000;" class="1" title="PrimaryZone" tagname="Primary Zone">Primary Zone</a>&gt;
after change what i got in IE &lt;<a title="PrimaryZone" class="1" style="color: rgb(0, 0, 0);" tagname="Primary Zone">Primary Zone</a>&gt;

[Ianko]

Hi Mohit,

The conversion of the RGB to HEX is done with the ConvertToXhtml filter and it is not recommended to be disabled.

The conversion is intended to provide a consistent style behavior across browsers.

Regards,
Ianko
Telerik