Can we automate a BEM naming to make generated classes clearer?

For those who are not used to BEM class naming, here is a refresh:

I got this idea when I saw a screenshot from Marius in previous post and always had me cringe when I saw it so far while editing myself:

This is kind of ugly and totally unfriendly to remember. It’s kindof the same reason why we use words as domain names and not an IP address. Anyways I digress.

The idea would be that when we create the original section or top block, we give it an original name, here: “c-menu” (I use the webflow article as example).

Then all the nested divs or elements would copy the original name with the 2 underscores and make that to the class as well.

But there’s a problem, this does not work as the class would have to be an linked copy of the name and this opens a can of worms…
So it’s from the class itself that the name should come from, feel free then to change your name but the class is BEM friendly and now instead of seeing random digits, we have a clear automated approved CSS naming convention to start from.

When we deal with virtual classes, we have a clear view of what is what.

@Louis perhaps this is doable and a good idea at all?
I know it is a potential very hazardous process as if you copy paste to another parent, it will screw things up as the top name is now different.

Honestly I don’t see how it could be done except manually but if your knowledge says it can somehow then great.
If not, then I don’t wish for this to be upvoted and we will have to keep things manual.
Which is ok.
At least maybe the cloud library could come up with pre defined well named classes to make newcomers more at home when branching elements, doing relative styling and such.

It just gives you the most freedom without any limitations.
I mean, the class has to be touched anyway, right?

Since block classes are now directly attached to the current post/page/template-part, etc., the BEM approach became actually a thing for me in Cwicly, unless one would use global classes for it anyway.

I highly disagree.

Both, the Cwicly and Community library, should use the defaults to avoid conflicts and assure a standardized/unified experience - even if it’s not the best way with the random class approach, but it’s the default, right?

If I could decide, it should even be mandatory when uploading to the Community library.
Even prefixing wouldn’t help much. Some random generated part is needed in any case, unless I miss something.

1 Like

Yes maybe again I projected too soon :smiley: Common habit of mine.
I don’t really care about throwing stupid ideas, as once in a while, one of them triggers positively or questions a status quo one way or another.

That being said, the more I think about it, and read your comment, the more satisfied I am with current situation as being a simple manual fix from the simplest default, “without limitations” as you said.

Cool. This thread can be moved somewhere else than featured requests.

1 Like

Come on, don’t give up already.

It’s only one single opinion and there still is the chance that other users might be out there, who come up with the exact opposite :man_shrugging:

And who says that I’m not missing (even essential) points?

There are no bad ideas. You have a point where you see space for improvements. If it makes sense in the end isn’t necessarily connected to it.
There might even be cases which make sense but won’t fit to the concept for various reasons.

I think you can do that by yourself in case you really don’t want to leave it here. Do you see a pencil next to the topic title?

Naming the blocks inside the Navigator properly improves the experience and workflow significantly.
If you don’t do it for yourself, you could consider it for the designs you upload to the library. It really helps a lot when working with designs someone else created.

1 Like

I guess it’s too cool to happen as it is too complex to set up properly, and bound, it if it were a thing, to get some users complain things got messed up because of a wrong copy paste.
I may even not foresee even worst case scenarios.
As Tom Usbourne, creator of GenerateBlocks said: It’s best to not implement too quickly.
Louis should be right to consider very thoroughly feature requests like this as it could lead to a broken tool with backward compatibility issues.