ฉันได้เห็นการแนะนำเฟรมเวิร์ก CSS มากมายเมื่อไม่กี่วันก่อน: “ในขอบเขตการมองเห็นที่จำกัดของฉัน ฉันไม่เคยเห็นสิ่งใดที่สามารถเรียกได้ว่าเป็นเฟรมเวิร์ก CSS จริงๆ เลย~” อาจเป็นของฉัน ขอบเขตการมองเห็นเล็กเกินไปหรือโลกกว้างเกินไป ฉันยังรู้สึกว่ายังมีอีกหลายอย่างที่ฉันมองไม่เห็น
ก่อนอื่นเรามาดูแนวคิดที่ฉันเห็นด้วยกับ:
Framework สามารถแบ่งได้เป็น 2 ประเภท คือ White-Box และ Black-Box
กรอบงานที่อิงตามการสืบทอดเรียกว่ากรอบงานกล่องสีขาว กล่องสีขาวที่เรียกว่ามีการมองเห็น และรายละเอียดการใช้งานภายในของคลาสพาเรนต์ที่สืบทอดมานั้นเป็นที่รู้จักของคลาสย่อย นักพัฒนาแอปพลิเคชันที่ใช้กรอบงานไวท์บ็อกซ์จะพัฒนาระบบโดยรับคลาสย่อยหรือแทนที่เมธอดสมาชิกของคลาสพาเรนต์ การใช้งานคลาสย่อยนั้นขึ้นอยู่กับการใช้งานคลาสพาเรนต์เป็นอย่างมาก และการพึ่งพานี้จำกัดความยืดหยุ่นและความสมบูรณ์ของการนำกลับมาใช้ใหม่ แต่วิธีการแก้ไขข้อจำกัดนี้สามารถสืบทอดเฉพาะคลาสพาเรนต์ที่เป็นนามธรรมเท่านั้น เนื่องจากคลาสนามธรรมโดยพื้นฐานแล้วไม่ได้จัดเตรียมการใช้งานอย่างเป็นรูปธรรม เฟรมเวิร์กกล่องสีขาวเป็นโครงกระดูกของโปรแกรม และคลาสย่อยที่ผู้ใช้ได้รับเป็นอุปกรณ์เสริมของโครงกระดูกนี้
กรอบงานที่ใช้ส่วนประกอบของวัตถุเป็นกรอบกล่องดำ นักพัฒนาแอปพลิเคชันได้รับการนำระบบไปใช้โดยการเรียงลำดับและประกอบออบเจ็กต์ ผู้ใช้จำเป็นต้องเข้าใจอินเทอร์เฟซภายนอกของส่วนประกอบเท่านั้น และไม่จำเป็นต้องเข้าใจการใช้งานภายในที่เฉพาะเจาะจง นอกจากนี้ แอสเซมบลียังมีความยืดหยุ่นมากกว่าการสืบทอดและสามารถเปลี่ยนแปลงได้แบบไดนามิก การสืบทอดเป็นเพียงแนวคิดเวลาคอมไพล์แบบคงที่เท่านั้น
ในสถานการณ์ที่เหมาะสม สามารถรับฟังก์ชันที่จำเป็นได้โดยการประกอบส่วนประกอบที่มีอยู่ ที่จริงแล้ว ส่วนประกอบที่มีอยู่ยังห่างไกลจากความต้องการในบางครั้ง การได้รับส่วนประกอบใหม่ผ่านการสืบทอดจึงง่ายกว่าการประกอบส่วนประกอบใหม่โดยใช้ส่วนประกอบที่มีอยู่ ดังนั้น กล่องสีขาวและกล่องดำจะถูกใช้ในการพัฒนาระบบไปพร้อมๆ กัน อย่างไรก็ตาม กรอบงานกล่องสีขาวมีแนวโน้มที่จะพัฒนาไปสู่กรอบงานกล่องดำ และกรอบงานกล่องดำก็เป็นเป้าหมายในอุดมคติที่การพัฒนาระบบหวังว่าจะบรรลุเช่นกัน
ลองย้อนกลับไปดูเฟรมเวิร์ก CSS ต่างๆ บนอินเทอร์เน็ตในปัจจุบัน (YUI เรียกว่า “YUI Library CSS Tools” แทนที่จะเป็น “YUI CSS Frameworks”) มีกี่เฟรมเวิร์กที่เขียนด้วยแนวคิดของเฟรมเวิร์ก และมีกี่เฟรมเวิร์กเหล่านั้น เพียงกำหนดคลาสพื้นฐานสไตล์ แน่นอนว่าความเข้าใจของทุกคนเกี่ยวกับกรอบการทำงานอาจไม่เหมือนกันและคุณอาจไม่เห็นด้วยกับที่ผมพูด
มาพูดถึงกรอบงาน CSS กันอีกครั้ง ไม่ใช่ว่าฉันไม่รู้จักการมีอยู่ของสิ่งนี้ ฉันได้ลองสิ่งเหล่านี้มาตั้งแต่หนึ่งหรือสองปีที่แล้ว สำหรับเว็บไซต์ขนาดใหญ่ การพัฒนาส่วนหน้าจำเป็นต้องมีวิธีแก้ปัญหา กรอบงานเป็นตัวเลือกแรกโดยธรรมชาติ น่าเสียดายที่มันอยู่ไกลจากฉันเกินไปและฉันอ่อนแอเกินไป T_T ฉันต้องการเพียงสองสิ่งเท่านั้น:
บางสิ่งบางอย่างในการจัดการเนื้อหาด้านล่าง
คลาส/ส่วนประกอบ
แน่นอนว่าประเด็นแรกคือ CSS ไม่สามารถทำได้ และประเด็นที่สองคือมันอ่อนแอมากเมื่อเทียบกับภาษาอื่นๆ
ตอนที่ฉันทำงานบนเว็บไซต์ขนาดกลางเมื่อประมาณหนึ่งปีที่แล้ว เพื่อที่จะขี้เกียจ ฉันจึงคิดที่จะแยกเนื้อหาออกเป็นโมดูลและให้โปรแกรมเมอร์รวบรวมหน้าต่างๆ ทิศทางทั่วไปคือการห่อหุ้มบล็อกการทำงานหนึ่งบล็อกหลังจากนั้นโปรแกรมเมอร์จะต้องใช้ HTML และ CSS ที่เกี่ยวข้องเท่านั้นเมื่อต้องการใช้เนื้อหาชิ้นใดที่สะดวกสำหรับทุกคน ไม่ต้องตอกโค้ดอีกแล้ว สวัสดีทุกคน
ในเว็บไซต์เดียวกัน เป็นเรื่องปกติที่บล็อกเนื้อหาที่คล้ายกันจะถูกใช้หลายครั้ง ซึ่งจะทำให้สามารถแยกส่วนได้ เช่น รายการรูปภาพ รายชื่ออวตารของผู้ใช้ หรือรายการไอคอนกลุ่ม ในเวลานี้ คุณจะต้องทำอย่างไร เขียนเหรอ? คำเดียวกันควรเขียนแบบนี้เหรอ?
.photoListUesr,.photoListGroup{ /*_*/ }
นี่ไม่ได้หมายความว่ามันเป็นไปไม่ได้ แต่ถ้าคุณต้องการเพิ่มสิ่งที่คล้ายกันโดยฉับพลันล่ะ ในตอนนี้ คุณอาจต้องปรับสไตล์ แล้วฉันล่ะ ฉันลองใช้มันแบบนี้:
<div class="photoList UesrCt" />
<div class="photoList GroupCt" />
ในกรณีนี้ เราจะแยกนิพจน์ทั่วไปออกจากจุดเริ่มต้น ใช้ .photoList เป็นต้นแบบ และจัดการรายละเอียดผ่านคลาสเพิ่มเติม เมื่อไม่กี่วันก่อน ฉันเขียนเกี่ยวกับการเขียนโปรแกรมเชิงวัตถุ XHTML และ CSS อันที่จริง ฉันเขียนเพียงครึ่งเดียวเท่านั้นที่เป็นตัวอย่างโดยละเอียด แต่ฉันยังเขียนไม่จบเพราะฉันต้องทำตัวอย่างมากเกินไป core ถูกเขียนไว้แล้ว ^^ แน่นอนว่านี่ก็มีปัญหาอยู่บ้าง กล่าวคือ คำจำกัดความของต้นแบบเบื้องต้นจะต้องระมัดระวังให้มาก และพยายามให้มั่นใจว่าถึงแม้จะมีการแก้ไขในอนาคตก็อาจไม่จำเป็นต้องแก้ไข แก้ไข ด้วย CSS โดยพื้นฐานแล้วเฟรมเวิร์กจะพอดีกับเว็บไซต์เดียวเท่านั้น แน่นอนว่าหากเว็บไซต์มีขนาดใหญ่พอ ก็สมเหตุสมผลที่จะใช้มันในลักษณะนี้
ยิ่ง HTML และ CSS แบบโมดูลาร์มากขึ้น ไฟล์ก็จะยิ่งกระจัดกระจายมากขึ้น และปัญหานี้ก็จะยิ่งรุนแรงมากขึ้นเท่านั้น HTML นั้นง่ายต่อการจัดการ เนื่องจากในที่สุดแอปพลิเคชันจะรวมและส่งออกสำเนาหนึ่งชุด แต่โดยปกติแล้ว CSS จะถูกละทิ้งและใช้โดยตรง หากในตัวอย่างตอนนี้ วิธีการนำเข้า CSS เข้าสู่หน้าเว็บจะเป็นดังนี้:
@นำเข้า URL(/xxx/photoList.css);
@นำเข้า URL(/xxx/UserCt.css);
@นำเข้า URL(/xxx/GroupCt.css);
คุณยังสามารถพิจารณาใช้โปรแกรมเพื่อรวมหน้าต่างๆ ได้ แต่ใช้งานง่ายและเป็นสัดส่วนกับจำนวนคำขอ โดยทั่วไป ทุกคนจะเลือกที่จะรวมไฟล์ด้วยตนเอง แม้ว่าสมองของมนุษย์จะฉลาดกว่าคอมพิวเตอร์ แต่ในหลายกรณี พลังการประมวลผลของสมองมนุษย์ก็ไม่ได้ดีเท่ากับคอมพิวเตอร์ ครั้งหนึ่งฉันเคยมีแนวคิดในการใช้โปรแกรมฝั่งเซิร์ฟเวอร์เพื่อจัดการกับกลไกการเผยแพร่ CSS แนวทางทั่วไปคือการวิเคราะห์การใช้งานหน้าต่างๆ ของเว็บไซต์ทั้งหมดผ่านบันทึกการเข้าถึงเว็บไซต์ และใช้โปรแกรมเพื่อคำนวณว่าการใช้งานสาธารณะแบบใด จำเป็นต้องรวมเข้าด้วยกัน ลำดับ (ลำดับของไฟล์ CSS จะส่งผลต่อลำดับความสำคัญ) ฯลฯ การคำนวณและการบีบอัดเอาต์พุตต่างๆ
น่าเสียดายที่โปรแกรมที่ซับซ้อนดังกล่าวอาจเหมาะสำหรับสถานีเดียวหรือกลุ่มสถานีในซีรีส์เดียวกันเท่านั้น แม้ว่าจะยุ่งยากนิดหน่อย แต่ฉันเชื่อว่าจำเป็นต้องใช้วิธีนี้กับเว็บไซต์ระดับพอร์ทัล แน่นอนว่าทั้งทีมต้องใช้รูปแบบการออกแบบเดียวกัน
PS: โปรแกรมเผยแพร่ CSS ข้างต้นเป็นเพียงจินตนาการของฉัน ฉันยังไม่ได้ลอง เพื่อนที่สนใจสามารถลองได้ หากเกิดอุบัติเหตุใด ๆ ฉันจะไม่รับผิดชอบ
แน่นอนว่าสิ่งที่กล่าวมาข้างต้นไม่สามารถเรียกว่า CSS Frameworks ได้ บางทีอาจเรียกได้ว่าเป็นเพียงโซลูชันระดับระบบเท่านั้น ท้ายที่สุดแล้ว CSS ก็เป็นเพียงภาษาอธิบายเท่านั้น
ตอนที่ฉันกินเป็ดย่างกับ Yueying เมื่อคืนนี้ เราคุยกันเรื่องนี้ และเขาก็ถามฉันว่าฉันมีโซลูชันส่วนหน้าแบบผสานรวมหรือไม่ ปัญหาเดียวกันนี้จะเกิดขึ้นเมื่อมีการแบ่งส่วนประกอบ JS และกลไกการเผยแพร่ที่คล้ายกันก็ควรนำไปใช้กับ JS ด้วยเช่นกัน แต่ฉันยังไม่ได้คิดวิธีแก้ปัญหาแบบผสมผสานอย่างสมบูรณ์ บางที Yueying อาจจะเลี้ยงเป็ดย่างให้ฉันอีกสองสามครั้งแล้วฉันก็คิดออก