span tags are replicating in certain contexts

[Mike]

Hello, discovered weird behaviour in CKEditor 4.4.5 integration testing for our CMS. Our current legacy CMS has been responsible for over using span tags, so this isn't a case where it's manually entered HTML that can just be cleaned up in a jiffy, chances are hundreds of our customers will be applicable for this quirk if we roll out CKEditor in our CMS.

The issue is when a span tag is surrounding a table tag.

Example 1 - this code is pasted into the source view, switch back to wysiwyg view then back to source view:

<span class="class1">
   <table>
      <tr>
         <td><span class="class2">Content Here.</span></td>
         <td>Content Here.</td>
      </tr>
   </table>
</span>

I did testing and narrowed it down to being a core editor behaviour that is separate from ACF.

Example 2 - with ACF disabled

<table>
  <tbody>
    <tr>
      <td><span class="class1"><span class="class2">Content Here.</span></span></td>
      <td><span class="class1">Content Here.</span></td>
    </tr>
  </tbody>
</table>

Example 3 - With ACF disabled and removal of blank span tags disabled (CKEDITOR.dtd.$removeEmpty.span = 0;)

<span class="class1"> </span>

<table>
  <tbody>
    <tr>
      <td><span class="class1"><span class="class2">Content Here.</span></span></td>
      <td><span class="class1">Content Here.</span></td>
    </tr>
  </tbody>
</table>
<span class="class1"> </span>

Ideally, I would of expected that the default behaviour would be to remove a span tag completely when surrounding a table tag since as far as I know a td does not inherit styles from a span tag.

Obviously besides the span tag replication, the issue for me is new styles are being applied to content. Examples 2 and 3 insert copies of the span tags in table cells, and Example 3 just seems to be even worse by inserting new span tags as well as making two blank ones.

This is replicated for me in browsers FireFox 33.1, Chrome Version 39.0.2171.65, and IE 11 (haven't tried other browsers). I run windows 7 64 bit.

[Mike]

Examples 2 and 3 are what the editor transforms example 1 into. Sorry should have been more clear on that.

[Piotrek Koszuliński]

I'm sorry for the late reply. Unfortunately we're not able to process every ticket immediately.

Example 2 shows a correct behaviour. Correct means - the parser was designed to work this way and I think that this is a highly justified decision. If you pass incorrect HTML structure (table inside a span) through the parser it tries to fix it. If the content was correct, nothing would happen. But if an unexperienced user creates such structure in a source mode (to which they should not have access in such case), then we can assume that they intended to apply that span or any other element (e.g. a <strong>) to an entire table. The only way to keep those tags is to move them to a correct context - i.e. inside <td>.

Example 3 shows a little bit how the parser works internally (that table splits the span). This is again, absolutely correct. Spans can be left outside the table - parser has no reasons to remove them. But empty inline elements cannot be edited, so the dtd.$removeEmpty specifies them all, so they are removed.

I don't see here any incorrect behaviour so I'm closing this ticket. We can reopen the ticket, so feel free to reply.