Hello,
I installed the beta version into a test environment and took a closer look at the HTML source code in terms of clean semantics. I noticed that almost all HTML elements get a unique ID AND the same ID as a class.
What is the benefit of this?
Examples:
2 headings below each other:
In my opinion, the classes are completely unnecessary. Because to use them they have to be overridden as a class. Who of the developers does that? Most developers have their own wording in styling style.
I for example work with the BEM method and don’t use these classes like brxe-text-basic. This unnecessarily inflates the source code and makes it unclear.
What do the other developers think about this?
Btw: Where is there a list / overview of all used CSS classes that can be used in the frontend?
The goal is to be able to do without IDs completely at some point in the future and to use only classes instead. This is not yet the case, but it has no effect on the performance of your pages whether the “ID classes” are there or not.
Of course, you can also add your own ID or classes to an element and style it.
.brxe-text-basic or .brxe-heading, on the other hand, are enormously important, because how else would we know what element it is in the first place? Somehow the elements must be identifiable as element x or y.
frontend.min.css/frontend-light.min.css contains all Bricks default styles. We don’t have a list or something, as we’re not a utility class framework What do you want to use the classes for?
I don’t think not using IDs at all is a good id (sorry).
IMHO, IDs should be added to the tag in two cases:
user manually adds a custom ID to the element (he uses it as an anchor or he wants to style it separately or whatever)
user adds some style to element in builder UI, then an auto-generated ID is added
Using class instead of ID will bring conflicts between rules because there will be ambiguity.
Using IDs ensures that the builder has priority over more general rules.
So there’s no point for auto-generated classes like brxe-mztzpj, and by default, there should be no ID or class at all.
True, but in real world it’s often not that easy to achieve as you describe it here!
A builder (not only bricks, but every) is a very complex ecosystem and sometimes it’s easier to use classes instead of ID.
I don’t see any reason to not use a class when an ID could also be used and vice versa. For my it’s more a personal thing. Of course you have to be aware of duplicate IDs and if you need an anchor then ID is the way to go, but for any other scenario I think it’s more a personal choice nowadays!
To identify and assign the properties to an HTML element an ID # is sufficient. This can also be used to overwrite values if the changes should only apply to this one element.
Even though unused classes should not cost performance**, it degrades the UX of the developer/developer team. The code becomes less readable. Especially if you want to make changes after 6, 7, 8 or more months. Then you search where which change was made. And if the search takes too long, an !important is added.
I have seen a lot of this with Elementor, DIVI and other pagebuilders. This is terrible code. Oxygenbuilder goes a very good way here and I thought until now that you want to go the same way to create slim well readable source code.
** The browser processes each class squentially and that costs performance.
The brxe-mztzpj Classes
The element class is used in combination with global classes or if it is a global element.
Again, the brxe-heading or brxe-basic-text Classes
An ID is definitely not sufficient to identify the element (inside of the builder, for example), because it can be changed (by you). So the element needs a class that is consistent and stays as it is.
All this is part of the Builder logic, without nothing would work.
Btw, maybe instead of “goal” I should have used “idea” in my first response. It’s an idea, nothing more, nothing less.
Sorry that I have thereby started a kind of avalanche…
True, but are you seriously comparing the Bricks HTML markup to Elementor and Divi right now (attention this is a rhetorical question)?
A global Class with a autogenerated unreadable Namespace?
That’s OK.
No, but it already has a tendency in that direction <a id="brxe-mztzpj" class="brxe-mztzpj brxe-button bricks-button bricks-background-primary"></a>
If one then still hangs its own classes to it.
Yes, the difference is the perspective. The builder logic doesn’t care if the class name is readable for you It is unique and cannot be changed. That is the crucial part.
Not even close.
If you reset the style setting from the button there are only three classes
What about utility classes? Do you like them because you can read them or do you think 20 classes are too much to get this button on the Tailwind Homepage?
I have no problem with brxe-heading or brxe-basic-text classes which are actually useful even on frontend and which are “readable”.
And I also agree that there must be things related to the builder inner mechanisms that we can’t think of, but could you elaborate this please:
I agree that duplicate ID would be an issue for a global element used multiple times on a page, but why not let people manage this by styling the element with a custom class instead of creating custom ID?
Or maybe generate a class with the same ID name and moving properties to the class when making the element global?
This way, you wouldn’t have to systematically auto-generate an unreadable and useless class when not needed.
If you create a button, for example, and make it a global element that you place several times on a page, the ID cannot be identical. But the class can be, and since it cannot be changed, the button can be uniquely identified as a global element within the Bricks mechanisms.
You are still able to style the button with a custom class of your choice and still make a global element out of it, but the automatically generated class is still necessary because it is a kind of safety mechanism (to ensure the mechanisms work).
Definitely. It starts with supposedly very simple things that suddenly become highly complicated in the builder context.
Btw., to make it complete, the .bricks-button class is used for theme styles
Webflow and Pinegrow both handle this. You can add an ID manually, otherwise it uses classes only and assigns a class for each element you create (until you rename them) - div1, icon3 etc
Recently, I noticed a new builder.
I like the way they handle styling.
For example, if I style the element without a global class, the styling will fall to its random class instead of ID. So, there will be no ID styling at all. The ID is only used for those sections for anchor links(switch section within the same page).
What do you want to use the classes for?
