WIP: [class*="brxe-"] max-width 100% is too intrusive

Feature Requests / Improvements
1

By default, Bricks sets all Bricks elements to max-width 100% by default.

It uses this statement to do it:

[class*="brxe-"] {
  max-width: 100%;
}

Aside from this being somewhat of a backwards approach, it’s very problematic for other reasons.

Mainly, it removes the ability of users to set different max-width defaults for specific elements (like headings and paragraphs in character units).

For example, this won’t work:

p {
   max-width: 50ch;
}

It won’t work because the class*= technique that Bricks uses is more specific.

The only way users can override Bricks is to increase specificity, which then breaks the builder controls for max-width.

This is easily fixable and we can all be happy. Bricks needs to wrap their instruction in a :where() function.

:where([class*="brxe-"]) {
  max-width: 100%;
}

:where() removes the specificity from the statement, making it easily overridable. However, if nobody attempts to override it, it will work as normal :slight_smile:

54 Likes
2

@thomas cana we implement this in next minor update please?

3 Likes
3

This is seems like a no-brainer to me. I’m not sure why Bricks wouldn’t fix this.

1 Like
4

The only reason i can think is due to Safari support, anything pre March 2020 the styles won’t apply.

I personally don’t see that as a big issue, Safari users are a very small % of users and it was 3 years ago, I use :where without concern.

But Bricks added :where before, in their menu, and it caused a few issues with people having clients on older browsers seeing it broken.

eg WIP: Nav Menu flexbox issues in older browsers

Maybe something that needs to be added in optional in the settings, as people may have strong opinions on what level of backward browser support is acceptable. And this is something that would obv affect every element on the page pretty much. (to be clear, i’d vote for it being changed by default, and have a setting to revert to the previous for those who need further older browser support)

3 Likes
5

I don’t see any bug here or that this is “very problematic for other reasons”. As you add this rule via custom CSS you can easily use the following CSS instead:

p, p[class*="brxe-"] {
  max-width: 100%;
}

Using :where for such an important rule that has to work in every browser is not improving anything, while at the same time, introducing issues for other customers.

1 Like
6

You’re right that it’s not a bug. It’s a feature. But it’s definitely a problematic feature, so I’m not sure where else to discuss it.

We can’t do anything to increase specificity because it renders the builder controls useless.

Example:

h1[class*="brxe-"] {
 max-width: 40ch; (user preference)
}

The minute we do this, the user can no longer adjust the max-width of H1 headings in the builder on the fly if needed (without styling at the ID level).

For non-Bricks users, all we have to do is a simple global styling rule:

h1 {
 max-width: 40ch; (user preference)
}

This is easily overridden by any other class or builder control, so it’s perfectly safe. But in Bricks, this doesn’t work.

More examples:

Users have utility classes like .text–s to make text smaller and match the max-width line length of their small text size. These won’t work without increased specificity, which again renders the builder controls obsolete for other adjustments the user may want to make to the max-width of a specific element or set of elements.

The same is true for heading classes. And the same is true for paragraph text in general. This would force users to style at the ID, which is fine in some cases, but not fine in many others.

The 100% max-width rule is problematic because:

  1. It’s not necessary (it’s only necessary because users are encouraged to misuse width).
  2. The way it’s implemented creates specificity issues.

It’s too late to remove the rule and re-train Bricks users on using max-width properly, but I do think the specificity should be optionally removable as @wplit suggested.

7 Likes
7

We can definitely discuss it here. If it’s a feature request, it might be a better fit for the feature category, though :wink:

Please correct me if I’m wrong, but last time I checked targeting a fully qualified class precedes targeting an attribute selector as we use for the default max-width of 100%. So working with utility classes should work perfectly fine.

Using the following CSS, the class name rule precedes the Bricks default, and the 20vh max-width takes effect as desired:

[class*="brxe-"] {
  max-width: 100%;
}

.brxe-text {
  max-width: 20ch;
}

What’s necessary is very subjective. It’s definitely not mandatory. We only added this rule after encountering a noticeable enough number of user reports that are not aware of when to use width and when not. It’s definitely a bit of a crutch, I am not saying it isn’t.

But that’s our job as the provider of a website builder: make building a website easier.

And it unquestionably helps more users than not, and removing it or implementing it through the :where pseudo-class would not be an improvement at all.

Feature detection via @supports selector is also not a solution as it was introduced roughly at the same time as the :where pseudo-class, and comes with the same browser-compatibility issues.

1 Like
8

Just adding to the discussion…

According to CanIUse Where has about the same amount of support as Gap. There will always be people with older devices and browsers that are going to run into problems…

Also for these type of CSS style crutches maybe a setting in the Bricks Builder (like the one for class chaining, Global Class Interface, Element Spacing) so it can be turned off for those that don’t need them?

4 Likes
9

Please correct me if I’m wrong, but last time I checked targeting a fully qualified class precedes targeting an attribute selector as we use for the default max-width of 100%. So working with utility classes should work perfectly fine.

It’s not really a question of whether the utility classes will work. They do work. It’s a question of what the user is then permitted or not permitted to do when attempting to override certain behavior.

.text–m, for example, doesn’t actually load after Bricks. So the order in your example is flipped. We intentionally load the utilities before Bricks because our philosophy is to defer to the builder’s controls as this is the best user experience. Other frameworks don’t do this – they pretty much just trample the builder by loading everything last.

We do have an overrides file that loads last, though, where we can put essential overrides. This is where we put .text–m for example, in the case of Bricks.

This does still cause an issue because some people want .text–m to only change the size of their text and not limit the line length. If they don’t want the character limitation for a specific element, they expect to be able to override it, which they can’t do with the builder unless they use ID styling (since we were forced to load this rule after the builder, given the attribute selector used by Bricks).

Granted, it’s not a super common issue. BUT, it’s definitely a big issue with default global styles: h1,h2,h3,h4,h5,h6,p, etc.

These cannot have a proper max-width set on them without increased specificity that then disables the max-width input in the builder for these elements.

If you’re not comfortable with :where() or providing a toggle that allows users to disable the max-width attribute selector, then another solution is to allow users to set a default max-width on headings and paragraphs from the global styles area — and make sure this is overrideable on any specific element, using a class (not ID), via the builder controls.

We can then instruct users to use the Bricks global styling area instead of setting these defaults in ACSS. It’s not perfect since they want to use ACSS to do this, but it at least gives them a workable option.

7 Likes
10

This is the best solution IMO. An intermediate or pro user doesn’t need Bricks to protect them from themselves. We know to use max-width instead of width and prefer to do so. It’s actually very uncomfortable for an experienced user to be asked to use the width input instead of the max-width input.

As an experienced user, I would love to have the option to turn this protection off. I want to use width and max-width as they were originally intended. This would also solve the global styles issues.

20 Likes
11

It’s time for us to use CSS layers, which at least works for new browsers.

Bricks can define certain layers like builder, framework, user

All Bricks rules are in builder layer. Then if ACSS rules are in framework layer, ACSS will always override Bricks rules no matter the specificity. Then the user’s custom CSS will always override Bricks and ACSS rules.

5 Likes
12

Hey Kevin,

don’t have to add anything more to the discussion at this point. Just being curious. Can you give me some background why exactly you made the decision to load the utilities before Bricks? Do you have an example of a case where you want Bricks to override something from your utilities? Cause without those insights I’d say that ACSS is a layer on top of Bricks. Thus in my head it’d make sense to load its assets after it.

Thanks for your input!

Best,

André

13

I agree with Kevin. The builder css should overwrite the framework.

While web design beginners may not understand when to use width vs max-width. It’s easy to explain and understand and once they learn it, they’ll always remember and be better off for it.

14

Hey @touchdowntech,

thanks for your input. Since @digitalgravy did not get back to me on this one yet and you agree with him… can you explain (or maybe even better provide an example or two) why the (default) builder settings should override the framework and not the other way round? Can’t get my head around it yet. :slight_smile:

Thanks,

André

2 Likes
15

Two reasons:

  1. Our philosophy is that the framework is for “utility.” The builder is for primary decision-making (should the user want to make decisions there). After all, the builder is writing the HTML, creating the custom classes, and so on. ACSS is not a utility-first framework like Tailwind – it doesn’t try to force the user to use it for everything. We encourage users to create custom classes and use BEM. With that, they use ACSS variables, but they’re still leveraging the builder for this. The builder is the primary work environment, so decisions made there should take precedence.

  2. It’s safer and less frustrating for the user. ACSS can do whatever they ask it to do, and the builder can do whatever they ask it to do, because of basic cascading. There’s no conflict. Since the user doesn’t have control of which stylesheet loads where, we need to create a safe environment where they can more or less do anything they want to do at any time. When you load an overbearing framework, this creates significant limitations for the user. They set up something with the framework, and then when they need to use the builder to override that decision with a custom class, for example, they can’t. The user is forced to use ID styling or !important or some other undesirable technique.

The only real challenge occurs when the builder gets overbearing (as is the case with the issue in this thread).

Someone else mentioned @layer, which I think should be heavily considered as well. Anything that makes these tools less specific and overbearing is best for the user.

The avoidance of :where() seems like an odd argument, considering Bricks already does a lot that has LESS browser support than :where(). I mean, we’re at 93% support … it doesn’t get much better than that.

17 Likes
16

Does the Bricks team know yet what solution are you thinking of implementing to address this issue?

17

Thank you for your explanation that even a “chump” like me can understand! Happy Birthday :birthday: for July 4th - what a great day to have it! :sparkler:

18

Was this tackled in 1.8.2? Haven’t installed it yet but didn’t notice it mention in the changelog.

Notice this issue also affects things like the svg element where I was using it as part of my shape divider (that is absolute positioned) forcing it to a max width of 100% when I had set width to something like 200% since I was using only a specific part of the SVG as the divider. Was really hoping for an override for these type of crutch css default settings.

19

Granted, it’s not a super common issue. BUT, it’s definitely a big issue with default global styles: h1,h2,h3,h4,h5,h6,p, etc.

@aslotta Hopefully this will be looked at soon. It’s important for accessibility being able to specify line lengths globally.

Line length - Wikipedia.

2 Likes
20

So when I set my max width of my h2’s to 30ch it’s being forced by Bricks to 100%…