Editing the board description seems closer to the context of editing a wiki page than the context of replying in a discussion (e.g., actions such as "mention" seem unlikely to be used, and users may edit larger content multiple times). Thus, I think it is reasonable to use the default VE toolbar when editing the board description (due to space constraints we may want to hide the references, table, and special character options inside the "insert" menu).

Regardless of the toolbar version used, it makes sense to keep it floating, considering the length of the content here.

In T100828#1330342, @DannyH wrote:

When you're editing a page, the floating toolbar also includes the Save page button. If we move the toolbar to the top, would it matter if the cancel/save was at the bottom?

Good point. We should probably have Save/Cancel in the same place as the other controls, which would imply putting them in the toolbar, which would imply putting them in the toolbar consistently, both when it's at the top and when it's at the bottom. Pau, thoughts?

When you're editing a page, the floating toolbar also includes the Save page button. If we move the toolbar to the top, would it matter if the cancel/save was at the bottom?

I think it would make sense to integrate them in the toolbar as if you were editing a regular wiki page. I provide more details below.

Good point. We should probably have Save/Cancel in the same place as the other controls, which would imply putting them in the toolbar, which would imply putting them in the toolbar consistently, both when it's at the top and when it's at the bottom. Pau, thoughts?

Although both are supported by VE, we are talking about two different components from the user perspective:

• Lightweight rich-text areas. . Text areas represent a piece of content which may vary in length but is normally not extremely long. It makes sense to extend the regular text areas with aids to help the user control the rich content they contain (e.g., keeping the actions visually inside the text area, and keep them attached to the bottom to make them feel more lightweight). Several of these areas (and other controls) can appear in the same form, so it does not make sense to embed form actions in them. For example, when creating a new topic you have two input fields (one of them being a rich-text area) while the "start new topic" action affects the whole form.
• Rich text documents. Documents contain rich content (often in large amounts) and there are actions that can be performed in the document themselves (e.g., save, publish, share) in addition to those to modify the content inside the document. For those cases it makes sense to integrate all actions related to the document together (e.g., in the same toolbar).

We can resolve the current issue with both kinds of elements:

• If we plan to have a single action to edit the whole sidebar and expect long-content to be added there, we can go with the "rich text document" approach. In that case the whole sidebar will become VE-based document editor with a toolbar on top that integrates the save action (just like a regular wiki page edited with VE). In this case, the toolbar actions can be rearranged a bit to make sure fits well the reduced width of the side rail (expanding the siderail when editing it is another option, but it has a reorientation cost).
• If we plan to have independent units of information which are not excessively long or contain complex content (or we want to push them to be that way), then a "lightweight rich text area" can work. We can just set the max-height to make sure it does not become bigger than the viewport (including the save buttons at the bottom) and rely on the internal scrollbars to move around the content (that probably also depends on T97457). In addition, a different set of actions may be needed since the kind of content we expect on the side rail is expected to be different than the one found on discussions (e.g., an action for mentions may not be needed, but one for adding templates and lists may be).

Given the current content we see in talk pages, I was suggesting to go with the "document" approach for the side rail; but I'm ok starting with the "rich text area" approach if we can adjust properly its main height as described above, and check how it is used.

I agree that we're likely to see longer content in the side rail, based on what's in the header on most talk pages now. I think the "document" approach makes sense.