WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 14 months ago

#26332 new defect (bug)

TinyMCE stripping <a id="abc"></a> on empty line

Reported by: Ipstenu Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 3.2
Component: TinyMCE Keywords: upstream close
Focuses: Cc:

Description

From http://wordpress.org/support/topic/mce-editor-stripping-attributes-and-removing-tags?replies=7 (started 11 months ago)

If you type in <a href="#"></a> in Text mode then switch to Visual and back, that tag gets replaced with a non-breaking space &nbsp;

Reported as an issue in 3.7.1

Attachments (1)

26332.diff (665 bytes) - added by alaminopu 4 years ago.

Download all attachments as: .zip

Change History (20)

#1 @SergeyBiryukov
4 years ago

  • Version changed from 3.7.1 to 3.2

3.1 and older versions keep the link.
3.2 and 3.3 remove it completely.
3.4 and newer versions replace it with &nbsp;.

#2 @Ipstenu
4 years ago

Excellent. I was only up to 3.5 testing when you posted this :) Thank you SergeyBot!

#3 @SergeyBiryukov
4 years ago

  • Component changed from Editor to TinyMCE

#4 @dgwyer
4 years ago

  • Cc d.v.gwyer@… added

#5 @Ipstenu
4 years ago

  • Keywords needs-patch added

This is still a problem with TinyMCE 4.

#6 @azaozz
4 years ago

Generally empty inline tags are considered "cruft" in HTML. They are "invisible" when the HTML is rendered (both on the front-end and inside TinyMCE), cannot be created using the editor and cannot be selected or edited inside the editor. Also, can be deleted without the user realizing it.

The reason an empty <a> tag is replaced with &nbsp; is because the <a> is wrapped in a <p> on switching to the Visual editor. Then on switching to the Text editor the content is cleaned up, the <a> is stripped and the empty <p> is preserved (by popular demand) by inserting &nbsp;.

#7 @Ipstenu
4 years ago

I understand. Was this a change in TinyMCE's processing or ours? Since this did work pre-3.1 (My personal expectation is "Yeah, invisible things go away, don't cross the streams between editors.")

#8 @azaozz
4 years ago

Not sure about pre-3.1 but MCE has been removing empty <a> for quite some time. Note that the old style "anchors" still work: <a name="abc"></a> is not stripped. In MCE 4.0 <a id="abc"></a> is kept too.

This ticket was mentioned in IRC in #wordpress-dev by alaminopu. View the logs.


4 years ago

@alaminopu
4 years ago

#10 @alaminopu
4 years ago

  • Keywords needs-testing has-patch added; needs-patch removed

TinyMCE was removing empty <a> node other than having attributes 'name' and 'id'. I just stopped it to do that.

This ticket was mentioned in IRC in #wordpress-dev by alaminopu. View the logs.


4 years ago

#12 @azaozz
4 years ago

  • Keywords close added; needs-testing has-patch removed

26332.diff patches TinyMCE's core. We can't do that :)

As far as I see removing empty <a> is the expected behavior and has been done for years. Don't see a compelling user case to stop it now.

#13 follow-up: @MadtownLems
3 years ago

Note that the old style "anchors" still work: <a name="abc"></a> is not stripped. In MCE 4.0 <a id="abc"></a> is kept too.

With MCE 4, (WP 3.9+), this is true only IF the anchor isn't on its own line.

If the anchor is on its own line, then <a name="foo"></a> is preserved, but <a id="foo"></a> is converted to a non-breaking space.

#14 in reply to: ↑ 13 @iseulde
3 years ago

Replying to azaozz:

In MCE 4.0 <a id="abc"></a> is kept too.

Replying to MadtownLems:

If the anchor is on its own line, then <a name="foo"></a> is preserved, but <a id="foo"></a> is converted to a non-breaking space.

Yeah, for me <a id="abc"></a> disappears too.

#15 @azaozz
3 years ago

  • Keywords close removed

Yeah, seems TinyMCE is too aggressive in removing empty <a> tags, <p><a id="abc"></a></p> is treated as empty paragraph. Worth opening a ticket upstream.

#16 @iseulde
3 years ago

  • Summary changed from TinyMCE stripping attributes and removing tags to TinyMCE stripping <a id="abc"></a> on empty line

#17 @iseulde
3 years ago

  • Keywords upstream added

#18 @afercia
23 months ago

  • Keywords close added

For accessibility, I think WordPress shouldn't encourage the usage of empty links. Reading the post on the support forum, also the usage of links for interactive controls

<a href="#"></a>

shouldn't be encouraged. Controls that behave like buttons should be buttons.
I don't see a use case for

<a id="abc"></a>

unless I'm missing something.
Just tested and

<a name="foo"></a>

is always preserved, both within a line of text and in its own line. Would propose wontfix :)

#19 @kcrusher
14 months ago

@afercia A good use case is for linking to content further down the page or to specific content on another page (rather than landing at the top of the page). You can't do that with a name property, at least that I'm aware of. Having to put content within the link doesn't always make sense - for example, I may want to put it higher than the content I want to show so that the content ends up in the middle of the viewport, rather than at the top.

Note: See TracTickets for help on using tickets.