FYI, I've discussed with Vincent about the new line behavior and we agreed to follow option 2 (well, Vincent already did this in the rendering module), precisely:
* 1 return key generates a br * 2 consecutive return keys generate a paragraph * for each consecutive return key above 2 we'll generate a div with class wikimodel-emptyline (their purpose is to separate paragraphs). You can follow this on http://jira.xwiki.org/jira/browse/XWIKI-2936 Thanks, Marius Guillaume Lerouge wrote: > Hi, > > In the current implementation of the WYSIWYG editor, when adding content, > pressing the return key creates a new paragraph (<p></p>) and pressing > shift-return creates a new line (<br>). > > In the wiki editor, the following behavior was discussed and implemented ( > http://www.mail-archive.com/[email protected]/msg04436.html ) : > > *>> So typing a new line in the wiki editor will result in a br tag in the >>> corresponding HTML? And two consecutive new lines in wiki editor will >>> result in a new paragraph? >>> >>> yep exactly.* > > After talking with our project managers and gathering their feedback from > the way customers use our tool, I think that implementing a similar behavior > in the WYSIWYG editor would be more intuitive for users : > > - Pressing return once generates a new line - <br> > - Pressing return twice generates a new paragraph - <p></p> > > In order for this behavior to be transparent for the user, the CSS setting > the height of blank space between 2 paragraphs should set it a one line's > height. > > In order to respect user intentions on the screen, we would also need to > handle the case where the user inputs, say, 4 return keypresses in a row. We > could handle it by inputting <br> tags and having the last tag be a > paragraph : > > <p> Some text </p> > <br> > <br> > <br> > <p> some other text </p> > > Another option would be to go the way of recent editors such as Google Docs > and ditch <p> in favor of <br> tags only. > > So there are 3 options: > > 1. Keep the current implementation (*pros:* it's working this way > already, *cons:* it's not what our project managers say our users expect) > 2. Use 1 return keypress for <br> and 2 return keypresses for <p> (*pros: > * it's more intuitive for users, it keeps the semantic meaning of <p>, * > cons:* it takes time to implement and we're already lacking time) > 3. Input <br> only everywhere, all the time (*pros:* that's what modern > editors do, *cons:* additional work, we lose the semantic meaning of <p>) > > I'm +1 for option 2. > > Guillaume > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
