Enhanced Shadow DOM Support

Hi @AStoker I don't understand what is the real issue with your example (aside not loading GrapesJS styles inside your shadow dom). If you're attaching shadow dom, obviously, you can't do this container: '#gjs', but you're still able to pass HTMLElements as you're already doing in your example, so what is the issue?

The issue is that I must pass HTML elements everywhere and cannot use selectors. This can become cumbersome to write as I must now use the shadow Dom's query selector for every panel, every element, anything that we hook into GrapesJS. Additionally, if there were the concept of a container, it would significantly help isolate GrapesJS from accidentally interfering with other parts of an application. As more applications make use of components and custom elements, proper isolation between components is important. The fact that GrapesJS automatically pulls in font-awesome (from a CDN too) into the root of the page isn't ideal, as there could very easily be conflicting styles. If you are using Shadow DOM, you could pass the container to GrapesJS and it would put font-awesome within the Shadow DOM, appropriately isolating styles from other parts of the application.

I updated the JSFiddle so you can see what we need to do to get styles within Shadow DOM. But unfortunately the CSS that's automatically added by GrapesJS exists on the body and is both polluting the global stylesheets and pointless due to GrapesJS being inside the Shadow DOM.

Thanks for reporting this, @AStoker.

Great suggestion about FEAT: Enhanced Shadow DOM Support! While this specific feature isn't yet in the core API, there are several ways to achieve similar behavior.

Using the event system:

editor.on('component:update', (component) => {
  // your logic here
});

Alternative approaches:

• Listen to selector:add for CSS selector changes
• Use selector:custom for custom rules
• Tap into the change:* events for fine-grained tracking
• Build a plugin that extends the editor with this capability

Making it official: If this feature would benefit many users, consider opening a formal Feature Request on the GrapesJS repo with:

• A detailed use case
• Code example showing the desired behavior
• Why this matters for your workflow

The core team is receptive to well-motivated feature requests backed by real use cases.