I have done extensive research in this area as well - my code is used in production by 100,000 users, by another company. I personally always choose to go with direct contentEditable without an iframe. It makes things much easier.

However, what the author did not mention was security. My assumption as to why the company that uses my code, still uses it inside an iframe, is to prevent accidental XSS injection from when their user's copy and paste content (sometimes with javascript embedded in it) into the editor. So be careful about that.

Another recommendation I have, is to NOT use execCommand.

Why not use execCommand?

I haven't used execCommand in a while but I think it adds a bunch of font tags. Also different browsers will use different tags for "bold" for example (<b> vs <em>) leading to inconsistent markup. Easier to just decide the tags and insert them yourself.

I built a demo, for a rich text editor, for fastmail.fm. The editor is called Squire (http://neilj.github.io/Squire/) and designed for essays, emails, longforms ect. Squire uses contenteditable within an iframe. However, the editor replaces all the functionality of content editable to create a higher level of compatibility across browsers.

Thanks for your article, I really enjoyed it. Matt (http://www.matthewbordenweb.com/)

I wonder what he thinks of eg, https://medium.com/medium-eng/why-contenteditable-is-terribl...

I couldn't find any good editor without iframe which provides delta save + content versioning. So I built one - Smalleditor (http://jdkanani.github.io/smalleditor) - it is similar to Medium's editor but with contenteditable.

> The most discussed benefit of iframes is separation from other styles and scripts on the web page.

I would love to hear your plans to overcome this as it is pretty much a hard requirement for any editor integration.

I have run into this and was quite hopeful about <style scoped> but browser support leaves much to be desired.

This issue was a huge problem for me for a few years. For Populr (https://populr.me), we created an entire theming system for our users. That, of course, means users could write css that would override our interface, since page editing is truly wysiwyg on Populr. To get around this, we actually split the display of the page and the editor up. The page is displayed in an iframe, with the theme's styles, and almost all of our editor is overlayed on top of the iframe. It get's kinda crazy at times, but it works pretty well.

Now, on a new product we are developing, We are taking the opposite approach. For TouchStream (https://touchstreamapp.com), we needed a rich text editor for users to edit their emails. We went with Redactor (http://imperavi.com/redactor/) for the editor. However, Redactor is a contenteditable editor, so it was inheriting a bunch of styles from our interface. Not exactly what you want when editing emails. In this case, I used a modified version of Cleanslate (http://cleanslatecss.com/) to reset all of the elements within the contenteditable to their browser defaults. It's not perfect, but I got it pretty close. It's the best you can probably do until scoped styles become more prevalent.

Edit: to be fair, Cleanslate is more of a polyfill for a combo of the css keywords "initial" and "unset".

I was wondering this as well - would be interested in the answer.

Years since I've really dabbled in WYSIWYG editing JS, but the best I can think of us to use a reset CSS file namespaced for the `div` (or whatever container) in question.

Yup that's more or less the only way I have seen in the wild.

The Scoped Polyfill https://github.com/PM5544/scoped-polyfill does just this and gets you most of the way there.

> It does so by prepending the styleRules selectorText with id's

I got to choose which text editor we implemented in a large project a while ago and we ended with Quill, because of its easy customisation and contained feature set. The latter was a bonus for us, as we had to do much less checking for users adding breaking code to the page.

I do not envy rich text editor authors one bit. Even implementing them has an unreasonable amount of gotcha's when you dive into getting your page and the iframe/editor to communicate effectively.

I'm looking for a simple text editor for a side project. I hacked something together with contenteditable, but am quite frustrated with it for various reasons.

Recommendation for a simple text editor that doesn't get in the user's way?

Try looking into Scribe. They describe it as:

> A rich text editor framework for the web platform, with patches for browser inconsistencies and sensible defaults.

https://github.com/guardian/scribe

I went through a number of them and ended up settling on TinyMCE.

I've been using QuillJS for half a year now and love it

I wished there was a good RTE implementation that supported custom classes but still worked with undo/redo like content-editable.

And... Yet another website that refuses to display plain text without JS. Progressive enhancement. It's not rocket science.

The page doesn't even seem to be loading content via Ajax.So it's likely the content is hidden with Css when the page loads, to make that fade-in effect. I think it's silly,the effect is totally unnecessary.