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

Tangible Blocks
#1

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

#2

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

#3

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
#4

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)

#5

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:

#6

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
#7

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
#8

@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

#10

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
#11

Appreciate it! Thanks!