Bagaimana tidak menulis template untuk bootstrap

Hanya sedikit orang yang merancang situs web dari awal - mengapa, jika ada banyak kerangka kerja CSS yang bagus? Yang paling populer di antara mereka adalah bootstrap. Namun demikian, semua orang ingin situsnya terlihat unik, tidak seperti yang lain - itu sebabnya mereka sering menempel (dengan kemampuan terbaik) templat gratis atau berbayar, atau kit UI mereka sendiri.

Saya ingin berbicara tentang beberapa masalah yang (sayangnya) terjadi bahkan di template berbayar, belum lagi solusi saya. Teks di bawah ini tidak mengklaim sebagai unik, dan tidak mungkin menarik bagi pengembang yang berpengalaman, tetapi mungkin berguna untuk pengembang front-end pemula, desainer tata letak, dan pengembang web berbasis luas. Jadi, jika Anda masih tertarik, selamat datang!

Kami memiliki begitu ...

Sebagai aturan, jika sebuah situs telah dikembangkan untuk waktu yang lama, persyaratan untuk penampilannya berubah secara teratur. Jika, selain itu, pemrogram secara teratur mengubahnya, maka kode (dalam kasus kami, css) berubah menjadi berantakan. Di suatu tempat kelas bootstrap, kadang-kadang kelas templat, semua ini diencerkan dengan kruk beberapa generasi desainer tata letak dan dibumbui dengan gaya inline. Berusaha untuk mengubah sesuatu atau menambahkan yang baru mengarah ke permainan ajaib panjang di "tebak kelas apa yang perlu Anda masukkan ke dalam blok html ini!". Saya ingin membuang semuanya dan menulis ulang dari awal. Tapi di sini, pada kenyataannya, saya melihat hanya dengan cepat menambahkan bidang ke formulir, saya punya cukup tugas di backend ... Sebenarnya, kita akan mempertimbangkan alasan yang mendorong saya untuk menulis artikel ini, pada contoh pertama.

Ukuran input

Jadi, kami memiliki tampilan standar elemen bentuk, yang ingin kami ubah sedikit, misalnya, mengurangi ketinggian. Apa cara untuk melakukan ini sehingga input sesuai dengan paus UI?

Anda dapat memasukkan gaya sebaris! Ini akan sangat menyenangkan - lalu salin semua alas kaki ini ke setiap input!

Seseorang akan tertawa, tetapi saya secara teratur melihat keputusan seperti itu. Untungnya tidak dalam kasus ini, tetapi itu terjadi. Apa yang terjadi jika kita melakukan ini? Anda harus menyalin deskripsi gaya panjang ke setiap input, menggembungkan templat dan membuatnya kurang mudah dibaca.

Mari kita tulis kelas kita sendiri, di mana kita akan menjelaskan pengaturan ketinggian yang diperlukan, dan pada saat yang sama mengubah ukuran font!

Ya Itu dia. "H40_px-16." Dari nama kelas, segera jelas apa fungsinya? Saya bertemu sesuatu seperti ini ketika saya mencoba memahami mengapa input baru sedikit lebih tebal daripada yang diperlukan. Saya melihat kode dalam template yang sama, dan menemukannya. Apa konsekuensi yang menunggu kita dalam kasus ini? Pada prinsipnya, tidak ada yang kritis. Di setiap kelas elemen formulir, selain "kontrol bentuk", kami akan menambahkan "h40_px-16". Perlu diingat, atau didokumentasikan. Dan jika ada persyaratan untuk melakukan semua elemen bentuk dengan latar belakang hijau? Cukup tambahkan kelas lain, "b_g". Dan kemudian satu lagi ...

Perluas kelas yang ada untuk elemen formulir?

Sangat jarang untuk melihat solusi ini, meskipun bagi saya tampaknya ada di permukaan. Dan menurut saya - yang paling benar. Hal ini memungkinkan kita untuk menghemat jumlah kelas yang perlu ditentukan dalam elemen, tetapi yang paling penting, ini mengurangi jumlah kebingungan di antara pengembang yang mencoba bekerja dengan kode ini. Jika perubahan yang diperlukan memengaruhi semua elemen jenis ini, kami cukup menambahkan seperangkat aturan kami sendiri untuk "kontrol bentuk", dan semua input mengubah tinggi, font, latar belakang, dll.

Solusi Khusus

Sesuai dengan kit UI, Anda perlu menambahkan solusi inovatif yang belum pernah terlihat sebelumnya ke situs! Dan itu ditulis dari awal. Benarkah? Tidak, saya bisa mengizinkan ini jika Anda menggunakan pureCSS - kerangka kerja yang bagus tapi minimalis - dan Anda perlu mengimplementasikan sesuatu yang tidak termasuk di dalamnya. Tetapi jika Anda menggunakan bootstrap - dengan probabilitas yang sangat tinggi, Anda hanya perlu membaca kembali dokumentasi.

Mari kita lihat situasi yang sangat terabaikan di mana situs tersebut memiliki penerapan lencana sendiri. Dengan bootstrap tersambung. Jadi, salah satu pengembang yang tidak berpartisipasi dalam pembuatan lencana ini perlu menambahkannya di suatu tempat di situs.

1. Pertama, dia melihat dokumentasi bootstrap, dan menyalin solusinya dari sana.
2. Melihat bahwa secara visual ini tidak sesuai dengan paus UI, ia mencari dokumentasi tentang solusi inovatif yang digunakan.
3. Jika dokumentasi ini tidak (dan kemungkinan besar tidak), ia mencari dalam kode untuk contoh bagaimana ini diterapkan.
4. Setelah menyalin kelas beijik yang diinginkan, ia melihat bahwa lencana sekarang benar, tetapi biru, dan ia perlu merah.
5. Setelah menemukan file css yang menggambarkan kelas untuk UI paus, mendeteksi bahwa warna merah tidak diletakkan, dan mendesah menambahkan kelas "beijik-red"

Sekarang, mari kita bandingkan ini dengan situasi ketika kelas badge didefinisikan ulang untuk implementasi badge-nya sendiri, dan implementasi warna dijelaskan dalam dokumentasi:

1. Pertama, dia melihat dokumentasi bootstrap, dan menyalin solusinya dari sana.
2. Dokumentasi menemukan cara menambahkan merah: lencana-merah

Di sini kami memeriksa contoh di mana diperlukan tidak hanya untuk mengubah solusi yang sudah jadi, tetapi juga untuk memperluasnya, karena kami tidak puas dengan fungsi di luar kotak (lencana di bootstrap3 tidak memiliki warna khusus). Dalam hal ini, semua sama, solusi terbaik tetap menimpa kelas yang ada, dan hanya setelah itu - tambahkan milik Anda.

Tentu saja, contoh yang saya berikan cukup halus, tetapi saya benar-benar menemukan situasi di mana saya pertama kali mencari solusi dalam dokumentasi untuk bootstrap, kemudian dalam dokumentasi untuk templat yang digunakan di situs untuk itu (untungnya, ada dokumentasi untuk itu), kemudian saya mencari file css di mana dan bagaimana perilaku standar didefinisikan ulang dan bagaimana analog diimplementasikan - tetapi pada akhirnya saya menulis gaya saya sendiri untuk mengembalikan (!) kemungkinan yang awalnya.

Jika Anda tidak ingin melukai kolega Anda dan ingin mempercepat pekerjaan tim secara keseluruhan, patuhi aturan berikut saat membuat gaya Anda sendiri untuk situs:

• Periksa bagaimana fungsionalitas yang diperlukan diimplementasikan dalam kerangka kerja yang digunakan (Anda ingat - kemungkinan besar ada di sana).
• Temukan kelas mana yang perlu didefinisikan ulang untuk membawa tampilan ke yang diinginkan.
• Jika fungsionalitas tidak diimplementasikan, atau tidak sepenuhnya diimplementasikan - berkoordinasi dengan rekan kerja cara mudah untuk memperluas fungsionalitas, dan coba mendokumentasikannya untuk masa depan.
• Jika fungsionalitas diperlukan tidak di mana-mana, tetapi hanya pada halaman tertentu - letakkan di file terpisah dan hubungkan \ kumpulkan untuk itu (tolong jangan gaya inline)

Kata penutup

Semua hal di atas adalah pendapat pribadi saya. Saya bukan pengembang front-end yang profesional, dan saya biasanya menemukan html dan css ketika saya menambahkan beberapa fungsi baru - lebih mudah bagi saya untuk segera mengkonfigurasi bagian depan dan belakang, dan kemudian memberikannya untuk menyisir desain. Jika tim Anda telah menetapkan proses, menjelaskan aturan kode yang baik, menyusun pedoman untuk semua pengembang dan semuanya melalui tinjauan kode - Anda bisa menertawakan artikel ini, saya tidak keberatan. Jika artikel itu ternyata bermanfaat bagi seseorang, maka tidak sia-sia saya mengemukakan pikiran saya yang bingung.