3 ms·

Looks decent. The approach taken is the right one: we do something very similar with the Squire rich text editor (https://github.com/neilj/Squire https://github

Looks decent. The approach taken is the right one: we do something very similar with the Squire rich text editor (https://github.com/neilj/Squire https://github.com/neilj/Squire) which I wrote for FastMail's webmail. Basically the browser can't be trusted to do any formatting itself, which is a slightly depressing state of affairs, especially as there has been zero improvements in this area for the last 5 years. I guess it's not shiny enough for browser devs to focus on. Looking through the code, a few things jumped out that should be looked at: * Native TreeWalker implementations are buggy in some browsers. In the end we decided it was safer to just implement the bit we needed ourselves (see comment at top of https://github.com/neilj/Squire/blob/master/source/TreeWalker.js https://github.com/neilj/Squire/blob/master/source/TreeWalke...). * The HTML sanitisation using document.implementation doesn't account for DOM clobbering so is currently bypassable with the right malicious content. I recommend using https://github.com/cure53/DOMPurify https://github.com/cure53/DOMPurify for this rather than writing your own. It's tricky to get all the edge cases right, so better to use something that's been reviewed by several people (and in DOMPurify's case also undergone a formal security review). Again, we use this at FastMail as part of our webmail.

seagreen 11y ago
Can you elaborate on not being able to trust the browser for formatting? Is the idea that web developers should just be able to use <textarea> and not have to think about it beyond that, and that browsers should provide solid default <textarea> editor?
- nmjenkins 11y ago
  I mean things as simple as bolding a piece of text. The way to get the browser to do this for you is to using the document.execCommand method, but the results are inconsistent between browsers. Worse than that though is stuff like hitting "enter" on the keyboard – all sorts of crazy stuff happens (new <span> tags being added, nothing consistent between browsers, generally doesn't do what you want). We came to the same solution the guys at Basecamp have: you generally can't trust the browser to get you from state A -> B and have to do it yourself. Probably the hardest thing to do is handle copying and pasting, partly because most browsers give you very little control over this, so you have to resort to terrible hacks. You also have to decide how much of the formatting in the clipboard item was "intentional" and how much should be cleaned. I see if you copy/paste just a word from within Trix, it pastes it as a whole block with the block's formatting around it. I suspect this may surprise many users who expect it just to copy the word (the inline bit, not the block around it in editor parlance). Once you start going down this rabbit hole, you end up having to do things like take one DOM tree and recursively merge the "edges" with the adjacent trees to get it to behave as the user expects. I think we do a pretty decent job with Squire, but I'm sure there are still more edge cases we haven't covered.
hasenj 11y ago
Awesome! I love how Squire has support for setting text direction (ltr/rtl). This has always been a huge beef for me with web-based rich text editors!

seagreen 11y ago

Can you elaborate on not being able to trust the browser for formatting? Is the idea that web developers should just be able to use <textarea> and not have to think about it beyond that, and that browsers should provide solid default <textarea> editor?

nmjenkins 11y ago
I mean things as simple as bolding a piece of text. The way to get the browser to do this for you is to using the document.execCommand method, but the results are inconsistent between browsers. Worse than that though is stuff like hitting "enter" on the keyboard – all sorts of crazy stuff happens (new <span> tags being added, nothing consistent between browsers, generally doesn't do what you want). We came to the same solution the guys at Basecamp have: you generally can't trust the browser to get you from state A -> B and have to do it yourself. Probably the hardest thing to do is handle copying and pasting, partly because most browsers give you very little control over this, so you have to resort to terrible hacks. You also have to decide how much of the formatting in the clipboard item was "intentional" and how much should be cleaned. I see if you copy/paste just a word from within Trix, it pastes it as a whole block with the block's formatting around it. I suspect this may surprise many users who expect it just to copy the word (the inline bit, not the block around it in editor parlance). Once you start going down this rabbit hole, you end up having to do things like take one DOM tree and recursively merge the "edges" with the adjacent trees to get it to behave as the user expects. I think we do a pretty decent job with Squire, but I'm sure there are still more edge cases we haven't covered.

hasenj 11y ago

Awesome! I love how Squire has support for setting text direction (ltr/rtl). This has always been a huge beef for me with web-based rich text editors!