The site [1] even pulls in the Trix editor source (js/trix.js), but doesn't do anything with it. I guess it's not finished? But they put in enough effort to add a blinking cursor animation--why not slap in a sample editor as well?
Neat, thanks! Literally just this morning I was thinking to myself that I would give just about anything for a high quality OSS rich text editor capable of generating terse, correct HTML output.
And here, not even 24 hours later, one just falls into my lap.
There's also ProseMirror [1], which I'm told is very good, and supports extensions of its document model to support things like embedded objects and Markdown, and is designed for collaborative editing -- all document operations are patches that can be sent over the network.
You should probably put a link in the README.md in the github repository - it was the first thing I looked for (Cmd+F -> "demo"). Nothing beats a visual experience in case of a frontend library.
You'll want to add "cursor: hand;" to your CSS when someone hovers over the styling buttons. Because right now, it default to the cursor point, which doesn't given a clue to the user that the styling buttons are clickable.
Sorry, I only just saw this message. I'd defintely offer to contribute if you're writing one alhough I'm not hugely familiar with many (but am with wysihtml5, quill and CKEditor).
Going from the README, the main difference is the architecture.
It creates a layer of indirection between user actions and the DOM. This has two advantages:
* For developers of Trix itself, it eases the pain of cross-browser development - as the README says, contenteditable is inconsistent across browsers.
* For developers using Trix, you get a clean API (Trix.editor) so you can edit the document programmatically without your own cross-browser development.
Sadly, while the Scribe developers correctly identified all the various problems with contenteditable (https://github.com/guardian/scribe/blob/master/BROWSERINCONS...), they chose to solve it like most other editors: by using execCommand, waiting for the browser to make a change, and then attempting to clean it up afterwards.
Trix's thesis is that this approach is fundamentally broken. Instead, Trix updates an internal document model on each input event, then re-renders the editor contents in response.
I tried Scribe and was quite enthused about it but there are trivial bugs that never got fixed, been a year since I filed this issue[1]:
Basically, http://jsfiddle.net/L59kL1rf/ -- you cannot delete the first paragraph and always end up with <p><br /></p> and if you try to delete that it just starts acting strange. This issue has been open since 2014 and it seems it's a bug in the core.
There were other similar issues I ran into around the same and decided I would revisit later but it's been a nearly a year since.
Trix fully supports file attachments and image attachments, as documented in the readme. It includes an inline caption editor for images.
Trix also supports "content attachments" (currently undocumented) which allow embedding arbitrary HTML as attachments in the document. Basecamp 3 uses this feature to embed @mentions with avatars, and various oEmbed types, in messages and comments.
I want to see those "content attachments" as a live demo!
I'm currently using CKEDITOR in a Rails app and inserting HTML "templates." CKEDITOR renders the HTML and allows the end-user (or content creator) to modify the HTML while it is rendered inside the contenteditable text area.
From the document model standpoint, Prosemirror has a tree of nodes, while Trix has an array of blocks with a stack of block-level formatting. Mathematically equivalent, practically not so much.
This looks interesting especially the part about "Trix sidesteps these inconsistencies by treating contenteditable as an I/O device". We recently started using froala (https://www.froala.com/wysiwyg-editor/v2.0) and are really happy with it so far.
One thing this gets right that heaps of other WYSIWYG's get wrong is lists. You can create a proper multi-level list here with order and unordered lists nested inside each other correctly. This sort of stuff is actually important for creating accessible documents as things like flowcharts need a plain text version and nesting lists is a reasonable way of displaying these.
Absolutely. I do note though that headers (h1, h2, etc.) are not supported (unless there's a way to customize the format bar past what I saw in the demo). Switching from ul/ol/li to h1, h2 and back has been a MAJOR headache for us when we tried to offer text-editing features based on an older library called wysihtml5. Medium also dodges that altogether. Text editing is still extremely complicated.
My litmus test for WYSIWYG lists — which Trix fails — is
1. start a numbered list
2. put several paragraphs...
> including some nested block element e.g. quote
... inside one list item
3. Then continue the numbered list (not from 1!)
This is something that's trivial to express in markdown, LaTeX etc but annoying to impossible with WYSIWYG where being in a list pretends to be a per-paragraph boolean property. In many WYSIWYGs you can't semantically put block-level stuff "into" a list item, only fake it by pressing Enter, cancelling numbering on the new paragraph and increasing indent to align with list item.
This makes it a nightmare to continue the list afterwards, because actually I've already closed it. Surprisingly, while many WYSIWYG editors are only ready to start a new "1. " list, they do allow me to paste the compound item into the middle of an existing list without interrupting its numbering. Sometimes there are other rituals involving liberal consumption of Shift+Enter and Backspace, dancing with text, and promising my firstborn to be contentEditable...
Anyway Trix fails it on the simpler task of multiple paragraphs in a list item. I haven't looked at the code but it seems its content model (at least strictly enforced) for list items is something like:
- a single block element (can be a quote or code)
- followed by zero or more sublist items.
It's good that Trix won't let me increase indent on a paragraph that doesn't fit its content model. But I need a stronger model for my docs...
Now a quote does allow multiple block content! What happens when I put a quote inside a list and then add sub-lists inside the quote? Madness:
I'd hope the continuous outer / non-continuous inner numbering is just styling bugs and not a crazy model?
P.S. A smaller usability issue: how do you make a numbered list with bullet sublist (or vice versa)? Enter->increase indent->switch to bullets works but Enter->switch to bullets leaves me with no option to increase indent. Unnecessarily confusing.
Anyway, lists are why I hate all WYSIWYG with passion as a user. I wish WYSIWYM with explicitly visible structure (cf. TeXmacs) was more popular.
Reported the clear bugs (#63, #64). not sure if the list content model is bug or intentional, though allowing the first line of an item to be a single quote or code block + the freedom inside a quote does make it questionable IMHO...
(cf. http://spec.commonmark.org/0.21/#principle-of-uniformity)
P.S. Squire doesn't seem to allow block content inside lists. Only Shift+Enter linebreaks.
ProseMirror does allow block content (it defaults to markdown content model); continuing the numbered list after non-sublist items required the paste-into-existing-list dance.
Firepad does allow non-item content but doesn't align it like part of the list. It does tend to continue the numbering afterwards, not sure what are its exact rules.
None of this is IMHO satisfactory UX. I've observed many people struggle with lists in any WYSIWYG I've ever seen :-(
Does anyone know if this would adapt well for real-time use with multiple people writing at once? Etherpad-style. Or would that need to be architected differently from the start?
ProseMirror [1] is designed for collaborative editing -- all document operations are patches that can be sent over the network. Like Trix, it uses its own document model, not contentEditable.
Yes, they are all terrible. I don't know if this will be any better. They all highlight how bad the web is as an environment to host applications. A rich text editor - something that is a trivial toy project in any other application development environment - is impossible to build on the web in 2015.
Yes, almost all of them have major issues. It's really hard to get something that works with all the main text use cases but can also support images and some basic layout features (like drag/drop, move stuff around, etc).
Finally an editor which can replace existing form elements without extra JavaScript! ContentEditable is wow and all but it doesn't replace textarea, this does.
Nice to see this particular bit of info high up in the README (though "as seen in Basecamp 3" would fit well in the Github repo description line):
> Trix is an open-source project from Basecamp, the creators of Ruby on Rails. Millions of people trust their text to Basecamp, and we built Trix to give them the best possible editing experience. See Trix in action in the all-new Basecamp 3.
Nothing gets me more interested in trying out a JavaScript library than seeing that it's used in a mainstream production product, especially a money-making/critical product by very same the company that created/maintains it...it's a bit of guarantee that the API is relatively mature/won't-go-crazy and that someone has a vested interest in keeping the library up to date with changes in the Web. That was why React was so much more appealing to me than Angular, relative to their respective public release dates...React was already in production at Instagram and parts of Facebook, whereas I don't think Angular was in any of Google's main public facing products (i.e. search, YouTube, Maps)
It's also open source. The developers (Basecamp) are obviously deeply invested in the Ruby stack.
If you want to install it with NPM, you could a create pull request with a package.json file and some helpful information for the authors about how to submit to the NPM registry, no?
This is the point of open source software you realise - that you can not just use the software, but that you can help improve it for yourself and others.
Isn't CoffeeScript the "Macro-assembler" of JavaScript? i.e. a simple 1:1 syntax mapping, without no differentiating semantics of its own. Or am I wrong?
It's neither a subset nor a superset of JavaScript. It's a language that isn't JavaScript that is compiled to JavaScript. There are to-JavaScript compilers for many languages now including Scala, Kotlin, Clojure and more. Maybe people who write CoffeeScript as part of some public thing consider themselves to be part of a JavaScript project, but I wouldn't.
You know that "languages that compile to JavaScript" (thanks for not using the word "transpiled", btw) include JavaScript? Babel, Traceur - does it ring a bell? Would you argue that their users are not a "part of JavaScript"? What about TypeScript (it's just an implementation of some ES6 features + a powerful linter)?
Coffee is just a set of syntactic improvements (well, it's debatable - let's say "syntactic changes") over JavaScript. JS is too weak a language to implement this syntactic sugar inside of it, so there is a need for an external tool. But if you take a look at any Lisp, you'll see that people are building syntactic abstraction inside a language and that it doesn't make their code "a different language compiled to (their kind of) Lisp".
This is not to say that everything compiled down to JS is still JS. But the difference is quite neatly explained in Mathias Felleisen great paper: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.51.4... All that Coffee does are local transformations, equivalent to what you could do with Lisp or Nim or Dylan macros.
[EDIT: removed the "soooo cute" opening sentence, as it was brought to my attention that it distracted readers]
I stopped reading your reply after this. Just FYI, HN doesn't condone bad attitudes. You'll end up getting hell banned.
Having said that, my down-voted comments are factual. They are not incorrect, they were down voted by people who have strong emotions about CoffeeScript.
True or false? All the statements below are true.
Trix is writen in CoffeeScript?
CoffeeScript is not superset or a subset of JavaScript?
Are there other languages that compile to JavaScript?
I don't consider projects written in CoffeeScript JavaScript projects?
I gave simple statements of fact that were not incorrect, and they got down voted and emotional replies.
I edited the post, removing this unfortunate opening sentence. It was intended as humorous, which could have backfired.
> Just FYI, HN doesn't condone bad attitudes. You'll end up getting hell banned.
user: klibertp
created: 1159 days ago
That is to say, you don't need to tell me what HN is about.
> They are not incorrect, they were down voted by people who have strong emotions about CoffeeScript.
No. I downvoted you, and I have no attachment to CoffeeScript. I downvoted you because in your earlier comment you wrote that it's "a shame" that Trix is written in Coffee, without any rationale.
> I don't consider projects written in CoffeeScript JavaScript projects?
Here, similarly, you didn't provide any explanation of why do you think that way. Without such an explanation what you wrote would be unacceptable in many other contexts. I won't cite examples, but definitive statements about what something is or isn't in general should be backed by convincing arguments.
---
You not considering CS projects a JS projects is a very debatable opinion. It's nuanced debate and has a great depth. Simplifying it to a simple statement without providing any context looks ignorant at best, and like an ill will at worst. Which is why I reacted.
> in your earlier comment you wrote that it's "a shame" that Trix is written in Coffee, without any rationale.
Where did I say that? I didn't say that at all. I'm on my threads page writing this reply to you and a search for shame only brings up your comment so whoever you're quoting isn't me.
Looks like you're right. Sorry. I must have confused you with some other commenter I read on HN today, it's a mistake on my part.
Having admitted this much, I'm still waiting for your explanation why you wouldn't "consider projects written in CoffeeScript JavaScript projects". I'd still downvote you for stating such a strong opinion without providing any rationale.
They're not JavaScript because the language used to write the source code isn't in JavaScript. Babel is used to bring modern JavaScript features into older browsers, but you're still writing JavaScript. If the language you are writing doesn't at least attempt to conform with some signficant portion of the ECMAScript specification, it's not JavaScript.
Not sure why so many downvotes -- they build an in-memory representation of the content of the contenteditable, intercept input events to update that representation, and use that to update the actual dom. Presumably they wouldn't just wipe out the entire contents each time either, so it's sending atomic create/update/delete commands to the dom.. So it's like React's vdom just for contenteditable.
quick experiment: after copying the original text 200 times into the text box it starts to be unbearable to write any new text. However, if one just inserts 200k characters with no formatting, the editor doesn't seem to slow down.
This is a very astute observation. When I was developing Gate One I experimented with something similar for terminals (using contenteditable to work around issues with keeping elements up-to-date while retaining formatting) but ultimately ran into severe performance problems. That was years ago though and browsers have gotten much better at handling contenteditable with larger amounts of text.
However, the more tags you add to contenteditable elements (i.e. for formatting) the more work the browser has to do every time there's a page reflow and there will be a reflow every time the text changes. So the more formatting, the slower (less responsive) it will be.
The workaround for this (no idea if it's used in this editor) is to divide the document up into lots of individual <div> elements with contenteditable=true and make sure that all outside-the-view elements are removed or at least hidden via 'display: none' and merely re-show them on-the-fly as the user moves about the page. Keeping a page or two above and below the view pre-rendered can help with responsiveness and you'd also have to make sure to pre-fill all the document's unseen space with whitespace so that the user can scroll to any position accurately even if the browser is still retrieving and rendering that portion of the document.
I came very close to implementing such a solution but ultimately decided on something else entirely (server-side rendering and a difference-based terminal update protocol). It's a great idea for an editor and tows the line of, "what we're supposed to be doing" on the web but ultimately it requires a lot of complicated code. Far more complicated that one would think at first glance.
They don't use contenteditable in the traditional way:
> Trix sidesteps these inconsistencies by treating contenteditable as an I/O device: when input makes its way to the editor, Trix converts that input into an editing operation on its internal document model, then re-renders that document back into the editor.
Has anyone found a good workaround for this? The best I can do is move the select content menu after it's loaded, but this looks ugly and is really, really distracting. Nothing else that I've tried works.
Actually, not every editor break it, this is not my real issue with
WYSIWYG editors anyway.
My problem is that I don't want to use them. Unless they use
markdown or another simple formatting language behind the scene, and allow
you to switch to a simple `<textarea>` input, you can't avoid them.
I already have a text editor, I already have a way to generate "rich"
text, I don't need another tool with another set of bindings, quirks, bugs and
incompatibilities.
Every editor has its own way to deal with very basic stuff: when writing a list
what happens if you press return twice? Backspace on an empty element? Tab? You
can't know beforehand.
I'm fine with giving tools to non-technical users, but there should be a way to
disable such editors completely so it can adapt to any workflow.
I really like this. If only it supported ie 9 and below I would use it.
Looks like we are stuck with CK unless anyone can offer other viable, preferably pretty, solutions?
Last time I saw Basecamp (then 37signals) working on a rich text editor is a long time ago. What happened to WysiHat? I know it had another developer than the two guys who made Trix.
What I especially liked about WysiHat was the complete bareness of the toolbar, just plain HTMl links. Is that also possible with Trix?
I was involved with the Wysihat project too. What we found is that its approach, like most other editors', is fundamentally broken. We created Trix to solve the problem. https://github.com/basecamp/trix#different-by-design
I think you'll find Trix's toolbar easy to style however you'd like, but if not, it ought to be straightforward to implement your own using the API.
Cool, and great work! I had a small e-mail conversation with Josh (forgot his last name) a couple of years back, I thought he worked on Wysihat alone.
I have seen and tested some RTEs for the web, and I can only imagine how hard it is to come up with a durable solution. So thanks for Trix and good luck!
P.S. Trix also has a 'royal' connotation to me, because it's short for Beatrix in The Netherlands. Beatrix being the former queen.
Probably more the "You just have to learn a few HTML tags", which reminded me (since it was quoted in another discussion today) of the comment about Dropbox saying that it was trivial to replicate by getting FTP space, mounting it using some tool and running SVN on top.
Try to imagine yourself in the shoes of someone who doesn't know HTML and just wants to write a message or comment with a little emphasis and maybe a bulleted list. That's the majority of our customer base at Basecamp.
Creating an editor for that does sound like a simple task, doesn't it? Except the tools the browser gives you just don't work, as we've experienced first-hand over the years in the form of customer bug reports.
This isn't meant to replace something like say vim, or perhaps dream weaver. Instead, I believe this is for people who want to make it easy for casual users to format text in a comment or what not.
136 comments
[ 4.3 ms ] story [ 233 ms ] threadhttp://jsbin.com/cazewaxoje/1
[1] http://trix-editor.org/
And here, not even 24 hours later, one just falls into my lap.
http://www.hulu.com/watch/33690
[1] http://prosemirror.net/
You'll want to add "cursor: hand;" to your CSS when someone hovers over the styling buttons. Because right now, it default to the cursor point, which doesn't given a clue to the user that the styling buttons are clickable.
http://xing.github.io/wysihtml5/
It creates a layer of indirection between user actions and the DOM. This has two advantages:
* For developers of Trix itself, it eases the pain of cross-browser development - as the README says, contenteditable is inconsistent across browsers.
* For developers using Trix, you get a clean API (Trix.editor) so you can edit the document programmatically without your own cross-browser development.
We (the Guardian) created Scribe to tackle this:
https://github.com/guardian/scribe
(I can't take any credit personally though alas!)
Trix's thesis is that this approach is fundamentally broken. Instead, Trix updates an internal document model on each input event, then re-renders the editor contents in response.
Basically, http://jsfiddle.net/L59kL1rf/ -- you cannot delete the first paragraph and always end up with <p><br /></p> and if you try to delete that it just starts acting strange. This issue has been open since 2014 and it seems it's a bug in the core.
There were other similar issues I ran into around the same and decided I would revisit later but it's been a nearly a year since.
[1]: https://github.com/guardian/scribe/issues/300
Trix also supports "content attachments" (currently undocumented) which allow embedding arbitrary HTML as attachments in the document. Basecamp 3 uses this feature to embed @mentions with avatars, and various oEmbed types, in messages and comments.
I'm currently using CKEDITOR in a Rails app and inserting HTML "templates." CKEDITOR renders the HTML and allows the end-user (or content creator) to modify the HTML while it is rendered inside the contenteditable text area.
This makes it a nightmare to continue the list afterwards, because actually I've already closed it. Surprisingly, while many WYSIWYG editors are only ready to start a new "1. " list, they do allow me to paste the compound item into the middle of an existing list without interrupting its numbering. Sometimes there are other rituals involving liberal consumption of Shift+Enter and Backspace, dancing with text, and promising my firstborn to be contentEditable...
Anyway Trix fails it on the simpler task of multiple paragraphs in a list item. I haven't looked at the code but it seems its content model (at least strictly enforced) for list items is something like:
- a single block element (can be a quote or code) - followed by zero or more sublist items.
It's good that Trix won't let me increase indent on a paragraph that doesn't fit its content model. But I need a stronger model for my docs...
Now a quote does allow multiple block content! What happens when I put a quote inside a list and then add sub-lists inside the quote? Madness:
I'd hope the continuous outer / non-continuous inner numbering is just styling bugs and not a crazy model?P.S. A smaller usability issue: how do you make a numbered list with bullet sublist (or vice versa)? Enter->increase indent->switch to bullets works but Enter->switch to bullets leaves me with no option to increase indent. Unnecessarily confusing.
Anyway, lists are why I hate all WYSIWYG with passion as a user. I wish WYSIWYM with explicitly visible structure (cf. TeXmacs) was more popular.
P.S. Squire doesn't seem to allow block content inside lists. Only Shift+Enter linebreaks.
ProseMirror does allow block content (it defaults to markdown content model); continuing the numbered list after non-sublist items required the paste-into-existing-list dance.
Firepad does allow non-item content but doesn't align it like part of the list. It does tend to continue the numbering afterwards, not sure what are its exact rules.
None of this is IMHO satisfactory UX. I've observed many people struggle with lists in any WYSIWYG I've ever seen :-(
Also, sad that it's in Coffeescript.
[1] http://prosemirror.net/
It seems very common to me, over the last several years, to see $NEW_SHINY_EDITOR, and I wonder why.
Are the alternatives that bad? Or is it just a matter of another dev wanting to scratch their own itch?
The readme explains how our approach is different from other WYSIWYG editors. (Most others are just toolbars that call execCommand.)
By the time we first heard of it several months ago, the bulk of Trix had already been written.
Yes, almost all of them have major issues. It's really hard to get something that works with all the main text use cases but can also support images and some basic layout features (like drag/drop, move stuff around, etc).
> Trix is an open-source project from Basecamp, the creators of Ruby on Rails. Millions of people trust their text to Basecamp, and we built Trix to give them the best possible editing experience. See Trix in action in the all-new Basecamp 3.
Nothing gets me more interested in trying out a JavaScript library than seeing that it's used in a mainstream production product, especially a money-making/critical product by very same the company that created/maintains it...it's a bit of guarantee that the API is relatively mature/won't-go-crazy and that someone has a vested interest in keeping the library up to date with changes in the Web. That was why React was so much more appealing to me than Angular, relative to their respective public release dates...React was already in production at Instagram and parts of Facebook, whereas I don't think Angular was in any of Google's main public facing products (i.e. search, YouTube, Maps)
Edit: Nevermind, just saw the edit on the comment below :)
Edit: yes, it's not a Ruby gem. I stand corrected.
If you want to install it with NPM, you could a create pull request with a package.json file and some helpful information for the authors about how to submit to the NPM registry, no?
This is the point of open source software you realise - that you can not just use the software, but that you can help improve it for yourself and others.
Edit: https://github.com/basecamp/trix/pull/32
It's not JavaScript, Trix is written in CoffeScript.
Coffee is just a set of syntactic improvements (well, it's debatable - let's say "syntactic changes") over JavaScript. JS is too weak a language to implement this syntactic sugar inside of it, so there is a need for an external tool. But if you take a look at any Lisp, you'll see that people are building syntactic abstraction inside a language and that it doesn't make their code "a different language compiled to (their kind of) Lisp".
This is not to say that everything compiled down to JS is still JS. But the difference is quite neatly explained in Mathias Felleisen great paper: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.51.4... All that Coffee does are local transformations, equivalent to what you could do with Lisp or Nim or Dylan macros.
[EDIT: removed the "soooo cute" opening sentence, as it was brought to my attention that it distracted readers]
I stopped reading your reply after this. Just FYI, HN doesn't condone bad attitudes. You'll end up getting hell banned.
Having said that, my down-voted comments are factual. They are not incorrect, they were down voted by people who have strong emotions about CoffeeScript.
True or false? All the statements below are true.
Trix is writen in CoffeeScript?
CoffeeScript is not superset or a subset of JavaScript?
Are there other languages that compile to JavaScript?
I don't consider projects written in CoffeeScript JavaScript projects?
I gave simple statements of fact that were not incorrect, and they got down voted and emotional replies.
I edited the post, removing this unfortunate opening sentence. It was intended as humorous, which could have backfired.
> Just FYI, HN doesn't condone bad attitudes. You'll end up getting hell banned.
user: klibertp created: 1159 days ago
That is to say, you don't need to tell me what HN is about.
> They are not incorrect, they were down voted by people who have strong emotions about CoffeeScript.
No. I downvoted you, and I have no attachment to CoffeeScript. I downvoted you because in your earlier comment you wrote that it's "a shame" that Trix is written in Coffee, without any rationale.
> I don't consider projects written in CoffeeScript JavaScript projects?
Here, similarly, you didn't provide any explanation of why do you think that way. Without such an explanation what you wrote would be unacceptable in many other contexts. I won't cite examples, but definitive statements about what something is or isn't in general should be backed by convincing arguments.
---
You not considering CS projects a JS projects is a very debatable opinion. It's nuanced debate and has a great depth. Simplifying it to a simple statement without providing any context looks ignorant at best, and like an ill will at worst. Which is why I reacted.
[EDIT: a bit of wording fixes]
Where did I say that? I didn't say that at all. I'm on my threads page writing this reply to you and a search for shame only brings up your comment so whoever you're quoting isn't me.
Having admitted this much, I'm still waiting for your explanation why you wouldn't "consider projects written in CoffeeScript JavaScript projects". I'd still downvote you for stating such a strong opinion without providing any rationale.
However, the more tags you add to contenteditable elements (i.e. for formatting) the more work the browser has to do every time there's a page reflow and there will be a reflow every time the text changes. So the more formatting, the slower (less responsive) it will be.
The workaround for this (no idea if it's used in this editor) is to divide the document up into lots of individual <div> elements with contenteditable=true and make sure that all outside-the-view elements are removed or at least hidden via 'display: none' and merely re-show them on-the-fly as the user moves about the page. Keeping a page or two above and below the view pre-rendered can help with responsiveness and you'd also have to make sure to pre-fill all the document's unseen space with whitespace so that the user can scroll to any position accurately even if the browser is still retrieving and rendering that portion of the document.
I came very close to implementing such a solution but ultimately decided on something else entirely (server-side rendering and a difference-based terminal update protocol). It's a great idea for an editor and tows the line of, "what we're supposed to be doing" on the web but ultimately it requires a lot of complicated code. Far more complicated that one would think at first glance.
They don't use contenteditable in the traditional way:
> Trix sidesteps these inconsistencies by treating contenteditable as an I/O device: when input makes its way to the editor, Trix converts that input into an editing operation on its internal document model, then re-renders that document back into the editor.
I find this a fine solution.
Did projects prior to being hosted on GitHub require a Code of Conduct or is that a new thing.
This will be a pain to use.
My problem is that I don't want to use them. Unless they use markdown or another simple formatting language behind the scene, and allow you to switch to a simple `<textarea>` input, you can't avoid them.
I already have a text editor, I already have a way to generate "rich" text, I don't need another tool with another set of bindings, quirks, bugs and incompatibilities. Every editor has its own way to deal with very basic stuff: when writing a list what happens if you press return twice? Backspace on an empty element? Tab? You can't know beforehand.
I'm fine with giving tools to non-technical users, but there should be a way to disable such editors completely so it can adapt to any workflow.
From the documentation:
> Eventually we expect all browsers to implement these standards. In the meantime, Trix includes polyfills for missing functionality.
I think you'll find Trix's toolbar easy to style however you'd like, but if not, it ought to be straightforward to implement your own using the API.
What would be useful though, would be an editor that supported "design" and not just text.
About rich text editors, since there are so many editors (even native) that lag on input I have just assumed that is something that only I care about.
EDIT: https://news.ycombinator.com/item?id=10412530
That said, it's kinda sad we need "specialists" to make web content. Maybe we should abandon HTML for a binary format for WWW 2.0 like with HTTP!?
Creating an editor for that does sound like a simple task, doesn't it? Except the tools the browser gives you just don't work, as we've experienced first-hand over the years in the form of customer bug reports.
That's why we built Trix.