[xwiki-devs] [VOTE] Tab key behavior in the new WYSIWYG editor
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). I need your vote asap. Thanks, Marius
On Dec 27, 2008, at 6:37 PM, 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)
+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.
C3) Indent the whole paragraph I don't know what I prefer... +0 for C1 and +0 for C3 I'd say but I can be swayed. Thanks -Vincent
I'm +0 for C1) and +0.5 for C2).
I need your vote asap.
Thanks, Marius
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
Anca Paula Luca 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, with the condition that list items should not become out of order, meaning that pressing tab will not create a third level item as a child of a first level item. Current editors allow something like this to happen, and our wiki syntax allows that, too, but I don't think that it is something that we should allow users to do. (Of course, now another question arises, what should happen if the wiki markup is already out of order. We could leave the list as it is, but ignore all further indentation requests)
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. If users want to indent, they will be able to do that with spaces (since now spaces are meaningful). Not doing this will not convince users not to indent paragraphs; they will continue to do this using spaces, but they will have one more grudge against XWiki. I implied that the spaces are inserted at the cursor position, and not at the start of the paragraph.
C2) Insert just one (breaking) space to discourage users from using the tab key to layout text.
-0. See the comment above.
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.
It was my impression that the WYSIWYG tries to allow the user to do whatever he wants, regardless of the significance of his actions. Although I agree that we should not let users indent paragraphs with spaces/tabs, it is against the goals of the editor, so for consistency, I disagree with you here.
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, although this might confuse users a bit. If they expect a full MSWord clone, they'll expect _something_ to happen.
C4) default browser behaviour -- move focus to next form field (which is happening now for all situations)
-1. If we vote for A and B, then this will be very confusing. Sometimes pressing tab does something, most other times it simply moves the focus somewhere else. Losing focus is not good. The user might not watch the screen, and loose important keystrokes before noticing that he's typing in the wrong place. OTOH, not doing this means that there's no way to navigate out of the editor without the use of the mouse. And I strongly disagree with this. I don't like taking my hands off the keyboard. When I find something that doesn't work without the mouse in a site, the accessibility/usability pseudo-expert in me wakes up and gets very angry. VERY angry.
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.5. This requires presentation rules to be embedded in the content. I know that many things will require the use of embedded style, but this is not essential, thus I'd rather avoid it. C6) Move to the start of the next block element (prev with shift). -0, since no text editor does this (spreadsheet software does this, but that's the same as with tables). Other questions: - What does GoogleDocs do? - What happens when pressing tab in/on other types of content, like images, macros, definition lists, code (which is a kind of macro). - What happens when a selection exists? In one para, and cross-para?
+0 for C2) +0.5 for C3) and C4).
Happy coding, Anca Luca
-- Sergiu Dumitriu http://purl.org/net/sergiu/
Sergiu Dumitriu wrote:
Anca Paula Luca wrote:
Marius Dumitru Florea wrote:
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, with the condition that list items should not become out of order, meaning that pressing tab will not create a third level item as a child of a first level item. Current editors allow something like this to
Would the following be considered a proper indentation? <ul> <li> <ul> <li>x</li> </ul> </li> </ul> This is the HTML generated for "** x" in xwiki/2.0. I think we should do the same in the WYSIWYG. Of course for this I'll have to overwrite the default list and indent/outdent support which currently generates invalid HTML for nested lists. Indent would then not only visually move the list item to the left but down also. [snip]
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. If users want to indent, they will be able to do that with spaces (since now spaces are meaningful). Not doing this will not convince users not to indent paragraphs; they will continue to do this using spaces, but they will have one more grudge against XWiki. I implied that the spaces are inserted at the cursor position, and not at the start of the paragraph.
Yes, spaces would be inserted at the caret position. [snip]
OTOH, not doing this means that there's no way to navigate out of the editor without the use of the mouse. And I strongly disagree with this. I don't like taking my hands off the keyboard. When I find something that doesn't work without the mouse in a site, the accessibility/usability pseudo-expert in me wakes up and gets very angry. VERY angry.
And you propose?
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.5. This requires presentation rules to be embedded in the content. I know that many things will require the use of embedded style, but this is not essential, thus I'd rather avoid it.
-0
C6) Move to the start of the next block element (prev with shift).
-0, since no text editor does this (spreadsheet software does this, but that's the same as with tables).
-0
Other questions: - What does GoogleDocs do?
* Tab outside a list item or table cell inserts 4 spaces at the caret position or in place of the current selection (inside a span with no styles applied to it; I don't understand why they use a span since if you delete the spaces the empty span remains as HTML garbage) * Shift+Tab moves the focus out of the rich text area to the previous focusable element.. :| * [Shift+]Tab inside a table cell behaves as in Open Office. The selected text (if any) is not deleted. * Tab at the beginning of the first _empty_ list item indents the list using style="margin-left: 40px"; each Tab increases the left margin with 40px.. :| Shift+Tab removes the list.. :| * Tab inside a list item no matching the previous case indents the list item. Even in the middle of the text :|. Shift+Tab outdents. The selection is not cleared. * If the selection spans across more list items, but not all, then Tab indents those list items. Shift+Tab outdents. Selection is not cleared. * if the selection spans across all list items from a list then pressing Tab indents that list using CSS as previously described. Shift+Tab removes the list if the left margin is 120px.. :| * if the selection spans across more table cells then pressing a Tab deletes the selected text and inserts 4 spaces in the cell where the selection started :| Shift+Tab moves the focus out of the rich text area to the previous focusable element.. :| ...
- What happens when pressing tab in/on other types of content, like images, macros, definition lists, code (which is a kind of macro).
Each could easily have their own custom behavior. But let's decide first for paragraphs, list items and table cells.
- What happens when a selection exists? In one para, and cross-para?
It depends on the action taken: * Insert: deletes the selected text and places the inserted text where the selection started. * Indent: keeps the selection. * Navigate: you have to collapse the selection in order to move the caret. Thanks, Marius
Marius Dumitru Florea wrote:
Sergiu Dumitriu wrote:
C1) Insert spaces (say 4); we would have to use non-breaking spaces of course. +0. If users want to indent, they will be able to do that with spaces (since now spaces are meaningful). Not doing this will not convince users not to indent paragraphs; they will continue to do this using spaces, but they will have one more grudge against XWiki. I implied that the spaces are inserted at the cursor position, and not at the start of the paragraph.
Yes, spaces would be inserted at the caret position.
[snip]
OTOH, not doing this means that there's no way to navigate out of the editor without the use of the mouse. And I strongly disagree with this. I don't like taking my hands off the keyboard. When I find something that doesn't work without the mouse in a site, the accessibility/usability pseudo-expert in me wakes up and gets very angry. VERY angry.
And you propose?
Go with spaces, since the tab key is important for users, and normal users aren't that bound to the keyboard as I am. We could try to use Ctrl+Tab to go to the next field, although it is used by browsers to switch tabs (or the OS to switch desktops). -- Sergiu Dumitriu http://purl.org/net/sergiu/
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
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
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).
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 for A) and B)
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.
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.
C3) do nothing
+0.
C4) default browser behaviour -- move focus to next form field (which is happening now for all situations)
-1 since this is what we're trying to avoid.
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, this seems not noobproof enough to me. Thanks, JV.
participants (7)
-
Anca Paula Luca -
Jean-Vincent Drean -
Marius Dumitru Florea -
Pascal Voitot -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol