[xwiki-devs] [Proposal] New Line behavior in the new WYSIWYG editor
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 -- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://blog.xwiki.com/
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.
+0 for option 1. +1 for option 2. -1 for option 3. -- Sergiu Dumitriu http://purl.org/net/sergiu/
On Fri, Oct 24, 2008 at 4:16 AM, Guillaume Lerouge <[email protected]>wrote:
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>).
How would [[return]] affect being in the <UL> or <OL> or <DL> environments? Seems like those should have newline behavior that enters a new list-element, e.g. "<LI>" or <DD> etc. IMHO, this context-dependent [[return]] behavior is often why I've found it useful to have some kind of indication of the "structure" or environment one is currently in, and a dynamic menu of the possible "special subnodes" that might be available in a given context. In a paragraph context, a dynamic choice for <BR> vs <P> might be made more apparent in a "special area" of the display, in order to be more apparent to the user. For example, http://nielsmayer.com/wwweasel/node27.html implements these:
Navigation through the document is made easier by the use of emacs key bindings and Motif/Mac-like key bindings. Keyboard commands for moving up and down lines will move between different markup elements including ``in line'' images, horizontal separators, and anchors. Context sensitive insertion of spaces and carriage returns ensure that only legal HTML is generated. For example, spaces are not significant in HTML documents except within preformatted (<PRE>) elements, so extra spaces (which would not be visible in a WWW browser) are caught and the user is advised that the spaces will not be entered in the document.
One important feature of WYSIWYG view is the automatic generation of the appropriate separator markups upon hitting the <return> key: for example, if in a list (ordered, unordered, menu, etc) environment, it makes sense that hitting return will start the next list item (especially since extra whitespace typed into WWWeasel's WYSIWYG view are ignored). If in a definition list, then <return> will cause toggling between entering the definition-term or the definition-definition. Finally if in a ``generic'' environment not covered by definition lists or list environments then <return> will start a new paragraph.
I also have found it extremely useful to be able to display both structure and WYSIWYG information at the same time, e.g. http://nielsmayer.com/wwweasel/node26.html ... This is especially true for selection as it is easier to control the extent of something selected for cut/paste; for example, if one can see the cut/paste animating over the "structure" being selected (WWWeasel v2, unpublished, I have the Winterp-Lisp-code for it since I wrote it...). Additionally, providing "UI-hysteresis" to make selection or cut/paste && drag/drop targets sticky-to-markup-structure is a helpful UI-aide for the user. -- Niels http://nielsmayer.com
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
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
participants (5)
-
Guillaume Lerouge -
Marius Dumitru Florea -
Niels Mayer -
Sergiu Dumitriu -
Vincent Massol