BEM a nazwy stałych

Odpowiedz Nowy wątek
2019-05-10 10:57
0

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

Pozostało 580 znaków

2019-05-10 11:58
1

BEM tyczy się tylko nazewnictwa selektorów.


Pozostało 580 znaków

2019-05-10 13:09
1

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ść?


Pokaż pozostałe 3 komentarze
@Patryk27: ktoś stworzył sobie globalny .separator No i (między innymi właśnie dlatego) uważam, że klasy .globalne nie są zbyt dobrym pomysłem :) - Freja Draco 2019-05-10 15:01
teraz się robi często tak, że klasy są lokalne (tzn. na poziomie pisania kodu, bo na poziomie implementacji to jest generowana po prostu unikalna globalna klasa o dziwnej nazwie, coś jak class="a4b8Zoie"). - LukeJL 2019-05-10 15:05
CSS modules tak działa choćby - LukeJL 2019-05-10 15:07
Nawet nie tworząc globalnych klas możesz nadziać się na zagnieżdżone selektory: https://css-tricks.com/bem-101/. Warto zauważyć, że skoro jakiś sposób pisania kodu CSS stał się całkiem popularny, to prawdopodobnie istnieje za tym jakiś sensowny powód ;-] Chociaż personalnie również nie przepadam za BEM. - Patryk27 2019-05-10 15:08
zastanawiam się czy zamiast tworzyć milion dodatkowych klas nie prościej odnieść się po prostu do konkretnych elemetów np. .container a {} czy .container span {} a potem jesli zajdzie potrzeba tworzyć nowe klasy. - czysteskarpety 2019-05-10 15:16

Pozostało 580 znaków

2019-05-10 14:14
3

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).


((0b10*0b11*(0b10**0b101-0b10)**0b10+0b110)**0b10+(100-1)**0b10+0x10-1).toString(0b10**0b101+0b100);
edytowany 2x, ostatnio: LukeJL, 2019-05-10 14:17

Pozostało 580 znaków

2019-05-10 14:46
0

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.


Pozostało 580 znaków

2019-05-10 14:56
0

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.


edytowany 2x, ostatnio: Freja Draco, 2019-05-10 14:58

Pozostało 580 znaków

2019-05-10 15:02
0
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.


Pozostało 580 znaków

2019-05-10 15:12
0
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.menu to 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.


Pozostało 580 znaków

2019-05-10 15:16
0

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.


edytowany 2x, ostatnio: Patryk27, 2019-05-10 15:17

Pozostało 580 znaków

2019-05-10 15:29
0
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:

  • położenie w strukturze DOM i rodzaj elementu, np DIV,
  • wszelkie atrybuty i style (w których w zasadzie mieści się też):
  • znaczenie elementu, np nav, które jest czymś w rodzaju metadanej wychodzącej poza opis struktury DOM,
  • treść.

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


Pozostało 580 znaków

2019-05-10 15:29
0

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.


Jest jak jest i w kopaniu się z koniem (a nawet całą federacją tabunów koni) sensu nie widzę. Niemniej swoją opinię mam :> - Freja Draco 2019-05-10 15:31
luz, nikt nie będzie się z Tobą kopał, po prostu nikt nie będzie chciał współpracować przy bardziej zaawansowanych projektach - czysteskarpety 2019-05-10 15:40
easy rider ;) - Freja Draco 2019-05-10 15:42

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0