สายลมแห่งฤดูใบไม้ผลิแห่ง "การสร้างใหม่" กำลังพัดไปทั่วประเทศ และอินเทอร์เน็ตก็อยู่ในภาวะสับสนวุ่นวายมาระยะหนึ่งแล้ว "div+CSS" ได้กลายเป็น "แฟชั่น" เว็บไซต์จำนวนนับไม่ถ้วนได้เริ่ม "สร้างใหม่" ของตัวเองอย่างสม่ำเสมอ อย่างไรก็ตาม การเปิดซอร์สโค้ดของเว็บไซต์ต่างๆ เหล่านี้มักจะทำให้ผู้คนหัวเราะ——
เราเห็นเค้าโครง div ที่มีการซ้อน 6 หรือ 7 ชั้น ตารางที่ไม่มีตาราง หน้าที่ประกอบด้วย div+a ล้วนๆ และคลาสเลเยอร์การนำเสนอหลายร้อยชั้น... ปัจจุบันมีหนังสือเกี่ยวกับมาตรฐานเพิ่มมากขึ้น ยกเว้นหนังสือบางเล่มที่โฆษณา "เทคนิคขั้นสูง" มีเพียงไม่กี่คนที่จะไม่เน้นประโยคดังกล่าวในสองสามบทแรกของหนังสือ - "การแยกโครงสร้างและการแสดงออก" อย่างไรก็ตาม มีผู้อ่านหนังสือเหล่านี้กี่คนที่อ่านสองสามบทแรกอย่างจริงจัง? หรือคุณอยากจะข้ามคำอธิบายโครงสร้างที่น่าเบื่อแล้วดำดิ่งลงสู่เทคนิคเลย์เอาต์และ Hacks ที่ดูเหมือนขั้นสูง
อันที่จริง คำว่า div+CSS ทำให้ผู้คนจำนวนมากเข้าใจผิดตั้งแต่เริ่มต้น และความคิดที่กระตือรือร้นที่จะประสบความสำเร็จอย่างรวดเร็วคือต้นเหตุของปรากฏการณ์นี้ ขั้นตอนแรกสำหรับผู้ที่คุ้นเคยกับการผลิตหน้าเว็บเค้าโครงตารางเพื่อสัมผัสกับมาตรฐานไม่ควรเป็นการแสวงหาเทคนิค CSS แบบสุ่มสี่สุ่มห้าเพื่อใช้เค้าโครงต่างๆ แต่มุ่งมั่นที่จะเปลี่ยนวิธีคิดของเขาหรือเธอ
ด้านล่างนี้ฉันจะพูดถึงวิธีคิดตามมาตรฐานโดยอิงจากประสบการณ์ส่วนตัวของฉัน หลายๆ วิธีเป็นเพียงทางอ้อม ฉันหวังว่ามันจะเป็นประโยชน์กับ XDJM ที่เพิ่งเข้ามาสัมผัสกับมาตรฐาน:
1. “การบันทึกรหัส” เป็นเครื่องมือทางการตลาด ไม่ใช่วัตถุประสงค์
"การใช้เค้าโครง div สามารถบันทึกโค้ดได้มากกว่าเค้าโครงตาราง" ฉันได้เห็นประโยคนี้ในหนังสือและเว็บไซต์หลายแห่ง ประโยคนี้ถูกต้อง "การบันทึกโค้ด" ถือเป็นข้อดีประการหนึ่งของการทำให้หน้าเว็บเป็นมาตรฐาน อย่างไรก็ตาม โปรดจำไว้ว่านี่เป็นเพียง "ผลประโยชน์ประการหนึ่ง" ไม่ใช่ "ผลประโยชน์เพียงอย่างเดียว" และไม่ใช่จุดประสงค์ “บันทึกโค้ด” มักเป็นวิธีการทางการตลาดที่เราใช้เพื่อโน้มน้าวหัวหน้าที่ดื้อรั้น จุดประสงค์เดียวของการทำให้หน้าเว็บเป็นมาตรฐานคือ "การแยกโครงสร้างและประสิทธิภาพ" และไม่เคยเกี่ยวกับการบันทึกโค้ดเพื่อประโยชน์ในการบันทึกโค้ด ครั้งหนึ่งฉันเคยใช้คลาสแบบรวมเนื่องจากแถบด้านข้างและแม้แต่เนื้อหาหลักของเว็บไซต์ก็มีแบบฟอร์มการนำเสนอเหมือนกัน (ยังมีหนังสือบางเล่มที่สอนเรื่องนี้) นี่เป็นการประหยัดโค้ดมากกว่าการตั้งชื่อ ID แยกกัน สิ่งนี้ก็คือโค้ดสูญเสียโครงสร้างคุณภาพดีไป ผลที่ตามมาของการสูญเสียโครงสร้างที่ดีคือ: 1. ไม่สามารถอ่านซอร์สโค้ดได้อีกต่อไป 2. เว็บไซต์เพิ่มค่าบำรุงรักษาที่ไม่ทราบ ลองนึกภาพว่าเมื่อเนื้อหาบางส่วนเปลี่ยนการนำเสนอตามความต้องการ เช่น สีของลิงก์ ฯลฯ เราจะต้องแก้ไขไฟล์ต้นฉบับของหน้าและเพิ่มคลาสเพิ่มเติม ปริมาณงานมีมากกว่าแค่การปรับรหัส การจัดกลุ่ม และหากเป็นเช่นนี้ต่อไป โครงสร้างก็จะแย่ลงเรื่อยๆ กลายเป็นวงจรอุบาทว์ที่ยากจะย้อนกลับ
มีอีกสถานการณ์หนึ่งที่เกิดขึ้นในการตั้งชื่อรหัส ซึ่งเป็นข้อผิดพลาดที่ฉันทำเช่นกัน ในเวลานั้นเพื่อ "บันทึกรหัส" เมนูหลักชื่อ "mm" เมนูรองชื่อ "m2" และเมนูระดับที่สามชื่อ "m3" ส่งผลให้สามารถอ่านได้ หน้าเว็บถูกลดขนาดลงอย่างมาก ทำให้เพื่อนร่วมงานคนอื่น ๆ เข้ามารับช่วงต่อได้ยาก พยายามกอบกู้ปัญหาแต่กลับทำให้ตัวเองเหนื่อยหน่าย ในทำนองเดียวกัน ไม่แนะนำให้ตั้งชื่อไฟล์และโฟลเดอร์ให้ง่ายเกินไป ตัวอย่างเช่น "การสร้างเว็บไซต์ใหม่" แนะนำให้จัดเก็บรูปภาพทั้งหมดในไดเร็กทอรี "i" โดยส่วนตัวแล้วฉันคิดว่าไม่แนะนำให้เลือกเว้นแต่คุณจะสามารถเขียนได้ โครงสร้างไดเร็กทอรีที่มีคำย่อสูง อธิบายโดยละเอียดและรับรองว่าทุกคนที่เกี่ยวข้อง รวมถึงพนักงานฝ่ายผลิต นักพัฒนา และแม้แต่หัวหน้าที่มีความรู้... สามารถเข้าใจและนำไปปฏิบัติได้ ไม่เช่นนั้นก็จะมีแต่จะเพิ่มปัญหาที่ไม่จำเป็นให้กับตัวคุณเองเท่านั้น
2. ID คือปืนไรเฟิล คลาสคือดาบสองคม
หากคุณต้องการมีโครงสร้างหน้าเว็บที่ดีทั้ง ID และคลาสจะต้องเชี่ยวชาญ สิ่งที่เรียกว่า "การจับมือทั้งสองมือต้องแข็งแกร่ง" ID ก็เหมือนกับปืนไรเฟิลซุ่มยิงซึ่งสามารถช่วยให้เราค้นหาองค์ประกอบที่เราต้องการโหลดรูปแบบได้อย่างแม่นยำ และคลาสก็คือดาบของอัศวิน ซึ่งเบากว่าและยืดหยุ่นมากกว่าเพียงปลายนิ้วสัมผัส การผสมผสานของทั้งสองอย่างเข้าด้วยกันจะทำให้ได้หน้าที่มีโครงสร้างที่ดี และประสิทธิภาพที่หลากหลาย อย่างไรก็ตาม มีมุมมองที่ผิดในขณะนี้ว่าสามารถแทนที่ id ด้วยคลาสได้อย่างสมบูรณ์ ที่จริงแล้วสิ่งนี้เป็นจริงสำหรับซอร์สโค้ดของหน้าเว็บจำนวนมาก เมื่อคุณเปิดทั้งชั้นเรียน คุณจะไม่พบ id มีสาเหตุหลายประการสำหรับปรากฏการณ์นี้ แต่แนวคิดที่หยั่งรากลึกของ "class=CSS" ที่สืบทอดมาจากยุคของตารางคือสาเหตุที่แท้จริง เป็นความจริงที่ว่าคลาสมีความหลากหลายและยืดหยุ่นมากกว่า id แต่ต้องตระหนักด้วยว่าคลาสนั้นมีประสิทธิภาพน้อยกว่า id มากในการสร้างโครงสร้างหน้าเว็บที่ดี เอกลักษณ์บังคับของ id ทำให้ง่ายต่อการดึงโมดูลใด ๆ ที่เราต้องการผ่าน id ในขณะที่คลาสไม่มีข้อได้เปรียบนี้ แม้ว่าเราจะสามารถกำหนดชื่อคลาสที่ไม่ซ้ำกันสำหรับโมดูลได้ แต่หลักฐานก็คือมีเพียงผู้ผลิตเท่านั้นที่สามารถเปลี่ยนสไตล์ของหน้าเว็บได้ ไม่งั้นก็หาคนขี้เกียจสักหน่อย เมื่อเห็นว่าสไตล์เหมือนกัน เขาก็จะประยุกต์คลาสก่อนหน้าโดยตรง ผลก็คือ เราพบว่ามีโมดูลมากกว่าหนึ่งโหลในหน้าเว็บที่เรียกว่า "gonggao" หรือ "xinwen" " จึงแยกแยะได้ยาก หากไม่มีการเพิ่มความคิดเห็น html จำนวนมาก ผลลัพธ์นี้จึงไม่ใช่สิ่งที่เราต้องการอย่างชัดเจน นอกจากนี้ ตามที่กล่าวไว้ข้างต้น รหัสที่บันทึกผ่านคลาสสากลจะต้องถูกใช้อย่างสิ้นเปลืองในแต่ละคลาสที่กำหนดแยกกัน
ID คือปืนไรเฟิลซุ่มยิง และคลาสก็คือดาบสองคม เราทั้งคู่ต่างได้รับประโยชน์ และต่างจากเราทั้งคู่ที่พ่ายแพ้
3. เนื้อหาบางส่วนไม่จำเป็นต้องมี div เป็น "คอนเทนเนอร์"
ฉันควรใช้ <div id="mainnav"><ul> หรือ <ul id="mainnav"> สำหรับเมนูหลักหรือไม่ นี่เป็นปัญหาของเกม จนถึงตอนนี้ยังไม่มีใครสามารถให้คำตอบที่ชัดเจนสำหรับคำถามนี้ได้ แม้แต่ฉันเอง เป็นเรื่องจริงที่เมื่อ <div id="mainnav"> มีองค์ประกอบ <ul> เพียงองค์ประกอบเดียว div นี้ดูเหมือนจะซ้ำซ้อนเล็กน้อย แต่บางครั้งเพื่อให้เข้ากับการออกแบบที่งดงาม แท็กอีกหนึ่งเลเยอร์หมายถึงการเปลี่ยนแปลงอีกหนึ่งเลเยอร์ ( บางคนก็ใช้ span ในแท็กด้วย) ข้อได้เปรียบโดยธรรมชาติของ div ที่ไม่มีแอตทริบิวต์ดั้งเดิมนั้นไม่ตรงกับแท็กอื่น ๆ ฉันแค่อยากจะอธิบายสิ่งหนึ่งด้วยข้อเสนอนี้ กล่าวคือ เราควรตระหนักว่า นอกจาก <div id="mainnav"><ul> แล้ว ยังมี <ul id="mainnav"> วิธีการเขียนแบบนี้ด้วย ยังมีโครงสร้างและความหมายที่ดี และช่วยลดการซ้อนชั้นอีกด้วย เมื่อเราไม่ต้องกังวลกับงานศิลปะที่งดงาม เราจะทำให้โครงสร้างเรียบง่ายขึ้นได้ไหม
ข้อเสนอนี้สามารถขยายไปถึง - "เนื้อหาบางส่วนไม่ต้องการองค์ประกอบบล็อกเป็นคอนเทนเนอร์" และ "ไม่ใช่ทุกลิงก์ที่ต้องการองค์ประกอบอื่นเป็นคอนเทนเนอร์" เช่น "เพิ่มเติม" ที่หลายๆ หน้ามี บางคนเขียนว่า "<div class="more"><a>" ในขณะที่บางคนเขียน <p><a> หรือ <strong><a> ยังจำเป็นต้องมีอยู่หรือไม่เมื่อ "คอนเทนเนอร์" เหล่านี้มีเพียงแท็ก <a> เท่านั้น การเขียนโดยตรง<a class="more">จะทำให้โครงสร้างเสียหายหรือไม่ มันจะขาดความหมายหรือไม่? มันจะส่งผลต่อการจัดวางหรือไม่? หากคุณคิดแตกต่าง คุณก็อาจได้รับสิ่งที่แตกต่างออกไป
4. บรรลุ "การแยกโครงสร้างและประสิทธิภาพ" ในที่ทำงาน
ในประเด็นนี้ ผู้เชี่ยวชาญหลายคนบนอินเทอร์เน็ตแนะนำสิ่งนี้ นั่นคือ เปิดตัวแก้ไขก่อน เขียนโครงสร้างทั้งหมด จากนั้นไปที่ CSS เพื่อเขียนประสิทธิภาพ และพยายามอย่าแตะต้องโครงสร้างที่เขียนไว้แล้ว
อย่างไรก็ตาม เป็นเรื่องยากสำหรับผู้ที่ใช้การอ่านหนังสือเป็นวิธีการเรียนรู้หลักในการทำความเข้าใจ เนื่องจากหนังสือเกี่ยวกับมาตรฐานส่วนใหญ่สอนทีละขั้นตอน ซึ่งหมายความว่าจะต้องผสมผสานโครงสร้างและการแสดงออกอย่างเป็นขั้นเป็นตอน แม้ว่าหนังสือบางเล่มจะมีข้อเสนอแนะในเรื่องนี้ แต่ประโยคสั้นๆ สองสามประโยคก็ยังด้อยกว่าผลกระทบที่ละเอียดอ่อนในระหว่างกระบวนการอ่านมาก เมื่อเจ้าหน้าที่ฝ่ายผลิตเข้าใจโครงสร้างได้ดี โครงสร้างการเขียนและประสิทธิภาพไปพร้อมๆ กันจะไม่ส่งผลกระทบต่อผลลัพธ์มากนัก แต่จากประสบการณ์ของผม วิธีการทำงานของการแยกโครงสร้างและการนำเสนอมีประสิทธิภาพมากกว่าการเขียนโครงสร้างและการนำเสนอในเวลาเดียวกันมาก ไม่ใช่เรื่องง่ายที่จะพลาดองค์ประกอบต่างๆ บนหน้า
แน่นอนว่าสิ่งที่เรียกว่า "การแยกโครงสร้างและประสิทธิภาพ" ไม่ได้หมายความว่าประสิทธิภาพจะถูกละเลยโดยสิ้นเชิง หากคุณต้องการคำนึงถึงประสิทธิภาพ คุณต้องแน่ใจว่าตัวเลือก CSS สามารถเลือกเนื้อหาได้มากที่สุดโดยไม่ทำลายโครงสร้าง . จะเพิ่มคลาสได้ที่ไหนหรือจะใช้ป้ายกำกับใดในการแยกแยะ เป็นเรื่องของความคิดเห็น ฉันเชื่อว่าทุกคนมีประสบการณ์เป็นของตัวเอง เมื่อรวมร่างการออกแบบที่แตกต่างกัน บางครั้งจำเป็นต้องทำการเปลี่ยนแปลงที่สอดคล้องกัน อย่างไรก็ตาม การเปลี่ยนแปลงเหล่านี้ทั้งหมดควรมีหลักฐานเดียวกัน - ไม่ทำลายโครงสร้างและความสามารถในการอ่านโค้ด
นอกจากนี้ เราต้องตระหนักว่าเครื่องมือทางการมองเห็นใดๆ ก็ตามนั้นเป็นปีศาจ เอฟเฟกต์ที่นำเสนอในอินเทอร์เฟซแบบภาพมักจะอยู่ห่างจากเบราว์เซอร์จริงหลายพันไมล์ สิ่งที่เราต้องการให้เข้ากันได้คือเบราว์เซอร์ ไม่ใช่อินเทอร์เฟซแบบภาพของโปรแกรมแก้ไข
5. CSS ไม่ใช่ยาครอบจักรวาล และเป็นไปไม่ได้ที่จะอยู่โดยปราศจาก CSS
เมื่อเปรียบเทียบกับยุค CSS1.0 แล้ว CSS ก็สามารถบรรลุผลสำเร็จได้มากกว่าในปัจจุบัน อย่างไรก็ตาม ความต้องการนั้นนำหน้าเทคโนโลยีอยู่เสมอ CSS ไม่สามารถทำงานเลเยอร์การนำเสนอทั้งหมดของหน้าเว็บให้เสร็จสมบูรณ์ได้ บางครั้งเราต้องรวม JS หรือภาษาอื่น ๆ เข้าด้วยกันเพื่อให้ได้เอฟเฟกต์บางอย่าง . ในบางครั้ง การใช้ JS นั้นง่ายกว่าการใช้ CSS เพียงอย่างเดียว และโค้ดก็มีโครงสร้างที่ดีมากกว่า ตัวอย่างทั่วไปที่สุดคือเมนูแบบเลื่อนลง ในเวลานี้ เราต้องโน้มน้าวตนเองหรือเจ้านายและลูกค้าของเราให้ใช้วิธีการที่ง่ายและสมเหตุสมผลมากขึ้น เนื่องจาก DOM เป็นองค์ประกอบสำคัญของมาตรฐานหน้าเว็บ ไม่ได้หมายความว่าการใช้ JS จะทำให้หน้าเว็บของเรามีประสิทธิภาพน้อยลงหรือไม่มีมาตรฐานอีกต่อไป ในทางกลับกัน นี่เป็นความเข้าใจผิดที่ใหญ่ที่สุดของ JS ต้องบอกว่าในยุคปัจจุบัน ทุกอาชีพจำเป็นต้องรู้ความรู้ที่เกี่ยวข้องมากขึ้นกว่าที่เคย ผู้ที่ทำการออกแบบจะต้องรู้เพียงเล็กน้อยเกี่ยวกับการโต้ตอบและการผลิต และผู้ที่ทำการผลิตก็ต้องเข้าใจการออกแบบและการเขียนโปรแกรมด้วย โดยเฉพาะอย่างยิ่ง ด้วยเทคโนโลยีส่วนหน้าเช่น JS คุณและเพื่อนร่วมงานจะทำงานร่วมกันได้ดีขึ้นด้วยวิธีนี้เท่านั้น และโอกาสในการพัฒนาส่วนบุคคลของคุณจะสดใสยิ่งขึ้น
ไม่มี CSS หมายถึงเวลาที่เว็บไซต์ของเราล้มเหลวในการโหลดไฟล์ CSS เนื่องจากเหตุผลที่ไม่ทราบสาเหตุต่างๆ อย่าตกใจเพราะเหตุนี้ นี่เป็นเวลาที่ดีที่สุดในการทดสอบคุณภาพของโค้ดของเรา หากหน้าเว็บยังคงสามารถอ่านได้ดีโดยไม่มี CSS ความสำเร็จนี้คุ้มค่ากับความภาคภูมิใจของเรามากกว่าการผ่านการตรวจสอบ W3C