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

  • Perhaps because it serves as a css reset. – CodesInChaos Nov 12 '15 at 14:18
  • Could you explain that "css reset" a bit more, please? – Basile Starynkevitch Nov 12 '15 at 14:19
  • Since the editor has full control over the content of the iframe, no javascript or css defined by the website will interfere with its function. (It's probably possible to use Shadow DOM to achieve a similar effect, but that's rather newfangled.) – CodesInChaos Nov 12 '15 at 14:20
  • 1
    @BasileStarynkevitch CSS styles from the parent page don't bleed into iframes. – Juan Mendes Nov 12 '15 at 14:24
  • Here's a guess (CodesInChaos guess is also valid): iframes can be set to designMode=true and there may be some quirks that work better with designMode? Maybe a combination of both? – Juan Mendes Nov 12 '15 at 14:32


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

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.