It's very important as BE and FED we shoudl follow the proper naming convenstions. mostly for the BE we usually work on C# patterns but while working on the SXA feature, we need to make sure that we undrestand the basic of BEM naming convenstions.
These are the some example of good and bad practices -
http://getbem.com/naming/
Harry Roberts - This is the main reason we end up with bloated code bases, full of legacy and unknown CSS that we daren’t touch. We lack the confidence to be able to work with and modify existing styles because we fear the consequences of CSS’ globally operating and leaky nature. Almost all problems with CSS at scale boil down to confidence (or lack thereof): People don’t know what things do any more. People daren’t make changes because they don’t know how far reaching the effects will be.
Philip Walton mentioned - While 100% predictable code may never be possible, it’s important to understand the trade-offs you make with the conventions you choose. If you follow strict BEM conventions, you will be able to update and add to your CSS in the future with the full confidence that your changes will not have side effects.
Again below lines are from the Harry Roberts
There are a number of common problems when working with CSS at scale, but the major two that namespacing aims to solve are clarity and confidence:
Clarity: How much information can we glean from the smallest possible source? Is our code self-documenting? Can we make safe assumptions from a single context? How much do we have to rely on external or supplementary information in order to learn about a system?
Confidence: Do we have enough knowledge about a system to be able to safely interface with it? Do we know enough about our code to be able to confidently make changes? Do we have a way of knowing the potential side effects of making a change? Do we have a way of knowing what we might be able to remove?
There are a pleny of existing methodology to define the name like below
(Ref - http://getbem.com/introduction/)
- OOCSS - Separating container and content with CSS “objects”
- SMACSS - Style-guide to write your CSS with five categories for CSS rules
- SUITCSS - Structured class names and meaningful hyphens
- Atomic - Breaking down styles into atomic, or indivisible, pieces
The reason I choose BEM over other methodologies comes down to this: it is less confusing than the other methods (i.e. SMACSS) but still provides us the good architecture we want (i.e. OOCSS) and with a recognizable terminology.
Mark McDonnell, Maintainable CSS with BEM
<section>
<h1>Sample Calculator</h1>
<form action="test.aspx" method="post">
<p>
<input name="amount">
<input type="submit" value="Calculate">
</p>
</form>
</section>
<section class="widget">
<h1 class="widget__header">Sterling Calculator</h1>
<form class="widget__form" action="test.aspx" method="post">
<p>
<input name="amount" class="widget__input widget__input--amount">
<input type="submit" value="Calculate" class="widget__input widget__input--submit">
</p>
</form>
</section>
Here Section element is a block (widget) and
widget__form - double underscore to recongnize that form is a part of widget
widget__input - double underscore to recongnize that input is a part of widget
widget__input--amount - amount is a variant of input
the complete css class will look like this
.widget {
background-color: #FC3;
}
.widget__header {
color: #930;
font-size: 3em;
margin-bottom: 0.3em;
text-shadow: #FFF 1px 1px 2px;
}
.widget__input {
-webkit-border-radius: 5px;
-moz-border-radius: 5px;
-o-border-radius: 5px;
border-radius: 5px;
font-size: 0.9em;
line-height: 1.3;
padding: 0.4em 0.7em;
}
.widget__input--amount {
border: 1px solid #930;
}
.widget__input--submit {
background-color: #EEE;
border: 0;
}
Excellent example is here -https://www.integralist.co.uk/posts/bem/#4
References-
- https://en.bem.info/methodology/naming-convention/
- https://css-tricks.com/bem-101/
