28 Dec
2008
28 Dec
'08
5 a.m.
Anca Paula Luca wrote:
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.
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. 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/