Overly broad CSS selectors being loaded by Tangible Blocks in BB Editor

There are some overly broad CSS selectors being loaded by Tangible Blocks in BB Editor:
Screen Shot 2023-01-10 at 10.33.54

Specifically the select one is causing issues with the new BB alpha version in the new responsive editor:
Screen Shot 2023-01-10 at 10.25.48

My request is for two things:
1 - make these more specific to your module with a Tangible class
2 - related to #1, make the classes on your module better (so you AND we can target them with css better). The classes currently look like this on the module settings window:

(in the settings window)
fl-builder-tangible-module-c805d3cede4844909dff0a8307a9096a-settings

(on the frontend)
fl-builder-tangible-module-c805d3cede4844909dff0a8307a9096a

It would be better for everyone if they were something like .fl-builder-tangible-module and .fl-builder-tangible-module-BLOCK-NAME-HERE instead of the random id string associated with that block

Let me know your thoughts.

Thanks,
Zack

For reference, this is what the classes look like on a standard BB module settings window:
fl-builder-settings fl-builder-module-settings fl-builder-photo-settings

Screen Shot 2023-01-10 at 10.43.45

And this is what it looks like once published:
fl-module fl-module-photo fl-node-37hpmf4gtuvw
Screen Shot 2023-01-10 at 10.49.34

Hey Zack, being a CSS noob myself, I had to check in with some more experienced folks about the approach here. It sounds like the long alphanumerical class name might be necessary to avoid collisions, but we might be able to use both approaches so that there’s an option when users want to reference the class of a particular block. I’ve sent it up the ladder to Eliot so we’ll see what solution he proposes and I’ll report back here to follow up.

1 Like

Collisions with what? It’s a class, not an ID. Every module on the page that is the same type of module would have the same classes. (except for the node class of course, which is unique to that module)

And that was only part of the suggestion. The current main issue is the broad css that is interfering with the alpha version of BB. The class thing was just an proposed improvement that could also aid in solving the overwriting css :+1:t2:

Right, I asked Julia to skim this and it seems she might have misread your explanation of the issue and I, wanting to be helpful but not fully understanding CSS, just passed along her message. Ultimately we’re just guessing why that was designed that way, so we’ll need to get Eliot involved to address that.

Understood, thanks for clarifying.

1 Like

Collisions with your other blocks and other people’s blocks! The UUID in the classname should in theory follow your block for its lifetime, identifying it better than a slug as the likelihood of someone else using the same slug is fairly high.

When you import a block whose UUID matches one already on your site you’ll get a notice that it already exists and an option to overwrite it with the new one.

In a CSS context the block generated styling is prefixed with the ugly UUID classname, again to avoid conflicts/collisions with other blocks and styling, keeping everything in context.

So yeah, we could definitely add another more friendly classname with the slug or allow custom classnames to be defined for the block, but that’s the reason for the ugly classname :slight_smile: it’s just our standard identifier for content created in L&L or Blocks.

If you do want to target all Tangible Blocks in Beaver Builder for some reason, you should be able to target them with an attribute selector: [class*="fl-builder-tangible-module-"] and although it’s long, ugly and provides no context, the UUID class works well for targeting individual types of blocks.

1 Like

@julia @benjamin Any updates here on this overly broad CSS being loaded by Tangible Blocks? It’s messing with the new responsive editing UI in 2.7.X

These .fl-builder-edit selectors like .fl-builder-edit select need to be scoped to Tangible Blocks, not every select in the BB UI

Seems to have fallen off the development radar so I’ve sent out the bat signal once more with more urgency. I’ll keep you posted.

1 Like

Appreciate it! Thanks!

Hey Zack, just chiming in to let you know that the fix to the issue will be included in the next release. I’m not sure I fully understand what the issue was, but I can parrot the dev chatter I’m seeing. It sounds like when Beaver Builder loads up their select2 element, the element that contains the dropdown list is not generated inside it but is instead a direct child of the <body> tag, which means that even if the select2 element is wrapped around a query-post-specific class, the dropdown will not be and every CSS selector we can use to select it will target every select2 dropdown of the page. To get around this, in the next version of Tangible Blocks, our CSS will only be applied when the post-query modal is opened.

It seems like the latest Beaver Builder release may be interfering with legacy controls (specifically select2 and the post-query control) in other ways too. This seems like part of the downside of relying on the builder’s own controls which is one of the benefits of the new Tangible Blocks controls which mitigate the risk of BB changing things. I doubt we’ll be investing more dev time into improving the compatibility of the legacy controls, but I thought I’d let you know that there are some known issues with the legacy controls. As always, if you spot issues with any of the controls, feel free to let us know so that we can make sure they’re on our radar.

I haven’t used any tangible blocks select fields yet, so I wanted to try one before the new version came out so I could see the difference. I can’t get it work…

I tried both examples from the docs: https://docs.loopsandlogic.com/171/select?category_id=131
Exact copy/paste. And neither one works. Both the selects are empty when inside of BB:

Screen Shot 2023-06-13 at 07.42.32

Screen Shot 2023-06-13 at 07.40.55

@zack In the toggle switch on your Block template, do you have the new controls or the legacy controls enabled? I think for the select control the syntax itself didn’t change so which control you’re using would just depend on that toggle. I know there’s a known bug with the legacy controls in Beaver Builder whereby the dropdown appears behind the control modal (like this). Is that what you’re experiencing?

Legacy controls. And no, that’s not what i’m experiencing. The select dropdown (and the select html markup) is completely empty

I just checked to compare the legacy select control syntax with the new syntax and my earlier comment was wrong, turns out there is a difference in the syntax. The legacy control used an options attribute and the new one uses choices. So the issue here is probably just that you used the new control syntax in your block but you have legacy controls enabled so you would need to use the legacy syntax.

Thank you. That worked Can someone at Tangible update the docs for each control with a link to the approprate legacy controls on each control type.

Ex: On the Select page, on that page, say “For legacy controls for Select, please see here.”

I was on the Select page and it doesn’t mention anything about new vs legacy markup

Now back to the original issue. I just tested it and it works just fine to make the CSS more specific!

.fl-builder-module-settings[class*="fl-builder-tangible-module"] select { }
instead of
.fl-builder-edit select { }

This selector just targets the <select> fields inside of a Tangible Blocks BB module. Not every <select> field inside of the BB editor like the original selector does.

Please have the devs test and then update this selector .fl-builder-edit select { }

We’re eventually going to be deprecating legacy controls so we don’t want to encourage their use too much. There’s a link to all the legacy controls under “control types” in the navigation menu and there’s information about how to transition to the new controls on the main Block Controls page in the docs which also includes a link to the legacy controls. The shift was explained in more detail on the L&L blog and I believe all members of the beta would have received that info by email. New control syntax on blocks is enabled by default now so most people creating new blocks will simply see and use the new syntax. I get that the new controls aren’t quite ready for prime time yet, but the rationale behind that structure is that we don’t want to make it seem like it’s an either-or option since support for legacy controls will eventually be dropped.

I’m not a frontend dev myself but I’ll pass this along to the folks in the know. I’m assuming there must be some reason they’re not doing this but I couldn’t tell you what that is. I’ll try to have someone who knows a thing or two follow up here.

I still think there should be a comment on each new one saying if the control markup has changed or not :man_shrugging:t3:

Thanks. Looking forward to hearing back from them on the new selector I provided

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

2 Likes