27 Dec
2008
27 Dec
'08
6:37 p.m.
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
27 Dec
27 Dec
8:15 p.m.
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
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
28 Dec
28 Dec
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/
11:52 a.m.
Sergiu Dumitriu wrote:
Yes, spaces would be inserted at the caret position.
[snip]
-0
Anca Paula Luca wrote:
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]
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 > 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. 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.
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
1:38 p.m.
Marius Dumitru Florea wrote:
Sergiu Dumitriu wrote:
Yes, spaces would be inserted at the caret position.
[snip]
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/
> 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. 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?
2:43 p.m.
On Sat, Dec 27, 2008 at 8:21 PM, Anca Paula Luca
<ancapaula.luca(a)xwiki.com> wrote:
+0
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 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
--
Thomas Mortagne
I need your vote asap.
Thanks,
Marius
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4 Jan
4 Jan
4:09 p.m.
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
<thomas.mortagne(a)xwiki.com>wrote;wrote:
On Sat, Dec 27, 2008 at 8:21 PM, Anca Paula Luca
<ancapaula.luca(a)xwiki.com> wrote:
line
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 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
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
I need your vote asap.
Thanks,
Marius
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5 Jan
5 Jan
12:19 p.m.
On Sat, Dec 27, 2008 at 8:21 PM, Anca Paula Luca
<ancapaula.luca(a)xwiki.com> 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.
5733
days inactive
5742
days old
9 comments
7 participants
participants (7)
-
Anca Paula Luca -
Jean-Vincent Drean -
Marius Dumitru Florea -
Pascal Voitot -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol