Selection after table remove

[mlewand]

We need explicitly specify what's the desired selection once the table is removed.

Consider following case:

<p>Some text</p>
<table>
    <tr>
        <td>Simple table</td>
    </tr>
</table>

What should the selection be when the table is removed? We have three options:

1. Put the selection at the end of preceeding element.
2. Replace table with a default flow content element, relevant for current context.
3. Put the selection at the beginning of subsequent element.

I'd be in favor of option 1. - it feels like a reverse operation to inserting the table. If following HTML has been used at the beginning (^ marks selection caret):

<p>foo^</p>
<p>bar</p>

Then inserting table would result with:

<p>foo</p>
<table>
    <tr>
        <td>^</td>
    </tr>
</table>
<p>bar</p>

So it's logical that if I decide to remove the table, the selection goes back to where it was.

[mlewand]

It's important to keep in mind that tables might be used in various contexts: directly in the editor, inside of a list item or another table just to name few possibilities.

[fredck]

I have the impression that "2" is an ok behavior and much easier to implement and avoid edge cases.

[mlewand]

@fredck I agree that it might be easier to implement, but I don't think it's acceptable from end user perspective.

Just think about it: you want to cleanup a document, and there are couple tables that you no longer want to have. So you select the table, pick the "Delete Table" option and you end up with an additional paragraph, that you need to remove once again.

What would be your pick if implementation costs wouldn't be considered?

[fredck]

I sincerely don't see the big deal. I would really not be surprised with such behavior.

At a minimum, this behavior would be consistent. No matter if the table is at the beginning of the text, end of it, preceded by content that doesn't catch the selection and many other weird cases.

For example, what if there are two tables, one right next to the other. I would find it surprising to have the first table selected if I delete the second one.

[mlewand]

Rather than selecting whole preceeding element, I'd imagine it going to last editable position, so here put a collapsed selection in last cell of previous table.

It feels natural for me.

At a minimum, this behavior would be consistent. No matter if the table is at the beginning of the text, end of it, preceded by content that doesn't catch the selection and many other weird cases.

Yes there is a case when you don't have any flow content element before remmoved table, but I find this inconsistency less punishing for the end user than requiring additional step to delete the table. In the end user explicitly marked the intention, user want's to delete the table - nothing more, nothing less.

[fredck]

Here we are, discussing specific cases. And if we keep talking and thinking, option 1 will have other weird scenarios, like what if I want to insert a table right after having deleted that one. That table insertion would not happen in the same place, but inside a table cell, a list item, the paragraph before a ruler, etc.

I just have the impression that if we keep thinking we'll find yet other exceptions and the proposed solution would be very fragile.

I'm still for option 2. It's a pretty ok and, mainly, safe approach.

It would have some similarities with the deletion of an empty list. I never got pissed because I have to delete twice to get rid of it.

[Reinmar]

(After reading only 2 first comments)

CKEditor 5 implements the second option. After you remove a widget (which is similar to removing a table) it leaves an empty paragraph in place of that widget.

Back in the days, in CKEditor 4 I implemented a different solution. The selection was moved to the previous paragraph (IIRC). Unfortunately, this leaves a lot of edge cases. We tried to have the same in CKE5 at the beginning, but we realised that the number of edge cases meant that support for them won't be cheap. So we changed the algorithm to replace the widget with an empty block and it helped a lot. No edge cases, no reasons to break.

PS. I thought that ER was not about implementation details. I preferred from the beginning if we could discuss here behaviour of the features, but you didn't want to. Turns out that we're discussing these matters anyway. Perhaps ER could be extended to cover also these aspects?

[Comandeer]

Are we still interested in pursuing this?