27 Dec
2008
27 Dec
'08
8:21 p.m.
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs