Tip untuk Struktur CSS untuk Situs Web Bisnis (atau Apa Pun untuk Hal Itu)

CSS dan HTML mudah dimengerti. Namun, dibutuhkan latihan bertahun-tahun untuk mempelajari pendekatan arsitektur terbaik saat membangun situs web (dan aplikasi) dengan cara yang membuatnya dapat digunakan kembali, dipelihara di masa mendatang, dan membuat pengembang senang.

Apa yang dimaksud dengan arsitektur di sini? Ini adalah struktur kode CSS. Cara Anda memisahkannya menjadi file, aturan di balik nama kelas, kedalaman penyeleksi, cara berjenjang, apa yang diwarisi, cara Anda menyiapkan komponen, halaman, elemen, dan pengubah.

Untuk menerapkan praktik terbaik ke semua komponen situs web ini dengan ratusan halaman, berbagai jenis konten, tampilan layar, kasus tepi, dan dengan pertimbangan untuk menambahkan lebih banyak di atas dan memodifikasi yang sudah ada adalah bagian yang sulit.

Bangun Dengan Komponen, Bukan Halaman

Ini adalah salah satu bagian utama yang perlu dipertimbangkan. Anda tidak boleh mengatur gaya berdasarkan halaman tempat Anda berada. Jangan lakukan gaya .homepage… {}. Jika halaman Anda memiliki bagian, berikan gaya pada bagian tersebut. Dengan itu, Anda juga dapat menggunakannya kembali di halaman lain. Jika Anda memiliki tombol, beri gaya tombol seperti .button {} dan gunakan kembali di tempat lain. Ini berlaku untuk semua tampilan.

Ini adalah saran paling umum dan pendekatan berkinerja terbaik (sejauh ini) yang dapat Anda manfaatkan.

Sekarang, bagaimana Anda mengelola perbedaan khusus halaman? Karena ini adalah alasan paling umum untuk menata gaya per halaman? Nah, ada beberapa pendekatan:

Gunakan pengubah.

Dalam "BEM", "M" adalah singkatan dari Modifier. Ini adalah tampilan .block__child – modifier. Bahkan jika Anda tidak menggunakan BEM, pengubah tetap ada. Jika ada variasi pada komponen atau bagian, tambahkan pengubah untuk itu.

Idealnya, perancang harus bijaksana dan menjaga variasi seminimal mungkin untuk menjaga kode tetap bersih, tetapi Anda tidak perlu takut untuk menambahkannya lebih banyak. Variasi idealnya hanya menimpa beberapa properti dan harus bekerja dengan markup yang sama. Ini adalah cara yang baik untuk mendekati komponen dalam fase HTML - tambahkan tag yang Anda perlukan dan pertahankan agar konsisten di seluruh situs. Jangan tambahkan yang baru karena kelas pengubah.

Gaya komponen anak-anak.

Pendekatan lainnya adalah gaya berdasarkan konteks. Tombol selalu merupakan tombol, ia memiliki kelas .button dan segalanya, tetapi Anda masih dapat menyesuaikannya jika itu bagian dari komponen lain. Ini umumnya bukan ide yang baik karena menciptakan ketidakkonsistenan, tetapi ini juga merupakan kasus penggunaan yang cukup realistis. Jika tidak, Anda akan mendapatkan 20 pengubah dengan nama yang aneh.

Gaya berdasarkan konteks adalah saat Anda memberi gaya pada satu komponen hanya jika itu adalah anak dari komponen lainnya. Mari kita ambil kartu artikel sebagai contoh. Ini memiliki gayanya secara default. Tetapi jika itu adalah bagian dari bagian warna-warni dengan beberapa teks di samping, desain mengharuskan kartu memiliki beberapa elemen lain di sekitarnya (seperti bentuk animasi, dll).

Dalam hal ini, Anda mengatur gaya dengan pemilih .parent .card {}. Anda hanya perlu menimpa beberapa properti seperti yang akan Anda lakukan dengan pengubah. Ketika Anda melakukan itu, kartu itu sendiri tidak menambahkan lebih banyak kerumitan pada gayanya, tetapi masih akan berperilaku dengan baik pada kasus tepi tertentu.

Ketika Anda memikirkan hal ini, Anda juga dapat melihat bagaimana ini dapat diterapkan pada basis "per halaman". Jika ada beberapa kasus tepi yang aneh dalam desain dan ada beberapa perbedaan kecil dari tampilan komponen standar (dan cara mereka semua berinteraksi bersama), maka Anda bisa mengaturnya dengan selektor .homepage {}. Ingatlah untuk menggunakannya dengan hemat. Dalam pengalaman kami, gaya seperti itu jarang melebihi beberapa baris kode.

Catatan penting untuk ditambahkan: Gaya berdasarkan konteks BUKAN merupakan praktik yang baik secara umum. Idealnya Anda bahkan tidak membutuhkan itu. Sebagian besar waktu, Anda akan memiliki pengubah yang harus melakukan pekerjaan dengan cukup baik. Meskipun realistis dalam beberapa build, menyelam terlalu jauh ke dalam kode abstrak yang bagus dengan aturan yang ketat bisa jadi terlalu mahal.

Bekerja di Bagian

Sebagian besar situs web bisnis (serta banyak lainnya dalam hal ini) memisahkan konten menjadi beberapa bagian. Setiap bagian adalah komponennya sendiri dengan kelas pengubah yang mendefinisikan berbagai properti. Satu saran untuk menyesuaikan dengan struktur kelas adalah:

• section.section-container - ini bisa menjadi "nama komponen" jika Anda mau, yang menyimpan paddings / margin yang konsisten atau apa pun yang diperlukan.
• section.section-border-top - adalah pengubah. Ini tidak menggunakan BEM, tetapi Anda dapat “menerjemahkan” ke section-container – border jika diperlukan.
• section.section-welcome - akan menjadi nama bagian.

Konvensi penamaan sekali lagi tidak relevan di sini. Dengan bagian seperti itu, Anda akan mendapatkan kebebasan untuk menyesuaikan gaya ke komponen yang dapat digunakan kembali dalam casing tepi yang dibuat oleh desain (baik itu karena ketidakkonsistenan yang harus diikuti atau hanya tampilan yang lebih rumit).

Pemisahan file

Kemungkinan besar Anda akan menggunakan Sass atau preprocessor serupa lainnya. Dalam hal pemisahan file, ada banyak pendekatan, tetapi yang kami ambil mengikuti struktur umum berikut:

• Umum - Umum biasanya terdiri dari kode penyiapan seperti membuat kisi berfungsi, gaya ke tag HTML, penyetelan ulang / normalizer, beberapa gaya khusus CMS dan sejenisnya.
• Halaman - Gaya halaman seperti dijelaskan di atas. Idealnya, Anda harus menyimpan sedikit kode di sini.
• Komponen - Inti dari build - berbagai komponen berada di sini. Salah satu tipnya adalah Anda dapat memiliki "elemen" atau "misc" yang akan memasukkan potongan kecil komponen ke dalam satu file, bukan 80 file. Yang lebih besar tentu saja idealnya harus disimpan dalam file terpisah.
• Tata Letak - Gaya global, misalnya, di Header, Footer, lalu tata letak halaman, pengubah kisi, dan sebagainya.
• Plugins - Apa pun yang bersifat eksternal yang dihasilkan dari plugin, ekstensi, atau apa pun. Sangat menyenangkan untuk memisahkannya karena Anda dapat menggunakannya kembali di proyek lain.

Jaga agar Pemilih Tetap Bersih

Pertanda baik dari kode bersih adalah betapa sederhananya tampilannya. Tidak ada properti aneh, semuanya ada tujuannya, ada lekukan rendah. Penyeleksi "Terlihat pintar" saat tidak perlu tidak membuat kode Anda "keren". Jika Anda dapat mengganti sesuatu seperti #container> .row div [rel = ”sesuatu”] dengan .rel-sesuatu (bayangkan itu adalah nama kelas yang berarti), maka Anda harus memperbarui markup sedikit. Tujuannya adalah untuk membuat semuanya lebih sederhana.

Jaga agar lekukan tetap rendah. Anda jarang perlu naik lebih dari tiga level. Mari kita lihat, misalnya, kelas .entry:

.masuk { ... }
.entry-title {...}

Lihat bahwa tidak perlu benar-benar membuat indentasi .entry-title di dalam .entry. Nanti, saat Anda menambahkan pengubah ke bawah file, Anda bisa memiliki .entry-modifier {} dan .entry-modifier .entry-title {}

Dengan pendekatan ini, penimpaan gaya di masa mendatang jauh lebih mudah. Mari kita lihat contoh umum lainnya: Anda memiliki markup nav.site-nav> ul.list-menu> li.list-items * 5> a (emmet)

Sekarang, untuk menata, yang Anda butuhkan hanyalah:

.site-nav {} - komponen 1

.list-menu {} - komponen 2
.list-menu .list-item {}
.list-menu a {}

Jika Anda memiliki lebih banyak komponen di dalamnya, seperti tarik-turun tambahan, Anda dapat menumpuknya langsung di dalam .list-menu. Anda tidak perlu menulis .site-nav .list-menu .list-item .dropdown {} (kedalaman 4 level) bila Anda bisa memiliki dua level .list-menu .dropdown {}

Tulis Lebih Banyak Nama Kelas Abstrak untuk Pengubah

Yang ini berlaku untuk pemeliharaan. Contoh umum yang akan Anda temukan di posting serupa adalah tidak menyetel variabel warna ke $ merah, Anda malah akan menyetelnya ke $ primer atau $ sekunder.

Alasannya adalah ketika perubahan diperlukan, variabel $ red akan mengeluarkan warna biru. Lebih masuk akal jika Anda ingin mengubah warna primer Anda, bukan warna merah Anda, bukan?

Hal yang sama berlaku untuk jenis warna dan properti lainnya. Katakanlah Anda memiliki garis yang memisahkan beberapa konten (seperti tag <hr>). Sebut saja .line-dash karena itu putus-putus. Masuk akal. Tapi kemudian perubahan datang dan itu harus diselesaikan. Apakah Anda pergi dan mengganti namanya menjadi .line-dotted? Ini bukan pengubah, ini adalah komponen. Alih-alih ini, Anda dapat menamainya sebagai .line-separator. Dan kemudian jika Anda ingin lebih spesifik, Anda dapat menambahkan pengubah untuk .dotted atau .dashed. Jenis penamaan ini sering kali memakan waktu paling banyak saat membangun situs.

Singkatnya

Ada praktik baik dan buruk yang tak terhitung jumlahnya. Salah satu cara untuk mencapai hasil yang lebih baik adalah dengan menetapkan aturan dan mengikutinya. Sulit untuk membuat aturan seperti itu, jadi satu saran yang baik adalah menjelajahi web dan mencoba mengumpulkan semua informasi yang mungkin tentang arsitektur seperti konvensi penamaan, praktik yang baik, cara menulis kode yang dapat dipelihara, dan banyak lagi.

Untuk menghasilkan kode yang baik membutuhkan banyak waktu dan ratusan ribu baris kode. Saat melakukan semua itu, selalu tanyakan pada diri Anda "Apakah skala itu?", "Dapatkah saya menggunakannya kembali?", "Apakah saya terlalu banyak menimpa?", "Apakah masuk akal untuk menamainya seperti ini?". Semakin banyak Anda melakukannya, semakin optimal keputusan Anda dan semakin cepat kecepatan kerja Anda.

Investasi pada fundamental yang baik akan menghasilkan lebih sedikit bolak-balik pada proyek Anda dan setiap perubahan di masa depan yang perlu terjadi akan jauh lebih mudah untuk diterapkan.