Q:

why are iframe-s so useful in HTML5 WYSIWIG applications?

<iframe> elements are documented as

The HTML Inline Frame Element (<iframe>) represents a nested browsing context, effectively embedding another HTML page into the current page.

However, most WYSIWYG editors HTML5 frameworks (such as tinymce, Aloha, Maqetta, etc...) are using a lot <iframe> but they intuitively do not need a new nested browsing context... (the canonical example of <iframe> is to show another website, but all the WYSIWYG editors in HTML I heard about are usable on the same website).
So why is <iframe> so important in that case? We know that contenteditable is terrible (so is probably not enough for WYSIWYG editors in HTML5).
(I guess it is related to event handling & capturing & bubbling, but I don't understand the relationship with <iframe>s)
PS. This SO question gives the motivation and the context of my question, and this one explains why contenteditable is disappointing for me.

A:

Isolation
By having the editor inside an iFrame it is guaranteed to be isolated from the page it is used in. The containing page can have Javascript, CSS, HTML tags,... that might interfere with the editor if it is not in an iFrame because they might 'bleed into' it. The editor would need to set css styles for every possible element to make sure that the styling from the containing page does not bleed into it and get applied where it does not make sense. This is simply not possible.
It also works in the other direction: even if the markup of the editor itself becomes corrupted, using an iFrame means that the content of the editor can be broken, but not the editor itself. If you use the editor for a blog you don't want a broken post to completely kill your ability to edit the broken post. If the editor's save button breaks you lose any and all ability to remove the content.
That is not to say a targeted attack could not break the WYSIWYG editor as there are still ways you can interfere with an iFrame's contents...

