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.
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.
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.
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 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.
(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 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!
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.
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 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 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 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.
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.
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.
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'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)
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
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.
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.
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 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.
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.
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?
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.
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.
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?
"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".
"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.
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.
> 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!
114 comments
[ 3.1 ms ] story [ 193 ms ] threadedit: Good morning everybody, the link is right above the list https://www.slatejs.org/#/rich-text
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.
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.
https://github.com/c-smile/sciter-sdk/blob/master/notepad/re...
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.
[0] https://www.slatejs.org/#/paste-html [1] https://github.com/ianstormtaylor/slate/tree/master/examples...
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.
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.
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..
https://maxfacts.uk
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.
It is really good to see they have RTL support.
-- However they messed up when using composing IMEs :(
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).
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)
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.
It should not be a reason not to consider slate
Disclaimer: I made it.
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.
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...
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...
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)
https://github.com/ianstormtaylor/slate/issues/2062
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...)
There's also a react wrapper (for versions 1 and 2).
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.
https://www.prezly.com/news/the-different-ways-to-use-images...
I am surprised there is no open source tool for cleaning up pastes from word and giving you HTML.
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!