SOLVED: Since v1.8.4, user defined font size in Typography > All Headings is overwritten by Bricks base defaults

Bugs
1

Browser: Chrome 115
OS: macOS

Hello Bricks team!

Since v1.8.4, in the editor, Bricks uses a :where() pseudo class to output the values from the theme styles > typography > all headings settings.

v1.8.3 and below:

h1,  h2,  h3,  h4,  h5,  h6 {
    line-height: var(--o-font-lineheight-1);
    font-size: var(--o-fluid-font);
    font-family: var(--o-font-sans);
}

Since v1.8.4

:where(h1,  h2,  h3,  h4,  h5,  h6) {
    line-height: var(--o-font-lineheight-1);
    font-size: var(--o-fluid-font);
    font-family: var(--o-font-sans);
}

This gives user defined preferences a specificity of zero. Therefore, the Bricks base default font size for headings, h1 for example:

h1 {
    font-size: 2.4em;
}

Takes precedence over the user defined values because it has a higher specificity. This results in a wrong font size output in the Bricks editor, where it is correct on front-end.

In my opinion, Bricks defaults should not have a higher specificity than user defined styles.

Suggestion:

  • Use a :where() pseudo class also for all Bricks defaults.
  • Even better, use a @layer bricks-defaults for all Bricks defaults, then a @layer bricks-user for all user defined values.
4 Likes
2

Hi Cédric,

Thank you so much for your report. I was able to replicate this and have added this to our internal bug tracker :slight_smile:

Best regards,
Charaf

2 Likes
3

So instead of implementing a proper fix and using where or layers, the where has just been removed in v1.9 and we have reverted back to the v1.8.4 way of doing things.

4

@dan Is the fix not working for you or what exactly constitutes a proper fix :)?

5

@charaf imo it would be reducing specificity on default Bricks styles by the use of :where or css layers as was suggested by OP and also in this thread → NO BUG: [class*="brxe-"] max-width 100% is too intrusive

All conversation from Bricks team seems to have gone quiet on the matter. It would be nice to get an update on current thoughts etc. I get that it might be a big task but radio silence on a big thread from any Bricks team member for 2 months is a bit strange.

Avoiding the thread hoping it goes away perhaps?

6

@dan we’re aware of the issue and as you’ve mentioned it’s a big task & decision that we shouldn’t rush. We’re getting reports from the instances where we’ve used :where that it’s breaking websites on older browsers and at the same time we also get your POV. So at this time, we’re still looking into it, which is why we haven’t shared much about the issue.

1 Like
7

@charaf I would be interested to know what versions and how old the browser’s are in these reports.

We as a web dev community want to move things forward. If styles break on an older browser then the first suggestion would be to update the browser, not only for CSS but for security too. All the latest versions of all browsers support :where and CSS layers.

If the person is unable to update for whatever reason (corporate governance etc) then there should be fallbacks in place and the dev of the site should be building accordingly.

We should not be stopping Bricks moving forward for the vast majority of people on the latest versions for the few on old outdated software.

Should I build a site that I need to display in IE for example and then complain that nothing shows properly?

Anyhow, I appreciate the response, it would be good if there was an official response on the other thread too. Or even if a new thread is opened by the Bricks team for discussion around this area

1 Like
8

Hey @cedric,

we’ve fixed this issue in Bricks 1.9, now available as a one-click update in your WordPress Dashboard.

Please let us know if you are still experiencing issues.

Best,

André