CSS Tanımlarını İsimlendirme – BEM Nedir?

Block, Element, Modifier (Blok, Eleman, Değiştirici) metodolojisi (genellikle BEM olarak adlandırılır), HTML ve CSS’deki sınıflar için popüler bir adlandırma kuralıdır. Yandex’deki ekip tarafından geliştirilen hedefi, geliştiricilerin belirli bir projedeki HTML ve CSS arasındaki ilişkiyi daha iyi anlamalarına yardımcı olmaktır.

BEM stilinde yazan bir CSS geliştiricisinin yazabileceklerine bir örnek:

Bu CSS yönteminde blok, yeni bir bileşenin üst düzey soyutlamasıdır, örneğin bir button: .btn{}. bu blok bir ebeveyn olarak düşünülmelidir. Alt öğeler veya öğeler içine yerleştirilebilir ve bunlar, .btn__price{} gibi bloğun adından sonra iki alt çizgiyle gösterilir. Son olarak, değiştiriciler bloğu manipüle edebilir, böylece tamamen ilgisiz bir modülde değişiklik yapmadan belirli bir bileşeni temalayabilir veya stil uygulayabiliriz. Bu, btn–primary gibi blok adına iki tire eklenerek yapılır.

İşaretleme daha sonra şöyle görünebilir:

Başka bir geliştirici bu işaretlemeyi yazdıysa ve CSS’ye aşina değildiyse, hangi sınıfların neye ve nasıl bağımlı olduklarından hangi sınıfların sorumlu olduğu konusunda hala iyi bir fikri sahibi olunmasını sağlar. Geliştiriciler daha sonra kendi bileşenlerini oluşturabilir ve mevcut bloğu içeriğine göre değiştirebilir. Çok fazla CSS yazmadan, geliştiriciler potansiyel olarak yalnızca işaretlemedeki bir sınıfı değiştirerek birçok farklı buton kombinasyonu oluşturabilirler:

Başlangıçta bu sözdizimi, her bir buton türü için yeni bir sınıf yapmaktan daha yavaş görünebilir, ancak bu, ele alacağımız birkaç nedenden ötürü durum böyle değildir.

Neden BEM’i düşünmeliyiz?

• Bir bileşenin yeni bir stilini yapmak istiyorsak, hangi değiştiricilerin ve çocukların zaten var olduğunu kolayca görebiliriz. İlk başta herhangi bir CSS yazmamız gerekmediğinin farkında bile olabiliriz, çünkü ihtiyacımız olanı yapan önceden var olan bir değiştirici var.
• CSS yerine biçimlendirmeyi okuyorsak, hangi öğenin diğerine bağlı olduğu hakkında hızlı bir şekilde bir fikir edinebilmeliyiz (önceki örnekte, .btn__price öğesinin .btn’ye bağlı olduğunu görebiliriz, bunun ne olduğunu bilmesek bile.)
• Tasarımcılar ve geliştiriciler ekip üyeleri arasında daha kolay iletişim için bileşenleri sürekli olarak adlandırabilirler. Başka bir deyişle, BEM bir projedeki herkese aynı sayfada olmaları için paylaşabilecekleri bildirici bir sözdizimi verir.

CSS ile ilgili sorunlar

Tabii ki BEM kurallarından koparsanız kimse size kızmayacaktır. Yine de böyle bir CSS seçici yazabilirsiniz:

BEM’in bazı bölümleri var gibi görünüyor, ancak BEM değil. İç içe seçicileri vardır ve değiştirici neler olup bittiğini doğru bir şekilde tanımlamaz. Bunu yapsaydık, BEM ile çok yardımcı olan özgüllük düzlüğünü bertaraf ederdik.

Bir block(.nav gibi) hiçbir zaman başka bir blok veya değiştiricinin (.btn-info gibi) stillerini geçersiz kılmamalıdır. Aksi takdirde, HTML’yi okumak ve bu bileşenin ne yaptığını anlamak neredeyse imkansız hale gelir; Bu süreçte başka bir geliştiricinin kod tabanına olan güvenini büyük ölçüde sarsmak zorundayız. Bu, HTML için de geçerlidir: Aşağıdaki işaretlemeyi görürseniz ne beklersiniz?

Muhtemelen burada olup bitenler, tamamen ilgisiz bir bloktaki bir öğenin geliştiricinin ihtiyaç duyduğu koda sahip olması, ancak alt öğelerin üst öğe olarak .nav sınıfı gerektirmemesi. Bu, her ne pahasına olursa olsun kaçınılması gereken son derece kafa karıştırıcı ve tutarsız bir kod tabanı sağlar. Bu sorunları şu şekilde özetleyebiliriz:

• İlişkisiz bir blokta değiştiricileri asla geçersiz kılma.
• Çocuk kendi başına mutlu bir şekilde var olabildiğinde gereksiz ebeveyn unsurları yapmaktan kaçınmak.

Bir şeyleri tamamlamak için, BEM’in tüm sorunlarımızı çözmese de, takımdaki herkesin işlerin nasıl geliştirilebileceği konusunda net bir fikre sahip olması gereken ölçeklenebilir ve sürdürülebilir arayüzler oluşturmak için olağanüstü yararlı olduğunu söylemek doğru olur. Bunun nedeni, çok sayıda ön uç geliştirmenin sadece kısa vadede küçük bir sorunu çözen güzel hilelerle ilgili olmamasıdır; kod tabanımızın zaman içinde uyum sağlayabilmesi için geliştiriciler arasında anlaşmalara, vaatlere ve bağlayıcı sosyal sözleşmelere ihtiyacımız var.