TYPO3 Core

I think the problem arises when the link is the only element within the cell and you select the text and cut it (with ctrl-x or the cut button), or backspace it. The link remains even if there is no more text. If you start to enter some text in the cell, you see the link again. I think the same issue could arise, for example, in lists of links.

If fact, if you have the unlink button in the tool bar, you will see that after cutting the text of the link, the unlink button is still available, indicating that the link is still there. If you press the unlink button, the link is gone.

I am not sure how this should be resolved. If the text in a cell is inside any inline element, such as bold or strong, etc., the same behaviour will be observed. The text is gone, but the empty inline element remains.

In short, cutting cuts the text not the html markup.

This behaviour is common to all browsers, except that in case of an empty link, IE will remove it!

Until this is resolved, the only safe way is to use unlink before or after removing the text.

This turns out to be pretty inconvenient for editors.

Attached patch filters links without linktext on the way to database, since those links would not be visible at all in htmlarea.
Which is a change of behaviour as well and maybe should be configurable if applied... although I would think it rather is a bugfix :)

@Ralf: Is the filter susch as <a href=""></a> is filtered out but not <a href=""><td></td></a>

And how does it work if it's <a href="" class="bogus"></a>? You can define a class so it shows something without any content in it?

Hi Staffan,
currently my suggestion would filter both of your examples above.

Comment for example 1: I can see, that this probably would be no good if htmlarea is used for something like "RTE styling", which your example <a href=""><td></td></a> implies. Which supports the idea of having the behaviour of the filter configurable - maybe an option like: Only filter empty links if there is none of the following tags inside: [list of tags].

Comment for example 2: I tried that first. As from my experience, showing "empty" links by CSS styling won't work in IE: it just wouldn't apply the CSS style due to the display-property of links in htmlarea. Changing the display property of links in htmlarea has other nasty side-effects, therefore I'd say that this isn't the way to go.

If example 1 was rewritten to <a href=""><img /></a>?

Example 2 was not related to the BE but to the frontend representation of links. But at the same time, a loss of an empty link element is not a major problem for me.

Hi Staffan,

regarding example 2: I think I now understand the idea - you could then in frontend give such bogus links a display none or the like. I would however dislike that very much if it was thought that way.

Regarding example 1 - my suggestion ain't the way to go, thanks for pointing that out.
Since it's nearly impossible to judge, when to filter links and when not without knowing the use of htmlarea (and keeping in mind that this could mean undesired loss of information in worst case), there's the need for configuring this filtering; I will try to add this in the next couple of days.

Another idea would be to append a [&]nbsp; to the linktext if no text is found within the link tags. But this again would have possible undesired side-effects, why I'd think this is not a very good idea as well.

The attached patch (rtehtmlarea_bugfix_4670_trunk.patch) cleans up any empty "a" tag left over by a cut operation (using CTRL-x key or Cut button), as well as other garbage that Safari may leave behind.

Tested in FF 3.5, IE8, Opera 10 and Safari 4.

Please test it. After installing the patch, it is necessary to clear the RTE Cache and the browser cache.

Second version of patch applies to current trunk (revision 6404+).

Committed to SVN TYPO3core trunk (revision 6406) for inclusion in TYPO3 4.3.