Currently, pressing [tab] makes the editor lose its focus. Does prosemirror support tabstops? If not, then what is the best/easiest approach to fake them? I suppose, on pressing tab, the editor could insert a “wide-space” element (a div that is about 4em wide). This is not the same as tab, I know, but at least it produces something which is reasonably useful (tabs are often used at the beginning of a paragraph anyway).
Any thoughts?
Nope. You could add a tab-like element to your schema, and bind tab to insert it. That will not be anything like traditional editor’s tab stops though. (But one could argue that tab stops are not a very semantic or clean concept to begin with.)
Yes, as a programmer, I can definitely relate to the idea that tabs are not a clean concept. However, users are accustomed to them.
So I just tried adding a tabstop as a block-level element, but I noticed that when you move the caret across them (by pressing tab, then arrow-left), the caret disappears. I guess this is because a block level element “captures” the caret. Is there a way around this?
Thanks for your thoughts.
Why block-level? These seem like they should be inline.
Did you set the node as selectable? Did you properly set its contains property to null?
Ok, thanks, I will try this. (In the meantime I was using a different solution, i.e., converting tabs to 3 spaces, which obviously isn’t the ideal solution).
PS: Yes, sorry, I meant inline (was confused about the terminology).
One strong warning about overriding tab’s default behaviour in the browser: interfering with tab violates WAI compliance and should be avoided. Simply put: If someone with sight issues uses your application they will expect to be able to use tab to navigate; it isn’t good practice to prevent them from having that option and, in some countries, actually opens your application to liability as a complainant could claim grounds for discrimination.