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