6 Dec
2008
6 Dec
'08
9:48 a.m.
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/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