The global node for the q-menu, q-select, etc does not work well inside native web components

[vladcosorg]

Describe the bug Sometimes there is a need to isolate the styles and code inside a native web component. In the 3.2 release, Vuejs delivers first class integration with the native web components. I have a need to use some elements (q-select) of Quasar inside one of those web components.

Everything is working very well, except the dropdowns, which are placed OUTSIDE the shadow dom of the component and thus the isolated styles of Quasar are not available there.

Codepen/jsFiddle/Codesandbox (required) https://l9iee.csb.app/ (click on the q-select)

To Reproduce

1. Insert any quasar element that uses a popup inside a shadow dom
2. Scope the quasar styles only to that component
3. See that the quasar element is property styles
4. See that the popup of that element does not have style

Expected behavior The popup should have styles as well

Platform (please complete the following information): Quasar Version: 2.0.4 on:

Quasar mode:

• [x ] SPA
• [ ] SSR
• [ ] PWA
• [ ] Electron
• [ ] Cordova
• [ ] Capacitor
• [ ] BEX

Tested on:

• [ x] SPA
• [ ] SSR
• [ ] PWA
• [ ] Electron
• [ ] Cordova
• [ ] Capacitor
• [ ] BEX

Additional context The problem is here https://github.com/quasarframework/quasar/blob/78df1f4939936fdbf591d90addf950a8f42e665b/ui/src/utils/private/global-nodes.js#L6

Inside a shadow dom, document.body should not be used

[vladcosorg]

I realise it is a narrow use case, but hopefully native components would start getting traction soon!

[pdanpdan]

Sorry, it can't be done. The popups are added at the end of the body so that they are the last in Dom (for z-index) and outside any parent that can have overflow restrictions. So they cannot work inside components, except if the component is Fullscreen

[vladcosorg]

I understand what you mean, it cannot be done reliably for native component users - that is true. Sure, there may be issues with the overflow and z-index - for those that are using it inside the native web components, but that is usually easily fixable and much better then it is now when the popups are not working at all.

I have made a few changes in quasar to make it work: If the element that requires the popup is inside the shadow dom, then place the popup node in the topmost position in the shadow dom, otherwise, use document.body as usually.

So there is no possible degradation for common users, it would work as it is now, just extra handling for this edge case.

Hope you reconsider, if not, no worries and thanks for your time!

[pdanpdan]

Can an element that is inside the shadow dom of a native component be rendered outside the visible area of the native component (honest question)? Or in your case the native component is big enough to have the dialogs/menus inside?

[LukaszKiedrowski]

@pdanpdan Solution suggested by @chetzof would be very helpful also for me because I have the same problem. It won’t break anything and just give possibility to specify web component as parent element instead of body 👍

[pdanpdan]

Yes, but my question is still valid. It would help if you can provide a repo where you are using it as a native component, so that I can play with it?

[LukaszKiedrowski]

Yes, but my question is still valid. It would help if you can provide a repo where you are using it as a native component, so that I can play with it?

@pdanpdan

solution is in the link provided by @chetzof https://l9iee.csb.app/ in the bug's description. You can use browser's inspector to move q-menu directly to web component or to change styles. As you can see in the attached images:

1. current behavior - q-menu is outside web component - styling is not working correctly.

2. once I move node to web component then styling is working correctly
3. also you can see that node which is inside web component(which is not full screen) can easily overlap whole screen and all other components.

[pdanpdan]

Sorry, I somehow missed the link on the first post. But I still cannot see how this might work for the whole framework - because there are lots of things that depend on the html or body elements (classes mainly). I'll reopen - maybe someone has an idea.

Hmm, dialogs also work :D

[LukaszKiedrowski]

@pdanpdan generally I see 3 main problems:

1. Regarding elements like q-select, q-menu and q-dialog - it would be good that you can provide property "wrapper" to those elements so you can override default body selector.

2. For global styles attached to body - you can create scss mixin so if you are using Quasar inside web component then you can use this mixin on the web component's root element.

3. Other problem is that Quasar append some classes to body element - e.g. "desktop" - it should be possible to pass base page selector(default body) while you init Quasar.

[cyfung1031]

For global node,

I would suggest to add a unique class "q-root" for the root container (i.e. the <div> under <body> in the current design) and change all relevant css from body xxxx > xxxx { ... } to .q-root xxxx > xxxx { ... }

In practice, web native component is still developing and thus ui components shall not use open shadow-root. You can find this technology is not commonly used in Google/Facebook/Youtube/Github... etc. This is for completely native component with pure js and pure css - eg <video> and <audio>

[craigrileyuk]

I'm hitting this as an issue too.

I'm using Quasar as a Vite plugin since I want to package it as an app that can be displayed into a variety of existing web pages (with their own stylesheets that can't be messed with).

So far, my process to deal with the styling issues are:

1. Set Vite's build mode to library and output all the CSS to file and then injecting a to the css into the Shadow DOM.
2. Using rollup-plugin-search-and-replace, swap out :root for :host to get the CSS variables working
3. Run a MutationObserver to match the document.body classes with the root element in the ShadowDOM.

My one remaining problem is the teleported overlay elements. Which would be solved by being allowed to pass an override for using document.body as the root element.

I know there may be some display issues with suboptimal z-indexing, but right now, it just doesn't work... which is surely worse.

[zhuyifang]

this is my suggestion https://github.com/quasarframework/quasar/discussions/13575

In fact, as a framework, there is no need to use body or shadow dom. In fact, for components that rely on body as the root node: dialog, menu and other components, a configuration can be provided, that is, the root node of these global components

Because using umd development mode, or my current method (chrome plug-in, injecting all web pages in DOM), will cause a lot of unnecessary troubles, and the cost of solving these troubles is not high, and at the same time It can make him more introverted (less chance of polluting the overall situation) @chetzof

[timsayshey]

There have been no comments on this since May. There is also a rotting pull request that added support for this. Is the Quasar team not open to support modern technology like Web Components?

[craigrileyuk]

Apparently not.

Giving us a completely opt-in option to overwrite default behaviour is apparently unworkable because it would only work 95% of the time as opposed to 0% of the time.

[doncatnip]

I am facing the same issue. My use-case being a Wordpress plugin. I's messy 90s tech, but unfortunately still widely used, which is why I was hoping to be able to write elementor-controls and widgets as isolated web components. It does work very well until I hit the wall with q-select.