Live data from Hacker News

Trix: A rich text editor for everyday writing

github.com

81–90 of 137 posts

Re: Trix: A rich text editor for everyday writing

#81

Earlier quoted context omitted.

It is not impossible. It just takes a lot of time and effort. It took two developers around 18 months to build Trix. The readme explains how our approach is different from other WYSIWYG editors. (Most others are just toolbars that call execCommand.)

Did you look at ProseMirror? http://prosemirror.net/

Yes, of course we've seen ProseMirror. It looks quite nice.

By the time we first heard of it several months ago, the bulk of Trix had already been written.

Re: Trix: A rich text editor for everyday writing

#82
post #62

Earlier quoted context omitted.

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 wit…

'contenteditable is inconsistent across browsers'. We (the Guardian) created Scribe to tackle this: https://github.com/guardian/scribe (I can't take any credit personally though alas!)

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.

Re: Trix: A rich text editor for everyday writing

#83
post #30

What is the computational complexity of inserting a character into a text containing N characters, using this editor?

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…

http://trix-editor.org/

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.

Re: Trix: A rich text editor for everyday writing

#84

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.

Re: Trix: A rich text editor for everyday writing

#86
This is totally off topic, but the first thing I thought of when I read "Trix" was: "Silly rabbit, Trix are for kids!" Anyone else?

On topic: Thanks, Basecamp. I like the minimalism and focus on function of this project. Contenteditable approaches to formatting text needed some love. I look forward to trying this out in my next project.

Re: Trix: A rich text editor for everyday writing

#87
post #61

It breaks Pentadactyl external editor feature as every other WYSIWYG editor do. This will be a pain to use.

If EVERY WYSIWYG editor is breaking the plugin. Maybe it's the plugin that is broken not the editors? Just a thought.

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 `` 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.

Re: Trix: A rich text editor for everyday writing

#88
post #73

I don't get these simplistic editors. You just have to learn ten HTML tags to do the formatting these editors offer. What would be useful though, would be an editor that supported "design" and not just text.

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.

That's why we built Trix.

Re: Trix: A rich text editor for everyday writing

#89
post #62

Earlier quoted context omitted.

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 wit…

'contenteditable is inconsistent across browsers'. We (the Guardian) created Scribe to tackle this: https://github.com/guardian/scribe (I can't take any credit personally though alas!)

We are using Scribe for our product and we are happy with it. It lacks some documentation but it's solid.

Re: Trix: A rich text editor for everyday writing

#90
post #80
post #73

I don't get these simplistic editors. You just have to learn ten HTML tags to do the formatting these editors offer. What would be useful though, would be an editor that supported "design" and not just text.

hahaha… oh god. This place is such an echo chamber…

Is "what would be useful is an editor that supports design" an echo chamber? Mightbe pretty hard to do right, but not an ordinary idea.

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.

Post reply on HN