Thanks for asking, thatās very kind of you . This project is built on top of an open-source stack
Find a way to support the maintainers of these projects ( star on Github, donate, write a kind letter ā¦):
Each little feature is accessible via workflows and have individual events that fire immediately. That means that you can create and control your own menu.
Keyboard shortcuts
Both for classical editor and markdown. You can set a paragraph to Heading1 either by typing ā + ā„ + 1 or by adding # at the beginning of a paragraph.
@rico.trevisan back with some more feedback (using version v.1.0.1 )
Issues
input is enabled option:
When check it works as expected;
When uncheck it doesnāt work as expected (input is still possible);
Responsive/layout behavior:
(context of use)
Iām using your plugin in a SPA
The tiptap editor is inserted into a floating group;
This floating group is used to create an edit notes;
Iām under the impression that in order to get inputted content in tiptap element, to scroll in a floating group, you need to enable the option āfit height to contentā even though I have inf max height for the element.
Would you consider this to be expected behavior? Try it out yourself by replicating these steps:
In editor:
Create a floating group with scrollable content (e.g: text). Configure the floating group as you would for a SPA (fullcreen);
Create a second floating group and include the tiptap element. Configure the second floating group as you would for a SPA (fullcreen);
Configure the tiptap element to have no max height. Keep the āfit height to contentā option unchecked;
In preview:
Insert a few paragraphs of text until text passes page fold;
Try to scroll (it wonāt work)
Now, go back to the editor an enable the option āfit height to contentā. Try to scroll again (it will scroll).
This behavior just doesnāt seem super intuitive (at least for me). Curious to know what you and perhaps others think.
I want to test it on a real app. To do that I need to publish a new version which will roll out to all of you. Iāll make sure to tag it as BETA. Try it out and let me know.
Could you show me your app? What do you mean when input is still possible? Can you type? Or are you referring to the actions (bold, italic, etc.)?
On my demo it seems to work properly.
Properlyāish. Typing input is disabled but actions still work. Whatās the right approach / philosophy: who should be responsible to restrict it: the plugin or the Bubble dev?
A small quibble from a UI perspective. The cursor doesnāt change to a finger icon when you hover over a url. Not sure if this is under your control.
For the custom menu, can I highlight text and then click a custom menu button to act upon the highlighted text? Is there any docs on how to do this yet?
If Iām using the current Bubble RTE, is there any migration issues?
Lastly, based on previous discussions weāve had, if I paste in an image, is it stored securely?
Just updated to beta version. From my brief testing, it does seem like auto-binding is working as expected! Iāll continue testing though and will report back
Iāve just realized that your demo actually has two pagesā¦ (index and doc). I completely missed the doc page (default goes to index ).
I see that you check a value and then based on that, the tiptap element is editable or not. I havenāt tried this approach. Iām just using the option shown in the screenshot aboveā¦
In any case, itās not really a deal breaker for me at the moment, as I can just use an html element to display content vs enable/disabling input within tiptap.
Demo
Editor
. This project is built on top of an open-source stack
star on Github, 
donate, write a kind letter 
ā¦):
You will need an account with either:
justify)
BETA Release 1.13.1 - customize H1
)
input is enabled option:
).