just to tell from my experience with basic users of WYSIWYG HTML editors: one of the first things anyone does when using a WYSIWYG editor is to try to indent text with the TAB key as anyone does in any text editor and it doesn't work. Result: they feel frustrated compared to OO or MSOffice. You can try to explain that it's HTML and not Word but their first feeling is bad and the conclusion is:"Your stuff is not good enough yet and I don't want to spend time on that" br Pascal On Sun, Dec 28, 2008 at 2:43 PM, Thomas Mortagne <[email protected]>wrote:
On Sat, Dec 27, 2008 at 8:21 PM, Anca Paula Luca <[email protected]> wrote:
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).
+1
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.
+1
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.
+0.5
C2) Insert just one (breaking) space to discourage users from using the tab key to layout text.
-0 I'd really prefer C1) or doing nothing.
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
+0
and: C4) default browser behaviour -- move focus to next form field (which is happening now for all situations)
-1 for this, we should not loose WYSIWYG focus. Plus even if FF jump to next form field by default it's not the case for IE which insert a tab character and I doubt we did anything to change this behavior yet, do we ?
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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs