Berbicara dari pengalaman! Menafsirkan kesalahpahaman produksi halaman web Div+CSS

Penulis：Eve Cole Waktu Pembaruan：2009-05-31 01:04:51

Angin musim semi "rekonstruksi" bertiup ke seluruh negeri, dan Internet berada dalam kekacauan untuk sementara waktu. "div+CSS" telah menjadi "mode". Banyak situs web yang selalu memulai "rekonstruksi" mereka sendiri. Namun, membuka source code berbagai website tersebut seringkali membuat orang tertawa——

Kita melihat tata letak div dengan 6 atau 7 lapisan bersarang, tabel tanpa tabel, halaman yang terdiri dari div+a murni, dan ratusan kelas lapisan presentasi... Ada semakin banyak buku tentang standar saat ini Kecuali beberapa buku yang beriklan "Teknik tingkat lanjut", hanya sedikit orang yang tidak menekankan kalimat seperti itu di beberapa bab pertama buku mereka - "pemisahan struktur dan ekspresi". Namun, berapa banyak pembaca buku-buku ini yang membaca beberapa bab pertama dengan serius? Atau apakah Anda lebih suka melewatkan penjelasan struktur yang membosankan dan mendalami teknik tata letak dan Peretasan yang tampaknya canggih?

Faktanya, istilah div+CSS telah menyesatkan banyak orang sejak awal, dan mentalitas ingin segera sukses adalah penyebab dari fenomena ini. Langkah pertama bagi seseorang yang terbiasa dengan produksi halaman web tata letak tabel untuk bersentuhan dengan standar tidak boleh secara membabi buta mencari teknik CSS untuk mengimplementasikan berbagai tata letak, tetapi berusaha mengubah cara berpikirnya.

Di bawah ini saya akan berbicara tentang cara berpikir dalam memenuhi standar berdasarkan pengalaman pribadi saya.Banyak di antaranya merupakan jalan memutar yang saya ambil, semoga bermanfaat bagi XDJM yang baru mengenal standar:

1. “Menyimpan kode” adalah alat pemasaran, bukan tujuan

"Menggunakan tata letak div dapat menyimpan lebih banyak kode daripada tata letak tabel", Saya telah melihat kalimat ini di banyak buku dan situs web. Kalimat ini sendiri ada benarnya. "Menyimpan kode" memang salah satu manfaat standardisasi halaman web. Namun perlu diingat bahwa itu hanyalah “salah satu manfaatnya”, bukan “satu-satunya manfaatnya”, dan bukan itu tujuannya. “Simpan kode” lebih sering merupakan taktik pemasaran yang kita gunakan untuk meyakinkan bos yang keras kepala. Satu-satunya tujuan standardisasi halaman web adalah "pemisahan struktur dan kinerja", dan ini bukan tentang menyimpan kode demi menyimpan kode. Saya pernah menggunakan kelas terpadu karena sidebar dan bahkan konten utama website memiliki bentuk presentasi yang sama (masih ada beberapa buku yang mengajarkan hal ini). Ini memang lebih menghemat kode daripada memberi nama ID secara terpisah. Namun, biayanya salah satunya adalah kode tersebut kehilangan kualitas strukturnya yang baik. Konsekuensi dari hilangnya struktur yang baik adalah: 1. Kode sumber tidak dapat dibaca lagi; 2. Situs web menambah biaya pemeliharaan yang tidak diketahui. Bayangkan saja, ketika suatu konten berubah penyajiannya karena kebutuhan, seperti warna link, dll, kita harus memodifikasi file sumber halaman dan menambahkan kelas tambahan. Beban kerjanya jauh lebih besar dari sekedar menyesuaikan id pengelompokan. Dan jika hal ini terus berlanjut, strukturnya akan semakin buruk, membentuk lingkaran setan yang sulit untuk dibalik.

Ada situasi lain yang terjadi dalam penamaan id, yang juga merupakan kesalahan yang saya buat. Pada saat itu, untuk "menyimpan kode", menu utama diberi nama "mm", menu sekunder diberi nama "m2", dan menu tingkat ketiga diberi nama "m3". halaman web berkurang drastis, menyulitkan rekan kerja lain untuk mengambil alih, mencoba menyelamatkan masalah tetapi melelahkan diri sendiri. Dengan cara yang sama, tidak disarankan untuk terlalu menyederhanakan penamaan file dan folder. Misalnya, "Rekonstruksi Situs Web" merekomendasikan untuk menyimpan semua gambar di direktori "i". struktur direktori yang sangat disingkat. Jelaskan secara rinci dan pastikan bahwa semua orang yang terlibat, termasuk staf produksi lainnya, pengembang, dan bahkan bos yang berpengetahuan... dapat memahami dan menerapkannya, jika tidak maka hanya akan menambah masalah yang tidak perlu bagi diri Anda sendiri.

2. ID adalah senapan sniper, kelas adalah pedang bermata dua

Jika ingin memiliki struktur halaman web yang baik, baik ID maupun kelasnya harus dikuasai dengan baik. Yang disebut dengan “menggenggam dengan kedua tangan, kedua tangan harus kuat”. ID seperti senapan sniper, yang dapat membantu kita secara akurat menemukan elemen yang ingin kita muat gaya; dan kelas adalah pedang ksatria, yang lebih ringan dan fleksibel di ujung jari Anda. Kombinasi keduanya dapat menghasilkan halaman dengan struktur yang baik dan kinerja yang kaya. Namun, ada pandangan yang salah sekarang bahwa id dapat sepenuhnya digantikan oleh kelas. Faktanya, hal ini berlaku untuk banyak kode sumber halaman web ketika Anda membuka seluruh kelas, Anda tidak dapat menemukan id. Ada banyak alasan untuk fenomena ini, tetapi konsep "class=CSS" yang mengakar yang diturunkan dari era tabel adalah akar masalahnya. Benar bahwa class lebih serbaguna dan fleksibel dibandingkan id, namun harus disadari juga bahwa class jauh kurang efektif dibandingkan id dalam membangun struktur halaman web yang baik. Keunikan wajib dari id memudahkan kita mengambil modul apa pun yang kita perlukan melalui id, sedangkan kelas tidak memiliki keunggulan ini. Meskipun kita dapat menentukan nama kelas unik untuk modul tersebut, premisnya adalah hanya produser sendiri yang dapat mengubah gaya halaman web. Kalau tidak, cari orang yang agak malas. Melihat gayanya sama, dia akan langsung menerapkan kelas sebelumnya. Hasilnya kita menemukan ada lebih dari selusin modul di halaman web yang disebut "gonggao" atau "xinwen ", sehingga sulit membedakannya. Tanpa menambahkan banyak komentar html, hasil ini jelas tidak kita inginkan. Lebih jauh lagi, seperti disebutkan sebelumnya, kode yang disimpan melalui kelas universal harus disia-siakan di setiap kelas yang ditentukan secara individual.

ID adalah senapan penembak jitu, dan kelas adalah pedang bermata dua. Bersama-sama, kita sama-sama diuntungkan, dan jika terpisah, kita sama-sama kalah.

3. Tidak semua konten memerlukan div sebagai "wadah"

Haruskah saya menggunakan

hanya berisi satu elemen

Proposisi ini sebenarnya dapat diperluas menjadi - "Tidak semua konten memerlukan elemen blok sebagai wadah" dan "Tidak semua tautan memerlukan elemen lain sebagai wadah", seperti "lebih" yang dimiliki banyak halaman. Beberapa orang menulis "

", sementara yang lain menulis

atau . Apakah mereka masih perlu ada ketika "wadah" ini hanya berisi tag ? Apakah menulis secara langsung merusak struktur? Apakah ini akan kekurangan semantik? Apakah ini akan mempengaruhi tata letak? Jika Anda berpikir secara berbeda, Anda mungkin memperoleh sesuatu yang berbeda.

4. Mencapai “pemisahan struktur dan kinerja” di tempat kerja

Mengenai hal ini, banyak ahli di Internet yang menyarankan hal ini, yaitu buka editor terlebih dahulu, tulis strukturnya secara lengkap, lalu masuk ke CSS untuk menulis pertunjukan, dan usahakan untuk tidak menyentuh struktur yang sudah ditulis.

Namun, sulit bagi orang yang menggunakan buku membaca sebagai metode pembelajaran utama untuk memahaminya, karena sebagian besar buku standar mengajarkan langkah demi langkah, yang berarti harus menggabungkan struktur dan ekspresi secara langkah demi langkah. Meskipun beberapa buku memiliki saran mengenai hal ini, beberapa kalimat pendek jauh lebih rendah daripada efek halusnya selama proses membaca. Ketika staf produksi dapat memahami struktur dengan baik, struktur penulisan dan kinerja pada saat yang sama tidak akan banyak berdampak pada hasil. Namun menurut pengalaman saya, metode kerja memisahkan struktur dan presentasi jauh lebih efisien daripada menulis struktur dan presentasi pada saat yang sama, tidak mudah untuk melewatkan elemen pada halaman.

Tentu saja, apa yang disebut "pemisahan struktur dan kinerja" tidak berarti bahwa kinerja diabaikan sepenuhnya. Jika Anda ingin mempertimbangkan kinerja, Anda harus memastikan bahwa pemilih CSS dapat memilih konten sebanyak mungkin tanpa merusak struktur . Di mana menambahkan kelas, atau label mana yang digunakan untuk membedakannya, adalah masalah pendapat. Saya yakin setiap orang memiliki pengalamannya masing-masing. Menggabungkan rancangan desain yang berbeda, terkadang perlu dilakukan perubahan yang sesuai. Namun, semua perubahan ini harus memiliki premis yang sama - tidak merusak struktur dan keterbacaan kode.

Lebih jauh lagi, kita harus menyadari bahwa alat visual apapun adalah setan. Efek yang disajikan dalam antarmuka visualnya seringkali ribuan mil jauhnya dari efek browser sebenarnya. Yang benar-benar ingin kami kompatibel adalah browsernya, bukan antarmuka visual editornya.

5. CSS bukanlah obat mujarab, dan bukan tidak mungkin hidup tanpa CSS.

Dibandingkan dengan era CSS1.0, CSS dapat mencapai lebih banyak hal saat ini. Namun, permintaan selalu mendahului teknologi. CSS tidak dapat menyelesaikan semua pekerjaan lapisan presentasi halaman web . Di lain waktu, menggunakan JS jauh lebih sederhana daripada hanya mengandalkan CSS, dan kodenya lebih terstruktur dengan baik - contoh paling umum adalah menu drop-down. Pada saat seperti ini, kita harus meyakinkan diri kita sendiri, atau atasan dan pelanggan kita, untuk menggunakan metode yang lebih sederhana dan masuk akal. Karena DOM juga merupakan komponen penting dari standar halaman web, bukan berarti penggunaan JS akan membuat halaman web kita menjadi kurang efisien atau tidak lagi standar. Sebaliknya, ini adalah kesalahpahaman terbesar tentang JS. Oleh karena itu, perlu saya sampaikan bahwa di era sekarang ini, setiap profesi dituntut untuk mengetahui lebih banyak ilmu yang relevan dibandingkan sebelumnya.Mereka yang melakukan desain harus mengetahui sedikit tentang interaksi dan produksi, dan mereka yang melakukan produksi juga harus memahami desain dan pemrograman , terutama Dengan teknologi front-end seperti JS, hanya dengan cara ini Anda dan kolega Anda dapat bekerja sama lebih baik, dan prospek pengembangan pribadi Anda akan lebih cerah.
No CSS mengacu pada saat website kita gagal memuat file CSS karena berbagai alasan yang tidak diketahui. Jangan panik karena ini adalah waktu terbaik untuk menguji kualitas kode kita. Jika halaman web tetap dapat dibaca dengan baik tanpa CSS, pencapaian ini jauh lebih layak untuk kita banggakan daripada lolos verifikasi W3C.