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 > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
