On Dec 6, 2008, at 9:06 AM, Marius Dumitru Florea wrote: > 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).
Actually it's not just for paragraphs but for separating any block elements (paragraphs, lists, block macros, hr, headers, etc)/ Thanks -Vincent > 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
