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.
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?
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.
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.
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.
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..
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.
I am surprised there is no open source tool for cleaning up pastes from word and giving you HTML.
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.
Thanks for sharing.
In general it’s been a massive improvement, with the nasty catch that IME input doesn’t work reliably, impacting CJK languages and similar: https://github.com/vector-im/riot-web/issues/7665.
There were a couple of irritating UI bugs around the editor that we were waiting for. this is good to hear and thanks for your work!
P.S. also the android app .... kind of needs a lot of work, but im hopeful
meanwhile on riot-web we're doing our best to track down the remaining Slate-related composer glitches!
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)
TypeError: Cannot read property 'key' of undefined
at a.n.renderBlockButton (https://www.slatejs.org/main-1783ad63c9cf9b77dd4d.js:42:2277...)
at a.value (https://www.slatejs.org/main-1783ad63c9cf9b77dd4d.js:42:2505...)
at Mi (https://www.slatejs.org/main-1783ad63c9cf9b77dd4d.js:22:6266...)
at Ti (https://www.slatejs.org/main-1783ad63c9cf9b77dd4d.js:22:6755...)
at mo (https://www.slatejs.org/main-1783ad63c9cf9b77dd4d.js:22:7712...)
at fo (https://www.slatejs.org/main-1783ad63c9cf9b77dd4d.js:22:7743...)
at Zo (https://www.slatejs.org/main-1783ad63c9cf9b77dd4d.js:22:8098...)
at Vo (https://www.slatejs.org/main-1783ad63c9cf9b77dd4d.js:22:8049...)
at Wo (https://www.slatejs.org/main-1783ad63c9cf9b77dd4d.js:22:8032...)
at Io (https://www.slatejs.org/main-1783ad63c9cf9b77dd4d.js:22:7969...)
It should not be a reason not to consider slate
Disclaimer: I made it.
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.
Currently it seems to not support customising and/or creating your own blots (like here — http://quilljs.com/guides/how-to-customize-quill/#customizin...)
Also, while we're at it, syncing operations (and example of which is shown here — https://www.slatejs.org/#/syncing-operations) was a hard concept to wrap my head around until I found this — https://operational-transformation.github.io/visualization.h...
We haven't encountered any issues aside from having to write our own parsers (Delta to react native components)
Here is why https://github.com/GitbookIO/slate/blob/master/Readme.md
All slate repos @ https://github.com/GitbookIO?utf8=&q=slate&type=&language=
> 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!
After running into some issues with Draft.js’  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. 
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  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! 
Ian did an amazing job! Thought it was worth sharing.
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.
If you are looking for a modern, modular editor, with a custom data model and collaboration check CKEditor 5 (https://ckeditor.com/docs/ckeditor5/latest/features/index.ht... and https://ckeditor.com/ckeditor-5/). It comes with decent mobile and Edge support already (Electron is supported too). Paste from Word will be delivered within 2-3 weeks. For collaboration we already offer a complete and stable solution out of the box where you don't have to code anything. If you are curious check https://ckeditor.com/blog/Lessons-learned-from-creating-a-ri...
Edit: reading through their issue tracker, looks like they're going to make a good go at it, but it is hard: https://github.com/ianstormtaylor/slate/issues/2062#issuecom...
It is really good to see they have RTL support.
-- However they messed up when using composing IMEs :(
I would love to see this in use for comments on HN, Reddit, Github and everywhere else.
edit: Good morning everybody, the link is right above the list https://www.slatejs.org/#/rich-text
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).
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.
I have been struggling to find a good editor for my form builder site  and settled with quill but I like slate's approach better
There's also a react wrapper (for versions 1 and 2).
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.
Also what's the difference between using SlateJS vs. say Monaco editor which powers VSCode?
This site helps understand it — https://operational-transformation.github.io/
You can provide (or use others') serialisers and deserialisers to convert between that representation and something else, e.g. RTF, HTML.
An error was thrown by one of the example's React components!