Forbid flexbox items to flex w/o use of * selector - html

Question

I work with BEM and use a flexbox container purely for alignment and responsive design purposes. The problem is that sometimes it also wants to scale its daughter elements, which I don't want. Like this:
.card {
width: 120px;
background: gray;
}
.container {
display: flex;
align-items: center;
}
.flex-item1 {
width: 50px;
background: blue;
}
.flex-item2 {
overflow-wrap: normal;
background: green;
}
.ruller {
width: 50px;
background: gray;
}
<div class='card'>
<div class='container'>
<div class='flex-item1'>
I'm picture 50px wide
</div>
<div class='flex-item2'>
I'm long text
</div>
</div>
</div>
<div class='ruller'>
My width is 50px
</div>
Here is the blue element is getting scaled and its rule width is ignored.
One direct solution for this is to just explicitly forbid flexing for every element.
.flex-item1 {
width: 50px;
background: blue;
flex: none; /* the fix */
}
But container is a general class, I'm using it in tens of different situations, I don't want to add more CSS code to all possible classes of its daughter elements, nor do I want to add another class like container-item to all those elements in HTML.
Another direct solution for this would be
.container * { /* the fix */
flex: none;
}
But this goes against general BEM guidelines on using selectors. I would like to avoid using * selector here.
Is there a way third way to do it? I.e. a way that doesn't add any CSS rules to styles of daughter elements and which does not use * selector.
What makes me ask such a question is the existence of rules like align-items, which are placed to the parent element (i.e. flexbox itself) by the acting on daughter elements (i.e. flex-box items). I imagine my solution would be is something like this:
.container {
display: flex;
align-items: center;
flex-items: none; /* a pseudo rule, which doesn't exist and need to be replaced by other rules to work */
}

Answer 1

If you insist on following BEM without exception, then you should have the rules you need within classes you've defined for your elements. That would be the BEM way. You may not like having that code in 20-30 different places as you say, but that is the tradeoff of BEM.
Personally I combine BEM with utility classes when it makes sense, I don't believe that following BEM blindly to the letter produces cleanest and easiest to maintain codebases.
On the other hand rise in popularity of Tailwind goes to say that BEM and similar methodologies don't work for all.
All this being said, I would suggest sprinkling some utility classes on your BEM project and enjoying best of both worlds.