Praktik Terbaik CSS: Sembilan Tanda CSS yang Buruk

CSS atau Cascading Style Sheets - Bahasa yang menentukan bagaimana halaman web harus terlihat, dan terkadang berperilaku. Ini sering diabaikan oleh pengembang web sebagai bahasa "mudah" yang tidak membutuhkan terlalu banyak perhatian. Mengingat beberapa properti yang paling umum, alur umum dan googling properti yang lebih tidak jelas adalah caranya. Namun, seperti yang diketahui oleh developer yang lebih berpengalaman, tidak ada bahasa yang pantas untuk diabaikan karena selalu ada cara baik dan buruk untuk melakukan sesuatu.

Dengan CSS, sangat mudah untuk melakukan sesuatu dengan cara yang salah karena tidak ada kompiler yang menghasilkan kesalahan, tidak ada peringatan atau pemberitahuan untuk implementasi yang buruk. Bahasa pemrograman seperti JavaScript memiliki banyak alat yang melacak kualitas kode yang baik, beberapa bahkan melempar pesan ke pengembang bahwa fungsi tertentu belum diterapkan dengan benar.

Dalam posting yang relatif singkat ini kita akan melihat beberapa masalah umum yang dihadapi pengembang dan cara memperbaikinya. Ini bukan tentang detail implementasi khusus untuk komponen visual tertentu. Sebaliknya, daftar tersebut berfokus pada proses pemikiran, arsitektur, dan pendekatan.

Kompleksitas CSS

Apakah CSS sulit? Tidak! Jelas tidak, ia memiliki beberapa aturan struktural yang sangat mendasar. Anda memiliki penyeleksi (kelas, id, elemen), Anda memiliki properti dan Anda memiliki ruang lingkup. Ini jauh lebih sedikit dari bahasa seperti C, Java atau PHP. Pengembang bisa mendapatkan seluruh ide dalam beberapa menit setelah membaca dan memulai gaya. Tentu saja, untuk mengetahui perbedaan antara margin dan padding, Anda dapat melihat w3schools, tetapi kapan menggunakannya yang membutuhkan pengalaman. Tapi ini bukan ilmu roket.

Sekarang, yang membuat hal-hal sedikit lebih rumit adalah semua cara penyeleksi berlomba yang akan menimpa properti berikutnya, dan bagaimana satu properti memengaruhi properti lainnya (misalnya display: block vs display: inline). Kemudian kami memiliki detail yang lebih kecil seperti margin collapsing, z-index stacking, GPU vs CPU performance properties, model kotak dan properti tipografi.

Di atas semua itu, fitur CSS baru yang tidak selalu diterapkan dengan cara yang sama di seluruh browser, beberapa bahkan tidak diterapkan sama sekali dan yang lainnya memerlukan properti yang berbeda.

Jika kita melihat dua paragraf di atas, kita akan melihat dua tahap utama yang dicapai developer front-end saat mereka bekerja dengan CSS - Salah satunya adalah " Oh, apakah itu semua? "Dan yang kedua adalah" Oh ****, itu belum semuanya ". Inilah yang dimaksud dengan "Kompleksitas CSS"

Ada banyak hal kecil yang saling terkait dan sulit untuk ditingkatkan. Jika Anda membangun hanya satu komponen, itu mudah - Anda mengatur gaya apa pun yang Anda lihat dan itu berhasil. Tapi letakkan komponen tunggal itu dalam aplikasi yang lebih besar dan gaya tambahan akan diterapkan. Anda mungkin berakhir dengan kelas yang sama dengan yang lain (seperti .button) dan gaya Anda akan diterapkan di seluruh aplikasi, merusak semuanya. Ini membuat stres!

CSS WordPress: Panduan Dasar untuk Pemula

Cara Menulis CSS: Memerangi Kompleksitasnya

Ada beberapa solusi yang ditemukan oleh orang pintar, gambarannya adalah:

• Konvensi Penamaan CSS seperti BEM, SMACSS dan lainnya, yang mendefinisikan aturan nama kelas yang akan mengurangi kemungkinan bentrokan.
• CSS di JS adalah metode baru yang secara praktis memungkinkan Anda menulis komponen CSS dalam file JS (terdengar buruk, terlihat buruk, tapi setidaknya masuk akal). Sebagian besar valid dengan React, Vue, dan lainnya.
• Modul CSS adalah pendekatan yang lebih masuk akal untuk CSS di JS bagi seseorang yang berakhir dengan semua gaya dalam satu file. Modul CSS merangkum gaya setiap komponen sehingga tidak dapat bocor ke komponen lain, membuat penggunaan kembali jauh lebih mudah. Ini juga mengurangi stres dengan banyak!

Yang pertama - Konvensi Penamaan mungkin yang paling sulit diterapkan karena tidak memiliki alat untuk membantu Anda. Itu menyerahkan semuanya kepada Anda sebagai pengembang untuk memahami dan menerapkan konvensi. Anda masih harus memikirkan nama kelas, mereka tetap tidak boleh bentrok dan kemudian Anda harus membuat seluruh tim mengikutinya. Cukup sulit!

CSS dalam Modul JS dan CSS adalah perbaikan implementasi. Mereka mengubah keluaran kode secara keseluruhan, yang secara praktis membuatnya tidak mungkin untuk membocorkan gaya. Tetapi mereka membutuhkan pemikiran dan pengaturan yang sama sekali berbeda, sesuatu yang tidak selalu dapat dilakukan atau diinginkan.

Saran terbaik di sini adalah: Pelajari konvensi penamaan yang paling umum dan sukses, gunakan yang sesuai dengan standar pengkodean perusahaan atau ekosistem Anda. Pahami pemisahan komponen dan mulailah berpikir dalam hal ruang lingkup dan unit tunggal yang membangun aplikasi besar. Bukan aplikasi besar sejak awal, yang tidak mungkin dikelola.

Jika Anda mengerjakan tumpukan yang termasuk sebagai pustaka seperti React atau kerangka kerja seperti Vue, lihat alat tambahan yang memungkinkan Anda untuk mengelola gaya Anda dengannya. Untuk pengembang CSS tingkat pemula hingga menengah, mereka akan sangat membantu! Dan Anda mungkin tidak pernah ingin membuangnya kecuali sesuatu yang lebih baik menghampiri Anda.

Pantau terus alat-alat baru! Mereka menghentikan kami untuk memerangi masalah yang telah ditemukan, diperbaiki, dan disediakan oleh komunitas pengembang untuk mengatasinya.

Sekarang setelah kami menguraikan apa arti Kompleksitas CSS dan beberapa tip pemula untuk melawannya, mari selami gambaran umum yang lebih mendetail dan memberikan contoh langsung.

Tips Desain Situs Web: Cara Meningkatkan Game Anda dalam Desain Web

Sembilan Tanda CSS yang Buruk

Daftar ini jelas tidak lengkap, tidak terlalu jauh. Sayangnya, Anda akan menghadapi masalah lain yang tak terhitung jumlahnya dan semoga menemukan solusi langsung untuk masalah tertentu di situs seperti Stackoverflow.
Namun, jika Anda ingin meningkatkan permainan Anda, ketika Anda memperbaiki masalah dengan beberapa baris css, Anda harus memahami apa yang mereka lakukan. Mengapa Anda harus mengubah markup Anda, dan mengapa Anda harus mengubah beberapa pemilih, properti?

Margin bertindak aneh

Masalah umum yang dihadapi developer adalah ketika dua elemen tidak menambahkan marginnya (atas / bawah). Misalnya, kami memiliki dua elemen <p> dengan margin: 20px 0 ;. Total spasi di antara keduanya adalah 20 piksel, bukan 40. Ini karena margin menciut. Kecuali jika elemen mengapung atau diposisikan secara mutlak. "Kecuali" ini hampir ada di mana-mana untuk hampir setiap definisi.

Z-index: 9999999 dan masih belum di atas z-index: 1

Pertama-tama, jarang ada kebutuhan untuk menulis indeks-z setinggi itu. Saya bahkan pernah melihat nilai seperti 99999999999999 atau lebih. Pertama, nilai maks indeks-z adalah 2147483647, jadi apa pun di atas tidak berguna. Kedua, tidak bekerja seperti itu. Elemen mana yang berada di atas ditentukan oleh konteks penumpukan, bukan hanya nilai indeks-z. Lihat grafik di bawah ini:

Tidak Menganimasikan Properti yang Benar

Ini pertanyaan yang agak sederhana, tetapi beberapa pengembang kesulitan dalam hal animasi dan pendekatan yang harus diambil. Pertama, apa yang bisa dianimasikan? Apa pun yang dapat memiliki nilai awal, nilai akhir, dan apa pun di antaranya. Opacity adalah properti seperti itu, Anda dapat mulai dari 0, berakhir pada 1, dan menambahkan langkah tak terbatas antara seperti 0,3, 0,6758, 0,9875 dll. Anda tidak dapat menganimasikan "tampilan" karena tidak ada langkah tengah antara sebaris dan kisi.

Animasi Tidak Efisien

Alasan paling umum untuk FPS yang buruk pada animasi adalah karena properti yang salah dianimasikan. Jika Anda mengubah properti "kiri" dari elemen absolut, Anda akan menggunakan CPU untuk menghitung. Namun, jika Anda menggunakan transformasi, maka itu adalah GPU-nya. Dan GPU seperti yang kita semua tahu lebih baik untuk membuat grafik.

Tapi bagaimana Anda menganimasikan bayangan, ketika tidak ada alternatif seperti kiri / transformasi? Nah, animasikan opacity! Memiliki dua elemen, satu dengan kondisi awal, status, satu dengan kondisi akhir. Kemudian pudarkan awal dan akhir. Ini akan membuatnya tampak seperti bayangan mengembang, padahal sebenarnya hanya memudar.

JANGAN menganimasikan elemen yang memengaruhi tata letak jika memungkinkan. Perhitungan tata letak mahal dan CPU hanya dapat melakukan perhitungan dalam jumlah terbatas. Seringkali, kurang dari satu setiap 16 md, yang akan menghasilkan FPS di bawah 60.

Selektor Terlalu Dalam

Apa itu pengubah? Kelas, yang dapat Anda tambahkan ke kelas lain dan mengganti beberapa propertinya. Contoh: .tombol memiliki warna: merah. .button-primary, memiliki warna: biru. Jadi, saat Anda menambahkan .button-primary ke .button, Anda akan mendapatkan warna biru. Sangat mudah. Meskipun, tidak setiap saat semudah itu. Dan tidak setiap kali komponen seperti ini.

Terkadang, kami ingin menimpa komponen, turunan dari komponen lain di halaman tertentu. Jadi kita berakhir dengan sesuatu seperti ini: .page-name .section-name .component-1 .component-2 {…} Sudah dalam empat level. Tapi ternyata kita cukup melakukan .page-name .componen-2 {…}. Lebih pendek lebih baik! Karena jika kebetulan karena suatu alasan Anda harus menimpa gaya baru itu, Anda tidak harus masuk 5 level lebih dalam, lalu 6, lalu lebih.

Penyeleksi mendalam itu menakutkan dan orang akhirnya menggunakan! Penting. ! important harus digunakan saat Anda ingin menimpa gaya sebaris yang tidak dapat Anda kendalikan. Jika tidak, itu pertanda bahwa Anda tidak melakukan sesuatu dengan benar.

File terlalu besar

Sekarang, tentu saja, untuk aplikasi besar akan ada banyak gaya, dan itu sangat bisa dimengerti. Tapi apakah selalu sebesar itu? Cara yang buruk untuk memperluas kelas di SASS (melalui mixin) akan menghasilkan rantai pemilih yang besar, yang memerlukan beberapa detik untuk menggulir untuk melihat semuanya. Ekstensi yang tepat akan banyak mengurangi file itu. Bahkan bisa menggandakan ukurannya.

Kerangka kerja yang disertakan, yang hanya menggunakan sedikit properti yang digunakan juga merupakan alasan umum untuk file besar. Gabungkan bootstrap / foundation, font-awesome, animate.css dan beberapa framework / library serupa lainnya dan Anda akan mendapatkan file besar dari mana Anda menggunakan sekitar 2%. Bersihkan, jaga agar tetap rapi dan gunakan hanya yang benar-benar dibutuhkan. Seringkali bahkan tidak diperlukan kerangka kerja.

Kerangka kerja saat tidak diperlukan

Bootstrap, Foundation, UIKit, dan semua kerangka kerja lainnya sangat bagus! Mereka memecahkan masalah nyata dan sangat berharga bagi komunitas pengembangan web. Tidak perlu mengetahui HTML atau CSS dengan baik untuk membuat dasbor dan situs. Tapi tinggalkan kasus itu, mulailah menulis beberapa CSS dan Anda akan menemui beberapa masalah.

• Anda harus memahami dengan benar bagaimana membangunnya dan bagaimana memasukkannya
• Anda harus membaca dokumentasinya untuk menemukan pengaturan kustom dan mixin yang mereka sediakan.
• Anda harus mengikuti markup mereka dan mengajari tim Anda untuk melakukannya.
• Anda harus benar-benar memahami cara memperluas dan gaya untuk membuat tampilan yang unik.

Memasukkannya dengan benar berarti Anda hanya menggunakan apa yang Anda butuhkan. Agar kerangka kerja seperti itu membantu Anda alih-alih melarang Anda membangun sesuatu yang khusus, Anda harus tahu bahwa itu cara kerja yang lebih baik daripada rata-rata. Dan untuk mencapai desain khusus apa pun, Anda harus mengubah pengaturan dan properti. Dan kemudian tulis beberapa CSS khusus. Dan CSS khusus itu untuk menimpa apa pun yang diberikan kerangka kerja.

Jadi jika tidak ada kebutuhan nyata untuk kerangka kerja CSS seperti itu, tetapi masih ada satu dan tidak digunakan dengan benar, ini adalah tanda bahaya bahwa ada sesuatu yang salah. Dan ketika Anda memulainya sekali, kemungkinan besar Anda akan menggunakannya sampai akhir siklus hidup proyek. Jadi itu keputusan penting.

Tidak mengizinkan konten untuk menentukan ukuran

Yang ini lebih merupakan masalah level pemula, tapi ini masalah yang sangat umum. Anda harus memberi konten kebebasan yang layak.

Contoh, Anda tidak ingin menyetel properti lebar situs menjadi 1200px. Anda ingin menyetel lebar maksimal menjadi 1200 piksel. Dengan begitu, viewport akan memungkinkan situs Anda tetap responsif.

Kemudian, bidang masukan tidak boleh memiliki tinggi 40 piksel, harus memiliki bantalan 1em. Sekarang, ukuran font, konten adalah yang menentukan ukurannya. Dan jika konten di dalamnya bertambah, elemen tersebut tidak akan rusak.

Cara berpikir seperti ini saat menentukan ukuran tetap penting di seluruh aplikasi. Dan setiap properti harus mempertimbangkannya. Idealnya, jangan menetapkan% untuk lebar pada area konten, karena Anda juga harus menulis kueri media.

Jika Anda memiliki lebar maksimal, saat browser Anda menyusut di bawah lebar maksimal itu, konten akan memenuhi lebar browser dan kemudian menyusut secara normal. Jika tidak, Anda harus menulis kueri media untuk ukuran tersebut. Dan kemudian untuk ukuran khusus lainnya yang tertulis di situs. Ini adalah kompleksitas yang ditambahkan karena pendekatan yang buruk. Hampir sama dengan semua poin lain yang sudah kita bahas.

Peretasan JavaScript

JavaScript dapat melakukan keajaiban! Tapi itu tidak selalu dibutuhkan. Anda dapat melakukan banyak hal hanya dengan CSS yang didukung dengan baik, tidak memerlukan fungsionalitas (yang paling baik diuji secara otomatis setelahnya) dan tidak mengharuskan anggota FE Anda yang lain untuk mengetahui JS juga.

Tentu saja, ada fungsi toggle standar, di mana Anda dapat menggunakan masukan kotak centang untuk mengubah gaya ketika: dicentang, ada hamparan latar belakang yang dapat dengan mudah dipicu dan ada properti seperti penghitung untuk membuat lebih dari sekadar daftar <ol> .

Saran di sini adalah mencari solusi CSS terlebih dahulu. Katakanlah Anda ingin membuat popup. Itu muncul di tengah (posisi: tetap). Kemudian Anda ingin menutupnya dari ikon [X] atau saat Anda mengekliknya. Di JS Anda perlu menulis peristiwa yang akan memicu apa pun kecuali konten popup. Tapi tetap trigger di [X] yang ada di konten popup.

Sebagai gantinya, dari CSS Anda bisa menulis <div> lain yang memiliki 100vw, ukuran 100vh dan indeks-z tepat di bawah popup. Kemudian Anda cukup menargetkan div itu di JS, yang merupakan satu baris.

Contoh lain - Anda menginginkan tombol yang dapat Anda tempatkan di konten, yang akan "memperluas" konten apa pun yang mengikutinya. Sederhana dengan CSS, sedikit lebih kompleks dengan JS. Dengan CSS Anda dapat melakukan sesuatu seperti ini:

 Label.button - mengatur gaya tombol secara visual.

 Input: not (: check) ~ * {display: none} - sembunyikan semuanya setelahnya dalam wadah yang sama.

Bit itu "dalam penampung yang sama", Anda membutuhkan logika khusus di JS. Anda juga perlu memilih semua elemen, yang mengharuskan melintasi pohon DOM. Dan kemudian terapkan gaya CSS padanya, yang akan berakhir dengan tag style = ””, yang pada gilirannya akan membutuhkan! Penting jika karena alasan tertentu Anda harus mengatasinya. DI CSS, untungnya, ini sangat sederhana.

Jalan untuk Menjadi Desainer Web yang Baik

Kesimpulan

Seperti yang Anda lihat, ini adalah masalah umum yang sangat sedikit. Untuk menutupi semuanya, dibutuhkan sebuah buku. Tapi mudah-mudahan, mereka akan memberi Anda titik awal yang baik dan mengingatkan Anda untuk memikirkan potensi masalah yang bisa muncul karena pendekatan yang salah. Menemukan masalah seperti itu datang dengan banyak pengalaman dan banyak bacaan. Dan jika Anda sampai pada kesimpulan di sini, maka Anda berada di jalan yang benar dengan bacaan, sekarang waktunya untuk berlatih!