Re: [w3c/editing] Should backspace merge text with last cell's content of a table above ? (#164)

Let me add some additional thoughts about this specific case and how it fir in the current spec. 

1- This use case corresponds to section "9.12 The delete command" (same as hitting backspace). 

In the note at the beginning, there is the following statement: 

" Backspacing at the start of most blocks merges with the previous block. (Visually, this is a matter of deleting a line break.)" 

I really think the above statement is a bit ambiguous; using the the term "most" gives poor information. At least, we should list there the blocks we already consider not valid candidates for block merging.  Maybe tables ? 

2- This use case corresponds to the step 16 "General block-merging case." 

I guess that we can consider that _start node_ is <div contenteditable=true> as soon as we hit backspace with the cursor just after the character "T". We could also have thought that we are at the anonymous block that contains the text, with offset 0, but then we would need an additional backspace to activate the block merging (if I have understood correctly the algorithm).

So, we are at start_node = <div contenteditable=true> and start_offset 1. There is indeed a start_node's child with index start_offset -1, which is precisely the table.  The first condition doesn't apply because the table is visible, but the second condition does apply.

So, _start_node_ is set to the <table> node.  I'm having hard time to figure out how to set the start_offset to length of the _start_node_ in this case (I assume there is something about how to do that for table elements). Lets assume _start_node_ ends up being the last <td> of the last <tr> in the table and the _start_offset_ the length of such <td> element. 

Once we are here, we can indeed merge the anonymous block containing the rest of the text ("esting") with the contents of the <td> In order to do that, we must follow the steps 17, 18 and 19 with the _start_node_ and _start_offset_ defined above.

And here is where I see a contradiction in the current spec. The step 19 is precisely the section "9.5 Deleting the selection". In such section there is a note at the step 14 that states: 

"We don't let either start block or end block be a td or th. This means we'll never merge to or from a td or th."

This statement implies that we can't merge contents of a different block into the <table> elements. This is compatible with the ambiguous statement that I remarked at the beginning; so perhaps we can define tables a not valid candidates for block merging after all, as I suggested before.

Such note also states:

"  This matches Firefox 5.0a2, and reportedly Word as well. Chrome 13 dev and Opera 11.11 allow merging from a non-table cell end block to a table cell start block, but not vice versa. In IE9 the delete key just does nothing." 

This is just a way of saying that there is no interoperability in this regard and I think the spec should aim for solving that issue. Considering that FF and Edge are compatible and that this proposal is to make Safari and Chrome follow that path, I think we should seriously considering it.
  

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/164#issuecomment-371452315