Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider shadowdom #2007

Open
voidus opened this issue Sep 23, 2024 · 6 comments
Open

Consider shadowdom #2007

voidus opened this issue Sep 23, 2024 · 6 comments

Comments

@voidus
Copy link

voidus commented Sep 23, 2024

Heya,

Context:
I've been experiencing some issues with application css messing up the toolbar.

Putting the component into a shadowdom would fix this issue, and since ddt doesn't interact with the rest of the page it would be a good fit I think.

A comparatively simple approach would be declarative shadow dom using something like this:

<div id="djDebug" ...>
  <template shadowrootmode="open">
    <link rel="stylesheet" ...>
    ...
  </template>
</div>

The main div still needs to be positioned in the context of the page, but the stuff inside the template would be shielded from the outside css.

Since ddt also uses some javascript, maybe a custom element might be a good call. Here's an example inspired by https://web.dev/articles/declarative-shadow-dom

<django-debug-toolbar>
  <template shadowrootmode="open">
    <button>
      <slot></slot>
    </button>
  </template>
  Open Menu
</django-debug-toolbar>
<script>
  class DjangoDebugToolbar extends HTMLElement {
    constructor() {
      super();

     // Do all the javascript stuf here, `this` is the django-debug-toolbar element
     // and this.shadowRoot is already set up.
    }
  }
  customElements.define('django-debug-toolbar', DjangoDebugToolbar);
</script>

I was thinking about this and didn't find anything, so I thought I'd start a discussion about this here.

@matthiask
Copy link
Member

I think this is an excellent idea. I'm not sure if the impact on third party panels would be so bad as to make it not worth it, but apart from that I don't immediately see any problems with this approach. It would indeed help us be shielded from site CSS and JS more.

@tim-schilling
Copy link
Member

@voidus How would this work with our additional JS modules?

I'm a bit worried about the browser support for this (right now). 2 users out of 100 wouldn't be able to use this according to caniuse.

@matthiask
Copy link
Member

I wonder what those browsers are? Shadow DOM is definitely supported not only in recent browsers.

How would this work with our additional JS modules?

As long as we're using an open Shadow DOM it shouldn't impact those modules at all, unless I'm mistaken. We would have to take care that CSS is loaded inside the Shadow DOM and not outside it to affect the toolbar, but that's what we would want anyway.

To clarify, I'm not sure it's doable and/or useful enough for the potential downsides, but I can see a few upsides to using Shadow DOM.

@tim-schilling
Copy link
Member

Alright, sounds good. I'm onboard. @voidus is this something you're interested in implementing for the library?

@voidus
Copy link
Author

voidus commented Oct 17, 2024

I've been thinking about doing a prototype, but to be completely honest, like most people probably are, I am a bit overloaded recently. I'm not really comfortable to commit to anything right now.

Edit: A naive 5-minute attempt broke some stuff, so it's not completely trivial, but I didn't have time to look into it at all.

@tim-schilling
Copy link
Member

All good! The toolbar will be here whenever you're more available.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants