Ideal BEM Class Naming for Shareable Elements & Layouts

Developers
1

I wanted to float this BEM (Block, Element, Modifier) related question out to the Bricks universe in the hopes of getting some constructive feedback.

So my end goal is to develop a set of ever expanding free Elements and Layouts that I can share with the Bricks Community. I plan to make them fully responsive and Iโ€™d like to assign a set of intuitive BEM based class names to them, allowing rapid implementation and style overrides for anyone using them.

Ideally Iโ€™d like to make the BEM class names specific enough to apply the requisite styling but not too general where it could potentially compete with the existing classes on any websites that use them. For this reason I was also considering adding a short modifier to the beginning of each class. So for example if my modifier was โ€œdmโ€ it would make my block class name for a carousel .dm-carousel, the structure would be something like this:

/* Example Block level class with modifier */
.dm-carousel .dm-carousel-style-01 { style:  here ; }

/* Example Element level classes */
.dm-carousel__item { style:  here ; }
.dm-carousel__image { style:  here ; }
.dm-carousel__title { style:  here ; }
.dm-carousel__description { style:  here ; }
.dm-carousel__button { style:  here ; }

(Or alternatively) Should I only use a specific class at the Block / Modifier level and use the root selector ( %root% ) to call out any classes/styles at the Element level?

Nothing is set in stone yet Iโ€™m just looking for constructive ideas, thoughts and feedback. Thanks!

2

Are you building those items inside the builder or as a custom elements in php? I have build quite a lot of elements using the custom elements api, and iโ€™m quite happy with the approach i have developed over the years. Hereโ€™s a list of what my baseline of elements is:

image
image260ร—1006 9.71 KB

If you build
I always define my root selector like this:

$selector = $this->name;

And then I can use it inside my code e.g. like this:

"{$selector}__list";
"{$selector}__item";

"{$selector}__img-wrapper";
"{$selector}__img";

"{$selector}__title";
"{$selector}__subtitle";
"{$selector}__meta"; // e.g. Date, Category, Author

"{$selector}__content";
"{$selector}__excerpt";

"{$selector}__icon-wrapper";
"{$selector}__icon";

"{$selector}__svg-wrapper";
"{$selector}__svg";

"{$selector}__link";
"{$selector}__button";

This makes it very easy to copy code between one element to another and not have to worry about the selectors or typos.

If you write VUE-JS Components you can do the same like this (with the variable โ€œnameโ€):

// MARK: Render Builder
    public static function render_builder()
    {
?>
        <script type="text/x-template" id="tmpl-bricks-element-uf-container">
            <component
            :is="tag"
            :settings="settings"
            :name="name"
            :class="[
                name,
                'container',
                settings.type ? `${name}--${settings.type}` : null
                ]"
            >
            <bricks-element-children :element="element"/>
      </component>
    </script>
<?php
    }

Cheers Suat

1 Like
3

Thanks @SuatB, I had originally planned on just using the builder to create my custom Elements and Layouts but I may pivot after reading your reply. I have a specific domain dedicated to just this Bricks project and had planned to use the Public Templates option in the settings to share them out. If I did it the way you have yours set up, I assume Iโ€™d need to bundle the Elements in a plugin in order to share them out. Is that your assessment as well?

4

Yes I would guess so. For me I have created a child-theme (for my company), that we reuse for each customer. But Iโ€™m thinking of excluding the elements from the theme and putting them into a plugin aswell.
There are multiple examples of people who have put out Bricks Elements Plugins:

There is a rudimentary tutorial on how to build custom elements, with itโ€™s early pitfalls, in this thread you might want to check out:

Cheers Suat

1 Like
5

child theme :fire:

1 Like
6

@SuatB, Thanks so much for all the awesome resources. I have bookmarked every one and plan to review them in much more detail over the coming days. I think I am going to experiment with a couple different approaches. Ideally I want to make the resources I build, easily shareable with the Bricks community so that may end up dictating my final approach.

1 Like
7

@sinanisler, I totally agree and always use child themes for every WordPress build. In fact Iโ€™ve developed my own child theme over the years with includes to custom functions similar to the one in the GitHub link you provided. Awesome work on that, by the way. I might just have to update my own with some of the items you included. Ironically my functions file is set up almost the same way with include files and I simply comment out links to the functions I donโ€™t need on a client by client basis.

Not to change topics, but out of curiosity did you have any thoughts on the BEM based class names or run across any standard conventions in your client projects that you found useful (or) problematic?

8

components and variables and the global classes are ofcourse way to go for re-usable values, parts and sections.

what you need depends on your workflow but for me I dont care bem you dont have to have that metodology for me its waste of time it only slows your development workflow. as long as your naming convention is semantic and logical it is good. bem helps people when they dont know nothing but that doesnt mean it has to be followed exacly.

every extra abstraction and workflow step you add on top of the native bricks builder will slow you down and it is cumulative.
this is why I love using existing native features classes, variables and components when they needed.

after slotable components comes it will be perfect for any global part/section needs.