WIP: Dynamic data in CSS ID field causes Custom CSS to not be scoped to element

Bugs
1

When using dynamic data in the CSS ID field, e.g. {term_slug}, CSS styles applied to %root% in the Custom CSS field appear to be rendered incorrectly.

If the selection is e.g. %root% {background: pink} the rule appears to not be rendered on the front end; if the selector contains a pseudo-class, e.g. %root%:hover {background: pink} then the rule is rendered as the non-scoped :hover {background: pink}.

The current workaround is to assign a custom CSS class in the CSS classes field and to reference this manually in the Custom CSS area, e.g. .custom-class {background: pink}.

2 Likes
2

Hi Robbie,
Thanks so much for your report, and welcome to the forum!

I can replicate the problem and have added it to the internal bug tracker. We will update this thread as soon as it is fixed.

Best regards,
timmse

3

Hey guys,

This bug remains after some time. @timmse are there any plans to address it?

Using dynamic data for CSS ID of a button in my case. There are multiple issues:

  • STYLE tab align-self option is overridden when the #{dynamic-data} ID is applied.
  • Custom CSS field is overridden, as noted by @robbiedawson in Sep 2025.
  • Duplicating the button element REMOVES the CSS ID setting (now blank) and REPLACES “%root%” in the Custom CSS field with “#{dynamic-data}” - so it also doesn’t apply properly.

This is from trying today in v2.3.1.

Edit - seems like Bricks tries to assign any STYLE tab settings to the #{dynamic-data} ID even though we cannot select or de-select it like a class.

So, if there are multiple instances of the dynamic-data ID in a page, they will all inherit each others’ STYLE tab settings. In my case I have multiple buttons within a page using the ID as it is a trigger for the same modal.

To work around that I have to apply different custom classes to each instance and write my STYLE tab settings as custom CSS. Not ideal.

4

Does your use case support prefixing the dynamic data tag, as in #post-{post_id}? I seem to recall that this avoids the issue described here, which is restricted to when the dynamic tag itself is at the start of the id/class name.

Robbie

5

Thanks Robbie,

I will give it a try. The prefix would be arbitrary but if it solves the issue then so be it.

Ideally the bug is addressed by the team in the longer term :slight_smile:

Edit - that doesn’t seem to work for my application unfortunately. I have tried setting the ID via attribute instead of via CSS ID but the result is the same.

%root% Custom CSS is ignored, individual element STYLE options are conflated with the #ID even if they were set before the #ID, duplication behaviour is weird, editor vs frontend rendering is off.

So I will need to use a mess of custom classes with media queries and !importants on these button elements, just to replicate already-done Bricks styling.

@timmse if you have any other suggestions I am all ears. Or if this could get back on the radar for a fix, that would be awesome.

6

Unfortunately, I can’t offer you a temporary solution—the task is still in progress. Unfortunately, I can’t say when it will be resolved.