Review `.bricks-is-frontend` styles in style.css

Miscellaneous
1

Hi Bricksforge team,

I noticed some quite specific default styles in style.css, for example:

.bricks-is-frontend .brxe-brf-pro-forms .form-group:not(.submit-button-wrapper):not(.brf-steps) {
    display: flex;
    flex-direction: column;
    padding: 0 0 20px;
}

I’m wondering why styles like padding: 0 0 20px need to be hard-coded there at all.

Because of the high specificity, values set in the builder can be difficult to override without additional custom CSS or !important.

It might be worth reviewing the selectors in style.css that start with .bricks-is-frontend in general and checking whether they are actually necessary or could be simplified.

Could these styles be reviewed so that builder settings can take precedence more reliably?

2

Hi,

fair point, thanks for raising it. Some background first: the 20px bottom padding mirrors the native Bricks form element, which ships the same default (padding: 0 0 20px on .form-group) as field spacing. In Pro Forms, the “Margin” control in the field styles writes to exactly this padding, so it’s meant to be changed in the builder. It’s padding rather than margin because fields sit next to each other via percentage widths, and a real margin would push them onto the next line.

Where you’re right is the specificity. Bricks wraps its default in :where(.brxe-form), so it has almost no weight. Ours is a plain descendant chain with two :not() and is much heavier. Values set on the element itself still win because Bricks renders them with the element ID, but a global class loses against it, and inside query loops and components Bricks switches to class selectors, so there even the element setting loses. That’s what you’re running into.

I’ll go through the .bricks-is-frontend rules in style.css and lower the specificity of the ones that are only defaults, so builder settings and classes take precedence. Until then the Margin control on the Pro Forms element is the reliable way to override the spacing.

Best
Daniele

1 Like
3

Thanks for your feedback, Daniele! I really appreciate you taking a look at this.

The reason I originally started looking into these styles is that I’d like to use CSS Grid for form layouts, similar to the approach Kevin Powell demonstrates in this video:

While experimenting with that, I ran into the specificity issues caused by some of the default .bricks-is-frontend styles. That’s what made me look more closely at the existing rules in style.css.

So for me, the main goal isn’t necessarily to change the default styling itself, but to make those defaults easier to override when building custom layouts — especially for forms using Grid.

Thanks again for reviewing this! :slight_smile: