When the Host Page's CSS Reaches Into the Editor's Dialogs

You opened the color picker during the release demo to show department heads what the new composer could do. It came up red with a teal border, the portal's own alert-box colors, not the editor's. Nobody on the call had touched that dialog's styling.

The Toolbar Dialog That Turned Portal Red

The HR team at the intranet portal embeds Synap Editor as the composer for policy announcements. Every release gets a demo in front of department heads before it reaches the rest of the company.

When the presenter opened the color picker for that demo, it came up in red and teal instead of the editor's own look. The portal's stylesheet carries a rule written for its own alert boxes. It sets a red background and a teal border three pixels thick, both marked important.

That rule targets a CSS class called se-external-container, the same class the editor's dialogs, balloons, and color picker render inside. The portal's rule does not distinguish between its own alert boxes and the editor's popups.

Why the Host Page's CSS Reaches the Editor's Popups

Synap Editor's dialogs, balloons, and tooltips are not sealed away from the page around them. By default, they render as part of the same document the portal's HR pages use. A CSS rule that targets any element in that document can reach them, intentionally or not.

The portal's alert-box rule was never written with the editor in mind. It was written to catch anything carrying the se-external-container class, and the editor's popups happen to carry it too. The browser cannot tell the difference between a popup the portal meant to style and one it did not.

What Actually Keeps the Host Page's Styles Out?

Synap Editor has two ways to seal that boundary. Shadow DOM gives the editor's external dialogs, balloons, and tooltips their own closed style environment, one the host page's CSS cannot see into or repaint. Nothing written for the portal's own alert boxes can reach inside it.

Iframe mode goes further. It puts the editing area inside its own document and its own window, not just its own style scope. A rule or a script written for the host page has no path into it at all.

The Dialog Opens in the Editor's Own Colors

With Shadow DOM turned on, the same color picker dialog in the same demo opens in the editor's own colors. No red background, no teal border. The portal's alert-box rule still exists on the page, but it has nothing to reach.

The dialog's container now renders inside its own Shadow DOM, sealed off from the portal's stylesheet in both directions. The portal's CSS cannot repaint it, and the editor's own styling cannot leak out into the rest of the page either.

[[shot: The color picker dialog open in the editor's own gray and blue interface, with the portal's red-and-teal alert styling visible elsewhere on the page but absent from the dialog]]

At the next release demo, the department heads see the same dialog they saw before Shadow DOM was on, minus the colors nobody meant to put there. There is nothing to explain about the dialog anymore.

How to Turn On Shadow DOM and Iframe Mode

Three settings turn this on.

// synapeditor.config.js
'editor.external.container.enableShadowDOM': {
  enable: true,
  'style.urls': [
    'url of synapeditor.min.css',
    'url of externalStyle.css'
  ]
}

Seals the external dialogs, balloons, and tooltips inside their own Shadow DOM, out of reach of the host page's CSS.

// synapeditor.config.js
'editor.mode.iframe': {
  'enable': true,
  'style.urls': ['../dist/iframeMode/contentsEditStyle.css'],
  'script.urls': ['../dist/iframeMode/SEPolyfill.min.js']
}

Runs the editing area inside its own document and window, isolating scripts and globals along with styles.

{
  'editor.popup.preventOverflow': true
}

Stops popups from overflowing past the editor's bottom-right edge, without isolating them from the host page's CSS.

The manual covers the rest: the full style.urls list, the iframe script requirements, and how pasted content behaves once isolated.

Common questions

Does Shadow DOM isolate the whole editor, or only the external dialogs, balloons, and tooltips? Only the external dialogs, balloons, and tooltips. Shadow DOM wraps the external container where those popups render, not the editor's main editing area.

If I enable Shadow DOM but forget a plugin's CSS file in style.urls, what breaks? Shadow DOM blocks CSS inheritance from the host page entirely, so nothing outside style.urls reaches it. If a plugin's CSS file is missing from that list, that plugin's dialog or tooltip renders without its styling.

Does Iframe mode isolate the editor's scripts and globals too, or only its styles? Both. Iframe mode gives the editing area its own document and window, so it isolates scripts and globals along with styles, not styles alone.

If neither Shadow DOM nor Iframe mode fits, can popups still be kept inside the editor's own box? Yes. Setting editor.popup.preventOverflow to true stops popups from overflowing past the editor's bottom-right edge, though it does not stop the host page's CSS from reaching them.