OK I've had a look at the issue register and there have been requests to add shadow DOM support in different capacities, ways, shapes and forms if you would like to call it, for example:
Yes all of them have been closed but with each of those examples above, they have been closed at least 2 years ago and now with support for various technologies such as web components and shadow DOM improving and considering not even sure if v6 is in an early enough stage of development (or if some little tweaks are possible in the context of version 5), I would like to request a feature that allows us to at least have the Javascript plugins supported in the shadow DOM from the onset.
This can be either writing web components that support shadow DOM, or using what Bootstrap has been using, but with shadow DOM in mind or even something we can pass in the config to allow us to change the context of DOM selection to allow us to use the shadowRoot selectors.
Motivation and context will be provided below to give a better understanding, which hopefully forms part of the justification.
Motivation and context
Currently I'm on a project that is using a different UI framework for an app. As part of a UI rebuild we are doing for that app, we are looking to progressively migrating our old UI components/elements to use a new framework that is based heavily on bootstrap as a dependency.
In order for our components to co-exist with the old framework while the migration is going on, we had to resort to using shadow DOM to fence off areas using the old UI vs areas using the new UI.
We sort of are in our initial stages, in this process and just trying out a few things to see how far we can go and see what problems we can encounter.
So far the CSS side has now been resolved and we can use Bootstrap's CSS with the shadow DOM and the REM font sizes will not get affected by the root element using the old framework.
On the Javascript side however, it doesn't seem as straight forward to use the current v5 bootstrap JS plugins.
It seems like many of them still seem to rely on us to add additional event handling ourselves (which may end up not being like for like), and since most of the DOM selection seem to be based on the document scope. Furthermore because of the document scope, some of that code would be kinda dead in the shadow DOM, called to do essentially nothing.
I have a branch of a repo that I used to create the simple initialisation of the Collapse, using javascript to instantiate the collapse instance. (Clone https://github.com/classicmike/stencil-bs-collapse-modules-bug.git and checkout shadowdom-experiment, run npm install then npm run start:dev.
As you can see, none of the simple things such as clicking to toggle collapse works and even the DOM selection methods such as the triggers return empty arrays. Hopefully I haven't caused any bugs.
Then there's also issues like this where the modal hard codes, where the modal seems to have been hard-coded to use the document scope which makes launching modals without any CSS issues impossible. This link should be enough to demonstrate issue: https://github.com/twbs/bootstrap/issues/36918.
Furthermore, there are hints where methods or referenced issues and have been use to support a shadowRoot on a case-by-case basis such as:
So there seems to be some precedent already for Shadow DOM's usage.
Now it's been around 5 years since the last reply on issues related to supporting web components: https://github.com/twbs/bootstrap/issues/28131 and even then feedback seems quite strong and the support for using it is getting better, it might be a good time to re explore this issue and anything related.
Even if the use of web components may be perceived as a 'step too far' here for v6 or v5 for that matter, I would like to see at the minimum, consideration for the shadow DOM context in the javascript plugins so we can use them in use cases like I have explained above.
Hopefully this request is a reasonable one and would be interested to hear what the position would be going forward.
Prerequisites
Proposal
OK I've had a look at the issue register and there have been requests to add shadow DOM support in different capacities, ways, shapes and forms if you would like to call it, for example:
Yes all of them have been closed but with each of those examples above, they have been closed at least 2 years ago and now with support for various technologies such as web components and shadow DOM improving and considering not even sure if v6 is in an early enough stage of development (or if some little tweaks are possible in the context of version 5), I would like to request a feature that allows us to at least have the Javascript plugins supported in the shadow DOM from the onset.
This can be either writing web components that support shadow DOM, or using what Bootstrap has been using, but with shadow DOM in mind or even something we can pass in the config to allow us to change the context of DOM selection to allow us to use the
shadowRootselectors.Motivation and context will be provided below to give a better understanding, which hopefully forms part of the justification.
Motivation and context
Currently I'm on a project that is using a different UI framework for an app. As part of a UI rebuild we are doing for that app, we are looking to progressively migrating our old UI components/elements to use a new framework that is based heavily on bootstrap as a dependency.
In order for our components to co-exist with the old framework while the migration is going on, we had to resort to using shadow DOM to fence off areas using the old UI vs areas using the new UI.
We sort of are in our initial stages, in this process and just trying out a few things to see how far we can go and see what problems we can encounter.
So far the CSS side has now been resolved and we can use Bootstrap's CSS with the shadow DOM and the REM font sizes will not get affected by the root element using the old framework.
On the Javascript side however, it doesn't seem as straight forward to use the current v5 bootstrap JS plugins.
It seems like many of them still seem to rely on us to add additional event handling ourselves (which may end up not being like for like), and since most of the DOM selection seem to be based on the document scope. Furthermore because of the document scope, some of that code would be kinda dead in the shadow DOM, called to do essentially nothing.
I have a branch of a repo that I used to create the simple initialisation of the Collapse, using javascript to instantiate the collapse instance. (Clone https://github.com/classicmike/stencil-bs-collapse-modules-bug.git and checkout
shadowdom-experiment, runnpm installthennpm run start:dev.As you can see, none of the simple things such as clicking to toggle collapse works and even the DOM selection methods such as the triggers return empty arrays. Hopefully I haven't caused any bugs.
Then there's also issues like this where the modal hard codes, where the modal seems to have been hard-coded to use the
documentscope which makes launching modals without any CSS issues impossible. This link should be enough to demonstrate issue: https://github.com/twbs/bootstrap/issues/36918.Furthermore, there are hints where methods or referenced issues and have been use to support a
shadowRooton a case-by-case basis such as:findShadowRoot()method for https://github.com/twbs/bootstrap/issues/24918So there seems to be some precedent already for Shadow DOM's usage.
Now it's been around 5 years since the last reply on issues related to supporting web components: https://github.com/twbs/bootstrap/issues/28131 and even then feedback seems quite strong and the support for using it is getting better, it might be a good time to re explore this issue and anything related.
Even if the use of web components may be perceived as a 'step too far' here for v6 or v5 for that matter, I would like to see at the minimum, consideration for the shadow DOM context in the javascript plugins so we can use them in use cases like I have explained above.
Hopefully this request is a reasonable one and would be interested to hear what the position would be going forward.
Thanks.