Marius Dumitru Florea wrote:
Hi devs,
We have to decide upon the proper behavior of the Tab key in the new WYSIWYG editor. Open Office has the following behavior:
A) If the caret is inside a table cell then jump to the next one (or previous one with Shift).
B) If the caret is at the beginning of a list item then indent that item (or outdent with Shift). By indent I mean make it a subitem of the previous list item.
C) Otherwise insert a Tab. The Tab doesn't always have the same width; it depends on the top ruler and on the caret position. Shift+Tab is ignored.
I'm +1 for A) and B)
Regarding C), it's difficult to have the same behavior. What we can do is:
C1) Insert spaces (say 4); we would have to use non-breaking spaces of course.
C2) Insert just one (breaking) space to discourage users from using the tab key to layout text.
I'm +0 for C1) and +0.5 for C2).
+1 for A) and B) -0 for C1). Imagine users could indent everything at the start of every line with tabs to have a paragraph indented 4 spaces away from the left. We definitely should not allow that. Which makes me think about the degree of wysiwyg-ness of what we're building since the width of the editor is never preserved / guaranteed for the view. Indeed users should not rely on that but we need to make sure somehow that they are well aware of it. there is also : C3) do nothing and: C4) default browser behaviour -- move focus to next form field (which is happening now for all situations) and also: C5) if the cursor is at the beginning of a paragraph it should indent the first line in the paragraph (the CSS way), but I am pretty sure that's too much trouble. +0 for C2) +0.5 for C3) and C4). Happy coding, Anca Luca
I need your vote asap.
Thanks, Marius _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs