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!

See our latest announcement here: https://tiptap.dev/tiptap-editor-v3

[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';

[volarname]

we are using custom config for table node. i hope cistomization only for one node will be still possible

[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!

[Ecaratti]

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

[Haoxincode]

Will this idea be implemented in V3 version?

[Nantris]

Personally I feel there are enough tools for converting HTML to markdown and this would be taking resources from other more valuable endeavors.

[wirtzdan]

👍

[productdevbook]

Is there a version of markdown we can test now? For v3

[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:

[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.

[SawkaDev]

Any update on this request? is this planned for v3 or still an idea?

[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

[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

[WilliamIPark]

This is something we had to build ourselves on top of Tiptap, but didn't really ever get it perfect. It'd be great to see this officially supported, as it did require us to build out a new type of "selection" to select multiple ranges, and I think you guys could do a much better job at doing this and supporting it. Sorry, this was only needed as we had to support "shift" to marquee select multiple areas, I had misremembered.

[Nantris]

Multiple ranges doesn't quite sound the same as marquee selection. Am I misunderstanding?

[WilliamIPark]

@Nantris You're right, sorry! This was a while ago and I misremembered. The complexity that required multiple ranges was the ability to hold shift to marquee select multiple parts of the document.

I still think official support for marquee selection would be a great addition, however.

[mustafa-yilmaz]

Reorderable rows and columns in tables (as also requested at #6149) similar to how they work on other platforms (as also shown in the GIF image below).

[Ragnar-Oock]

While this would be nice to have I think it strays a bit too far from the intent of Tiptap of providing a framework to build an editor without being partial on the UX or UI aspect. You can't really implement this feature without making compromises on how it should be working or on how it should look like. That would make the feature harder to integrate into design systems using different assomptions than the one made for the feature's implementation
For example :

• should the rows/cols be shown as floating elements while dragged or should they snap to the table?
• should the drag interaction only work on a dedicated handle on the side? Which side?
• Or should you be able to drag via selection?
• what should the DOM look like (influences how much the markup can be customized with CSS)

[mustafa-yilmaz]

Thanks very much for the detailed, informative response.

[pprg1996]

A first party extension for columns would be great. There are extensions made by the community like @tiptap-extend/columns but I feel this is important enough for it to be included in your repertoire

[Nantris]

I feel like columns are functionally very similar to tables. Are there reasons tables can't be adapted to act like columns? I suspect there are, but what are they?

[pprg1996]

I guess you're right. This is nothing an unstyled column couldn't achieve. I can't come up with a reason other than "It feels wrong" but that's entirely subjective.

[pprg1996]

Maybe the reason it feels wrong to me is because in HTML/CSS we have separate multi-column functionality via of Flexbox and Grid and my brain just sees Tables for layout as taboo because of that.

[Ragnar-Oock]

Depending on how those columns are implemented (if it's a table or a flex box or if it uses the native css columns) it can have an impact on the accessibility of the content created by the editor. Tables should only ever be used for tabular data (data that has multiple instances of the same structure defined by multiple rows of the same columns) while columns are just text formating that isn't even picked up by most accessibility software (think keyboard navigation or screen readers).
The reader mode of your browser or a screen reader will format/announce a table as such with the column headers and the rows (or the other way around if the th are on each row). But neither will care about css columns because it's just formating like text justification or line spacing.

Having a way to control column width or the number of columns (depending on the needs) could be interesting for content edition I suppose. Though if the end user don't need to change the column's width I don't see why you couldn't just set the css on the editor container to create those columns. From what I remember of who Prosemirror (the underlying WYSIWYG editor under tiptap) resolves selection/cursor position, it should have no impact on the usability of the editor. (Unless you have custom Nodes or Marks that do unconventional things with the width property (tables or images for example might lead to issues)

[Nantris]

Very good points.

I feel like this might not need to be a top priority if the existing extension is able to work as is, but not knowing the Tiptap 3 API, who knows. Also, that extension doesn't have a license file, so there's that.

[Haraldson]

Very happy to finally get rid of Tippy, but I can't help but feel the timing for introducing another opinionated popover library is a bit off, as the native browser solutions are maturing and being adopted en masse.

Web apps using or moving to Tiptap are also likely to already have an existing popover solution, so having to either change because one piece of the app is opinionated, or roll with two side-by-side, is less than optimal.

Are there any plans to make Floating UI an optional dependency, and to make it possible to integrate our own popover solutions?

[bdbch]

I already thought about it - first decision to replace Tippy was not to get rid of a dependency but avoiding Tippy's old API and complexity that was often causing DOM errors when for example reactive children where unmounting that were alread rendering a Tippy element (The Floating UI in the end is almost only the computePosition function).

My idea for the future would be to just provide a computePosition option for menus and other popover elements where users can plug in their own calculations giving the DOMRect's of the target and source element.

[Nantris]

I don't think browser APIs can do anything remotely close to what floating-ui can do? I guess they might cover the most basic use cases, but rich text editing rarely falls into that category. In the meantime you can always implement your own floating-related extensions and, if you use webpack, set floating-ui dependencies to not resolve. Not ideal, but I don't think there should be a rush to replace floating-ui since every change has an opportunity cost.

[Nantris]

Enabling clicking (or tapping on mobile) to select an entire table cell would be nice, and click/tap and drag to multiselect would be great too.

Lexical attempts at least the first request on mobile, but it's not quite right.

This would enable more Excel-like behavior and clicking again would create a TextSelection as I envision it.

[Ragnar-Oock]

Excel like software behave very differently from a text editor. To have tried to implement such behaviors with the table extension (through a heavily customized version) it's not the way to go. Prosemirror (and thus Tiptap) have an inherently 1 dimensional representation of the document (because they output html or json which have themselves a single spacial dimension). This makes implementing excel like behaviors painful and flaky.

I might be extrapolating a lot from what you originally talked about, but all that is to say, I don't think that this is something tiptap should natively implement, it's best kept as an external extension.

[Nantris]

Nothing you've said is false, but nothing you've said is any actual impediment to implementation either. If it was, then the current table extension would also be at issue.

It's not the output of the editor that's the issue, but the selection logic that presents difficulty. But it certainly possible to imagine a reasonable implementation, and indeed other editors do sometimes handle it as I outlined. Of course the implementation details would differ in ProseMirror, but not in any fundamentally crazy way.

[Nantris]

It would be great to be able to use chain-like logic inside of input rules, paste rules, transformPasted, etc. I have to admit I'm not sure how that would work, if it even could.

TipTap makes ProseMirror so much easier to wrangle with chained commands, but unless you extract the logic from the commands into helpers that effectively do the same thing, their logic isn't reusable in other key areas.

[bdbch]

Nice idea! I'll put that on my list.

[CorruptionTiger]

tiptap has been doing a lot of work on how to edit content elegantly and efficiently, but has neglected the “uneditable”. For example: when the user is editing a template file, the template part should not be edited (title, notes, etc.), and would like to add this attribute: uneditable, when true, the marked node can not be edited or deleted.

[CorruptionTiger]

@bdbch Thinking about this the other way around, non-editable or non-deletable also means read-only. So if the whole document has read-only mode, then is it possible to make an individual node read-only as well?

[CorruptionTiger]

I noticed that google docs (excel) has a feature in the shared edit mode that restricts the scope of editing and allows you to choose who has permission to edit the selection, which is what I'm getting at

[bdbch]

There's a difference between deactivating the whole document or just a part of a document.

Deactivating the editing of a specific region/node is not a problem. You can also set a node to contenteditable="false" and disable transactions editing it - however it gets more complicated when you have to handle edits around said disabled section as you could for example wrap/unwrap nodes around it, delete the whole document, etc.

We don't have an API for that yet and since right now it's very user specific I think it's best if developers handle those usecases themselves.

[bdbch]

As said, if you don't want a user to edit a specific node, make it non-editable and reject any transaction that would cause this node to change directly (as in being replaced or content inside being replaced).

[nperez0111]

v3 will have a deleted event which will tell you want content was deleted, from that you could implement something which would filter that transaction out, but that is going to be highly application specific and should not belong in this library.

If something is marked as "uneditable" on the node level like you suggest, then it would not make sense to ever allow it to be inserted into the document.
You may also just be looking for decorations which are outside of editable content.

[chrisdeeming]

@nperez0111 do you have a current ballpark estimate as to when 3.0.0 is likely to be releasing as stable? I know it's not always that clear, but the answer could change our plans slightly.

[Nantris]

Related to this, besides an anticipated release date I'm wondering if any more minor releases are planned before 3.0?

[nperez0111]

I'm not part of the team anymore, so can't say specifics. But, I think this still applies: #5793 (reply in thread)

As far as I know, they plan to release it soon, but are working on the final touches: https://tiptap.dev/tiptap-editor-v3

[nperez0111]

Related to this, besides an anticipated release date I'm wondering if any more minor releases are planned before 3.0?

I would not expect this. I know for sure that there is little capacity for maintenance on prior versions. v3 is meant to be mostly backwards-compatible with a clear guide for this reason

[bdbch]

3.0.0 is going out as a beta next week (missing 3 features - Migrations API, Decorations API and Markdown Support)

I plan to finish these three topics (Decorations API looks good and Migrations API is already started as well) - after I'm done with that and we've seen feedback on the Beta we'll promote it to stable.

[bdbch]

Quick update - almost everything is ready, just tomorrow and on monday we have public holiday and we didn't want to go out with the beta today so we can react fast to feedback. So I will handle the push to live on tuesday.

[jevakallio]

Hey! Excited for v3! I'm testing out 3.0.0-next.8 and seeing persistent crashing issues when initialising the editor on page load with the Collaboration plugin enabled:

Error: [tiptap error]: The editor view is not available. Cannot access view['docView']. The editor may not be mounted yet.
    at Object.get (http://localhost:3000/node_modules/.vite/deps/chunk-S56HXQJQ.js?v=bad059b9:4923:17)
    at get isDestroyed (http://localhost:3000/node_modules/.vite/deps/chunk-S56HXQJQ.js?v=bad059b9:5228:53)

Edit: This issue turned out to be due to missing useEditor#immediatelyRender prop. Setting that to false fixed the SSR issue.

---

I was also not able to get the editor to load with vite/react-router SSR enabled due to the fast-deep-equal package imports not resolving correctly:

Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/Users/hal/dev/poc/node_modules/.pnpm/@tiptap+react@3.0.0-next.8_@tiptap+core@3.0.0-next.8_@tiptap+pm@3.0.0-next.8__@tiptap+pm@3.0._yxhov5amxnqakiawuu6bjnqmgy/node_modules/fast-deep-equal/es6/react' imported from /Users/hal/dev/poc/node_modules/.pnpm/@tiptap+react@3.0.0-next.8_@tiptap+core@3.0.0-next.8_@tiptap+pm@3.0.0-next.8__@tiptap+pm@3.0._yxhov5amxnqakiawuu6bjnqmgy/node_modules/@tiptap/react/dist/index.js
Did you mean to import "fast-deep-equal/es6/react.js"

In both cases, this is a React 19 application. I don't have a reproducible repro easily at hand, but happy to create repros for these if helpful, just don't want to spam you guys with issues if these are known WIP.

[Nantris]

Maybe good for the team to specify how they want bug reports for beta releases reported. I'm guessing as part of the issue template or auto-tagging system as individual issues would be ideal.

[nperez0111]

Maybe good for the team to specify how they want bug reports for beta releases reported
Issues with the release should go through GitHub Issues, specifiying the version of the package they are on, nothing different from normal there.

I was also not able to get the editor to load with vite/react-router SSR enabled due to the fast-deep-equal package imports not resolving correctly:

Likely an issue with your bundling setup, you probably need to change your tsconfig settings to be moduleResolution: "bundler" to that it is able to find the import correctly. Though, for fast-deep-equal specifically, it does seem that it isn't a package.json#exports so, in my PR, I added the file extension too to be more compatible with other bundlers #6233

While V3 is SSR compatible, do not expect everything to work considering that it is being run on the server

[hejianxian]

Hello, our company has been using TipTap for a long time, and we are glad that the v3 version is about to be released. Then, combined with some of our usage experience and customer feedback, we want to see whether the v3 version will consider adding the following capabilities:

1. Lists support more flexible indentation effects:

2025-04-14.16.21.04.mov

As shown in the video above, it is currently found that products such as Slack and Lark can achieve the effects in the video when editing lists. Compared with TipTap's "traditional" list indentation rules, the method in the video is more flexible, especially when editing small pieces of content, such as writing multi-column text messages.

I searched online and found that Meta (Facebook)'s Draft.js and Lexical support the above video effects.

2. When entering link text, it can be automatically converted into link style:

2025-04-14.16.52.19.mov

As shown in the video above, when currently typing in Tiptap, you must press a space to trigger link generation; and when the link and text content are the same, modifying the text content will not modify both the link and the text at the same time.

Thanks.❤️

[bdbch]

For 1: There's a difference between flexible and semantic lists. By default we'd like to keep the semantic lists in tact (lists that follow semantic rules).

We could theoretically add an alternative List extension that would not follow semantics but just allows dynamic indentation but it's not high priority right now.

For 2: Links are usually transformed into links once when a whitespace separator is inserted because the linkify step should not be rerun to often. We can consider this in the future but also not high priority right now.

[bdbch]

And thanks for the kind words!

[Nantris]

@hejianxian you may already have peaked at the difference, but Lexical emulates lists (doesn't use OL/UL) whereas TipTap does not (just rephrasing what @bdbch already has really.)

[hejianxian]

Thanks for your replies.

According to our observation, more and more IM software will use "rich text" technology when editing message content. The user's brief input will be different from writing a long text, flexibility and efficiency will become very important.

This direction or usage scenario may be worth paying attention to 😄

[CorruptionTiger]

Since v3 is going to support importing and exporting word, and will handle headers and footers as much as possible, will it support pagination? I've noticed that building a pagination extension is very complex, and in fact there is no mature solution so far.

[Nantris]

Not involved in the project but I think this is insanely unlikely. This would be very involved.

[bdbch]

I am still working on a pagination solution however I also didn't reach a satisfying solution yet.

[CorruptionTiger]

Pagination is quite complex, to solve the truncation of text, images, tables, etc., and even word allows the setting of pre-paragraph paging or post-paragraph paging, whenever the user enters the content, it is necessary to deal with the content of the affected

[CorruptionTiger]

We need to have a brainstorming session and create a thread for this discussion

[benoj]

Is there any sort of docs for v3 - we're interested in using the next release (or at least testing it in our environment for certain use cases)

[bdbch]

v3 Docs coming very soon!

[SawkaDev]

Love this project, thanks to all the contributors. Any chances of a persistent mark solution. For example, once you set a font family, that should persist across all new lines in the editor, even if you go back to a previously added empty paragraph.

[CorruptionTiger]

You can do this by setting the global font of the editor, and at the same time supporting span to override the default font.

.tiptap {
  --editor-base-fontfamily: "xxxx";
  p {
    font-family: var(--editor-base-fontfamily);
  }
}

[nperez0111]

Agreed, this does not belong as a mark if it is expected to be global. Set it on the editor element & switch out the font like that (either CSS vars or classnames work)

[Nantris]

@SawkaDev, without commenting on advisability, I think you could set the storedMark via appendTransaction whenever the selection changes. Obviously it's a bit more complicated than that deciding when to switch it on/off, but that's the basic framework for the idea.