Hi @zack , and sorry for the delay regarding this issue!
You are right that ideally, those 3 CSS rules should have been implemented in a more targeted way to avoid any conflicts. It should be fixed in the next version of tangible-blocks
The reason why those 3 problematic rules have been initially implemented that way is that we have to apply them for elements that are placed outside of the module setting form ( .fl-builder-module-settings), for elements that are placed as an immediate child of <body>
It happens in 2 different cases:
- For the select2 dropdown element
- For our modal element
Two of the three rules you mentioned apply to the select2 dropdown:
.fl-builder-edit span.select2-container {
z-index: 9999999999;
}
.fl-builder-edit span.select2-container.select2-container--open {
z-index: 9999999999;
}
The reason why the selector is so broad is linked to how the select2 library creates its drop-down element. From the select2 documentation:
By default, Select2 will attach the dropdown to the end of the body and will absolutely position it to appear above or below the selection container.
As the drop-down list will be added as a direct child of <body>, any wrapping class around the element used to initialize the select2 can’t be used as a selector for the dropdown element, and only classes that are on <body> or above can be used to select it
The select2 documentation mentions a dropdownParent option that we could use to place the dropdown somewhere else in the DOM, but as this control is already legacy and that it might create issues/unexpected behavior, we probably won’t try to implement it
Instead, we will now conditionally add/remove classes on <body>, and use them in the selector, which should prevent any conflict in the future
If I remember correctly, the other CSS rule (which seems to be the most problematic one) was initially needed because without it, select2 elements inside our modules were not initialized with the correct size/placement:
.fl-builder-edit select {
width: 100%;
max-width: 100%;
min-height: $modal-select-height;
}
I believe the reason why the selector was also very broad in that case is that we needed to add that fix on both regular select2 controls (inside .fl-builder-module-settings), and inside modals (when used inside the post-query control)
Our modal is also created as a direct child of <body> (because like for the select2 dropdown, it needs to use a position: absolute; inside <body> to be placed correctly). However, we could (and should) have targeted it more efficiently in that case, as it was possible to use the modal container class in the selector
Anyways, in my testing it seems that this third CSS rule is not needed anymore with the most recent version of beaver-builder (regardless of if the new “Responsive Iframe UI” is used or not), so I guess we will simply remove it in the next version of tangible-blocks
it’s just our standard identifier for content created in L&L or Blocks.
