BEM denkwijze
Duidelijk verhaal ... wat ook daadwerkelijk opgaat als dingen/elementen continu zouden veranderen. Echter ... volgens mij bouwen we een website naar een vaststaande structuur en weten we dus op voorhand wat waar staat.
Wil ik een speciale lijst toevoegen dan voeg ik een lijst met class "my_special_list" toe. Waarom moet ik dan alle <li>'s die daar inzitten ook weer een aparte class geven, terwijl ik die prima kan benaderen via het root-element <ul> met de class "my_special_list"?
Komen we weer even terug op het voorbeeld met het klaslokaal. Stel we hebben 1 klaslokaal met felle groene verlichting, en 1 klaslokaal met felle rode verlichting.
Ieder kind dat het rode lokaal binnenstapt wordt door de verlichting vanzelf roodgekleurd en is dus een "rood" kind. Ieder kind dat het groene lokaal binnenstapt wordt op diezelfde manier "groen" van kleur. We weten dus dat in het rode lokaal altijd rode kinderen zitten, en in het groene lokaal altijd groene kinderen. WAAROM zouden we dan bij de kinderen in het rode lokaal nog een extra bordje om hun nek hangen om aan te geven dat ze rood zijn? Nergens voor nodig, want omdat ze in het rode lokaal zitten, weten we dat al. Idem voor het groene lokaal.
Hoe achterlijk dit voorbeeld ook is (maar goed dat was het originele voorbeeld ook) geeft het wel exact aan wat ik bedoel te zeggen. Op basis van een overkoepelend element, kun je generieke elementen binnen het overkoepelend element prima stijlen. Het lijkt mij overkill om al die generieke elementen een bordje om hun nek te hangen / een class te geven.
Gewijzigd op 10/08/2016 03:14:38 door Ozzie PHP
Ozzie PHP op 10/08/2016 03:02:22:
Wil ik een speciale lijst toevoegen dan voeg ik een lijst met class "my_special_list" toe. Waarom moet ik dan alle <li>'s die daar inzitten ook weer een aparte class geven, terwijl ik die prima kan benaderen via het root-element <ul> met de class "my_special_list"?
Het verschil is dat jouw versie impliciet is met een verborgen opmaak die je alleen kunt terugvinden door in de CSS-code te zoeken. Ik moet bijvoorbeeld binnen de accolades gaan kijken hoe jij een kerstboom optuigt:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
2
3
4
5
6
7
8
9
10
11
ul.kerstboom {
...
}
ul.kerstboom li {
...
...
/* Dit moet ik allemaal lezen om te achterhalen wat je doet en laat. */
...
...
}
...
}
ul.kerstboom li {
...
...
/* Dit moet ik allemaal lezen om te achterhalen wat je doet en laat. */
...
...
}
Aangezien jij HTML-elementen rechtstreeks opmaakt, loop ik ook nog het risico dat je elders in de CSS-code bijvoorbeeld hebt verzonnen dat lijsten in een footer anders worden opgemaakt:
Code (php)
1
2
3
2
3
footer ul {
...
}
...
}
BEM maakt keuzen expliciet:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
.kerstboom {
...
}
.kerstboom__kerstbal {
...
}
.kerstboom__piek {
...
}
.kerstboom__kerstbal--goudkleurig {
...
}
.kerstboom__kerstbal--zilverkleurig {
...
}
...
}
.kerstboom__kerstbal {
...
}
.kerstboom__piek {
...
}
.kerstboom__kerstbal--goudkleurig {
...
}
.kerstboom__kerstbal--zilverkleurig {
...
}
Ozzie PHP op 10/08/2016 03:02:22:
Duidelijk verhaal ... wat ook daadwerkelijk opgaat als dingen/elementen continu zouden veranderen. Echter ... volgens mij bouwen we een website naar een vaststaande structuur en weten we dus op voorhand wat waar staat.
Maar BEM is dan ook bedoeld voor templating. Kijk bijvoorbeeld maar eens naar de BEM-bouwstenen in Material Design Lite (MDL) van Google. Als een structuur op voorhand vastligt en later zelden of nooit ingrijpend verandert, is een objectgeoriënteerd, modulair template-systeem niet interessant. Áls ...
Dat is dus een situatie waarin het handig zou kunnen zijn.
>> Het verschil is dat jouw versie impliciet is met een verborgen opmaak die je alleen kunt terugvinden door in de CSS-code te zoeken. Ik moet bijvoorbeeld binnen de accolades gaan kijken hoe jij een kerstboom optuigt
Dat moet je in de BEM variant ook, met hooguit als verschil dat je daar direct naar het naampje kunt gaan van de class. Maar met bijv. Firebug zie je ook direct de opmaak van ieder element, dus voor mij persoonlijk is dit geen zwaarwegend argument. Ik vind het dan weer zonde van resources om generieke elementen pseudo-uniek te maken door ze hun eigen class te geven.
Maar goed, uiteindelijk is het een kwestie van wat je zelf makkelijk vindt. Ieder nadeel heb z'n voordeel ;)
Ozzie PHP op 08/08/2016 21:25:20:
Wat een vreemde manier om generieke elementen te voorzien van een class ... lijkt me overkill.
Helemaal mee eens.
Ik haak dan wel even halverwege in het topic aan, maar om elk element een class te geven, is toch niet nodig?
Je kan er toch (bijna) altijd bij zonder enige class dan ook?
Een class op <body> is geen gek idee en soms op <section> ook niet, maar dat doe je dan meestal via een id=...!
Wat is er mis met dit?
Code (php)
1
body#contact nav ul li a:nth-child(1) { font-weight: bold; }
Toch duidelijk dat de eerste link van je menu op de contact-pagina vet wordt?
Toevoeging op 10/08/2016 22:29:58:
Als reactie op Ward z'n code van een kerstboom:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
<div class="kerstboom">
<div>Piek</div>
<div class="bal zilver">Zilveren bal</div>
<div class="bal goud">Gouden bal</div>
<div>Voet</div>
</div>
/* Kerstboom hier */
.kerstboom { }
.kerstboom div:first-child { /* piek /* }
.kerstboom div:last-child { width: 10%; background-color: brown; }
.kerstboom .bal { border-radius: 100%; }
.kerstboom .zilver { background-color: grey; }
.kerstboom .goud { background-color: yellow; }
<div>Piek</div>
<div class="bal zilver">Zilveren bal</div>
<div class="bal goud">Gouden bal</div>
<div>Voet</div>
</div>
/* Kerstboom hier */
.kerstboom { }
.kerstboom div:first-child { /* piek /* }
.kerstboom div:last-child { width: 10%; background-color: brown; }
.kerstboom .bal { border-radius: 100%; }
.kerstboom .zilver { background-color: grey; }
.kerstboom .goud { background-color: yellow; }
Zo houd je sematiek hoog, weet je alsnog alles te vinden en ben je veel flexibeler. Je kan ook een gouden stam hebben... Gewoon class=goud toevoegen...
Gewijzigd op 10/08/2016 22:30:47 door Eddy E
Quote:
Toch duidelijk dat de eerste link van je menu op de contact-pagina vet wordt?
Ironisch bedoelt? Zo ja, negeer de rest van t bericht maar. :)
<nav> is niet alleen je hoofdnav. Ook die serie linkjes in je footer is een nav. Sterker nog, die "< prev | next >" linkjes bij blogposts zijn ook nav. Dus nu wordt elk eerste li'tje in een nav (iedere willekeurige nav) bold.
Ja, je zal nu wel 1 <nav> hebben. Maar over 30 dagen voeg je toch nog een sidebar met een subnavje toe en het gedoe begint. Dan moet die weer font-weight:normal; krijgen, met eventueel andere stijlen die van andere CSS selectors zijn geinherit, etc.
Tevens is de selector veel te specifiek. Niet alleen kun je op deze manier de stijl nogmaals hergebruiken, ook zal deze selector relatief traag zijn. (CSS selectors worden altijd van rechts naar links gelezen).
Body met een id is niet nodig, want er staat op iedere pagina maar 1 body.
Dan hou je dus over:
#contact nav ul li a:nth-child(1) { font-weight: bold; }
Die ul en li zijn uit m'n hoofd ook niet nodig, dus blijft over:
#contact nav a:nth-child(1) { font-weight: bold; }
nth-chilc(1) kan first-child worden en dan krijg je:
#contact nav a:first-child { font-weight: bold; }
>> Tevens is de selector veel te specifiek.
Nu dus niet meer ;-)
Quote:
Nu dus niet meer ;-)
Gelukkig weten jij en ik dat "Tevens" betekend dat er voor nog veel meer geschreven staat.
Overigens werk de hele selector niet zoals verwacht (zowel specifieke als de korte, welke idd identiek zijn), maar dat mag eenieder zelf uitvinden :)
Haha ... zou zomaar kunnen ;-) Heb 'm ook niet getest.
Anyhow ... gebruik gewoon BEM als je dat fijn vindt. Ik gebruik het niet. Stijl dingen die algemeen zijn ook als zodanig, en wat specifiek noodzakelijk is, ook als zodanig. Dat is mijn werkwijze. Scheelt in ieder geval een hoop classes ;-)
Wouter J op 10/08/2016 22:31:36:
Ironisch bedoelt? Zo ja, negeer de rest van t bericht maar. :)
Beetje wel ja ;)
Desalniettemin is het zo benaderen van elementen, (hetzij een strakke hierachie nodig is) wel mogelijk.
In tegenstelling tot BEM, vond ik vanochtend dit: http://acss.io/
Maar hetzelfde als in mij ogen: veel te veel classes en code voor iets wat veel eenvoudiger met iets geavanceerdere CSS ook gewoon mogelijk is.
Eddy E op 11/08/2016 10:03:48:
In tegenstelling tot BEM, vond ik vanochtend dit: http://acss.io/
Maar hetzelfde als in mij ogen: veel te veel classes en code voor iets wat veel eenvoudiger met iets geavanceerdere CSS ook gewoon mogelijk is.
Maar hetzelfde als in mij ogen: veel te veel classes en code voor iets wat veel eenvoudiger met iets geavanceerdere CSS ook gewoon mogelijk is.
Er zijn inderdaad meer template-talen die er, net zoals BEM, een eigen dialect van CSS op nahouden. Naast ACSS (Atomic CSS) zijn dat bijvoorbeeld SMACSS (Scalable and Modular Architecture for CSS) en OOCSS (Object Oriented CSS).
Het draait er niet om dat ze iets zouden doen dat in CSS onmogelijk is: ze gebruiken uiteindelijk immers allemaal CSS. Ik denk dat je ze meer moet zien als tussentaal die een logischer (of beter te hanteren) verband legt tussen DOM-elementen enerzijds en CSS-eigenschappen anderzijds.
Vooral het feit dat ze objectgeoriënteerd zijn, maakt ze aantrekkelijk als je ook al objectgeoriënteerd PHP gebruikt. Een BEM-block kun je zien als één klasse. Vergelijkbaar met methoden en properties in een PHP-klasse kan één zo'n CSS-klasse meerdere DOM-elementen en meerdere CSS-eigenschappen omvatten.
Gewijzigd op 11/08/2016 10:28:39 door Ward van der Put