Allow toolbar to be displayed at the top of the editable area

[briri]

We have a need to place the toolbar at the top of the textarea rather than in a dynamic position close to the user's selection. I think this would be valuable to provide as an option to the div element to allow users to choose the location of the toolbar.

For example:

<div id="about" editable data-type="area" menu-position="[fixed|inline]">
    <p>Tell us <strong>something</strong> about <em>you</em></p>
</div>

[michael]

Can you describe the situations where the overlay (dynamic positioning) makes problems? Maybe we can do improvements there instead.

I see several issues with a fixed toolbar:

• when fixed we need to either reserve space or display toolbars for all texareas at all times
• either way the fixed toolbars will 'pollute' the page design and there will be a stronger need to customize toolbars / icons etc. to fit the page layout
• when a toolbar is anchored at the top of a text area and given there is a lot of text (e.g. multiple pages), the toolbar would need to follow the cursor as you scroll down

I think one fixed toolbar works well for editor 'apps' when they are always visible outside of the scrollable editing area (cmp. Word, Google Docs, Texture). However for our light-weight Forms use-case, I think the contextual toolbar is the better option.

[briri]

@michael I understand your points about using a fixed toolbar. I think perhaps the concerns could be solved in other ways. We found 2 specific situations where the current toolbar was either problematic or confusing for a user:

1. The user must highlight text to get the toolbar to appear. This means that they must first enter text and then apply styling afterward. It does not allow for them to select styling first. While it is common for users to apply styling afterward it is also common for them to try to set styling before they begin.
2. The user highlights text, the toolbar appears, they select the 'comment' feature and the focus changes to the commenting text area. At that point the toolbar in the main text area stays in place and is hiding some of the underlying text from the commentor. It would be better if they could see the entire text while typing their comments.

The 1st item is not necessarily an issue with the toolbar position. It is more of an issue with timing and when the toolbar becomes available. Perhaps if it were available on focus it would allow the user to select styling and then enter text.

The 2nd issue could perhaps simply be resolved by hiding the toolbar when the comment button is clicked.

[michael]

Thanks for writing that up!

Regarding 1) With Substance we went for 'semantic' annotations, which means you write first, then you tag certain things (strong, link, etc.). We had requests from other users to use a classic paint-mode for style annotations (turn emphasis on, then start typing). There are some technical difficulties with this but we may add this at some point. However, I think this paint-mode only works well with fixed toolbars. When using an overlay, we don't want to show the tools on a collapsed cursor (that would be too noisy). The current behaviour is consistent with other editors that use overlays (e.g. Medium.com). Tools appear contextually when you select text.

Regarding 2) We can solve that by moving the focus to the comment field. Will work on that.