Tiptap V3 Roadmap

[nperez0111]

Hello, Tiptap community!

Internally, we are planning out next steps for the next major version of Tiptap v3. We thought that it would be great to involve the community in this planning!

There are some items which we've already decided and made some progress on, while others are only in the ideation phase or need some feedback. I will be posting each feature/idea in a separate thread, so that we can keep the discussion tight to a specific feature as well as to allow voting on particular issues.

So, please upvote an idea if you think that it will be a valuable addition to Tiptap!

---

We've already started to make some progress towards v3 on the next branch if you want to check out some of the upcoming changes like:

• Replace the tippy package with floating-ui: Remove tippy.js and replace with Floating UI #5398

  • We’ve had a number of issues with tippy come up: element removal errors, an awkward API and strange integration into apps. But, no more, we are moving to using @floating-ui/dom which is tippy’s official successor and offers a much more convenient API

• renderHTML JSX: feat(jsx): add @tiptap/jsx for more convenient rendering of Tiptap content #5558

  • With the new JSX functionality, we can now support JSX as the return type from renderHTML resulting in this nice API:

    Node.create({
       renderHTML({ HTMLAttributes }) {
        return <div {...HTMLAttributes}><slot /></div>;
      },
    })

• Optimal Framework Performance by default

  • Tiptap 2.5 significantly improved the performance of the framework integrations, but the React integration was an opt-in change to not break users, no more. The React integration will be modified to have the more performant shouldRerenderOnTransaction API be default false, with an opt-in to the previous in-optimal behavior.

• Static Renderer: feat(static-renderer): add @tiptap/static-renderer to enable static rendering of content #5528

  • This allows rendering of Tiptap content outside of an editor instance, it supports multiple targets, HTML strings, React elements and is flexible enough to render to much more.

• Support for Prosemirror Markviews: feat(core): add support for markviews #5759

  • Prosemirror Markviews allow for flexible rendering of a mark & it’s inner content. Allowing you to attach event handlers to the element for more dynamic mark experiences.

Please vote & discuss your favorites below!

Or, add your own if you've been looking for something yourself!

[nperez0111]

Package versioning strategy (Status: Feedback)

Tiptap major version 2 had all packages bumped at the same time, this was to try to make it clear what versions were compatible with one another, but we are thinking about decoupling versions. We may be moving towards a model where if a change is made to only one package, only that one package has it's version bumped, this should help make it clear what actually changed between versions (rather than getting a package bump because any tiptap package was bumped).

This would mean that packages would be bumped a lot less often (since core is 80% of our changes).

TLDR; Moving from:

@tiptap/react@3.1.2
@tiptap/core@3.1.2
@tipatp/extension-table@3.1.2

To:

@tiptap/react@3.1.0
@tiptap/core@3.4.2
@tipatp/extension-table@3.0.1

[nperez0111]

I originally proposed this change within the team, and also pushed for changesets (which, I admit, we may have introduced prematurely).

To speak from my own perspective on the maintenance side of things, I see two compelling reasons to change the versioning to be independent, I will then go into more detail on what that means for consumers, and how it may actually benefit consumers too.

1. As @bdbch said, it makes it much more difficult to introduce changes when forced to keep stability across the library as a whole.
2. It makes communicating what changed much more difficult, with each version we release, all packages have to be bumped and therefore it is difficult to sort out what actually changed in the library. Which is actually the main point that @rfgamaral was making in our decision to use changesets, it is noisy now, because we bump all versions, if we used it with independent versioning, it would make it easier because there would be 1 unified changelog of all the changes that were actually made to the library since the previous version.

I think what most people are overlooking here, when saying that fixed versioning (current approach) "Makes it clear which packages are compatible", is that if you were to just always take up all of the latest versions of tiptap's packages, it would effectively be the same thing between fixed and independent versioning. Also, this is just false, to know what version is compatible with a package should be strictly by the package's own declared version ranges. If sticking to SemVer, we should not run into a situation where you can install a version which is incompatible with another.

How does it look for the consumer-side?

It would be clearer to know what changed, and why, and dependencies between those changes (when reading the changelog, seeing new updates to packages, etc.).
You'd be surprised to know, that even though we bump all of our packages in tandem right now, I've helped many who update their packages separately leading to subtle incompatibilities like accidentally installing multiple versions of the package.

Conclusion

I don't agree with the current versioning pattern, it either has to be that we remove changesets and find another way to communicate the changes in a fixed versioning pattern, or, my preferred method, actually stick to SemVer and implement independent versions.

[Nantris]

I think what most people are overlooking here, when saying that fixed versioning (current approach) "Makes it clear which packages are compatible", is that if you were to just always take up all of the latest versions of tiptap's packages, it would effectively be the same thing between fixed and independent versioning

What if you have some problem with the latest versions? That's where it all gets sticky. I know package managers are supposed to abstract away this concern, but that's not always the reality.

I don't know. My opinion is unchanged personally, but it's not my decision to make. This change would make me sad, but I understand that maintainers are likely in the best position to weigh these things and reach the right conclusions. I appreciate you both taking so much time to lay out your reasoning.

[nperez0111]

What if you have some problem with the latest versions? That's where it all gets sticky.

Pin your versions to known working combinations. This is the point of lockfiles, and should not be our concern

[Nantris]

Pin your versions to known working combinations.

But this is exactly what my concern is - having to worry about that at all.

---

Tangentially related, some fun I've been having with Emotion lately: emotion-js/emotion#3300

[codefromrvk]

#3650

Please consider this

[nperez0111]

Package grouping (Status: Merged) #5469

We are trying to reduce the number of overall packages we have.

Right now, to have a table in your application you need to depend on @tiptap/extension-table @tiptap/extension-table-cell @tiptap/extension-table-row @tiptap/extension-table-header which, is just too many packages for what a user actually needs (who would need a table but not table cells?).

So, we are going to maintain the existing packages to not break existing apps, but have them all be re-exports on a single package @tiptap/extension-table.

Relatedly, we also want to introduce smaller kits of functionality like for tables, lists, and text styling (bold, italics, underlining, etc.).

[rfgamaral]

Sounds good. I never used the table extensions, but the issue seems similar to extension-list-item. This package alone serves no purpose, so it makes sense to group related packages that need one another to fully function.

[Ragnar-Oock]

maybe keep the @tiptap/extension-table as is and only use a @tiptap/kit-table to avoid confusion between extensions and groups of them that one might want to (or need to in the case of tables) use together.

[nperez0111]

I sort of disagree about making the table kit have to be it's own package. The idea should be that everything related to tables would be available within the one package. After all, the goal of this is to bring together all of the functionality into one extension.

The way I've implemented this in #5469 is that all of the table extension (rows, cells and headers) are now within the single @tiptap/extension-table package. To not break the previous packages, the V3 versions of the @tiptap/extension-table-cell for example, will just be a re-export of the TableCell from @tiptap/extension-table.

For TableKit, I've made it a new export of @tiptap/extension-table. So to get all of the table functionality all you need to do is:

import { TableKit } from '@tiptap/extension-table';

[nperez0111]

Drop UMD support (Status: Merged) #5455

We’ve moved build systems for a much faster development experience, unfortunately, this means that we will be forced to drop UMD builds of our packages since it is not supported by our build tool (tsup). UMD is a very old format so this should not be a concern for most consumers

[nperez0111]

Starter-Kit (Status: Merged) #5466

We want to make it easier to manage multiple sets of extensions, and give a better out of the box experience with Tiptap. Historically, we had the @tiptap/starter-kit package which made it easy to get started with your editor, but, we want to add even more functionality into the main starter-kit. Like, links, underlining and the list keymap extension.

[nperez0111]

Package manager (Status: Merged) #5978

NPM used to be a good package manager, but it has been left behind in terms of speed and functionality, we will migrate off of it internally, but this should have no effect on package consumers. Currently we are deciding between pnpm & bun, with a slight preference towards pnpm for it's ability to publish packages

We've decided to go with PNPM, for stability, speed & feature-set

[bcorcoran]

+1 pnpm

[gethari]

+1 pnpm

[Ragnar-Oock]

Whatever you decide on make sure to configure corepack correctly so anyone that might want to contribute for the first time don't need to waste time setting up the package manager used on the repo if they don't have it already.

[somonek]

+1 for pnpm . bun is fast, but it's messing things up in large monorepos

[Nantris]

As someone using Yarn - I would opt for pnpm if I were to start over or find mythical excess time for nice-to-haves. Please not bun! The whole bun ecosystem just still isn't ready from what I've seen.

[nperez0111]

Decorations API (Status: Decided) WIP: #5437

Tiptap users have drop down into Prosemirror plugins, whenever they wanted to leverage Prosemirror decorations, now we are experimenting with an API that will make Decorations easy. Feel free to comment on our PR here: #5437

We aren't entirely sure at the moment what this API will look like, but in Tiptap fashion we hope that it is flexible enough to handle all of your decoration needs!

[rfgamaral]

This is only meant for decorations, right? In other words, we'll still need to drop down into ProseMirror plugins for more complex things, right?

[nperez0111]

Markdown extension (Status: Idea)

We’ve heard you, we want to build a solution to have the editor both accept & output content as markdown, in the age of LLMs which are quite good at outputting markdown, it is a must! Of course, this will be a tradeoff since markdown is an ill-defined format, but we understand the need for it.

Our idea is to offer a first-party extension which will add support for inputting & outputting markdown. To keep bundle sizes lean, we would not want to force this on users who do not need such an extension. We are still working on the details of what this would mean so please leave your ideas below!

[rfgamaral]

How do you intend to make this work with custom extensions for things that Markdown have no support for? For instance, mentions? Will you provide means for consumers to define the output Markdown for each extension, especially custom ones? How about pasting a full Markdown document, did you consider that? You'd need every single extension to provide an input/paste rule, and some of them currently don't (i.e. links). These are all things that we had to figure out in Typist (which has Markdown support).

From my experience on adding Markdown support to Typist, this will be quite the endeavour to get done right, in a way that works for everyone, and is customizable (some people might have strict requirements in the Markdown output, I know we do). Regardless, built-in support sounds amazing if done right. For instance, some ideas:

• Every extension should have input and paste rules to handle Markdown
• Every extension will probably need a renderMarkdown and parseMarkdown methods
  • Defaults can be provided, but users should be allowed to customize
• It should be possible to tweak/extend Markdown support for custom requirements

This is just from the top of my head.

---

Although I see this as a great idea, and something that a lot of people would love to have, I'm also thinking of the amount of work involved to get it done right (unless you forgo customizability). And in that sense, I wonder if your efforts aren't best applied to make the core Tiptap editor better in all fronts.

[nperez0111]

@rfgamaral Exactly the sort of pushback I wanted to see.

You are right on all fronts, and you are right to point out that this is a big challenge to overcome.

From my current understanding here is how I'd approach this:

• You are right, "Every extension should have input and paste rules to handle Markdown", doable and nice to have in any case
• Extensions should be able to define renderMarkdown with a fallback to plain html (from the already required renderHTML)
• I would not have parseMarkdown be the responsibility of each extension, since that would require shipping a markdown parser for everyone that uses that extension, and you'd have the possibility of multiple extensions matching markdown content. I'd instead leave markdown parsing and mapping to be the responsibility of a new separate markdown extension
• Tweaking output markdown should just be Node.extend({ renderMarkdown: (node)=> `>${node.children}` }), Tweaking the parsing of markdown will depend on how we do that mapping.

To ease your concern around the amount of work to do this, it definitely would be a lower priority project.

[rfgamaral]

Looking forward to seeing how this evolves. Also, since I've spent quite some time around adding Markdown support to Tiptap/Typist, feel free to tag me in future public discussions about this topic. I'm happy to brainstorm with you folks.

[StephanMeijer]

Inspiration can be drawn from ProseMirror.

[Ecaratti]

There's also a tiptap-markdown extension out there, may be worth checking out their implementation for inspiration.

[nperez0111]

Better TypeScript typings (Status: continuous improvement)

To improve the typing of the project overall, we need to completely refactor the typings we have right now, this would allow typing of things like attributes, HTMLAttributes, the editor storage API and so on…

Doing this in a major version is a natural place to make this sort of a change as it may affect how you type your projects. Give your ideas of what you would like to be better typed below!

[Ragnar-Oock]

Whatever comes out of this, a blog post (or something like it) to explain how the implementation works. I find the current implementation of the commands really pleasant to use as a client of the lib so I wanted to replicate it in one of my project but I have a hard time understanding how it works under the hood. so having a something that explain the dark magic at work would be nice.

[zrosenbauer]

I really liked this https://github.com/octokit/webhooks as they use JSONSchema to generate types, aka I can use the JSONSchema to do real-time validation if needed... just a thought.

[zrosenbauer]

Doing this in a major version is a natural place to make this sort of a change as it may affect how you type your projects.

I'm stressing out just thinking about this 😅

Last time the typings changed for things like these, it was a pain to fix them on our side. But I guess this is part of the job, I'm in no way suggestion to keep the TypeScript typings as-is. If they can be better, let's make them better 💪

Couldn't you make this almost 100% opt-in by creating a package that you import import {} from '@tiptap/types-rock'; and it just overrides with module augmentation/declaration merging.

Here is an example from MUI:

• https://www.typescriptlang.org/docs/handbook/declaration-merging.html
• https://github.com/mui/material-ui/blob/master/packages/mui-material/src/themeCssVarsAugmentation/index.d.ts

It would just take some fancy TypeScript footwork but def doable IMO...

or just major version it and codemod 😆

[Ragnar-Oock]

Because we're talking about a major version here I think it would be better to make the optional type package a compatibility package you can install while you transition from v2 to v3. That way new v3 only projects don't need it and projects that update from 2 to 3 can use it to ease the pain a bit.
It does have the downside of not allowing to use said type package on a v2 project but I'm not sure if that's really needed (or possible)

[nperez0111]

So far, the type changes that I've made should be mostly backwards-compatible. So, I don't think we need to over think this with an extra package or even a codemod.

Storage is now typed, and Node, Mark and Extension configs are more strictly typed. #6060

[nperez0111]

Trailing Node Extension (Status: Merged) WIP: #5970

This extension automatically adds an additional empty node at the end of your document to allow the user to easily continue writing content. This resolves an issue, where if a table is the last node within your document it can be tricky to get the selection after it.

This extension has been in our Tiptap "experiments" for several years now, we want to upgrade it to be a fully-fledged extension we will support and maintain. See it's demo here: https://embed.tiptap.dev/preview/experiments/trailingnode/

[rfgamaral]

I find it weird that this is an extension, why isn't built-in core behaviour? Also, am I only hearing about this extension now? 😅

where if a table is the last node within your document it can be tricky to get the selection after it.

What other scenarios, besides tables, could this extension fix? I'm asking because although I haven't really felt the need for such extension, maybe that's because I know how the editor works, and I can always work around small issues like these, but our users probably can't (which could generate more support tickets). So I'm wondering what other nodes could this help with?

[nperez0111]

It isn't core behavior because we want the editor core lean and predictable. This would be installed to the editor and is based on this experiment: https://embed.tiptap.dev/preview/experiments/trailingnode/

This is more of a workaround than anything, but it would also help with things like an image just being pasted in as the last piece of content and now the user cannot just focus past it to continue writing.

For example, in this demo, you can't just click after this image to keep writing, you have to get your cursor into the editor then arrow toward the end just to type after it: https://tiptap.dev/docs/examples/basics/images

[svenadlung]

I think this could be part of Tiptaps StarterKit, as it is the default in most editors and people are used to it.

[rfgamaral]

For example, in this demo, you can't just click after this image to keep writing, you have to get your cursor into the editor then arrow toward the end just to type after it: https://tiptap.dev/docs/examples/basics/images

I think I've been working around with the gapcursor extension, but this feels like a better approach. How stable is this experiment? I might introduce it in our editor. If I do, do you think the gapcursor extension is still required?

[svenadlung]

Definitely still necessary. E.g. between 2 images. The new extension is only for the last node in the document. I have an updated version of the experiment. I can create a PR for it soon.

+ it behaves a bit different. It adds the default node (paragraph) to the end of the doc instead having a virtual "cursor".

[nperez0111]

SuggestionMenu Extension (Status: Idea)

Implementing something like a slash-command is very difficult to do, and even more difficult if you use a framework like React or Vue to render the UI within the menu. We want to make it easy with a first-class component for each of the frameworks like we provide with BubbleMenu & FloatingMenu.

[Chaddeus]

Definitely. I've sort of built my own /command implementation, but a "native" one would be ideal.

[rfgamaral]

Implementing something like a slash-command is very difficult to do

Maybe I'm not seeing the whole picture, but what's so difficult about it compared to the mention extension, or even the bubble and floating menus? What am I missing?

[nperez0111]

The bubble menu and floating menu are easy because they have React and Vue bindings.

Mention & Suggestion would be improved in a similar way. Instead of having to manage the popover state & and mounting/unmounting the React or Vue components yourself, you'd just use a React component and render your UI.

[rfgamaral]

I see, thanks for clarifying.

[mattkrick]

radix-ui (or radix-view for vue) has been a joy to work with wrt a11y, focus management, managing portal children (i.e. hitting escape only closes the top-most portal). I've been using that wherever I can. I see you've used in the block-editor example too!

I wouldn't be mad if tiptap took a strong opinion & made it a dependency. With a refactored render() function in the suggestion util you could even get rid of tippy/floating-ui in favor of a more expressive API.

[nperez0111]

Indentation Extension (Status: Idea)

We’ve heard your feedback, it is strange that you hit tab and the content does not just indent properly. This would be an extension that allows you to indent content as you'd expect.

For example, with Google Docs you can indent a paragraph node several levels:

[Ecaratti]

I should have a bit of time to get around to it this week/weekend, I'll get back to you on that one, maybe in discord @nperez0111 (NickTheSlick)

When you say a number of things, is one of them multi-level lists?
I hope we'll get the chance to discuss them further in the future, but if you're considering it, here is the rabbit hole I got myself into:

I've gotten pretty far with multi-level lists, but there are still things I need to crack...
Here are some considerations:

• You cannot use the default list extension for multi-level lists, as the numbering, to format properly (in cases of hanging where the number is too long or in case of first line indentation where a marker would not be part of the indent), needs to be done by an additional node (or can you, maybe using inline node on the ::before element would solve that... 🤔 )
• In my case I created a counterNode that saves as attribute its level, its computed label, a numbering config unique id, and whether it's followed by a space, a tab or nothing (like word, which infuences the entire formatting of the numberd paragraph/heading)
• Using a counterNode makes it easier and more efficient to update numbering by creating a plugin that uses appendTransaction and checks for any removal/additions of counterNodes. I've tried using NumberedPragraphs, but that would cause the transaction to be appended on each keystroke in the numberedParagraph, so no bueno.
• Using counterNodes with content also allows for formatting of the counterNode
• Using counterNodes without using the css counter also allows for cross references (ex: referencing paragraph X.Y)

Numbering can also be formatted in a lot of ways, (A. a), I, i, 1, ...) and multi level numbering can be separated by points, spaces, parentheses, etc, so allowing multi-level numbering, means having to store a config object for each list at each level.

• This can be saved in an extension's storage, BUT, in collaboration there is an issue when a user A creates a list config, and another user B updates a counterNode but this other user B's client doesn't have the config, so it cannot use the config object to update the counters. So my solution was to save list configs both in storage and sync them in a YMap attached to the document.
• There is a lot of ui involved in making multi-level lists work, ex: choosing the format (decimal upper, lower roman, etc.), then there is the configuration of how exactly is each level is going to display its parent (let's take an example, say at level 3 we want to display all levels separated by a point and finishing by a point such as 1.1.1.,

Just note, with multi-level lists, that I did have to ditch tiptap's list element for the following elements:

• Multi level lists make it a lot harder to keep track of where the
  behave
  1. Using ::before markers and css counters was not a viable option, for the following reasons:
     -::before makes using first line formatting inconsistent, I needed the numbering to be part of the paragraph's content, this is also important when a paragraph is hanging but the number is so close to the paragraph's content that it should indent the paragraph's text
     For example, in my case the user can write %1.%2.%3. in the ui to modify the list's config, each %X will be replaced by the parent at level X, or itself if X is equal to the current level.

There are soooo many things to take into account, it's honestly one of the hardest things I had to code in a long time, I can't pretend I have all the answers, but hopefully now you have a better idea of what that entails.

Got carried away haha, hope that was helpful, and I'll get back to you regarding formatting ;)

[nperez0111]

I've not really thought too much about multi-level lists. But, I guess I can share how I'd approach it:

I'd probably just have attributes on list nodes (bulletList and orderedList) that specifies the "style" which could be any of any enum of strings and a separator property.

type AdditionalListAttrs = {
  style: "lower" | "upper" | "roman";
  separator: "period" | "paren";
}

For orderedLists, the list can be started at any number, so they'd use the start option to indicate where the list should begin from.

For maximum control over the list markers, I'd probably render them as decoration nodes before the list item contents. You could even have things like selections and menus be managed from within the item marker. Since it is a decoration, it would be able to have information on the document to know its placement within the document to not have to store things like level within the count (which would save us from trying to keep that in sync somehow).

But, IDK you clearly have implemented something, so I wonder how that scales out for you, it does feel awfully complicated though.

[Ecaratti]

Actually I hadn't considered decoration nodes, I should brush up on them...
Here, @nperez0111, I had a bit of free time today for a formatting example. repo is public and MIT so go nuts, also deployed a demo for you to try out.
Tbh I didn't feel like figuring out how to make it work with listItems and pseudo elements (as mentionned I used counterNodes, at it was already a pain to set up...)
Happy to give more insights in private if you want
Cheers

[Ecaratti]

To come back to numbering and scaling,

one of the biggest concern I had was, since numbering is computed through js and is pretty complex (as explained above), was how to trigger the recomputation of numbering at the right time. The biggest advantage of counterNodes is that it's super easy to recompute the numbers exactly when you need to (i.e. when a counterNode is added or removed, just check the changed ranges to see if they include a counterNode, it's super efficient), having them with content also allows for easy formatting of the counterNodes, and backSpacing to remove the counter is default behaviour (although it's not hard to do with pm).

I'm really not sure what would be the condition to recompute counters using decorations...

1. I could go through transaction steps to check whether a listItem node has been added or removed (although having tried that, a lot of edge cases appear, especially with collab, thus making it a challenge to implement right)
2. I could return the oldState and newStare doc's descendants that are listItems, and compare sizes, but going through the entire document at each keystroke feels incredibly inefficient,

In addition to that, using decorations, I'd need to to somehow make it so that the decorations are updated on all clients (I'm using collab); which is not super straightforward, while a counterNode is part of the document so it's a non-issue.

Overall I found having a counterNode makes it a lot more straightforward to update the doc's numbering at the right time. Especially with large documents, that's crutial for me.

And to top it all off, I need headings to be numbered as well, so I'm not sure how well that plays with listItems (I feel like we're going into "bad html semanthics" theritory here". My current implementation of counterNodes is on custom headings and paragraphs, not listItems (I may just keep them for non-multi level lists). I know, not great accessibility-wise, I may create custom numberedParagraph's that return a li item (but then, having the right li in the right ol is another challenge, what if the user wants to continue a list but the selection is out of the ol? Looking at wordOnline, they use li without ol at all. Super odd, not great, but I'm guessing they faced a similar issue and that's what they came up with, also looking at word online their headings are actually just paragraphs with a custom stlye and attributes, so li could work if I ditch headings (also, not great for accessibility...)).

But hey, I'm not pretending to have the nicest implementation, counterNodes definetly have their drawbacks as much as decorations have theirs. I may even change it in the future if it turns out my reasoning was wrong, in any case, hope this makes sense, and maybe someone looking into multi level lists will read this and gain something from it haha,

In any case, thanks for sharing your point of view on the matter :)

Multi level lists are a mess...

[kalda341]

I've also implemented my own lists to get around multi-level lists. We've done it with attributes on the paragraph node, (styling, indent, continue) and an attribute for the computed marker value, which is updated in a Prosemirror plugin with appendTransaction.
"data-list-marker" is set on the paragraph DOM node, and then rendered with CSS.
It's much simpler than built in nested lists, and works pretty well for our use case.

[nperez0111]

Content Migrations (Status: Idea)

This would introduce the ability to re-write Tiptap JSON from a previous incompatible version, to the latest version your editor supports. This would allow gradual migration of content as it is edited by others.

Something like: https://github.com/remirror/prosemirror-migration may be interesting to look at.

[afomera]

YES please, please provide an upgrade path that doesn't require migrating content ourselves in one big go 🙏 it makes it hard to do so when you're storing millions of JSON blobs from rich content.

this has been a pain point for me, as well trying to figure out how to migrate/modify existing content once an extension is rolled out but then you need to make changes, so I like the idea of migrations like the example posted.

[WilliamIPark]

This would be a big one for us at Niice. It's thankfully something we've avoided needing for the most part, but not having it is pretty scary for us.

[StephanMeijer]

Big one, specifically also if we can migrate our custom nodes and attributes.

[dbousamra]

Is there any room for any more Ideas? In particular, I'd love to see page (i.e. automatically breaking, and ability to render as a page) somehow integrated. I know it's a super difficult problem, but for certain use cases it's crucial

[nperez0111]

so I can't even imagine trying to create and maintain the feature for multiple frameworks.

Yea, this would be hell, which is part of the reason we have not approached it. On top of the fact that it would be very difficult to do in even 1 framework.

I fear their implementation is not super performant, as I believe their plugin needs to recompute the content of each page after each document transformation

Yea, it has to re-compute where the page breaks are on every change to the doc, it definitely will not scale beyond tens of pages.

Looking at the implementation of word online

They are using canvas, so this is not a fair comparison at all. We have all of the mess of contenteditable to deal with

preventing a heading from being at the bottom of the page

Widows & Orphans sounds like hell to maintain.

it's a lot to take into account, but would definetly elevate TipTap to a new level.

It would be a huge undertaking, Google Docs started as contenteditable & gave up on it. We do not have nearly the number of people working on this project (~3 of us & not even full-time, we have our paid offerrings). So, this likely would not be open source if we made it, just by sheer number of hours it'd take

[Ecaratti]

Makes perfect sense, I should read up on the contentEditable hell haha, thanks for taking the time to answer though, but yeah, I'm with you on that one, for it to be done and done properly would definetly be a mostreous undertaking and open sourcing it doesn't make much commercial sense for you in any way :)

[dan-cooke]

@nperez0111 I just wanted to point out that Word Online is not using canvas

so its definetly possible without

You are potentially thinking of Google docs, which migrated to canvas a while back for their editor. But Word online is still 100% HTML.

[nperez0111]

Well, I stand corrected. But, I think it still completely out of reach. I think we are a bit smaller than Microsoft

[hugs7]

Hey @nperez0111 , it's not perfect but I'm working on this and have most of the bugs ironed out. Let me know what you think - I posted here.
To be clear, I am aware this isn't perfect so I'm not expecting this to become an internal ext.

[Nantris]

@GreedyWhale wondering what issues you're seeing and with what language?

[GreedyWhale]

@Nantris @nperez0111 Yes, I've encountered a lot of problems on iOS, I'm using Chinese, and the most obvious problem is the loss of styling, such as font color, bolding, and other information, check out these issues:

#4726
#5733
#4572

In addition to this I'm also having problems with inaccurate cursor positioning, which moves automatically when the browser window changes, for example:

6a0ae88355cd23af7b618ba77a9583b1.mp4

I really hope you guys can fix these problems, but of course it doesn't matter if you can't, I still think this editor is a great product.

[nperez0111]

Thank you for bringing this up. Obviously, we have a ton of open issues. We'd appreciate any help that anyone give for this. Most of the issues we see with languages like Chinese are issues around the view.composing, composition is a very complex topic. But it seems to me like these should be fixable

[GreedyWhale]

I really want to try to fix it, but I don't know how to get started because I don't understand rich text implementation, and I would like to ask if I want to get started in this area, is it a good idea to start with proseMirror's source code? Thank you! @nperez0111

[nperez0111]

Obviously, the answer to that question is that "it depends" on where the issue ends up being. Ideally, you would have enough JS knowledge that it should really just be:

• running Tiptap locally
• reproducing the issue
• adding console logs to places to identify the cause (good places would be to log each transaction, which are the unit of change within the editor)
• come up with a plan for a fix
• implement fix

I don't think that rich text is anything special that needs to be treated differently than any other JS programming, though it certainly has more quirks and workarounds

[nperez0111]

I think that what you are describing is more in-line with our paid offerings, like, the content AI extension: https://tiptap.dev/docs/content-ai/getting-started/overview

[nperez0111]

Excalidraw as a node (Status: Idea)

Excalidraw is an embeddable virtual whiteboard, distributed as a React component. It'd be great to embed this within a Tiptap document a custom node to allow the user to draw up their ideas right within the text editor.

They represent their content as a large JSON blob, so using the Tiptap Cloud or stored directly in your editor, we can store this as being associated to your editor content.

[chrisdeeming]

There's not a lot here to dislike! Hugely support everything you guys are working towards. Thanks for sharing the roadmap @nperez0111

What is the current thinking/status of integrating Pro extensions to be core/open source extensions?

Pro extensions being privately published and closed source used to make a lot of sense. After all, Pro extensions could only be used by customers who were paying.

Now the Pro extensions are available to all customers, subject to creating an account (even a free account) so it no longer seems logical to treat Pro extensions differently.

Open sourcing them would reduce confusion and it would allow the wider customer base to contribute fixes and new functionality in the same way they might contribute to the current core extensions.

It would be somewhat reasonable to keep the concept of "Pro extensions" for things that do actually need a paid plan, such as collaboration and AI extensions.

I think the team have previously commented that this might be something you'd be looking to do in the future, and therefore I was surprised to not see it in this list. What is the current thinking surrounding the Pro extensions?

[nperez0111]

Now the Pro extensions are available to all customers, subject to creating an account (even a free account) so it no longer seems logical to treat Pro extensions differently.

The Tiptap Pro license only allows free usage by single developers, as well as other restrictions, so this is not technically true.

Open sourcing them would reduce confusion and it would allow the wider customer base to contribute fixes and new functionality in the same way they might contribute to the current core extensions.

We've thought about open sourcing a couple of them, but do not intend to open source all of them.

We have more thoughts on this, but it is dependent on some upcoming changes to our pricing model that we have not released publicly so I cannot speak to it here.

[Nantris]

I hadn't realized the Pro extensions were available for use for solo developers. I poked around looking for the other restrictions you mentioned but couldn't readily find them. Could you point me to a link or briefly outline them @nperez0111?

<3 TipTap

[nperez0111]

Pro extensions are all licensed under the Pro License: https://tiptap.dev/pro-license

I am not a lawyer, but it even has an examples section which should make it clear whether you are abiding by the license

[Nantris]

Thanks, and sorry! Not sure how I overlooked that link.

[rfgamaral]

I have one suggestion: Rewrite from scratch the Suggestion utility. The current one is hard to reason with, and has a few crucial bugs (there are issues around for these). The new one should be "bug free", and with all the features with the current one.

[nperez0111]

I agree with this whole heartedly, suggestions is definitely a bug bear right now

[einarpersson]

I just want to say that whatever you do, don't mess up Svelte compatibility! (from a happy user of https://github.com/sibiraj-s/svelte-tiptap)

[aoleksyshyn-spscommerce]

I'd love to see resizable images with possibility to align them (left, center, right, wrap image with content).

[timheerwagen]

The ability to display the image with a caption inside a figure would also be nice. The same behavior for videos.

[nperez0111]

Putting aligning aside, since I can see that being something semantic.

How do you implement something like this in a headless way? We don't have anything else like this.

[Nantris]

I think it would just be nice if images readily stored their dimensions as attributes to avoid content shifts even without resizability. This is already on our internal wishlist, so I figured I'd share it here.

[nperez0111]

image dimensions or aspect ratio would be something I'd take a PR for!

[nperez0111]

Asked for here: #5793 (comment)

[hallgurdBakr]

Over 500 million individuals write in RTL languages; I'm not sure why it isn't supported in Tiptap yet!
I hope to see this in version three, and I recommend it.

[nperez0111]

Could you maybe speak to why dir="auto" on your root HTML element is not sufficient enough?

I'm not sure that tiptap is specifically incompatible with RTL, Prosemirror (our base library) should be RTL compatible.

[exorex]

@nperez0111 ProseMirror supports RTL in most cases (around 90%), but some extensions, like the table extension, have limited RTL support—especially for features like dragging (resizing) table cells, rows. Additionally, in RTL mode, when clicking on a table cell or row, the bubble menu opens and positions itself at the location of the clicked table row or cell. This behavior happens only in RTL mode. The correct behavior should be for the bubble menu to open and position itself relative to the table node as a whole.

[nperez0111]

Interesting, could you share some screenshots / recordings so that I can better understand the needs here?

[hallgurdBakr]

by RTL support do you think about fully RTL document or mixed RTL and LTR ? 'cause I feel like the former is much easier to implement than the latter (I might be wrong tho)

Writing a document that combines both RTL and LTR languages is critically necessary.

[hallgurdBakr]

@nperez0111
Adding dir="auto" to the root of an HTML element is not always a good idea.
If see the example below:

<!DOCTYPE html>
<html>
  <body dir="auto">
    <!-- Kurdish Language(RTL) input -->
    <input type="text" value="سڵاو" />
  </body>
</html>

You can try it, the output won't display correctly.

I think the best practice is to provide a button to change the direction of each element by adding dir="rtl|ltr" to each element. like Tiny WYSIWYG editor.

[akirarika]

I'm curious if the v3 version has a tentative completion date? I want to use it in my project, but I'm concerned that the v3 version is not backward compatible, especially with the extension section (I may need to write many extensions)

[nperez0111]

It is hard to commit to any sort of completion date, but we have been publishing next versions along the way that should allow you to try the pre-releases along the way.

So far, I would say that there mostly have not been breaking changes, more just better defaults for things. Even with the package re-organization, things are backwards-compatible. If you want to see how to use the project while we have not yet updated the documentation, you can see all of the examples in the demo folder.

[ImSingee]

One suggestion: I expect the "drag handle" can be used inside nodes

For now, only the top level for the whole block can be dragged:

But I believe the notion style is better:

[exorex]

Great idea 👍

[ImSingee]

And yes, there're already thrid-party solutions like https://github.com/NiclasDev63/tiptap-extension-global-drag-handle

But third-party cannot work well for everything, especially custom nodes. Since there's already a native indent support planned, I believe provide first-party support for this is best.

[ArihantBapna]

Hi there, any updates on when this will be released?

[nperez0111]

Feel free to use the @next versions. I feel like this is solid already, but we need to update our docs & other major version related things. I don't think we are planning on adding anything else (esp. breaking changes).

Preliminary docs are here, with a migration guide ueberdosis/tiptap-docs#95

[vilius]

TipTap feature idea for V3

An ability to render a React component inside Decoration.widget. React (and co) node views are awesome, while decorations truly feel like a missing piece.

[Nantris]

You can already do this - it's just a pain.

[bdbch]

We're looking into this in combination with the new decoration API

[shiz-ceo]

Marquee Selection Extension Idea for V3

This is a great idea that improves the user experience when working with block selections. It should also work well with drag handle nodes.

I found a post about it on the prosemirror forum.

https://discuss.prosemirror.net/t/help-marquee-selection-selecting-multiple-nodes-for-dragging/2569/10