Issue integrating Mosparo with Lit Element due to Shadow DOM encapsulation

[Crooks2k]

Hi Mosparo team,

I'm currently working on integrating Mosparo into a web application built using Lit Element heavily on the use of Shadow DOM for encapsulating component structure and styles.

While trying to include Mosparo's spam protection in a form rendered inside a Lit component, I noticed that Mosparo does not detect or apply its logic to the form fields or the #mosparo-box container when they are inside the component's shadow root.

However, if I expose the form and the Mosparo container to the main DOM using innerHTML, Mosparo works as expected and applies its logic correctly.

Problem Summary:

• Lit Element renders form fields inside a shadow root.
• Mosparo does not seem to detect or interact with elements inside the shadow DOM.
• The #mosparo-box div is not found by Mosparo when inside the shadow root.
• Exposing the form and Mosparo container to the main DOM resolves the issue, but breaks encapsulation and is not ideal for component-based architecture.

Questions:

• Is there a recommended way to integrate Mosparo with frameworks that use Shadow DOM?
• Could Mosparo support querying inside shadow roots in future versions?
• Are there any known workarounds or best practices for this kind of integration?

Any guidance or suggestions would be greatly appreciated. I’d be happy to provide a minimal reproducible example if needed.

Thanks in advance!

[zepich]

Hi @Crooks2k

Thank you very much for describing your problem and use case!

It's a very interesting one. I want to be open: I don't have a lot of knowledge about Shadow DOM (yet). It would be great if you could provide an example that reproduces the issue and helps us find a solution.

Regarding your questions:

• Is there a recommended way to integrate Mosparo with frameworks that use Shadow DOM?

I haven't tried it yet, so I don't have a working solution at the moment.

• Could Mosparo support querying inside shadow roots in future versions?

Yes, that's certainly possible (if technically feasible). We want to support any possible setup/integration that we can, so we have no reason not to support such a use case. We need the idea/request (what you did by starting this discussion) and some help/feedback from professionals like you, which can help us do the right things.

• Are there any known workarounds or best practices for this kind of integration?

Currently, the only workaround I see is to copy our mosparo-frontend.js file (https://github.com/mosparo/mosparo/blob/master/assets/mosparo-frontend.js) into your website and adjust it to meet your needs. The file has no dependencies, so it should be straightforward to copy it. You would need to update it when we release a new version and make changes to it.

There is a callback to collect the form data when the user checks the form (which is likely one of the problems you mention that mosparo cannot find the form elements in the shadow DOM), so you could set the form data manually with the callback. However, the entire initialization is not compatible with the shadow DOM, as far as I understand right now, so the only solution for that is to copy and adjust the file as mentioned above.

I'm looking forward to your example and appreciate your idea.

Kind regards,
zepich

[Crooks2k]

Hi @zepich,

Thank you very much for your detailed response and for being so open about your Shadow DOM knowledge! I really appreciate your willingness to explore this integration and your practical suggestions.

What is Shadow DOM?

Since you mentioned you'd like to learn more about Shadow DOM, let me provide some context:

Shadow DOM is a web standard that provides encapsulation for DOM trees and styling. It's a core technology behind Web Components and is used by modern frameworks like Lit Element, Stencil, and even native browser elements (like <video> controls).

Key characteristics:

• Style encapsulation: CSS styles inside a shadow root don't leak out, and external styles don't leak in
• DOM isolation: JavaScript queries like document.getElementById() cannot access elements inside shadow roots
• Scoped rendering: Each shadow root creates its own isolated DOM subtree

The Problem in Practice

Here's a concrete example of why Mosparo doesn't work with Shadow DOM using Lit Element:

class MyForm extends LitElement {
  firstUpdated() {
    // This fails because Mosparo looks in global DOM
    new mosparo('mosparo-box', host, uuid, publicKey);
  }

  render() {
    return html`
      <form>
        <input name="email" type="email" required />
        <div id="mosparo-box"></div>
        <!-- This is inside Shadow DOM -->
        <button type="submit">Submit</button>
      </form>
    `;
  }
}

When Mosparo executes document.getElementById('mosparo-box'), it can't find the element because it's encapsulated inside the component's shadow root, not in the global DOM.

Following Your Recommendation

Based on your suggestion to copy and modify the mosparo-frontend.js file, my team and I have decided to work on a custom Shadow DOM-compatible version of Mosparo. We're currently developing this implementation using the file you provided.

Our Development Approach

We're modifying the key areas that cause Shadow DOM incompatibility:

1. Container detection: Instead of document.getElementById(), use the shadow root context
2. Form discovery: Replace document.querySelectorAll('form') with shadow root queries
3. CSS injection: Inject styles into the shadow root instead of global <head>

Proposed Solution

Our approach involves modifying the constructor to accept either:

• A string ID (current behavior - fully backward compatible)
• A ShadowRoot reference (new Shadow DOM functionality)

// Current usage (unchanged)
new mosparo('mosparo-box', host, uuid, publicKey, options);

// New Shadow DOM usage (what we're implementing)
new mosparo(shadowRootElement, host, uuid, publicKey, {
  containerId: 'mosparo-box',
  ...options,
});

Working Example

Here's how it would work in our Lit Element component:

class NequiLoansBanner extends LitElement {
  firstUpdated() {
    // Pass shadowRoot directly to mosparo
    this.mosparoInstance = new mosparo(
      this.shadowRoot, // ← Shadow DOM context
      'https://our-mosparo-instance.com',
      'our-uuid',
      'our-public-key',
      { containerId: 'mosparo-box' }
    );
  }

  render() {
    return html`
      <form>
        <input name="email" type="email" required />
        <div id="mosparo-box"></div>
        <!-- Now accessible within shadow root -->
        <button type="submit">Submit</button>
      </form>
    `;
  }
}

Future Collaboration Opportunity

Once we complete and thoroughly test our Shadow DOM implementation, we'd be very interested in sharing it with you to evaluate the possibility of integrating it into the official Mosparo project.

This could benefit the entire Mosparo community by:

• Supporting modern Web Component frameworks (Lit Element, Stencil, Angular Elements)
• Maintaining 100% backward compatibility with existing implementations
• Providing native support for component-based architectures
• Eliminating the need for developers to maintain custom file copies

Would you be open to reviewing our implementation once it's ready? We believe this could be a valuable addition that would help many developers working with modern web technologies.

Thank you again for your guidance and for being so receptive to exploring this integration!

Best regards,
@Crooks2k

[zepich]

Hi @Crooks2k

Thank you very much for your detailed answer and the details about Shadow DOM!

The adjustment you and your team make sounds good, but I suggest keeping the box ID as the first argument in the function and using an option to define the 'container'. Something like

new mosparo(
      'mosparo-box',
      'https://our-mosparo-instance.com',
      'our-uuid',
      'our-public-key',
      { container: this.shadowRoot }
);

This way, we do not entirely change the API but offer the same functionality. The code's functionality would check if container is set. If yes, use the container to search the mosparo box element; otherwise, use document.

Once we complete and thoroughly test our Shadow DOM implementation, we'd be very interested in sharing it with you to evaluate the possibility of integrating it into the official Mosparo project.

Would you be open to reviewing our implementation once it's ready? We believe this could be a valuable addition that would help many developers working with modern web technologies.

Yes, of course! That you have to copy and adjust the file is just a workaround. It's not a practical solution, since when we change anything in this file, you have to make the same change; otherwise, mosparo will not work anymore.

It would be great if you could provide a small example with LIT components (for example) with which I can reproduce the issue by myself (if you find time for that).

Future development

I think it would make sense to adjust the function so that you can also pass an element as the first argument for the mosparo box element. With the option to specify the container element in the options, it's possible to set two elements instead of IDs. This gives the developer better control of which elements are used.

new mosparo(
      document.getElementById('mosparo-special-box'), // or 'mosparo-box'
      'https://our-mosparo-instance.com',
      'our-uuid',
      'our-public-key',
      { container: document.getElementById('contact-form') } // or this.shadowRoot
);

Thank you very much for your support and feedback!

Kind regards,
zepich