Właściwie, niby co nie jest skodyfikowane, jest dozwolone, ale... czy BEM dotyczy także nazewnictwa stałych, używanych dajmy na to w SCSS? Chodzi mi o np. coś takiego.
$modal__center-color
czy
$modalCenterColor
Czy taki zapis w ogóle podlega ocenie na zgodność z BEM
BEM tyczy się tylko nazewnictwa selektorów.
Swoją drogą, właśnie się dowiedziałam, że coś takiego jak BEM istnieje i po pobieżnym oglądzie, wygląda mi to w większości niedorzecznie :/
Zamiast prostego:
<div class="menu">
<div>jeden</div>
<div>dwa</div>
</div>
DIV.menu {}
DIV.menu > DIV {}
Proponuje:
<div class="menu">
<div class="menu_pozycja">jeden</div>
<div class="menu_pozycja">dwa</div>
</div>
DIV.menu {}
DIV.menu__pozycja {}
Gdzie tu czytelność i (sugerowana) przenośność?
abstrahując od BEM, to DIV.menu nie jest dobrym selektorem, ponieważ uzależniamy się od tego, że coś będzie siedziało w elemencie div. Czyli pewnego dnia zamienisz* div na jakikolwiek inny element i rozjedzie ci się całe stylowanie. Chyba, że faktycznie chcesz, żeby reguła się odnosiła tylko wtedy, kiedy coś jest tylko i wyłącznie w div, ale to są rzadkie przypadki. W szczególności w tym przypadku to div na początku jest po prostu niepotrzebne.
A już kod tego typu:
DIV.menu > DIV {}
zwykle jest po prostu bardzo ryzykowny - chodzi mi teraz o tę część > DIV - czyli każde bezpośrednio dziecko, które jest divem. Strasznie to obniża elastyczność i może prowadzić do niespodziewanych efektów - bo wtedy każdy div, jaki dodajesz do pojemnika będzie miał dany styl, nawet jeśli nie powinien. Plus to, że nie możesz dodać niczego innego niż <div>, żeby zachować stylowanie.
Ogólnie stylowanie po elementach jest słabe, chyba, że robisz własną bibliotekę typu Bootstrap (albo coś innego, generycznego) albo modyfikujesz istniejącą.
Np. takie reguły jeszcze bym zrozumiał:
div {
font-family: sans-serif;
}
button {
border-radius: 5px;
border: none;
background: orange
}
czyli takie ogólne stylowanie, "temat" przewodni.
*a zwykle tak jest. Kodu nie pisze się na wieczność, ale w realnych projektach ciągle się coś może zmienić... I coś co było divem, stanie się ul, li, span, article, section albo my-fancy-whatever czy dupa-dupa).
Obecnie w dobie królowania frameworków js i tak style nie mają znaczenia ponieważ nawet jeśli konkretne komponenty mają swoje style to i tak one są ładowane w jednej skompilowanej wcześniej paczce i nie ma znaczenia czy klient obejrzy wszystkie podstrony (i ich style), ładowane są wszystkie w mixie z js.
Trochę inaczej to wygląda w MPA gdzie style mogą być ładowane w momencie wywołania podstrony przez klienta, wtedy jakaś optymalizacja ma sens.
Nawet ostatnio google się odwidziało i doradza aby w sytuacji kiedy style używane są tylko raz, w jednym miejscu to po prostu wrzucać je w html.
abstrahując od BEM, to DIV.menu nie jest dobrym selektorem, ponieważ uzależniamy się od tego, że coś będzie siedziało w elemencie div.
No niby tak i niby zapis .menu jest potencjalnie bardziej uniwersalny, ale DIV.menu pełni (jak dla mnie) też funkcję opisową, bo informuje właśnie, że to się odnosi do czegoś, co siedzi w DIV-ie, który domyślnie przyjmuje DIV-owe ostylowanie modyfikowane dopiero przez konkretną klasę. I po prostu łatwiej mi wtedy kojarzyć (w głowie) opisy z CSS z elementami w HTML.
DIV.menu > DIV {}
zwykle jest po prostu bardzo ryzykowny
No jest, ale jeśli to tylko prosty kontener zawierający proste, powtarzalne elementy (pozycje menu) to przestylowywanie tego tylko zaciemnia.
Niemniej podobnego numeru nie będę na pewno robiła odnośnie kontenerów o różnorodnej zawartości.
P.S. A tak swoją drogą, to jak spojrzę z perspektywy na swoje zwyczaje odnośnie nazewnictwa klas, to stwierdzam, że pierwotnie wymyśliłam sobie własny system zbliżony koncepcyjnie właśnie do BEM, a później od tego odchodziłam, starając się minimalizować ilość opisów.
Freja Draco napisał(a):
ale DIV.menu pełni (jak dla mnie) też funkcję opisową
Jak dla mnie to bardziej <nav> plus jakaś klasa do tego, DIV.menu to mi śmierdzi jakimś pongliszem.
czysteskarpety napisał(a):
Freja Draco napisał(a):
ale DIV.menu pełni (jak dla mnie) też funkcję opisową
Jak dla mnie to bardziej
<nav>plus jakaś klasa do tego,DIV.menuto mi śmierdzi jakimś pongliszem.
To, że konsekwentnie używam sobie polskiego nazewnictwa to jedno (i może pomińmy tutaj tę kwestię).
Natomiast pragnę wspomnieć, że osobiście uważam iż niektóre wynalazki HTML5 jak NAV właśnie gwałcą mój zdrowy rozsądek i logikę. Dla mnie to są przede wszystkim i pozostają właśnie DIV-y, a nav to dopiero ich funkcja. Mogli ro rozwiązać np. dodając nowe atrybuty: <div nav> a wymyślili coś takiego, że do tej pory nie mogę się pogodzić. I to raptem parę lat po tym, jak trwała dyskusja, żeby B I U zastąpić jednym tagiem emfazy stylowanym zależnie od potrzeb, a tu nagle taki ruch w zupełnie przeciwną stronę i mnożenie bytów.
Dla mnie to są przede wszystkim i pozostają właśnie DIV-y, a nav to dopiero ich funkcja.
Rzecz właśnie w tym, że znaczniki z założenia powinny opisywać strukturę semantyczną dokumentu, nie sposób prezentacji (od prezentacji jest w całości CSS) - Twoje menu jest rodzajem nawigacji, stąd powinno być oparte o <nav>, a wykorzystanie <div> to takie trochę leaky abstraction.
Patryk27 napisał(a):
Dla mnie to są przede wszystkim i pozostają właśnie DIV-y, a nav to dopiero ich funkcja.
Rzecz właśnie w tym, że znaczniki z założenia powinny opisywać strukturę semantyczną dokumentu, nie sposób prezentacji (od prezentacji jest w całości CSS) - Twoje menu jest rodzajem nawigacji, stąd powinno być oparte o
<nav>, a wykorzystanie<div>to takie trochęleaky abstraction.
Wychodzi z tego filozoficzny offtop, ale mój mózg i moja (prywatna) intuicja mówi mi, że mamy tu kilka niezależnych bytów:
DIV,nav, które jest czymś w rodzaju metadanej wychodzącej poza opis struktury DOM,I (mój) mózg w używaniu NAV zamiast DIV widzi po prostu psucie logicznej spójności systemu.
No ale to mój mózg i moja prywatna opinia :p
Dodatkowo 99% frameworków to <nav><ul><li> stosuje, tak więc wchodząc do teamu od razu wiesz co i jak stosując sprawdzone i znane wszystkim schematy, no chyba, że sobie klepiesz do szuflady to luz.
A tak jeszcze odnośnie koncepcji lansowanych we frameworkach.
CSS (jak wiadomo) wymyślono po to, żeby odseparować treść i strukturę od opisu sposobu jej wyświetlania.
No ale później wymyślono Bootstrapa i jego klasy :p
.text-left
.text-nowrap
.table-bordered
itp.
Bootstrap ma sass, podział na moduły, wersje jquery free, kompilatory, oddzielny grid, nie bagatelizowałbym go aż tak bardzo, ostatnio sporo ewoluował, oczywiście to framework więc momentami jest beton (jak zawsze przy gotowcach), ale ocena "porażka/zło" jest jak dla mnie lekką ignorancją.
Freja Draco napisał(a):
abstrahując od BEM, to DIV.menu nie jest dobrym selektorem, ponieważ uzależniamy się od tego, że coś będzie siedziało w elemencie div.
No niby tak i niby zapis
.menujest potencjalnie bardziej uniwersalny, aleDIV.menupełni (jak dla mnie) też funkcję opisową, bo informuje właśnie, że to się odnosi do czegoś, co siedzi w DIV-ie, który domyślnie przyjmuje DIV-owe ostylowanie modyfikowane dopiero przez konkretną klasę. I po prostu łatwiej mi wtedy kojarzyć (w głowie) opisy z CSS z elementami w HTML.
Czyli twój problem to coś w stylu:
"patrząc w regułę CSS, chciałabym widzieć, w jaki sposób dany kawałek CSSa jest używany w HTMLu"
zgadza się?
No to czemu nie rozwiążesz tego właśnie problemu, w bardziej bezpośredni sposób niż partyzanckie brudzenie sobie HTMLa?
Np. tak:
Oczywiście czasem warto mieć takie informacje pod ręką w IDE, a nie latać po plikach czy dev toolsach, to też jestem w stanie zrozumieć.
Ale w takim razie:
Pytanie tylko, czy zależy ci na tym ficzerze tak bardzo, że aż będziesz chciała poświęcić czas, żeby napisać wtyczkę.
Może nie, może tak.
No i może to brzmi jak overkill, ale na serio myślę, że już lepiej napisać wtyczkę(albo poszukać istniejących albo edytora/IDE, które będzie miało to out of the box) niż brudzić sobie kod w ten sposób (i sprawiać, że staje się mniej utrzymywalny, bo z moich doświadczeń wcześniej czy później się coś zmieni. I czasem cała podstruktura HTMLa jest do wywalenia. I w najlepszym wypadku style trzeba pisać całkowicie od nowa (w najgorszym to nie da się napisać od nowa, za to istniejące style powodują potem jakieś dziwne konflikty i bugi wizualne, bo np. było założenie, że coś ma być divem, a potem jest np. ul i już kasza. Podobnie z hierarchią. Jeśli zakładamy coś takiego > div to też zwykle będzie to jedna z pierwszych rzeczy, która się zmieni).
EDIT: do VSCode jest wtyczka CSS Navigation, która pozwala ci podejrzeć, gdzie jest używana dana reguła CSS
https://marketplace.visualstudio.com/items?itemName=pucelle.vscode-css-navigation
chociaż sprawdzałem to na czystym CSS i czystym HTML, nie wiem, jak to sobie radzi w innych przypadkach.