If you add cm_dontconvertlink to a link in an editable field via the source view, the rich text editor converts this to a vaild xml shape,
e.g <a cm_dontconvertlink="" href="blah">
This does still stop the link converting in the rendered email, but after stripping out the cm_dontconvertlink, leaves the ="" still in there e.g
(this may have even happened in the old system, but generally i'd like to say congrats on the new system, it's great.)
Thanks for the heads up about that Toby, it's something we can definitely tweak to avoid the empty="". Glad you're liking the new system too.
I'd just like to add a request to get something that handles the cm_dontconvertlink="" nicely on the email generation. We ran into a problem where this was intermittently causing a problem with the problem with the preview and it appeared to be the editor behaviour that was causing us grief.
The problem in the preview of the email is that it takes
<a cm_dontconvertlink="" href="http://blahblah.com">
and turns it into
This <a="" seems to cause a major issue with any actual web browser and it won't display the text as a link.
All the browsers I've tested will at least render it as a link when it is entered as
<a href="http://blahblah.com" cm_dontconvertlink="">
and shortened to
The problem here is that whenever the editor loads the content, it moves the cm_dontconvertlink="" to the beginning of the tag. This means that every time you edit a section that has a link in it (even if you're not changing the link), you need to remember to go and move the cm_dontconvertlink to the end of the tag. To make matters worse, firefox always moves the cm_dontconvertlink to another position. You can flip the source on and off and watch the cm_dontconvertlink move from the front of the tag to the end of the tag and back again.
We were able to help a client who ran into this problem, but it took a while to figure out what was going on and it turns the editor from a beautiful tool into a nightmare if you're dealing with links that you don't want to track properly. If the email generation removed cases of cm_dontconvertlink="" and cm_dontconvertlink then it would eliminate the hassle of positioning it in the right place and the possibility that a browser/email client won't happily handle the badly formed tag the currently gets generated.
I haven't tested this with cm_dontimportimage but I'm guessing that the exact same problem exists there.