Saya telah melihat banyak pengenalan tentang kerangka CSS baru-baru ini. Saya mengatakan sesuatu beberapa hari yang lalu: “Dalam bidang penglihatan saya yang terbatas, saya belum melihat apa pun yang benar-benar dapat disebut kerangka CSS~”. mungkin milikku. Bidang penglihatannya terlalu kecil, atau dunia ini terlalu besar. Saya masih merasa masih banyak hal yang tidak dapat saya lihat.
Pertama mari kita lihat konsep yang saya setujui:
Kerangka kerja dapat dibagi menjadi dua jenis: White-Box dan Black-Box.
Kerangka kerja berbasis warisan disebut kerangka kotak putih. Kotak putih yang disebut memiliki visibilitas, dan rincian implementasi internal dari kelas induk yang diwarisi diketahui oleh subkelas. Pengembang aplikasi yang menggunakan kerangka kotak putih mengembangkan sistem dengan menurunkan subkelas atau mengganti metode anggota kelas induk. Implementasi subkelas sangat bergantung pada implementasi kelas induk, dan ketergantungan ini membatasi fleksibilitas dan kelengkapan penggunaan kembali. Namun cara untuk mengatasi keterbatasan tersebut bisa dengan hanya mewarisi kelas induk abstrak saja, karena kelas abstrak pada dasarnya tidak memberikan implementasi yang konkrit. Kerangka kerja kotak putih adalah kerangka program, dan subkelas turunan pengguna adalah aksesori untuk kerangka ini.
Kerangka kerja yang didasarkan pada perakitan komponen objek adalah kerangka kotak hitam. Pengembang aplikasi memperoleh implementasi sistem dengan menyortir dan merakit objek. Pengguna hanya perlu memahami antarmuka eksternal komponen dan tidak perlu memahami implementasi internal spesifik. Selain itu, perakitan lebih fleksibel daripada pewarisan dan dapat diubah secara dinamis. Warisan hanyalah konsep waktu kompilasi yang statis.
Dalam situasi ideal, fungsionalitas apa pun yang diperlukan dapat diperoleh dengan merakit komponen yang sudah ada. Faktanya, komponen yang tersedia jauh dari memenuhi kebutuhan. Terkadang lebih mudah mendapatkan komponen baru melalui pewarisan daripada merakit komponen baru menggunakan komponen yang sudah ada. kotak putih dan kotak hitam akan digunakan dalam pengembangan sistem secara bersamaan. Namun, kerangka kotak putih cenderung berkembang ke arah kerangka kotak hitam, dan kerangka kotak hitam juga merupakan tujuan ideal yang ingin dicapai oleh pengembangan sistem.
Mari kita lihat kembali banyaknya framework CSS di Internet saat ini (YUI disebut “YUI Library CSS Tools” dan bukan “YUI CSS Frameworks”) cukup tentukan kelas dasar gaya. Tentu saja, pemahaman setiap orang tentang kerangka kerja ini mungkin tidak sama, dan Anda mungkin tidak setuju dengan apa yang saya katakan.
Mari kita bicara tentang framework CSS lagi. Bukannya saya tidak mengakui keberadaan hal ini. Saya sudah mencoba hal seperti itu sejak satu atau dua tahun yang lalu. Untuk situs web besar, pengembangan front-end memerlukan solusi. Kerangka kerja ini tentu saja merupakan pilihan pertama. Sayang sekali jaraknya terlalu jauh dariku dan aku terlalu lemah T_T. Aku hanya butuh dua hal:
Sesuatu untuk mengelola konten di bawah ini
Kelas/Komponen
Jelas, poin pertama adalah CSS tidak dapat melakukannya, dan poin kedua adalah sangat lemah dibandingkan dengan bahasa lain.
Ketika saya sedang mengerjakan situs web berukuran sedang sekitar setahun yang lalu, karena malas, saya berpikir untuk memodulasi konten dan membiarkan pemrogram menyusun halaman-halamannya. Arahan umumnya adalah merangkum blok fungsional satu demi satu. Pemrogram hanya perlu menggunakan HTML dan CSS yang sesuai ketika mereka ingin menggunakan konten mana tidak perlu mengulang kodenya. Halo semuanya.
Di situs web yang sama, biasanya blok konten serupa digunakan beberapa kali. Hal ini juga memungkinkan modularisasi, seperti daftar gambar, daftar avatar pengguna, atau daftar ikon grup menulisnya? Haruskah kata-kata yang sama ditulis seperti ini?
.photoListUesr,.photoListGroup{ /*_*/ }
Bukan berarti tidak mungkin, tapi bagaimana jika Anda tiba-tiba ingin menambahkan yang serupa? Saat ini, Anda mungkin perlu menyesuaikan gayanya. Bagaimana dengan saya? Saya mencoba menggunakannya seperti ini:
<div class="photoList UesrCt" />
<div class="photoList GroupCt" />
Dalam hal ini, kami memisahkan ekspresi umum dari awal, menggunakan .photoList sebagai prototipe, dan menangani detailnya melalui kelas tambahan. Beberapa hari yang lalu, saya menulis tentang pemrograman XHTML dan CSS berorientasi objek. Sebenarnya saya hanya menulis setengahnya saja. Separuh lainnya adalah contoh detail, tetapi saya tidak menyelesaikannya karena saya harus mengerjakan terlalu banyak contoh dan core sudah ditulis ^^ Tentu saja, ini juga memiliki masalah tertentu, yaitu definisi prototipe awal harus sangat hati-hati, dan berusaha memastikan bahwa meskipun direvisi di masa mendatang, mungkin tidak perlu dilakukan. dimodifikasi. Dengan CSS, pada dasarnya sebuah framework hanya dapat memuat paling banyak satu situs web. Tentu saja, jika situs web tersebut cukup besar, masuk akal untuk menggunakannya dengan cara ini.
Semakin modular HTML dan CSS, semakin terfragmentasi filenya dan semakin serius masalah ini. HTML mudah untuk ditangani karena aplikasi pada akhirnya akan digabungkan dan menghasilkan satu salinan, tetapi CSS biasanya dibuang dan langsung digunakan. Kalau pada contoh tadi, cara import CSS ke halaman web adalah seperti ini:
@import url(/xxx/photoList.css);
@impor url(/xxx/UserCt.css);
@impor url(/xxx/GroupCt.css);
Anda bahkan dapat mempertimbangkan untuk menggunakan program untuk menggabungkan halaman, tetapi program ini mudah digunakan dan sebanding dengan jumlah permintaan. Umumnya, semua orang akan memilih untuk menggabungkan file secara manual. Meskipun otak manusia lebih cerdas daripada komputer, dalam banyak kasus daya komputasi otak manusia tidak sebaik komputer. Saya pernah memiliki ide untuk menggunakan program sisi server untuk menangani mekanisme rilis CSS. Arahan umumnya adalah menganalisis penggunaan berbagai halaman di seluruh situs melalui log akses situs web, dan menggunakan program tersebut untuk menghitung penggunaan publik mana. perlu digabungkan. Urutan (urutan file CSS akan mempengaruhi prioritas), dll. Berbagai perhitungan dan keluaran terkompresi.
Sayangnya, program yang rumit seperti itu mungkin hanya cocok untuk satu stasiun, atau sekelompok stasiun dalam rangkaian yang sama. Meskipun agak merepotkan untuk dilakukan, saya yakin metode ini perlu digunakan untuk situs web tingkat portal. Tentu saja, premisnya adalah seluruh tim harus menggunakan pola desain yang sama.
PS: Program penerbitan CSS di atas hanya khayalan saya saja, saya belum mencobanya, teman-teman yang berminat bisa mencobanya.
Tentu saja hal di atas tidak bisa disebut Kerangka CSS, mungkin hanya bisa disebut solusi tingkat sistem. Bagaimanapun, CSS hanyalah bahasa deskriptif.
Saat saya makan bebek panggang dengan Yueying tadi malam, kami membicarakan hal ini dan dia bertanya apakah saya memiliki solusi front-end yang terintegrasi. Masalah yang sama akan dihadapi ketika JS dikomponenisasi, dan mekanisme penerbitan serupa juga harus diterapkan pada JS. Tapi saya belum memikirkan solusi yang sepenuhnya terintegrasi. Mungkin Yueying akan mentraktir saya bebek panggang beberapa kali lagi dan saya bisa mengetahuinya.