I've used Slate in a production application for about 2 years now, as part of a CMS for medical professionals to write rich content for other medical professionals and patients.
They tend to write the initial content in MS Word which they are comfortable with and then paste into the editor, then the editor has to reconcile this according to the site's structural elements. Then for editing, this works fantastically well, and allows more complex widgets and unusual design elements to be embedded and edited in the WYSIWYG context in the editor.
When the system was first being built we trialed 10-20 or so other solutions in this space, many with the same design concepts as Slate, but something about this stuck. Just brilliant.
I have been dealing with paste-from-word issues as well. The biggest issue is ordered lists. Word is very smart about keeping the ol going even if there are extra linebreaks in between list items. Most rich text editors mess up this enumeration when pasted from Word. One thing I noticed about slate.js is that it simply converts the ol into text, which keeps the correct numbering. This is a successful solution.
And my question to HN is: why do our web app users keep typing in Word first? I save drafts in local storage, but they still use Word first. Is it the formatting familiarity? Is it a Start Menu shortcut? What is it? What can we do to address users not using our web apps first?
I think they are comfortable with it from using it for a long time.
In fact I find people do everything in MS Office products, generally in ways you wouldn't necessarily expect the software to be used. E.g. PowerPoint is the de facto tool for designing conference posters. To create 'versions' of documents, people will copy and paste the file and add a number at the end.
I think we often get so myopic about our perspective on technology that we forget that non-technologists have a vastly different relationship with it.
(CKEditor team member speaking) Proper handling pasting from Word really takes a lot of time and it's hardly possible to provide a high quality solution alone. We will deliver some basic (in our understanding) support for pasting from office in our most recent editor (https://ckeditor.com/ckeditor-5/) in 2-3 weeks and it already took long weeks of development (see https://github.com/ckeditor/ckeditor5-paste-from-office/issu...), even with our years of experience in rich text editing and with this particular feature.
If pasting from Word is absolutely critical feature for you you may want to check older editors on the market, like CKEditor 4 or even... TinyMCE, one of our competitors. These editors are on the market for 6+ years and had enough time and people to deal with the crap that MS Word produces - correctly preserving as much formatting as possible, without wasting a lot of your end users time on recreating the same content again in an online rich text editor.
It seems to somewhat work in the Paste HTML example [0], for which the source is available [1]. I just did a cursory test with some simple formatting, so YMMV, but it may be a good starting point.
My issue is mainly that Word doesn't really maintain the same structured hierarchy in the XML that HTML would – it's more like a sequential format. The users wanted a way to indicate certain types of content or annotations and they do so via coloring text in certain ways – but I found in practice this is very hard to reconcile since there is a lot of invisible formatting in word, the element may terminate and start again, with a new invisible element in between. Invisible to the user - but very visible to the parser.
Essentially it's a balance of attempting to remove all the spurious elements (`<o:p>`, or invisible empty formatting, etc.) and then reason about what remains. Much of that involves a lot of walking the tree to inspect neighbouring nodes because them being co-located can indicate something.
Look you may be recoiling in horror by now – it sounds horrific. Actually what we have is a remarkably stable system all things considered but it was built up over time. I think the only approach you can take is write a large amount of unit tests for the schema normaliser, with real MS-word samples and expected outputs, and then really put the system through its paces. Every time you find an example that breaks your model, add a unit test for that snippet, and evolve.
God forbid a Word update ever introduces a new format.
While it looks pretty simple it cleans MS Word and browser artifacts in pasted markup pretty well.
But I shall admit that such simplicity is possible only with sciter (that html-notepad is based on). E.g. that canonicalizeDOM gets called before the content appears in target document. So all this does not affect undo/redo stack, etc.
It was an attempt to provide a resource for comprehensive, in-depth, accessible information for maxillofacial / heck & neck patients and practitioners. Part of the movement of empowering patients by giving them the information traditionally held by clinicians, but also helping clinicians to be aware of scientific research from adjacent disciplines that might be useful.
The CMS design comes into it because when you have a larger collection of non-technical authors you need an accessible way to manage the content. This was how it was initially conceived anyway - in practice more development time had to go towards handling the users' existing workflow (MS Word) rather than migrating them into the CMS directly. A real eye-opener for me about user-centred design..
Very cool project - thanks for giving me the background. Just clicked around and enjoyed checking it out. Sounds like you learned a lot and built a valuable tool, well done!
We're using Slate to for a mid-sized react application where content editing is the core. I don't want to link/plug a product video showing you how it works but imagine dropbox paper, medium editor, CKeditor 5, ...
The implementation includes mentions, pretty complex gallery/inline image functionality, galleries with size/output controls, embeds (iframely) and other inline elements.
First we had TinyMCE, Redactor, DraftJS and then switched to Slate.
I would not say it's smooth sailing from here, we're mostly struggling with pasting from word, tables, mobile support and overall performance with the number of plugins, but working on it.
Similar story here - started with DraftJS but it was kind of cumbersome. Slate in comparison is much more flexible and we've been using it in production for almost a year now. In fact we just launched a sticky notes project management tool which features a smooth rich text editing based on slate https://whimsical.co/sticky-notes/
So, I have to ask why whimsical.co's navigation is so counter-intuitive? Why do arrow keys move the screen the opposite direction, and why is there no drag and drop? I am not trying to be aggressive, I just want to understand the design decision?
What was the main reason for switching from draftjs to slate? Just curious since we’ve been working on various tools in the space (not directly related to either). Was it an api design issue or more a plugin/ecosystem issue?
interesting, I am using TinyMCE and paying them for the PowerPaste plugin, figure a team that manages pastes from Word will do a better job than I could, and $1850/year.. I couldn't easily make that feature and maintain it for that money.
I am surprised there is no open source tool for cleaning up pastes from word and giving you HTML.
I wish you would post a product link. For me personally, I really enjoy when some library or what have you front pages, and people post a mix of comments and products showing off its usage or an alternative to it.
Note that though this lists ProseMirror as one of the evaluated editors, followed by a bullet list of issues, only one of those issues can reasonably be considered to apply to ProseMirror—and that's "Re-inventing the view layer", i.e. "doesn't use React", which can arguably be an advantage.
I've also recommended http://letterpad.app/ to use it and they've switched to it now.
I'm a huge fan, it's insanely powerful and customizable, you can build anything you want with it.
The only problem is lack of documentation and tutorials, it's really hard to figure out how to use it beyond the very basics (for me at least). They do have a great community in the slack channel, they've helped me a lot, but better docs would make a huge difference.
[OT] Writingstreak is very interesting, and the gamification looks promising. I'm not sure I have the time to write on a daily basis, but be asured I'll think about it and eventually register.
Good to know. I may have added a comment to one myself - especially around copy pasting code in the editor.
Also, just so you know... there's a lot of confusion around riot with your multiple names:
vector.im - name of the company. No social media presence.
riot.im - name of the webapp. This is your twitter handle.
modular.im - name of your hosted product where you are actually making money. For a mission critical product, you dont even have a contact-us email. You also dont have a list of features - you are assuming people who come here are super aware of Matrix features. Even this is so much better - https://docs.google.com/spreadsheets/d/1-UlA4-tslROBDS9IqHal...
matrix.org - half the UI source code is here (other the API reference implementation which is the only thing that a standards organization should have). So where do we file bugs ? on vector-im/riot-web (!!) or matrix.org .
As of Aug 2018, the only skin that exists is vector-im/riot-web; it and matrix-org/matrix-react-sdk should effectively be considered as a single project (for instance, matrix-react-sdk bugs are currently filed against vector-im/riot-web rather than this project).
Its super weird and confusing. Riot is a cool name (and my personal favorite)... but use anything you want. Just have one name - Gitlab does this so very well (with both its open source product and hosted product)
I feel like some of the biggest difficulties Rich text editors in browsers face nowadays are supporting social media type inputs like mentions, hashtags, emojis, etc. while still maintaining the classic rich text selections. DraftJs is the only one that achieved that for me, I had to do some serious elbow grease to get functioning hashtags in Redactor (another rich text editor).
SlateJS user mentions are far away from what users expect a mentions plugin to work like.
What issues are you seeing with slate? I was able to integrate pretty easily several advanced mention style patterns (similar to how slack integrations work) using draftjs. Assuming how slate has addressed other draftjs design issues, I can’t imagine the api would be far off. I’m curoious since we are working in this space currently.
Tons. I think it’s a modern UX issue, and the fact that social platforms popularized an @, #, shortcut platform means even my mom (somehow) knows how to use it. It’s a stretch saying, but i feel there’s a loss for a developer/product to not take advantage of the momentum around popularized social-style tagging patterns for unrelated use cases.
I haven't found an editor that can act anything like word in relation to object placement. I should be able to drag images around and have it automatically format with my document. I should be able to resize just by dragging on the edges. Same goes for embeds, graphs, etc.
I believe wordpress has had some commercial plugins that could do this well, but I have not found an open source editor that redefines rich text editing at all.
I will be probably switching from quill to prosemirror because quill ignores numerous requests for shadow dom compat. It also annoyed me that its hard to get rendered delta results from it - we had some workarounds for it, maybe they provide an API for that nowdays.
I made a rich text editor in 2004 and last year I made another one, and nothing has changed. The most annoying thing is that contentEditable works different in different Browsers. Some browsers for example use <div> instead of <p>. And browsers will add extra HTML elements! If you for example pass in <table> the contentEditable will add a <thead> element, so you constantly have to check what the contentEditable is up to. It would probably be easier to use HTML Canvas and implement everything from scratch.
You might be interested in the video linked below on how DraftJS (which was the forerunner of SlateJS) uses the virtual DOM created by React along with contentEditable to make the same tooling work across browsers.
> We are not in any case criticizing Slate's community or the work Ian has done. GitBook simply must focus on improving the experience of its users, which requires fixing core issues in our editor (mainly performances) that are impacting our business.
> Our goal is not to replace Slate with our fork within the community. We do not expect people to use our fork. If you do, you should know that we will not accept contributions that are not fully aligned with our goals.
This is how the Lucid Emacs situation should have been handled!
Discovered Slate last night while evaluating Draft.js for building the rich text editing experience of our WYSIWYG editor.
After running into some issues with Draft.js’ [1] Flow types, and going deep into the GitHub repo looking for solutions, I concluded that the project wasn’t receiving enough support from Facebook to invest in it. [2][3]
After discovering Slate from one of the issues, I was extremely impressed with its documentation and well designed API. The plugin system is so good it even gives me some ideas on how to design our WYSIWYG’s API.
And for people that don’t use React, while there aren’t any official plugins for other libraries yet, the source [4] is so readable that making one wouldn’t be hard at all. I’m sure contributions would be accepted for a Vue plugin, Angular plugin, or even a vanilla plugin. In the React plugin there’s a DOM plugin used already! [5]
Ian did an amazing job! Thought it was worth sharing.
Looks promising. After working with and evaluating many rich text editors I usually consider building one myself as a nightmare, due to the interaction complexity and browser differences.
One thing that strikes me with this editor, similar to many others that are innovative and promising, is how Edge and mobile are not first class citizens.
That will severly limit the use case for the editor to niche products or embedded in apps build in Electron or similar.
I am using Slate Js and it's fantastic, though there are some caveats. Mobile support is limited, slate is still not in a stable release so there may be breaking changes, and for now you're limited to using react. But when it works, it's amazing! I really like the freedom it gives you in defining and changing your own document schema and how everything is rendered.
I think the biggest fault is a lack of virtual rendering. Slate renders the entire document so if you're doc is too big, slate starts to break fast. Virtual rendering (like in the Ace Editor) solves the problem.
"Built on top of react", sorry at least for now it is too big of a dependency for most projects that are not react based. IMO that disqualifies it from being "framework for building rich text editors".
The core actually doesn’t rely on React at all, allowing interop with any front-end framework, or even vanilla JS. The current plugins provided officially are React plugins, but other plugins can be built for Vue, Angular, etc.
If you are looking for a completely framework-agnostic rich text editor, then check CKEditor 5 (https://ckeditor.com/ckeditor-5/). It comes with it's own UI library which you can swap freely with any other UI thanks a to highly decoupled architecture.
"Better" is a subjective thing. Currently I use lit-element base class for web components, but I plan to try stencil and vue to see how it feels like. At work we also use react for some projects.
Does this work on Android Mobile? We just implemented a feature before realising Draft.js doesnt' work on Android Mobile - Our fault admittedly, but annoying none the less.
It's an ongoing issue, I believe due to the way Android Chrome implemented keyboard events. Editors that specifically avoid the HTML endstate of contenteditable in favour of constructing a parallel state using keyboard events are all trying to deal with the same issue
I do not know Slate JS (yet), but I think it is worth
mentioning react-draft-wysiwyg[1], a rich text editor
made on top of React and Draft. I used it in one of
my projects and it was really cool.
I used slate in one of my projects but replaced it eventually with draft.js.
The biggest pain points were:
Not stable yet. A lot of breaking changes between releases, so you have to update your code frequently.
Breaking changes often introduced new bugs.
Big in size (even bigger than draft.js).
I did a full heads down comparison of a bunch of text editors for Polar (https://getpolarized.io/) and their practical features and I ended up going with Summernote:
it's definitely not perfect and seems to not be developed as much as the others but it handles copy and paste VERY well. I can literally copy test from my editor (intellij) and it keeps the formatting perfectly.
With Polar users need a way to reliably annotate their books and having a quality text editing component is important.
I think I'm going to look at Slate too but also look at CKEditor5... both seem like really decent options.
Love Slate. Amazing plugin system -- I've started integrating a backing CRDT with Slate, enabling realtime collab. Would recommend. Coming from Draft, it's a order of magnitude more maintainable and much better developer experience.
I used SlateJS a year ago and couldn’t be more impressed. It struck a great balance with minimalist architecture while also providing the React building blocks I’d rather use than create myself.
This looks cool - is there anything about accessibility testing - how well it works with screen readers for example? I couldn't see anything in the docs.
Happy to see this topic re: rich text editors back on track. It's one of those things that never seemed to evolve since the early '90 days. Google docs set the bar really high.
I have been struggling to find a good editor for my form builder site [0] and settled with quill but I like slate's approach better
I'd second CodeMirror - I've been tinkering with it (v2 - https://codemirror.net/2/) for a couple of weeks and it's pretty nice to use. I'm using a bit of simple syntax highlighting.
There's also a react wrapper (for versions 1 and 2).
I love how customizable this is. Text selection on iOS doesn’t seem to work across styled text unfortunately. It would be great for RTF editing on mobile sites if it had better mobile support.
Slate is not an editor so much as a framework for building editors. Which is to say yes, it would be a good basis for an editor for mathematical formulas, but you would have to create the schema yourself (MathML seems like a good starting point). Defining transformations so you could use the LaTeX syntax as short-cuts seems like it would not be too arduous – although obviously a complete implementation would be a vast undertaking.
Lots of progress in this space but they all seem to be coalescing into the same basic style. For standard apps that just need rich/html input, I highly recommend Froala.
The whole point of slate is an immutable representation of a document. Without getting too much in the weeds, a document is an immutable object. Edits to the document are transforms. The obvious benefit is undo/redo is pretty simple. The more subtle benefit is that really complicated document rules become tractable. I built temi.com using this (https://www.temi.com/good-audio-quality). One feature that Slate enables pretty easily is incremental saves. Since the object is immutable, you can pass changes to the server instead of the entire document by just checking element ids. You can get multi-person edits relatively easily as well.
You define an internal schema, which is essentially just a tree structure according to your own use-case. In this way it lets you do editing of more complicated page elements than a typical WYSWYG editor.
You can provide (or use others') serialisers and deserialisers to convert between that representation and something else, e.g. RTF, HTML.
They tend to write the initial content in MS Word which they are comfortable with and then paste into the editor, then the editor has to reconcile this according to the site's structural elements. Then for editing, this works fantastically well, and allows more complex widgets and unusual design elements to be embedded and edited in the WYSIWYG context in the editor.
When the system was first being built we trialed 10-20 or so other solutions in this space, many with the same design concepts as Slate, but something about this stuck. Just brilliant.