Medium-editor: Option to always show toolbar

[Pajamaman]

Is there a way to always show the toolbar? Like right above the editor? I've got staticToolbar set to true but it still disappears when the editor loses focus.

One way I found to do this:

var editor = new MediumEditor('.editor', {
    onHideToolbar: function () {
        editor.toolbar.showToolbar();
    }
});

The problem with this is the toolbar doesn't show on page load. I figured out a workaround for this but it seems hacky to me:

editor.elements.forEach(function (el) {
    el.focus();
    el.click();
    el.blur();
});

[nmielnik]

If you're using the staticToolbar option, a possible option is to add your own css and just override the .medium-editor-toolbar class to have visibility: visible. This would prevent the toolbar from ever actually being hidden.

Internally, hiding and showing the toolbar is just adding and removing the .medium-editor-toolbar-active class, which just sets visibility: visible.

This is a simple approach. If we wanted to introduce something like a constantToolbar(?) option, we would likely have to treat it the same as staticToolbar so that it wouldn't move around (or maybe we might still allow for it to move to wherever the cursor is?). Perhaps implementing the option then could be as simple as always adding the .medium-editor-toolbar-active class when the toolbar is created, and if the constantToolbar option is set to true, we just ignore calls to hideToolbar().

Those are some potential solutions.

[litera]

If one needs to always show toolbar at the top I suggest they use some other editor. Plenty of tested and great ones out there that are also much more mature than Medium editor. The main differentiator of Medium editor is the in-place toolbar on selection.

This feature is also not just a styling feature. Currently toolbar only displays when something is being selected. But if we'd see the toolbar at all times, it would also mean that it should work without selections.

[phiggins42]

i think exposing the toolbar and allowing replacement would be a goodthing. I personally am investigating the feasibility of having a [user-selectable] alternate fixed toolbar, but don't want to throw away the investment into specific ME things I've put in (and would have to re-implement in SomeOtherEditor's API). I also want the ability to define buttons that react to the content they are in, eg: disallow b and underline while in heading elements, and access to the toolbar code might get me there faster. another case for allowing "always show toolbar" would be the position:fixed style floating toolbar in margin of content. if it show/hid individual button elements reacting to the carat location and selection it would be a neat UX. being able to un-heading things without selection is a feature request I get often. I understand the goal of ME was to be a Mclone, but providing hooks for people to do things beyond intended scope makes it that much cooler.

[litera]

_I also want the ability to define buttons that react to the content they are in, eg: disallow bold and underline while in heading element and access to the toolbar code might get me there faster_

^^^^ This should be a separate issue that should become a feature This is a superb suggestion!

[nmielnik]

This actually wouldn't be too difficult with our current setup. We start from the root node within a selection and traverse up through its ancestors until we hit the parent contenteditable element. Along the way, we support calling checkState() on every extension/button. This gives those buttons a chance to hide/show themselves based on what's currently in the selection.

Very cool idea, I think this could be extremely valuable depending on the product.

[phiggins42]

yah I have a partially working dynamic button solution (probably should move to new issue to continue discussion) but found some inconsistency in practice about resetting after a selection change, and little nits like "if the last button goes hidden, the mdeium-button-last class is improperly applied/etc) that i hadn't fully worked around. Ideally i'd be able to define toolbar buttons per-block out of the box. eg:

extensions:{ "header2":{ disallow:["bold","italic",underline"] } } 

and be done with it. or something random:

extensions: { header2: { only_buttons:["header1","header2"] }  } }

[phiggins42]

created #527

[Sergiy-Babich]

Also always visible toolbar should fit fair enough to editor element. Now it is positioned absolute and cover previous elements.
That should be good to make some padding in editor element to fit toolbar.

[pjanuario]

I am also needing to have the toolbar visible, in matter of user experience styling is not directly understood by all users and if it's not that difficult to implement, it seems a nice option feature.

[Sergiy-Babich]

Have temporary solution with toolbar static + sticky and position: static + visibility:visible

[pjanuario]

@Sergiy-Babich sticky and static doesn't seems to be working for me. Any tip?

I am using npm module with browserify.

[Sergiy-Babich]

Did you use CSS I mentioned?

[pjanuario]

Thanks @Sergiy-Babich I already was able to make it work.

For future readers:
I also needed to set the elementsContainer property, otherwise would appear on document body.

[nmielnik]

In the spirit of what this editor was intended for (to mimic medium), I'm gonna say this shouldn't be a built-in feature for medium-editor. There are various ways to manually force the toolbar to be visible, and especially now that the toolbar is an overrideable extension, I'm ok with developers needing to find their own way to make the toolbar always be visible for their usage.

[Ondoher]

"There are various ways to manually force the toolbar to be visible, and especially now that the toolbar is an overrideable extension, I'm ok with developers needing to find their own way to make the toolbar always be visible for their usage"

Um, why would you not implement an obvious feature? "because" doesn't seem like a useful answer. This editor is pretty good, but to force a user to manage some clunky replacement for what amounts to a silly philosophical opinion is counter productive.

Make the editor better, who does it hurt?

[nmielnik]

@Ondoher if someone were to open a PR that supports making the toolbar always be visible and the feature works well with the existing code I can't imagine not accepting the code (emphasis on the code quality and sensical integration). However, if others were looking to invest time in improving medium-editor, there are certainly plenty of other enhancements or bugs I would try to urge them to dig into before this specific feature.

but to force a user to manage some clunky replacement for what amounts to a silly philosophical opinion is counter productive.

I'm not sure we're forcing anyone to do anything with this open-source editor we've all helped create, but in the absence of a well-supported, built-in feature for making the toolbar always be visible, we have provided a few workarounds for those who wish to have it in their project.

It may sound clunky to you, but it was a priority of ours to structure the project in such a way that folks could override any part of the editor to work any way they wanted it to. This is why every feature of the editor (including the toolbar) are exposed as completely overrideable extensions. This way, we can be free to have our own opinions on what the core editor functionality should be, but we would in no way be preventing others from making their editor behave any way they saw fit.

I'm guessing it's not obvious when looking at this project, but medium-editor was created by @daviferreira as a WYSIWYG editor to mimic the editor medium has been using. A few of us have decided to use medium-editor at our work, and have pitched in as much as we could to try to make the editor better as each of our individual organizations have used it. There is no full-time team that supports this, and there is no group of folks that are the decision-makers with this. From what I can tell, @j0k3r has been the only guy hanging around to keep the lights on with the project (Thanks a million @j0k3r!) over the past 6 months. Very little (if anything) has ever been rejected with this project, generally if people put in time to add something it's gonna end up making it in.

So, anyone who is thinking about adding this feature or any other feature, please don't think we would reject your work simply because we don't agree with it. We appreciate effort people put in and will do our best to be gracious and accepting of it.