Visual Editor Creates Blank (Orphaned) Anchor Tags

[miqrogroove]

Steps to reproduce:

1. Insert image into new post.

2. Place cursor at the left side of image.

3. Press the delete key.

4. Switch to HTML view.

Expected results: Blank post. :)

Actual results: Empty anchor tags, and sometimes paragraphs too.

Workaround: Various combinations of Delete and Backspace key strokes can get rid of the anchor, but it is somewhat unpredictable.

[azaozz]

This is a browser bug. In FF you can't place the cursor before the image at all, in IE the delete key may behave unexpectedly (backspace works well), in Safari all seem to work properly.

There are many other oddities when the browsers are in contentEditable mode. Best would be to report these problems to the browser vendors.

For deleting images you can use the Delete button that shows when clicking on the image.

[miqrogroove]

Please reconsider the SEO consequences of having invisible links in blog posts. I can't believe there was a consensus about blaming the browsers.

[azaozz]

The delete button does not work as expected in Internet Explorer and Firefox. It works as expected in Safari and Chrome. There is no reliable way for TinyMCE or WordPress to fix these browser bugs, so I think they should be reported to the browser vendors and this ticked closed.

[miqrogroove]

What I'm getting at is if the browser is known to supply garbage, WordPress should filter it. <a href="google"></a> is easy to find and delete, is it not? Why be resigned to a garbage-in-garbage-out system?

[markjaquith]

Can anyone think of a valid case for an ID-less empty anchor?

[miqrogroove]

​http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=66353

Google considers links "hidden in a small character" as deceptive and "intended to be crawled by Googlebot". They do not get specific about links that have no characters.

[nacin]

Replying to markjaquith:

Can anyone think of a valid case for an ID-less empty anchor?

And name-less. That said, such an anchor could be given size, shape and position via CSS. I'm not sure I'd consider that valid, though.

[Denis-de-Bernardy]

I think the keyword in google's FAQ item is this:

If your site is perceived to contain hidden text and links that are deceptive in intent, your site may be removed from the Google index, and will not appear in search results pages.

I honestly doubt that Google takes empty anchor tags into account. It basically treats the anchor's text as a tag. If there no tag, the link would presumably be ignored.

That said, it don't cost much to filter empty tags out on the content_save_pre hook using some regex foo. We just need to make sure that we're not stripping out stuff that contains a name or ID attribute.

[hakre]

Ahh, not another filter running on the_content. WYSIWYG is defective by design so I would not wonder about some empty tags within the code. If someone is bothering, should get a tidy plugin or so. I find it very hard to properly take care of the broken output when we now the editor / concept is broken.

[hakre]

I suggest to close as invalid or wontfix.

[hakre]

miqrogroove any objections closing this as wontfix? or any suggestion on how to actually fix that?

[hakre]

It might make sense to test the behaviour against the default tinymce implementation and report bugs upstream.

[miqrogroove]

Replying to hakre:

miqrogroove any objections closing this as wontfix? or any suggestion on how to actually fix that?

hakre I don't file bug reports just for the thrill of seeing them rejected. As I pointed out above, filtering empty elements should be an easy accomplishment. I'd patch it myself, but I have close to zero experience in the post editing area of this code base.

[Denis-de-Bernardy]

@miqrogroove: note that you can strip those with a plugin in the meanwhile. the filter is content_save_pre, or something like that.

[miqrogroove]

This might be a different symptom of the same bug. Webmaster Tools just flagged this bit of garbage in the middle of a post:

<a rel="attachment wp-att-7429" href="http://domain.was.here/?attachment_id=7429"></a>

Not really sure how to reproduce that behavior, but it happened.

[azaozz]

Cannot reproduce this in FF or IE9 any more, appears fixed in the browsers.