Comments design evolution

We found out two issues with the newly integrated comments rich editor.

  1. This has a negative impact on page load time
  2. This can break the use of keyboard shortcuts (cf XWIKI-17614)

For these reasons, we propose to not activate the rich editor by default and to only activate it on demand.
You will find below two design proposals for this evolution.

Proposal 1

Adding a clickable text to expand the comment input field on click.
The comment form would only be expanded when the text is clicked.

Screenshot_2020-08-07 Home - XWiki(1) Screenshot_2020-08-07 Home - XWiki

Proposal 2

Displaying a text field without rich editing activated on page load.
The rich editor is activated lazily once the user clicks on the text field.


  • More engaging toward user contribution because it’s more visible
  • The user experience stays almost the same


  • More space consuming


Actually 3 :slight_smile:

The 3rd one is that displaying the WYSIWYG for all pages in veiw is quite obstrusive.

I’m +1 for proposal 1 but I don’t really like the proposed design.
Since we used to have the whole width to click on for starting to type the comment, I think I would have preferred to have some kind of fake full-width div button that you could click on directly.
Thinking about something like that: Capture d’écran_2020-08-07_15-03-27

FTR, re Proposal 2 it’s the same L&F as what we had before 12.6.

@surli for me your proposal is proposal 2 (with just a smaller height) :wink: In any case it’s closer to proposal 2 than proposal 1.

Well proposal 2 is about providing in the html an actual textarea, while I’m proposing to have an actual div element. The difference is important since I don’t know how this textarea would need to be handled with some JS to be transformed when you focused on it, which might be unexpected for users. While with my solution you expect some reaction when clicking on the button.

From a technical and implementation POV it might be different (but not so much since transforming a DIV or a TEXTAREA is the same IMO; they both require JS to replace the element) but from a user POV it’s about having a zone (like a textarea) that you click and that transforms into a WYSIWYG editor.

Well it all depends how you plan to show proposal 2, but if the proposal is to keep displaying the old textarea we used to have then I don’t agree with your assumption. Because in that case, the user POV is to be able to type directly his text when he clicks on the textarea, not the textarea to be transformed in any way.

Isn’t that what you’re proposing? Your suggestion really looks like a one-row textarea. It has a text of “click to add a comment…” which I assume (and I think it’ll a general assumption from users seen that it doesn’t look like a button and it’s not the style or the xwiki buttons) that if you click it, then you can then start typing a comment. That’s exactly how the textarea proposal would work too.

Difference is that in my proposal it’s not a textarea, but really a button so you definitely cannot type once you clicked on it. You have to wait. While with proposal 2 since it’s a textarea, you’ll be able natively to type once you clicked on it, so you might lose what you type if it takes a bit of time to load or to interact with the focus event etc. That’s the main issue I see and that’s why I’m actually -1 for Proposal 2.

Now I’m open to discuss about the design of the button for Proposal 1, I don’t like the first design proposal made but maybe it’s only me.

Indeed that’s true that there’ll be a lag (to load the WYSIWYG editor). But you cannot type in the textarea since it doesn’t have the focus so you first need to click on it, that’s why I don’t see the difference. If there’s a way to capture the tab keypress so that we also transform it into a wysiwyg editor when you tab to it, then it’ll be the same as a button no?

What I don’t like too much with your proposal is that it’s not standard and not consistent with the controls that xwiki uses.

@surli to make it more clear what proposal 2 is about check JIRA. For example go to and try clicking in the description.

This is why I think we’re talking about the same thing. A better example might be The hover thing is quite nice too I think.

Well you’re bringing me more arguments there :slight_smile: There’s no textarea until you clicked in Jira. It’s a div which is transformed. So yeah I’m +1 to go towards something like that since it’s not a textarea (i.e. I cannot type until it’s loaded or if there’s an issue with my JS).

So to recap, for me the 2 proposals so far can be seen on

  • In the description area (clickable area - proposal 2)
  • In the comments area (button - proposal 1)

ok cool, we’re talking about the same thing. I said textarea but I’ve used the wrong terminology. I meant a zone that can be clicked and when you click on it it transforms into a WYSIWYG. The closest mental image I had was a textarea (a DIV is not visual).

Side note: We still need to handle the TAB keypress for accessibility if we choose proposal 2.

+1 to that. I don’t like it either.

I’m +1 for the first proposal, but I don’t like the link style. I would simply use a flat button with an icon. Same style as the Create page button.


+1 but maybe with a something a little more explicit like “Add comment”

A last vote to close the debate.

To summarize, solution 1 involves a button (with the style proposed by @mflorea, and the “Add comment” label proposed by @tmortagne). Clicking on the button displays the comment form.
Solution 2 offers a zone that has the look of an editable element (eg, textarea) and becomes active once the user click on it.

Solution 1.1: "Add comment"

  • -1
  • 0
  • 1

0 voters

Solution 1.2: "Comment"

  • -1
  • 0
  • 1

0 voters

Solution 2:

  • -1
  • 0
  • 1

0 voters

I think I prefer just “Comment” since it’s a verb and we use short verbs for actions: 'Edit", “Create”, “Administer”, “Copy”, “Rename”, etc.

Same here.