You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Attached is a small patch that tries to improve behavior a little bit when
pasting content that includes TABs into contenteditable divs. It just adds
some regex translation for the unicode tab character and HTML tab entities to
single spaces.
AFAIK true tab-stop support in a DIV would be much harder than in a textarea.
At least, it seems like it would require a more complex structure for the HTML
children of the div, and that is not currently in the scope of what the divhack
code can handle.
Here is a summary of what to expect regarding TAB and contenteditable divs:
1) when typing in a contenteditable div with jV/divhack enabled, hitting the
TAB key will insert a single space when the jV option "The tab key, in insert
mode, should... insert a tab" is selected. Hitting the TAB key will move focus
out of the div when the jV option "The tab key, in insert mode, should... move
focus out of the textarea, as usual.". This should all be true both in a gmail
compose contenteditable div as well as in a simple unadorned contenteditable
div.
2) pasting plain text content which includes ascii or unicode TAB characters
differs in gmail compose vs an unadorned contenteditable div. In the latter
case HTML content is inserted into the DIV which simulates tabs (this appears
to be the same whether or not a simple paste or a "paste and match style" is
selected). It should still be possible to use jV to edit plaintext above the
pasted HTML content as long as the jV option "allow editing above HTML content"
is enabled, but the pasted HTML content (nor anything below it in the div) will
be editable.
3) pasting plain text content which includes ascii or unicode TAB characters in
gmail compose differs depending on whether the compose div is set to "plain
text mode". If so then TAB characters are translated to single spaces upon
paste, and the pasted content is considered plain text and remains part of the
jV/divhack-editable region in the div.
4) pasting plain text content which includes ascii or unicode TAB characters in
gmail compose with "plain text mode" off behaves the same as a paste into an
unadorned contenteditable div (case 2 above)
5) pasting cells of an HTML table (for example, a clipboard copy of a region
from a google spreadsheet) into an unadorned contenteditable DIV behaves as
case 2 above when selecting "paste and match style". For a plain paste an
actual HTML table is inserted into the div (and the same caveats about
jV/divhack being able to edit only content above it apply)
5) pasting cells of an HTML table into a gmail compose with "plain text mode"
on and selecting "paste and match style" behaves as case 3 above: tabs are
converted to spaces and the result is editable plaintext. A simple paste in
this case also results in editable plaintext but the tab characters are deleted
entirely, cramming adjacent cell contents together.
6) pasting cells of an HTML table into a gmail compose with "plain text mode"
off behaves as case 5 above
Original issue reported on code.google.com by [email protected] on 17 Dec 2013 at 8:58
The text was updated successfully, but these errors were encountered:
Original issue reported on code.google.com by
[email protected]
on 17 Dec 2013 at 8:58The text was updated successfully, but these errors were encountered: