6 Dec
2008
6 Dec
'08
9:06 a.m.
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/devs@xwiki.org/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