Smashing Podcast ตอนที่ 19 กับ Andy Bell: CUBE CSS คืออะไร?

วันนี้เรากำลังพูดถึง CUBE CSS มันคืออะไรและแตกต่างจากแนวทางเช่น BEM, SMACSS และ OOCSS อย่างไร? ฉันได้พูดคุยกับผู้สร้าง Andy Bell เพื่อหาคำตอบ

แสดงหมายเหตุ

• CUBE CSS
• พิกคาลิลลิ
• เรียนรู้ Eleventy From Scratch - ประหยัด 40%!
• Andy Bell และ Piccalilli บน Twitter

หมายเหตุ : ผู้ฟัง Smashing Podcast สามารถประหยัดเงินได้ถึง 40% ในหลักสูตร Learn Eleventy From Scratch ของ Andy โดยใช้รหัส SMASHINGPOD

อัพเดทประจำสัปดาห์

• “สิ่งที่ Vitruvius สามารถสอนเราเกี่ยวกับการออกแบบเว็บ”
  โดย Frederick O'Brien
• “บทนำสู่ SWR: React Hooks สำหรับการดึงข้อมูลระยะไกล”
  โดย Ibrahima Ndaw
• “นักออกแบบเว็บไซต์สามารถช่วยให้ร้านอาหารก้าวไปสู่ประสบการณ์ดิจิทัลได้อย่างไร”
  โดย Suzanne Scacca
• “คู่มือปฏิบัติสำหรับการทดสอบ React Applications ด้วย Jest”
  โดย Adeneye David Abiodun
• “จุดเด่นของ Django: การโต้เถียงกับทรัพย์สินคงที่และไฟล์มีเดีย (ตอนที่ 4)”
  โดย Philip Kiely

การถอดเสียง

Drew McLellan: เขาเป็นนักการศึกษาและนักออกแบบเว็บไซต์อิสระในสหราชอาณาจักร และเคยทำงานในอุตสาหกรรมเว็บสำหรับนักออกแบบมานานกว่าทศวรรษ ในช่วงเวลานั้น เขาทำงานร่วมกับองค์กรที่ใหญ่ที่สุดในโลก เช่น Harley-Davidson, BSkyB, Unilever, Oracle และ NHS ควบคู่ไปกับ Heydon Pickering เขาเป็นผู้เขียนร่วมของ Every Layout และเปิด Front-End Challenges Club ซึ่งเน้นการสอนแนวทางปฏิบัติที่ดีที่สุดสำหรับการพัฒนาส่วนหน้าผ่านการท้าทายสั้น ๆ ที่สนุกสนาน

Drew: กิจการล่าสุดของเขาคือ Piccalilli จดหมายข่าวเว็บไซต์พร้อมบทแนะนำและหลักสูตรที่จะช่วยให้คุณก้าวขึ้นเป็นนักพัฒนาและนักออกแบบส่วนหน้า เรารู้ว่าเขาเป็นนักพัฒนาและนักการศึกษาที่มีประสบการณ์ แต่คุณรู้หรือไม่ว่าเขาเป็นคนแรกที่ได้รับอนุญาตให้แข่งขันที่ Crufts กับแพนด้า?

ดรูว์: เพื่อนที่ยอดเยี่ยมของฉัน ยินดีต้อนรับแอนดี้ เบลล์ สวัสดี แอนดี้ สบายดีไหม

Andy Bell: ฉันยอดเยี่ยมมาก ขอบคุณ คุณเป็นอย่างไรบ้าง?

ดริว : ฉันสบายดี ขอบคุณมาก วันนี้ฉันอยากคุยกับคุณเกี่ยวกับสิ่งที่คุณโพสต์บนไซต์ Piccalilli เกี่ยวกับวิธีการใช้ CSS ที่คุณพัฒนาขึ้นเพื่อตัวคุณเองในช่วงหลายปีที่ผ่านมา ก่อนอื่น ฉันเดาว่าเราน่าจะสำรวจว่าเราหมายถึงอะไรโดยวิธี CSS เพราะนั่นอาจหมายถึงสิ่งที่แตกต่างกันสำหรับแต่ละคน เมื่อคุณนึกถึงวิธีการ CSS คุณนึกถึงอะไร?

Andy: นั่นเป็นคำถามที่ดีและยากสำหรับการเริ่มต้น Drew ขอขอบคุณที่ขอบคุณ!

ดริว: ยินดีต้อนรับ!

แอนดี้: มันเป็นเรื่องที่ยุ่งยาก ดังนั้นสำหรับบริบท ฉันใช้ BEM มาเป็นเวลานาน และนั่นคือตัวดัดแปลงองค์ประกอบบล็อก มันมีมานานแล้ว วิธีที่ฉันดูวิธีการ CSS คือ มันไม่ใช่เฟรมเวิร์ก มันคือโครงสร้างองค์กร นั่นเป็นวิธีที่ฉันชอบดู มันเหมือนกับกระบวนการเกือบ มันเหมือนกับว่าคุณมีปัญหาที่คุณต้องแก้ไขด้วย CSS และคุณใช้วิธีการเพื่อแก้ปัญหาให้กับคุณ และทำให้สิ่งต่าง ๆ สามารถคาดเดาและจัดระเบียบได้ BEM เป็นเพียงตำนานเพราะมันประสบความสำเร็จอย่างมาก

Andy: จากนั้นคุณเกือบจะมีคุณสมบัติเหมือนองค์ประกอบของสไตล์และสิ่งนั้น คุณแทบจะพูดได้เลยว่าพวกมันมีการวางแนวทางตามระเบียบวิธี ถึงแม้ว่าพวกมันจะมีความเกี่ยวพันกันมากกว่ากรอบงานเล็กน้อย แต่ก็ยังเป็นวิธีการแยกสิ่งต่าง ๆ ออกเป็นโมเลกุลเล็กๆ โดยพื้นฐานแล้วนั่นคือสิ่งที่ฉันพยายามทำกับ CUBE CSS เช่นกัน โครงสร้างการคิด ฉันคิดว่าฉันอธิบายเป็น

ดรูว์: มันคือการประยุกต์ใช้กระบวนการสำหรับวิธีที่คุณออกแบบสถาปัตยกรรมและเขียน CSS มันไม่ได้มีอะไรมากไปกว่าเครื่องมือหรือเทคโนโลยีประเภทอื่น ๆ มันเป็นเพียงขั้นตอนการทำงาน จึงมีแนวทางที่แตกต่างกันมากมาย คุณพูดถึง BEM มี SMACSS, OOCSS, Atomic CSS แล้วคุณมีแนวทางลูกรักที่ไม่ธรรมดาแบบนี้ อย่าง ABEM คุณเคยเห็นสิ่งนั้นหรือไม่?

แอนดี้: ค่ะ

Drew: ทำไมต้องเผยแพร่ของคุณเอง?

แอนดี้ : ค่ะ ค่ะ ทำไมต้องทำด้วยตัวเอง? เป็นคำถามที่ดีมาก ฉันคิดว่าคนที่รู้จักฉันดีคงรู้ดีว่าฉันชอบแล่นเรือต้านกระแสน้ำมาก ส่วนใหญ่เป็นเพราะฉันมักจะทำโปรเจ็กต์ที่หลากหลายเช่นกัน ในทีมที่หลากหลาย ฉันพบว่ามันยากมากที่จะทำงานกับ BEM กับนักพัฒนาแบบเดิมๆ เพราะพวกเขาคุ้นเคยกับการใช้ CSS สำหรับสิ่งที่เกี่ยวกับ CSS: น้ำตก และอื่นๆ และนั่นเป็นเหตุผลที่ฉันขโมยสิ่งนั้นมาจากภาษา .

แอนดี้: อีกด้านก็คือ วิธีการที่มีโครงสร้างน้อยกว่า มันยากกว่าที่จะทำงานกับโปรแกรมเมอร์ คนประเภท JS เพราะพวกเขาชอบโครงสร้างและการจัดระเบียบ และส่วนประกอบเล็กๆ ซึ่งเข้าใจได้ในการทำงานกับภาษาที่พวกเขาทำงาน

Andy: ดังนั้นฉันจึงพบว่าตัวเองอยู่ในตำแหน่งเหล่านี้ที่ฉันทำงานกับผู้คนประเภทต่างๆ โครงการประเภทต่างๆ ที่วิธีการเดียวใช้ไม่ได้ผล หลายปีที่ผ่านมา ฉันแค่คิดเล่นๆ กับแนวคิดที่ว่าสิ่งต่างๆ เป็นอย่างไร และมีบางสิ่งที่ฉันและเฮย์ดอนทำ ทุกเลย์เอาต์ ซึ่งบังคับส่วนใหญ่ของมัน ซึ่งก็คือ C ส่วนการเรียบเรียง แล้วฉันก็ค่อยๆ พัฒนามันอย่างรวดเร็วในช่วง 6 เดือนที่ผ่านมา

Andy: เหตุผลเดียวที่ฉันเขียนบทความเกี่ยวกับเรื่องนี้ก็เพราะฉันเพิ่งจะเรียนหลักสูตรนี้ และฉันคิดว่าฉันควรเขียนเนื้อหาเพิ่มเติมเพื่อให้คนเข้าใจ และทุกอย่างก็พังทลายไปหมด ดังนั้นบางทีเรายังไม่จบเรื่องระเบียบวิธีมากนัก Drew

Drew: เนื้อหาหลักสูตรที่คุณรวบรวมมาใช้จริง ๆ แล้วใช้ CUBE CSS เป็นวิธีการใช่ไหม

แอนดี้: ค่ะ ดังนั้น 50% ที่ดีของหลักสูตรจึงเป็นส่วนหน้าจริงๆ แม้ว่าจะไม่จำกัดหลักสูตรก็ตาม มันเกี่ยวพันกับวิธีที่เราสร้าง front-end มากจนฉันพูดไม่ได้ว่า “อ้อ เปล่าหรอก นี่คือวิธีที่ฉันเขียน CSS ที่ดี” แล้วก็ปล่อยมันไป รู้ว่าคนชอบลงรายละเอียดก็เลยแบบว่าจะทำเป็นเขียนโพสต์นี้ที่ยาวและละเอียดจริงๆ แล้วถ้าใครอยากได้ทักษะและเข้าใจสิ่งที่เราทำจริงๆ แล้วพวกเขาก็ทำได้ ที่เหลือก็มาจากที่นั่น วันนี้เรามาถึง ดรูว์ นั่งคุยกันอยู่

Drew: ถ้ามีใครเข้าใจ BEM แล้ว และอาจกำลังใช้ BEM อยู่เป็นตัวอย่าง เพราะนั่นอาจเป็นหนึ่งในวิธีการที่กว้างที่สุดที่นำมาใช้ ใช่ไหม ดังนั้นหากพวกเขามีความเข้าใจเกี่ยวกับ BEM แล้วและกำลังจะมาที่ CUBE นั่นคือสิ่งที่พวกเขาจะยอมรับได้ง่ายหรือไม่? มีความคล้ายคลึงกันมากหรือแตกต่างกันอย่างสิ้นเชิง?

แอนดี้: ค่ะ ฉันจะบอกว่าการเปลี่ยนจาก BEM เป็น CUBE อาจเป็นการเปลี่ยนแปลงที่ราบรื่น โดยเฉพาะอย่างยิ่งวิธีที่ฉันยังชอบเขียน CSS สำหรับ CUBE ส่วนใหญ่สิ่งที่เกิดขึ้นในระดับที่สูงขึ้น ดังนั้นมันจึงเกิดขึ้นที่ระดับคาสเคด และมันกำลังเกิดขึ้นทั่วโลก CSS โดยใช้ยูทิลิตีเพื่อทำสิ่งต่างๆ มากมาย แต่เมื่อคุณเข้าใจถึงน็อตและสลักของมันคือส่วนประกอบ บล็อก และองค์ประกอบที่คล้ายกับ BEM สิ่งเดียวที่แตกต่างจาก BEM คือแทนที่จะมีตัวดัดแปลง เราใช้สิ่งนี้ที่เรียกว่าข้อยกเว้นแทน ซึ่งแทนที่จะใช้คลาส CSS มันจะเปลี่ยนเป็นแอตทริบิวต์ข้อมูลซึ่งฉันคิดว่าให้การแยกที่ดีและเป็นจริง ข้อยกเว้นซึ่งเป็นสิ่งที่ตัวดัดแปลงควรเป็น

แอนดี้: เหตุผลส่วนหนึ่งที่ฉันออกจาก BEM เพราะฉันพบวิธีทำงาน โดยเฉพาะอย่างยิ่งในระบบการออกแบบ ถูกครอบงำและกลายเป็นปัญหา เพราะมันเหมือนกับว่า บทบาทของบล็อกของฉัน ณ จุดนี้? เพราะถ้าฉันแก้ไขจนถึงจุดที่ไม่รู้จักเป็นประจำ วิธีการนี้ยังคงทำงานตามที่ควรจะเป็นอยู่หรือไม่

Andy: แล้วก็มีโทเค็นการออกแบบทั้งหมด สิ่งที่ Jina ทำกับ Lightning Design System ซึ่งเราทุกคนเริ่มนำมาใช้ในตอนนี้ สิ่งที่คลาสยูทิลิตี้เริ่มสมเหตุสมผลกับวิธีการนั้น ฉันก็เลยเอาทุกอย่างที่ฉันชอบเกี่ยวกับงานของคนอื่นมายัดใส่ตัวเองแทน

Drew: คุณพูดถึง BEM แนวทางการปรับเปลี่ยนแบบควบคุมไม่ได้ นั่นเป็นหนึ่งในปัญหาหลักของ BEM ที่ CUBE พยายามแก้ไขหรือไม่?

แอนดี้: ใช่แน่นอน ฉันชอบวิธีการปรับเปลี่ยนด้วย BEM มันสมเหตุสมผล สิ่งที่ฉันชอบเกี่ยวกับ BEM คือสิ่งที่ฉันยังทำอยู่ คือเครื่องหมายขีดล่างคู่สำหรับองค์ประกอบ แล้วมีเส้นประคู่สำหรับตัวปรับแต่ง ฉันชอบวิธีการจัดระเบียบสิ่งของ ไม่เป็นไร ตัวดัดแปลงจำนวนมากที่ฉันสามารถอธิบายได้ด้วยคลาสยูทิลิตี้และบิตอื่น ๆ ...

Andy: ตัวอย่างที่ฉันใช้ในบทความนี้คือ สมมติว่าคุณมีการ์ดแล้วพลิกการ์ด ดังนั้นเนื้อหาจึงปรากฏก่อนรูปภาพ ดังนั้นจึงเป็นเรื่องที่สมเหตุสมผล ที่จะเห็นการแสดงผล: งอแล้วคุณกลับด้าน ย้อนลำดับ เป็นเรื่องที่สมเหตุสมผล ที่จะมีกฎข้อยกเว้นสำหรับเรื่องนั้น เนื่องจากเป็นข้อยกเว้นของสถานะเริ่มต้นของการ์ด และนั่นคือสิ่งที่ฉันชอบที่จะเห็น มันเหมือนกับสถานะที่ได้รับผลกระทบในองค์ประกอบนั้น เป็นสิ่งที่มีข้อยกเว้น และนั่นก็สมเหตุสมผล

Andy: ด้วยหลายๆ อย่างที่ฉันได้ทำไปเมื่อเร็วๆ นี้ front-end stack สมัยใหม่ที่มี JavaScript เชิงโต้ตอบ ทำให้สถานะเปลี่ยนไปมาก และการจัดการที่เหมาะสมระหว่าง CSS กับ JavaScript เป็นเรื่องที่สมเหตุสมผล เพราะมันมีมากขึ้นและมากขึ้น มีความผูกพันกันมากขึ้นไม่ว่าจะชอบหรือไม่ก็ตาม เป็นภาษาทั่วไปสำหรับพวกเขา อย่างที่คุณเห็นต่อหน้าฉัน ไม่ค่อยเท่าไหร่ แต่เอาเถอะ คุณอาจจะคิดว่า “อันที่จริง ฉันทำงานกับการตอบโต้ได้ค่อนข้างมากเมื่อเร็ว ๆ นี้ ดังนั้นฉันกลับตรงกันข้าม” ฉันก็เลยมองเห็นได้เช่นกัน

ดรูว์: งั้นก็เข้าไปใน CUBE กันเถอะ CUBE ย่อมาจาก Composition Utility Block Exception นั่นถูกต้องใช่ไหม?

แอนดี้: ค่ะ ที่หนึ่ง

Drew: หมายความว่าอย่างไรบนโลกนี้?

Andy: โอ้เพื่อนคุณน่าจะเคยได้ยินมาก่อน! ปีที่แล้วผมกำลังคุย ฉันได้พูดคุยและถูกเรียกว่า Keeping it Simple ด้วย CSS ที่ปรับขนาด และในนั้นฉันได้แนะนำเวอร์ชันก่อนหน้าของชื่อ CBEUT ซึ่งเป็น Cascade Block Element Utility Token มันเป็นขยะ ฉันเกลียดชื่อของมัน ฉันทำมันสองสามครั้ง พูดคุยนี้เมื่อปีที่แล้ว และฉันไม่ชอบชื่อนี้จริงๆ จากนั้นเมื่อฉันมาทำสิ่งนี้ในปีนี้ ฉันคิดว่า "ฉันต้องคิดว่าจริงๆ แล้วมันคืออะไรและเรียกว่าอะไร" ฉันคิดว่า CUBE ขยะน้อยกว่าเล็กน้อย ฉันคิดว่านั่นเป็นวิธีที่ดีที่สุดที่ฉันสามารถอธิบายได้

Andy: แต่แล้ว ชื่อพวกนี้มันขยะแขยงเสมอสำหรับสิ่งเหล่านี้ ใช่ไหม? ฉันหมายถึงอย่าง BEM ชื่อขยะอะไรอย่างนี้! แต่เราทุกคนทำ ดู Jamstack: นั่นเป็นชื่อที่แย่มากเช่นกันใช่ไหม

Drew: ริมฝีปากของฉันถูกปิดผนึก!

แอนดี้: เจ้านายของคุณกำลังจะไป “อะไรนะ?” มันเป็นความจริง. มันเป็นอย่างที่มันเป็นในอุตสาหกรรมของเราไม่ใช่หรือ

Drew: ดูเหมือนว่าวิธีการ CSS จำนวนมากจะพยายามแก้ไขคุณลักษณะบางอย่างของ CSS เช่น น้ำตก ความเข้าใจของฉันจากสิ่งที่ฉันอ่านคือ CUBE พยายามใช้ประโยชน์จากคุณลักษณะและคุณสมบัติของ CSS เหล่านั้น

แอนดี้: ค่ะ การเปรียบเทียบที่ดีสำหรับมันคือ SCSS เช่น Sass เป็นส่วนขยายของภาษา CSS ตามธรรมชาติใช่ไหม คุณยังคงถูกต้องใน CSS ดังนั้น CUBE CSS จึงเป็นแบบนั้น ดังนั้นจึงเป็นส่วนขยายของ CSS ดังนั้นเราควรเขียน CSS เหมือนเดิม อย่างที่ CSS ควร… ก็ควรจะเขียน พูดตามตรงว่าควรจะเขียนอย่างไร ชื่อนี้บอกได้เลยว่า: Cascading Style Sheets ดังนั้นมันจึงกลับมาเป็นเหมือนเดิมอีกครั้ง เพราะสิ่งที่ฉันพบคือฉันได้ลดระดับลงมาจนถึงระดับการปรับให้เหมาะสมระดับจุลภาค ฉันเคยลงไปบนเส้นทางที่ฉันเห็นคนจำนวนมากไปเมื่อเร็ว ๆ นี้ที่… และฉันได้กล่าวถึงสิ่งนี้ในบทความเช่นกัน ที่ฉันเห็น… มีหลักฐานบางอย่างเกี่ยวกับมันเมื่อเร็ว ๆ นี้ ฉันพบว่าผู้คนกำลังสร้างส่วนประกอบตัวเว้นวรรคและอะไรทำนองนั้น และฉันเข้าใจปัญหานั้น ฉันเคยอยู่ในสถานการณ์นั้น

Andy: วิธีที่ฉันแก้ไขคือ แทนที่จะเจาะลึกและพยายามปรับให้เหมาะสมระดับจุลภาค จริงๆ แล้ว ฉันเริ่มคิดถึงสิ่งต่างๆ ในระดับการเรียบเรียงแทน เพราะมันไม่สำคัญว่าส่วนประกอบของคุณจะเล็กแค่ไหน ในบางจุด พวกเขากำลังจะไป จะเป็นเพจ พวกเขากำลังจะถูกดู คุณไม่สามารถหลีกเลี่ยงได้ นั่นคือวิธีที่มันจะเป็น ดังนั้นแทนที่จะพยายามพูดว่า "ใช่ ฉันต้องการผู้ช่วยตัวน้อยๆ เหล่านี้เพื่อทำเลย์เอาต์นี้" คุณพูดว่า "ใช่ ฉันมีมุมมองหน้าผู้ติดต่อ หรือหน้าผลิตภัณฑ์ และนั่นคือองค์ประกอบโครงร่างโครงกระดูก จากนั้นฉันก็สามารถใส่ส่วนประกอบอะไรก็ได้ที่ฉันต้องการเข้าไป” ขณะนี้มีสิ่งต่างๆ เช่น Grid และ Flexbox ซึ่งช่วยให้ทำสิ่งต่างๆ ได้มากขึ้น และโดยพื้นฐานแล้วคุณสามารถใส่อะไรก็ได้ที่คุณต้องการลงในโครงร่างโครงกระดูก ไม่สำคัญ จากนั้นคอมโพเนนต์ควรทำงานตามที่คุณต้องการ โดยมีหรือไม่มีการสืบค้นคอนเทนเนอร์

Drew: นี่คือส่วนองค์ประกอบของ CUBE ที่คุณกำลังมองหาสิ่งต่าง ๆ ในระดับมาโคร ดูว่าส่วนประกอบสามารถประกอบเป็นมุมมองได้อย่างไรเพื่อสร้างประเภทของหน้าที่คุณต้องการสร้างสำหรับไซต์หรือแอพ หรือมีอะไรคุณ

Andy: ดังนั้นจึงเป็นการสร้างกฎเกณฑ์ ก็เหมือนเป็นแนวทาง กำลังพยายามหาแนวทางสำหรับบางสิ่ง มันไม่เหมือนกฎเกณฑ์ที่เข้มงวด เช่น คุณควรทำเช่นนี้ คุณควรทำอย่างนั้น นั่นคือสิ่งที่คุณกำลังทำกับเบราว์เซอร์ ด้วยวิธีนี้ คุณกำลังพูดว่า... คุณไม่ได้บังคับให้ทำอะไรเลย คุณกำลังพูดว่า “ถ้าคุณสามารถจัดวางแบบนี้ได้จะดีมาก แต่ฉันเข้าใจว่านั่นอาจไม่ใช่กรณี ดังนั้นนี่คือขอบเขตและระดับบนและล่างบางส่วนที่เราสามารถใช้ได้ ทำในสิ่งที่คุณทำได้และเชียร์” จากนั้นคุณก็แค่โยนส่วนประกอบบางอย่างลงไป แล้วปล่อยให้มันทำในสิ่งที่มันทำ คุณเพิ่มการควบคุมให้เพียงพอเพื่อไม่ให้ดูขยะแขยง

แอนดี้: ตัวอย่างที่ดีจะได้เห็น… เราทำเลย์เอาต์ในทุกเลย์เอาต์ที่เรียกว่าตัวสลับ ซึ่งโดยพื้นฐานแล้วจะแสดงรายการในบรรทัดจนถึงจุดหนึ่งที่การคำนวณที่คำนวณความกว้างที่ควรวางซ้อนกัน . แต่เนื่องจากเราเพิ่มระยะขอบให้กับอินไลน์และบล็อค มันจึงใช้งานได้ ไม่ว่าสถานะจะเป็นอย่างไร มันก็ยังดูดี นั่นคือแนวคิด นั่นคือ เราไม่ได้บอกให้เบราว์เซอร์พูดว่า "คุณต้องเลเยอร์กริดสามคอลัมน์นี้ออก" เรากำลังพูดว่า “ถ้าคุณสามารถเลเยอร์ตารางสามคอลัมน์ออกได้ ให้ทำเลย มิฉะนั้นเพียงแค่กองและเว้นวรรคแทน” จึงเป็นวิธีการแบบนั้น ที่ปล่อยให้เบราว์เซอร์ทำหน้าที่ของมันจริงๆ

Drew: แนวทางต่างๆ มากมายที่นำมาใช้กับ CSS ในช่วงไม่กี่ปีที่ผ่านมาได้มุ่งเน้นอย่างมากที่ระดับองค์ประกอบของการจัดการกับทุกอย่างเหมือนเป็นส่วนประกอบ CUBE ไม่ได้มองข้ามแง่มุมขององค์ประกอบนั้นมากนัก เพียงแต่ให้แนวคิดพิเศษนี้เหนือการนำส่วนประกอบเหล่านั้นมาประกอบเป็นเลย์เอาต์ที่ใหญ่ขึ้น แทนที่จะบอกว่าเลย์เอาต์เป็นเพียงองค์ประกอบอื่น

Andy: ใช่ นั่นเป็นประเด็นที่ดี ใช่ ฉันคิดว่าสิ่งที่จะพูดเกี่ยวกับส่วนประกอบคือมันสำคัญ โดยเฉพาะอย่างยิ่งในส่วนหน้าที่ทันสมัย เราทำองค์ประกอบหลายอย่าง หลายอย่างเกี่ยวกับระบบ แต่วิธีที่ฉันเห็นส่วนประกอบคือ มันเป็นชุดของกฎที่ขยายขอบเขตของสิ่งที่ได้ทำไปแล้ว

Andy: ประเด็นที่ฉันพูดในบทความนี้คือ เมื่อคุณลงไปถึงระดับบล็อก สไตล์ส่วนใหญ่ของคุณเสร็จเรียบร้อยแล้ว และสิ่งที่องค์ประกอบของคุณกำลังทำอยู่คือจุด Is และข้าม Ts และมันบอกว่า “ใช่แล้ว ในบริบทนี้…” ตัวอย่างเช่น สำหรับการ์ด ทำให้รูปภาพมีความสูงขั้นต่ำ X และเพิ่มช่องว่างภายในเล็กน้อยที่นี่ ทำสิ่งนี้สิ่งนั้นและอื่น ๆ วางปุ่มที่นี่ เป็นเพียงกฎเพิ่มเติมที่สืบทอดมาจากส่วนที่เหลือของ CSS ฉันคิดว่านั่นอาจเป็นวิธีที่ดีที่สุดในการอธิบาย

Andy: ในขณะที่ BEM ส่วนประกอบคือที่มาของความจริง จนกว่าคุณจะใส่คลาสนั้นในองค์ประกอบ ไม่มีอะไรถูกนำไปใช้ ณ จุดนั้น และวิธีการนั้นก็ใช้ได้ ฉันเพิ่งพบว่าฉันเขียน CSS มากขึ้นโดยทำอย่างนั้น และ CSS ซ้ำๆ ซึ่งฉันไม่ชอบทำ

Drew: คุณจะพิจารณารูปแบบตัวอักษรและสี ตลอดจนจังหวะในแนวตั้ง ระยะห่าง และทั้งหมดนั้น ทั้งหมดนั้นเป็นส่วนหนึ่งของแนวคิดเรื่องการจัดองค์ประกอบในแบบจำลองนี้หรือไม่

แอนดี้: ค่ะ ใน CSS ทั่วโลกใช่อย่างแน่นอน โดยเฉพาะจังหวะแนวตั้งและกระแสน้ำ เราทำบทความเกี่ยวกับเรื่องนี้ 24 วิธี จริงไหม เมื่อสองสามปีก่อน เกี่ยวกับองค์ประกอบการไหลและจังหวะ นั่นเป็นนามธรรมจากแนวทางนี้เช่นกัน โดยที่คุณตั้งค่าองค์ประกอบพื้นฐานซึ่งโดยพื้นฐานแล้วจะใช้ตัวเลือกนกฮูกที่ทำ lobotomized ฉันไม่รู้ว่าจะอธิบายสิ่งนั้นอย่างไรในรายการวิทยุ แต่เราจะอธิบาย ฉันคิดว่าเราจะใส่ไว้ในบันทึกการแสดงเกี่ยวกับบทความ Heydon หรือบางสิ่งบางอย่าง แต่โดยพื้นฐานแล้วมันเลือกองค์ประกอบย่อย… ขออภัยองค์ประกอบพี่น้อง

Andy: ดังนั้นมันจึงบอกว่า "ใช่แล้ว ทุกองค์ประกอบที่ตามหลังองค์ประกอบ X มีค่า Margin ด้านบนของต้นทุน CSS และมูลค่าทรัพย์สิน" จากนั้นความสวยงามของสิ่งนั้นก็คือ คุณสามารถตั้งค่าคุณสมบัติ CSS แบบกำหนดเองนั้นในบริบทการเรียบเรียงได้เช่นกัน ดังนั้นคุณสามารถพูดว่า "ใช่แล้ว ในองค์ประกอบนี้ หากมีการไหลระหว่างเดินทาง เราจะตั้งค่าพื้นที่การไหลเป็น 2 rem จริง ๆ เพราะเราต้องการให้มันสวยและแข็งแรง พื้นที่กว้าง" จากนั้นคุณอาจพูดว่า “จริงๆ แล้ว ฉันต้องการให้ flow space ครึ่ง rem เพราะฉันอยากให้มันแน่น” ทั้งหมดนี้เกิดขึ้น การควบคุมทั้งหมดมาจากระดับที่สูงขึ้น และสิ่งที่คุณทำคือ คุณกำลังเพิ่มการแทนที่ตามบริบท แทนที่จะสร้างมันขึ้นมาใหม่ในแต่ละครั้ง สร้างสิ่งเดิมซ้ำแล้วซ้ำอีก

Drew: นั่นคือ C, องค์ประกอบ ต่อไปเรามี U ซึ่งก็คือยูทิลิตี้ ยูทิลิตี้หมายถึงอะไร?

Andy: ดังนั้นคลาสที่ทำหน้าที่เดียวและทำได้ดีจริงๆ นั่นอาจเป็นการนำโทเค็นการออกแบบไปใช้ ซึ่ง... เป็นนามธรรมของคุณสมบัติ โดยปกติแล้วจะเป็นสีหรือรูปแบบการพิมพ์ ขนาด และกฎเกณฑ์เช่นนั้น แนวคิดคือคุณสร้างคลาสยูทิลิตี้ที่ใช้สิ่งเหล่านั้น ดังนั้น คุณมีโปรแกรมอรรถประโยชน์ที่จะปรับใช้พื้นหลังหลัก ซึ่งเหมือนกับสีหลัก แล้วจึงใช้สีหลัก ซึ่งเป็นสีข้อความ จากนั้นคุณอาจสร้างโทเค็นการเว้นวรรคสำหรับการเติมขอบและสิ่งต่างๆ เหล่านั้น พวกเขาทำแค่งานเดียว พวกเขาแค่เพิ่มกฎการเว้นวรรคหนึ่งกฎ กฎสีหนึ่งกฎ แค่นั้นเอง

แอนดี้: แต่แล้วคุณก็มีระบบสาธารณูปโภคอื่นๆ ด้วยเช่นกัน ตัวอย่างที่ดีคือยูทิลิตี้แรปเปอร์ สิ่งที่จะทำคือ มันจะวางความกว้างสูงสุดบนองค์ประกอบ แล้ววางระยะขอบอัตโนมัติซ้ายและขวาเพื่อวางไว้ตรงกลางของสิ่งนั้น จึงมีงานเพียงงานเดียว และทำอย่างมีประสิทธิภาพและดี

แอนดี้: ดังนั้น คุณมีสไตล์ที่เป็นสากล คุณได้ตั้งค่าตัวพิมพ์มามากแล้ว และพื้นที่ของคุณก็เยอะ การจัดองค์ประกอบของคุณให้บริบทและการจัดวาง จากนั้นยูทิลิตีจะนำโทเค็นไปใช้กับองค์ประกอบโดยตรงเพื่อให้มีสไตล์ตามที่คุณต้องการ ตัวอย่างเช่น คุณกำลังพูดว่า "ฉันต้องการให้มีขนาดเท่านี้ และฉันต้องการให้มันมีส่วนนี้ และฉันต้องการให้มีการวัดนี้" จากนั้นในจุดนั้น… นี่คือสิ่งที่ฉันกำลังพูดเกี่ยวกับบล็อค… จากนั้นคุณไปที่สแต็กต่อไป และคุณได้ทำงานส่วนใหญ่ไปแล้ว ณ จุดนั้น

แอนดี้: ดังนั้นพวกเขาจึงให้วิธีการทำงานที่มีประสิทธิภาพจริงๆ แก่คุณ และเนื่องจากการจัดเรียงของ HTML ของกระแสข้อมูลลงในไพพ์ด้วย การสรุปภาระงานไปยัง HTML แทนที่จะเป็น CSS เป็นเรื่องที่ดีมาก ฉันเคยเข้าเรียนวิชาอรรถประโยชน์จริงๆ อย่างเช่น ในรูปแบบคนขี้โมโหแบบเก่า "โอ้ การแยกข้อกังวล" แต่จริงๆ แล้ว ฉันคิดว่ามันเป็นวิธีการทำงานที่ดีจริงๆ ฉันพูดถึงในบทความว่าฉันชอบ Tailwind CSS ฉันคิดว่ามันใช้ได้ผล และฉันชอบที่จะใช้มันสำหรับการพิมพ์ผลิตภัณฑ์ เพราะฉันสามารถพิมพ์อะไรออกมาได้อย่างรวดเร็วจริงๆ แต่ฉันคิดว่ามันเกินเลยไปหน่อยสำหรับ Tailwind ในขณะที่ฉันชอบใส่ฝนเมื่อมันทำมากกว่าแค่การใช้กฎเดียวในชั้นเรียน ฉันคิดว่าอย่างนั้น คุณล่ะ?

Drew: ใช่ คุณพูดมากในบทความเกี่ยวกับโทเค็นการออกแบบ ซึ่งเป็นสิ่งที่เราเคยพูดถึงใน Smashing Podcast กับ Jina Anne ในตอนที่สาม ฉันคิดว่ามันเป็นอย่างนั้น ดังนั้นดูเหมือนว่าโทเค็นการออกแบบจะเป็นองค์ประกอบพื้นฐานอย่างแท้จริง

แอนดี้: ค่ะ โอ้พระเจ้าใช่ ฉันจำได้แม่นมากตอนที่ Jina กำลังทำเรื่อง Lightning Design System เพราะตอนนั้นฉันกำลังสร้างระบบการออกแบบ หรือบางอย่างที่คล้ายกับระบบการออกแบบ และเรากำลังดิ้นรนเพื่อขออนุมัติจากผู้บริหาร เมื่อ Lightning Design System ออกมา ฉันแค่ส่งลิงก์ไปทีละลิงก์ แล้วบอกว่า "นี่คือสิ่งที่เรากำลังทำ เรากำลังสร้างระบบการออกแบบ นี่คือสิ่งที่ Salesforce กำลังใช้งานอยู่” ฉันจำได้ว่างานของเธอในตอนนั้นช่วยให้ฉันขนของเข้าบ้านได้จริงๆ

Andy: ถ้าอย่างนั้น โทเค็นการออกแบบก็ติดอยู่กับฉันเสมอว่าเป็นวิธีที่ดีจริงๆ ในการใช้กฎเหล่านี้ เนื่องจากฉันเป็นนักออกแบบโดยการค้าขาย ดังนั้นฉันสามารถเห็นได้ว่าองค์กรนั้นและความสามารถในการจัดระเบียบและสร้างแหล่งความจริงเพียงแหล่งเดียวนั้นมีประโยชน์จริงๆ เพราะเป็นสิ่งที่เราไม่มีจริงๆ ในการออกแบบดิจิทัล โดยเฉพาะใน Adobe ยุคของการทำงานกับ Photoshop และสิ่งต่างๆ เราไม่ได้มีความหรูหราขนาดนั้น เรามีฉบับพิมพ์ด้วยหนังสือ Pantone แต่เราไม่มีในรูปแบบดิจิทัลที่มีรหัสเลขฐานสิบหกแบบสุ่มทั่วทั้งร้าน

แอนดี้: มันเยี่ยมมาก ฉันชอบการควบคุมระดับนั้น อันที่จริง ฉันคิดว่ามันช่วยในเรื่องความคิดสร้างสรรค์ เพราะคุณไม่ได้คิดถึงเรื่องไม่สำคัญอีกต่อไป คุณแค่คิดว่าคุณกำลังทำอะไรกับมัน

Drew: การใช้โทเค็นการออกแบบเหล่านั้นมีความสำคัญกับแนวทางนี้หรือไม่? เป็นคุณสมบัติที่กำหนดเองของ CSS เสมอหรือไม่

Andy: ฉันคิดว่านั่นเป็นประเด็นที่สำคัญจริงๆ กับ CUBE คำตอบบางส่วนที่ฉันได้รับ ผู้คนต่างประสบปัญหาเล็กน้อย ไม่มีการเอ่ยถึงเทคโนโลยีในนั้นเลย เทคโนโลยีเดียวที่สอดคล้องกันคือ CSS คุณสามารถทำมันได้ตามที่คุณต้องการ คุณสามารถทำสิ่งนี้ด้วย CSS และ JS อะไรก็ได้ที่ผู้คนกำลังทำอยู่ หรือคุณสามารถทำได้ด้วย Vanilla CSS คุณสามารถทำได้ด้วย Sass ฉันทำมันกับ Sass น้อยกว่าถ้านั่นคือสิ่งที่คุณยังทำอยู่ เทคโนโลยีที่มีอยู่ทั้งหมดเหล่านี้ โพสต์ CSS สิ่งเหล่านี้ทั้งหมด อยากทำอะไรก็ได้ ไม่สำคัญ

Andy: แนวคิดก็คือถ้าคุณทำตามโครงสร้างเหล่านั้น คุณจะไม่เป็นไร นั่นคือแนวคิดเบื้องหลัง มันหลวมมากและไม่เข้มงวดเหมือนวิธีการบางอย่าง ฉันเคยเห็นมันกับ BEM โดยเฉพาะอย่างยิ่ง ผู้คนต่างหยั่งรากลึกในหลักการของ BEM จนถึงจุดที่มันเหมือนกับว่าคุณไม่ได้แก้ปัญหาอีกต่อไป ฉันคิดว่าคุณต้องมีความยืดหยุ่น ผมเคยพูดไว้ในการเสวนานี้เมื่อปีที่แล้ว ฉันชอบ "ถ้าคุณยึดปืนแน่นเกินไป คุณสามารถสร้างปัญหาให้กับตัวเองได้ในระยะยาว เพราะคุณพยายามเดินตามเส้นทางที่กำหนด และคุณรู้ว่ามันไม่ได้ผลอีกต่อไป" คุณควรมีความยืดหยุ่นและทำงานกับระบบแทนที่จะทำงานตามตัวอักษร

Drew: ดังนั้น B, B คือบล็อก คุณได้พูดถึงแนวคิดนี้แล้ว เมื่อถึงเวลาที่คุณไปถึงระดับบล็อก ทุกสิ่งทุกอย่างควรจะเข้าที่ จากนั้นการจัดสไตล์ระดับบล็อกจะเกี่ยวข้องกับรายละเอียดจริงของส่วนประกอบนั้น ๆ เท่านั้น โดยทั่วไปแล้ว แนวคิดของบล็อกคล้ายกับที่คนทั่วไปคุ้นเคยหรือไม่?

แอนดี้: โอ้ แน่นอน ใช่ ลองนึกภาพองค์ประกอบ BEM ของคุณและนำสิ่งที่มองเห็นออกมาทั้งหมดออก และนั่นคือสิ่งที่คุณเหลือ หลักๆ แล้วคือบล็อก นี่คือสิ่งที่ฉันพยายามจะพูดเมื่อเริ่มคิดถึงวิธีการนี้ครั้งแรก บล็อกจริงๆ แล้วเป็น C เป็นองค์ประกอบ แต่นั่นทำให้มันยากจริงๆ เพราะคุณอยู่ในอาณาเขตแบบเรียกซ้ำที่นั่น และฉันคิดว่าสมองของผู้คนจะระเบิด แต่จริงๆ แล้วนั่นคือสิ่งที่เป็นบล็อก จริงๆ แล้วมันเป็นเลเยอร์การจัดองค์ประกอบอีกชั้นหนึ่ง แต่มีบริบทที่เข้มงวดมากกว่า เช่นการ์ดของคุณ ปุ่มของคุณ ภาพหมุนของคุณ ถ้าคุณชอบทำแบบนั้นอยู่ และอะไรทำนองนั้นทั้งหมด

แอนดี้: มันเหมือนกับสิ่งที่เฉพาะเจาะจง เป็นส่วนประกอบ และภายในนั้นคุณกำลังตั้งกฎเกณฑ์เฉพาะเพื่อให้เป็นไปตามนั้น โดยไม่สนใจส่วนที่เหลือจริงๆ ดังนั้นคุณจึงไม่ใช่... คุณอาจใช้โทเค็นในบล็อก และฉันทำอย่างนั้น ถึงกระนั้น แต่จริงๆ แล้วมันเน้นเลย์เอาต์มากกว่า เป็นบล็อก เท่าที่ฉันทำงานกับพวกเขา หรืออย่างน้อยก็เอาโทเค็นและนำไปใช้ในวิธีเฉพาะ เช่น สถานะโฮเวอร์ของปุ่ม อะไรทำนองนั้น ดังนั้นจริงๆ บล็อกของคุณควรมีขนาดเล็กเมื่อคุณเข้าไปหาพวกเขา พวกเขาไม่ควรทำอะไรมากเลย

Drew: ดังนั้นมันอาจจะเล็กพอๆ กับไฮเปอร์ลิงก์

แอนดี้: ค่ะ

Drew: แต่มันอาจเป็นชุดรวมของบล็อกอื่น ๆ ด้วยเหรอ?

แอนดี้: ค่ะ เหมือนโมดูลอะไรบางอย่าง คุณทำได้แน่นอน เพราะอีกครั้ง ที่กลับไปสู่การจัดเรียงขององค์ประกอบ เป็นสิ่งที่ไม่ควรมีความสำคัญ ตัวอย่างที่ดีของสิ่งนั้นก็เหมือนกับการ์ด ดังนั้นเนื้อหาของการ์ดจึงเป็นเช่นหัวเรื่อง สรุปและปุ่ม คุณไม่ควรกำหนดเป้าหมายองค์ประกอบทั้งสามนี้โดยเฉพาะ คุณควรพูดว่า “ดูสิ อะไรก็ตามที่เกิดขึ้นเพื่อค้นหาตัวเองในเนื้อหา มีกฎโฟลว์อยู่ในนั้น และมีกฎการจัดวางองค์ประกอบ” และจากนั้นก็ไม่สำคัญหรอกว่าคุณใส่อะไรลงไป คุณอาจตัดสินใจว่าคุณต้องการใส่รูปภาพในเนื้อหานั้นและควรใช้งานได้ดีควรดูดี

Andy: นั่นคือประเด็นทั้งหมดในการทำงานกับ CSS เป็นวิธีที่ให้อภัยอย่างมากในการทำงานกับ CSS คุณกำลังทำให้ชีวิตของคุณง่ายขึ้นมากโดยการเข้มงวดน้อยลง เพราะเมื่อสิ่งต่างๆ บังเอิญพบตัวเองในบางสิ่ง ซึ่งมันจะดูไม่น่ากลัวอย่างที่ควรจะเป็น หากคุณเจาะจงเกี่ยวกับสิ่งต่างๆ มากขึ้น นั่นคือสิ่งที่ผมทำ พบ.

Drew: ฉันต้องการการให้อภัยอย่างมากเกี่ยวกับ CSS ของฉัน!

แอนดี้: ฉันรู้ว่าคุณทำ!

ดริว : เชอะ! นั่นคือ B สิ่งสุดท้ายคือ E: E คือข้อยกเว้น ตอนนี้เราไม่ได้พูดถึงข้อความแสดงข้อผิดพลาดใช่ไหม

แอนดี้: ไม่ ไม่ มันเป็นแบบของ-

Drew: เราไม่ได้พูดถึงข้อยกเว้น JavaScript

แอนดี้ : ค่ะ ค่ะ ไม่ควรมีสิ่งใดในจุดนี้ ฉันไม่ควรจะหวังอยู่แล้ว ไม่อย่างนั้นคุณอยู่ในป่าจริงๆ แล้ว: ฉันไม่คิดว่าฉันจะสามารถช่วยคุณได้! แนวคิดทั้งหมดของสิ่งนี้คือ… ดังนั้น คุณจึงได้สร้างบริบทด้วยบล็อกของคุณแล้ว และข้อยกเว้นก็คือว่า มันเหมือนกับข้อยกเว้นของกฎ: ดังนั้นการ์ดที่พลิกกลับหรืออาจเป็นปุ่มผี คุณรู้จักปุ่มเหล่านั้นที่เพิ่งมีเส้นขอบและพื้นหลังโปร่งใสหรือไม่? นั่นเป็นข้อยกเว้นเนื่องจากปุ่มอาจมีสีพื้นหลังทึบและสีของป้ายกำกับ มันจึงสร้างสถานะการแปรผันที่แตกต่างออกไป

Andy: เหตุผลที่ฉันทำเช่นนี้กับ data data แทนที่จะเป็น class และเหตุผลที่เป็นเพราะ a) ฉันคิดว่ามันดีที่จะมีความแตกต่าง ดังนั้นเมื่อคุณสแกน HTML หลายๆ แบบ คุณจะเห็นข้อมูล ขีดกลางบางอย่าง แบบว่า "ใช่ ตกลง มีบางอย่างเปลี่ยนแปลงไปในองค์ประกอบนี้" อีกอย่างคือมันดีมากที่จะให้ JavaScript เข้าถึงสถานะนั้น และในทางกลับกันด้วย ดังนั้นฉันจึงชอบใช้ state กับ data data ใน JavaScript ฉันคิดว่านั่นคือสิ่งที่พวกเขาต้องการ เป็นชั้นการสื่อสาร ความสามัคคีระหว่างพวกเขาดูเหมือนจะทำงานได้ดีจริงๆ

Andy: ตัวอย่างที่ดีคือ สมมติว่าคุณมีข้อความแสดงสถานะ จากนั้น JavaScript จะเพิ่มสถานะข้อมูลเป็นความสำเร็จ ข้อผิดพลาด หรือข้อมูล หรือบางอย่าง จากนั้นคุณสามารถเชื่อมต่อกับรูปแบบข้อยกเว้นของคุณใน CSS ดังนั้นคุณจึงรู้ว่านั่นเป็นข้อยกเว้นขององค์ประกอบสถานะและมันขัดกับสถานะเริ่มต้น ดังนั้นจึงเป็นวิธีที่สะดวกมากในการทำงานกับสิ่งต่างๆ สามารถคาดเดาได้ทั้งสองด้าน: สามารถคาดเดาได้ที่ส่วนท้ายของ CSS และคาดเดาได้ในส่วนท้ายของ JavaScript เช่นกัน

Drew: ฉันเดาว่ามันค่อนข้างดีที่บางสิ่งที่ชื่อคลาสไม่ได้ให้คุณคือคุณสมบัติและคุณค่า ดังนั้น ถ้าคุณต้องการมีบางอย่างที่เป็นสถานะ และอาจเป็นได้ทั้งความสำเร็จ ความล้มเหลว หรือคำเตือน หรือสิ่งที่คุณมี คุณสามารถระบุคุณสมบัติของรัฐนั้นโดยเฉพาะและพลิกค่าของมันได้ ในขณะที่มีรายการชื่อคลาสจำนวนมาก หากคุณจัดการสิ่งนั้นใน JavaScript คุณจะต้องดูแต่ละชื่อและเพิ่มตรรกะทางธุรกิจนั้นเข้าไปที่ระบุว่า “ฉันทำได้แค่ตั้งค่า หนึ่งในนั้น” และจะเกิดอะไรขึ้นถ้าสองคลาสเหล่านั้นถูกนำไปใช้กับองค์ประกอบเดียวกัน? คุณไม่สามารถรับสิ่งนั้นได้ด้วยแอตทริบิวต์ data มีเพียงค่าเดียวเท่านั้น

แอนดี้: ค่ะ นั่นเป็นวิธีที่ดีที่จะบอกว่าใช่ ฉันพบว่าการทำงานแบบนั้นมีประโยชน์มาก

Drew: น่าสนใจทีเดียว ฉันไม่คิดว่าฉันเคยเห็นวิธีการอื่นที่ใช้แนวทางนั้น นั่นเป็นเอกลักษณ์เฉพาะของ CUBE หรือไม่?

แอนดี้: มันอาจจะใช่ ฉันไม่ค่อยสนใจเรื่องอื่นมากนักซึ่งฉันควรทำ คนอื่นน่าจะทำอย่างนั้น ฉันจะบอกคุณตอนนี้ มันเป็นแง่มุมที่ขัดแย้งมากที่สุดของมัน บางคนไม่ชอบแนวคิดในการใช้แอตทริบิวต์ข้อมูล สิ่งนั้นก็เช่นกัน และวิธีที่ฉันตอบสนองคือ ทำในสิ่งที่คุณต้องการ เราไม่ได้บอกให้คุณทำอะไรบางอย่าง มันเป็นเพียงคำแนะนำเท่านั้น หากคุณต้องการยกเว้นคลาส CSS เช่น โมดิฟายเออร์ คุณก็ทำได้ ตำรวจ CUBE จะไม่มาเคาะประตูบ้านคุณ ไม่เป็นไร

Andy: สิ่งที่ CUBE คือการคิด มันคือโครงสร้าง คุณใช้โครงสร้างนั้นอย่างไรก็ตามที่คุณต้องการนำไปใช้กับเครื่องมือที่คุณต้องการ หรือเทคโนโลยีใดๆ ที่คุณต้องการ ตราบใดที่คุณรักษาสิ่งต่าง ๆ ให้สอดคล้องกัน นั่นคือสิ่งสำคัญ

Drew: ดังนั้นไม่มี CUBE บริสุทธิ์เลยเหรอ?

Andy: วิธีที่ฉันเขียนมันเป็น CUBE ที่บริสุทธิ์ Drew คนอื่นๆ เป็นแค่ของปลอม เป็นเพียงการเลียนแบบที่อ่อนแอ

Drew: นอกจากคุณแล้ว ไม่มีใครสามารถพูดว่า “นั่นไม่ใช่ตำรา CUBE”

แอนดี้: ไม่ แค่นั้นแหละ ไม่มีใครโต้แย้งได้จริงๆ ใช่ไหม ได้ ฉันจะไปด้วย ฉันคิดว่าน่าจะมีผลอะไรประมาณนั้น

Drew: คุณสามารถผสมผสานแนวทาง CUBE กับวิธีการอื่นได้หรือไม่? คุณสามารถใช้บิตของ BEM ได้หรือไม่

แอนดี้: ใช่ ฉันคิดอย่างนั้น ฉันคิดเกี่ยวกับมันนิดหน่อยเพราะฉันจะทำอย่างอื่นเพิ่มเติมในไม่ช้านี้ เพราะมันค่อนข้างเป็นที่นิยม ดังนั้นผู้คนจะต้องการงานมากขึ้น สิ่งหนึ่งที่ฉันจะดูคือวิธีการใช้วิธีการ CUBE กับสิ่งที่มีอยู่

แอนดี้: สเกลมีสองด้านตรงข้ามกัน คำถามที่ดีที่ผู้คนมักถามกันคือ: “วิธีนี้ใช้ได้กับทุกเลย์เอาต์ และอื่นๆ อย่างไร” ฉันชอบ โดยพื้นฐานแล้ว ทุกเลย์เอาต์คือ C นั่นคือสิ่งที่ทุกเลย์เอาต์เป็น มันคือเลเยอร์การจัดองค์ประกอบ จากนั้นมีคนอื่นถามว่า “แล้วสิ่งนี้จะทำงานกับ Atomic Web Design ได้อย่างไร เช่นเดียวกับสิ่งที่พวกเขา Brad Frost ทำ? มันเหมือนกับว่า คุณสามารถแยกชิ้นส่วนเหล่านั้นออกและนำไปใช้ในแต่ละระดับ การออกแบบปรมาณูลงลึกไปถึงรายละเอียดปลีกย่อย มันเป็นนามธรรมว่าในการใช้ ใช่ โอเค เอาล่ะ ฉันสามารถประยุกต์ใช้สิ่งนี้กับยูทิลิตี้ได้ ดังนั้นฉันคิดว่าโมเลกุล ฉันสามารถใช้สิ่งนั้นกับยูทิลิตี้ได้ และมันกำลังแปลสิ่งที่คุณรู้อยู่แล้วให้เป็นโครงสร้างการทำงานที่ต่างไปเล็กน้อยนี้

Andy: จริงๆ เป็นการเปลี่ยนชื่อหลายๆ อย่าง ฉันไม่ได้ประดิษฐ์อะไรที่นี่ ฉันแค่ อย่างที่ฉันพูด ฉันแค่ขโมยของที่ฉันชอบ ฉันชอบวิธีคิดเกี่ยวกับการออกแบบ Atomic Design นั่นเป็นงานที่ฉลาดจริงๆ และบีเอ็ม สิ่งที่แฮร์รี่ทำ คือ Inverted Triangle CSS ฉันคิดว่ามันเจ๋งมาก ดังนั้นฉันจึงมีเศษเล็กเศษน้อยที่ฉันชอบจากแต่ละอันและเย็บเข้าด้วยกันเป็นไฮบริดอื่น ๆ วิธีการ ฉันคิดว่าจะมีมากขึ้น

Drew: แนวทาง CUBE สามารถใช้กับโปรเจ็กต์ที่มีอยู่ซึ่งมี CSS อยู่แล้วได้หรือไม่ หรือเป็นสิ่งที่จำเป็นจริงๆ ในการเริ่มโปรเจ็กต์ใหม่ด้วย

แอนดี้: นั่นขึ้นอยู่กับอย่างมาก ดังนั้น หากคุณมีเหมือนงานบูตสแตรป และมีเพียง CSS แบบกำหนดเองหลายพันบรรทัด ซึ่งฉันเคยเกี่ยวข้องมาก่อนแล้ว ฉันคิดว่าคุณอาจจะพยายามดับไฟด้วยขวดน้ำตรงนั้น จุด. But if you… say, for instance, if you've got a rough BEM setup and it's gone a bit layer-y, you could use CUBE to refactor and actually pull it back into shape again.

Andy: It depends, the answer to that one. But it's doable, as with everything. If you really want it to work, Drew, you can do it if you want, can't you? The world is our oyster!

Drew: Especially if your BEM site's gone layer-y.

Andy: Yeah. Nothing worse than a layer-y BEM site!

Drew: I've noticed in the examples that you've given… and I've got an eagle eye, I've seen you've been doing this for a while… a lot of your class values in the HTML attribute are wrapped in square brackets.

Andy: Oh, God, yeah. Tell you what, Drew-

Drew: What is that about? มันเกี่ยวกับอะไร?

Andy: I'll tell you what, if there's ever one thing that I've done in my whole career that's just been absolutely outrageously controversial… and you follow me on Twitter, you've seen what comes out of my mouth… it's those bloody brackets! My, God! People either love them or hate them. They're Marmite, they are.

Andy: The reason I do them is a grouping mechanism. So if you look at the way that they're structured, the way I do it is, block at the start and then I'll do a utilities after that. Then what I might do is, in between a block group and a utility group, there might be another block class. So a good example of that would be… we'll go back to the card again. But then say that there's a specific block called a CTA, like a call to action. You might have that applied to the card as well, and then your utilities are enforcing the design attributes, so the colors and all that business. So then you've got three groups of stuff.

Andy: When you come to it, if you've got that order in your head each time, you know, okay, right, this first group's blocks. Oh, that's looks like another block. I've got that one. Then it's like, right, they're definitely utility classes. Then what I might even do is, if there's a lot of design token implementation, have that in a separate group. So it's just very clear what each group is doing, and there's a separation inside of the classes there as well. I've found it really helpful. Some people find it incredibly offensive. It's definitely a do it if you want to do it. Definitely you don't have to do it.

Andy: It's quite funny, when I published that article, so many people finished halfway through to ask me, “What is it with these brackets?” I was like, “Did you finish the article? Because there's a big section at the end where it explains exactly what they're doing,” to the point where I actually had to write a bit in the middle of the article of, “If the brackets are essentially doing your head in, click here and I'll skip you all the way down to that explanation bit so you can just read about them.” It can be quite controversial.

Andy: When I've worked on really, really complex front-ends… and we did a little bit of stuff together, didn't we, last year?

ดริว : ครับ

Andy: You've seen the sort of design implementation on that project that we were on. It requires that sort of grouping because there's just so much going on at the time, there's so much different stuff happening. I've just found it really, really useful over the years, and also get lots of questions about it, to the point where I was almost going to write just one page on my website that I could just fire people to to answer the question for them.

Drew: Slash, what's with the brackets?

Andy: Yeah. Slash, brackets. Have you seen that new Hey Email thing that's just come out? They've bought a domain of itsnotatypo.com, just to answer the whole Imbox, like im with an M rather than an in. Basically, I was like, “I think I need to do that,” like, whatswiththebrackets.com, and just do a one-pager about it.

Drew: It strikes me that the approach with brackets actually could be something that might be useful when using things like Tailwind or something that has a lot of classes because that can-

Andy: Yeah. Oh, God, yes.

Drew: You have classes that are addressing your break points and what have you, and then you'll have things that are for layout, things that are for color or type, or what have you. So it might also be a useful way of dealing in situations like that.

Andy: I'd definitely agree with that. A good analogy… not analogy. A good bit of info about Tailwind is that I actually quite like Tailwind. I've used that on very big projects. The one thing that really opened my eyes to Tailwind though was when I saw a junior developer try to work out what was going on, and it was really, really eye-opening because they just didn't have a clue what was happening.

Andy: I think that's one problem I've found with these sort of over-engineered approaches, which I think it's fair to say Tailwind is, is that there's a certain skill level that is required to work with it. I know the industry tends to have an obsession with seniority now, but there's still people that are just getting into the game that we need to accommodate, and I think having stuff that's closer to the language itself is more helpful in those situations because they're probably learning material that is the language as it is. So I think it's just a bit more helpful. Especially having a diverse team of people as well. Just food for thought for everyone.

Drew: People might look at all the different methodologies that are out there and say, “This is evidence that CSS is terrible and broken, that we need… all these problems have to be solved by hacking stuff on top. We need tools to fix bits of CSS. We need strict procedures for how we implement it, just to get it to work.” Should the platform be adapting itself? Do we need new bits of CSS to try and solve these problems or are we all right just hacking around and making up funny acronyms?

Andy: I think the power of CSS, I think, is its flexibility. So if you're going to program CSS, a lot of the knowledge is less of the syntax and more of the workings of a browser and how it works. I think that might be a suggestion, that the problem is that people might not have learnt CSS quite as thoroughly as they thought they might have learnt it, who created these problems. I've seen that in evidence myself. I spotted a spacing mechanism that had been invested, which was very complicated, and I thought, “This person has not learnt what padding is because padding would actually fix this problem for them, understanding how padding works and the box model.” That's not to be snidey about it.

Andy: We work in an industry now that moves at an even faster pace than it has done previously and I think there's a lot less time for people to learn things in detail. But, on that front, I think CSS still does have work to do in terms of the working group, who I think do a bloody good job. A great, shining example of their work was the Grid spec which was just phenomenal. The way that rolled out in pretty much every browser on day one, I thought that was so good.

Andy: But we've got more work to do, I think, and I think maybe the pace might need to increase a little, especially with stuff like container queries, we all love talking about them. Stuff like that I think would help to put CSS in a different light with people, I think. But I think CSS is brilliant, I love it. I've never had a problem with it in lots of years really. I do find some of the solutions a bit odd, but there you go.

Drew: What's the response been like to CUBE since you published the article?

Andy: Mind-blowing. I honestly published it as just supporting material, and that's all I expected it to be, and it's just blown up all over the place. A lot of people have been reading it, asking about it, been really interested about it. There's definitely more to come on it.

Andy: I did say in the article, I said, “Look, if people are actually quite interested in this, I'll expand on this post and actually make some documentation.” I've got bits of documentation dotted around all over the place, but to sort of centralize that, and then I was thinking of doing some workshops and stuff. So there's stuff to go. It's how Every Layout started as well. We both had these scattered ideas about layout and then we sort of merged them together. So something like that, I suppose, will come in the future.

Drew: Are there any downsides that you're aware of to using CUBE? Are there problems that it doesn't attempt to solve?

Andy: Yeah. This accent, Drew, it just won't go way, no matter what I do! In all seriousness, I think CUBE's got as close as I can get to being happy with the front-end, which is saying a lot, I think. You never know, things might change again. This has evolved over more recent years. Give it another five years, I'll probably be struggling with this and trying something else. I think that's the key point, is to just keep working on yourself and working on what you know and how you approach things.

Andy: This definitely won't work for everyone as well, I know that for a fact. I know that from my comments. I don't expect it to work for everyone. I don't expect anything to work for everyone. It's the same with JavaScript stuff: some people like the reactive stuff and some people don't. It is what it is. We're all people at the end of the day, we all have different tastes. It's all about communicating with your teammates at the end of the day, that's the important thing.

Drew: I know you as a very talented designer and developer and you, like many of us, you're just working on real projects all day, every day. But you've recently started publishing on this site, Piccalilli, which is where the CUBE CSS introduction article was. So Piccalilli is kind of a new venture for you, isn't it? What's it all about?

Andy: Very kind of you to say, Drew. You've actually worked with me, so that's high praise. But the Piccalilli thing is an evolution. So I'm a freelancer. I do client work, but I think this has become apparent with the pandemic, that that is not the most sustainable thing in the world in some industries. I think freelancing can be very, very tough, as a developer and designer. It's something that I've been doing it for so long now, 10 years… well, 12 years now actually.

Andy: ฉันชอบทำสิ่งที่แตกต่างออกไปเล็กน้อยและใช้ความรู้ที่ฉันมีและแบ่งปันกับผู้คนจริงๆ ฉันเปิดเผยและแบ่งปันมาโดยตลอด และฉันต้องการทำให้มันเป็นทางการ ดังนั้นฉันจึงสร้าง Piccalilli เพื่อเขียนบทช่วยสอน แต่สำหรับหลักสูตรที่ฉันผลิตเป็นหลัก นั่นคือ เนื้อสัตว์และมันฝรั่งหลัก แล้วก็มีจดหมายข่าวซึ่งก็คือ… ผู้คนต่างเพลิดเพลินกับจดหมายข่าวมากเพราะฉันแบ่งปันสิ่งดีๆ ที่ฉันพบบนอินเทอร์เน็ตทุกสัปดาห์ นั่นคือกระดูกสันหลังของมัน มันกำลังไปได้สวยจริงๆ นั่นคือสิ่งที่ฉันต้องการเห็นตัวเองทำงานเต็มเวลามากขึ้นเรื่อย ๆ ฉันคิดว่าหลายปีผ่านไป

Drew: แล้วอะไรจะเกิดขึ้นต่อไปสำหรับ Piccalilli? คุณมีของที่ออกมาหรือยัง?

Andy: ขอบคุณสำหรับประตูที่เปิดอยู่ Drew! เมื่อการบันทึกนี้ออกไป หลักสูตรแรกจะเผยแพร่: Learn Eleventy From Scratch และนั่นคือที่ที่เราได้เรียนรู้วิธีสร้างเว็บไซต์ Gatsby! ไม่ คุณเรียนรู้วิธีสร้างไซต์ Eleventy ดังนั้นคุณจึงเริ่มต้นด้วยไดเร็กทอรีที่ว่างเปล่าทั้งหมด ไม่มีอะไรอยู่ในนั้น ว่างเปล่า และในตอนท้าย คุณจะจบลงด้วยไซต์เอเจนซี่ที่ดูดีจริงๆ เราเรียนรู้ทุกประเภทในนั้น คุณเรียนรู้วิธีเข้าเมืองจริงๆ กับ Eleventy เราดึงข้อมูลระยะไกลจากสถานที่ต่างๆ เราใช้ CUBE CSS เพื่อสร้าง front-end ที่ดีจริงๆ

Andy: ถ้าคุณต้องการเข้าสู่ Jamstack และต้องการเข้าสู่ Static Site Generator หรือเพียงแค่วิธีการสร้างเว็บไซต์ที่ดี ฉันหวังว่าจะเป็นหลักสูตรที่มีประโยชน์มาก ขณะนี้กำลังได้รับการแก้ไขภายในหนึ่งนิ้วของชีวิตในขณะที่เรากำลังพูดถึง ฉันหวังว่ามันจะเจ๋งและมีประโยชน์ แต่นั่นเป็นการสะสมของสิ่งต่างๆ มากมายที่ฉันทำในช่วงสองสามปีที่ผ่านมา ดังนั้นมันควรจะสนุก

Andy: ซื้อเลย แล้วฉันจะทำโค้ดส่วนลดให้ เหมือนกับ smashingpod ที่ลดราคา 40% แล้วคุณจะได้มันมาตอนที่มันออกมา

ดริว : น่าทึ่งมาก เราจะเชื่อมโยงมันขึ้น คุณรู้วิธีสะกด Piccalilli อย่างน่าเชื่อถือแล้วหรือยัง?

Andy: ฉันอยู่กับ Chris และ Dave กับ ShopTalk Show และฉันก็พูดที่นั่นว่า "ถ้ามีสิ่งหนึ่งที่คุณต้องการจ้างฉันก็คือการเขียน Piccalilli ด้วยมือครั้งแรกโดยไม่ต้องคิด" เพราะฉันได้ เขียนคำนั้นหลายครั้งจนฉันรู้วิธีสะกดด้วยใจ ดังนั้นคำตอบสำหรับคำถามของคุณคือใช่

Drew: ฉันยังดิ้นรนอยู่ฉันจะบอกคุณมาก!

แอนดี้: มันยาก โอ้พระเจ้า. ฉันเห็นอกเห็นใจโดยสิ้นเชิง ฉันใช้เวลานานในการเรียนรู้วิธีการสะกดคำ แต่เป็นหนึ่งในคำเหล่านั้นในคำศัพท์ของเรา ปีนี้ฉันพยายามสะกดคำที่จำเป็นโดยไม่สะกดผิด!

Drew: ดังนั้นฉันจึงได้เรียนรู้ทุกอย่างเกี่ยวกับ CUBE CSS คุณได้เรียนรู้อะไรเมื่อเร็ว ๆ นี้ Andy?

แอนดี้: คุณรู้อะไรไหม? นี่จะทำให้คุณประหลาดใจ ดรูว์ MySQL คือสิ่งที่ฉันได้เรียนรู้เมื่อเร็วๆ นี้ โดยพื้นฐานแล้ว Piccalilli เผยแพร่ด้วยตนเองโดยสิ้นเชิง มันเป็นไซต์ Eleventy แต่มี API อยู่เบื้องหลังและมีฐานข้อมูล MySQL อยู่เบื้องหลัง เนื้อหาที่ให้เนื้อหาแก่ผู้คนที่พวกเขาซื้อนั้นจำเป็นต้องมีการสืบค้นที่ค่อนข้างหนักหน่วง ดังนั้นฉันจึงลงทุนอย่างถูกต้องใน MySQL บางตัว… โดยเฉพาะอย่างยิ่งความแตกต่างระหว่างการเข้าร่วม ซึ่งฉันไม่ได้ตระหนักจริงๆ ว่ามีความแตกต่างระหว่างการเข้าร่วมแต่ละประเภท นั่นจึงมีประโยชน์จริง ๆ และส่งผลให้มีการโต้ตอบกับฐานข้อมูลอย่างรวดเร็ว

Andy: ฉันเคยเรียกใช้สิ่งนี้ที่เรียกว่า Front-End Challenges Club และเมื่อฉันเปิดตัวครั้งแรกมันก็พังและตายไปเองเพราะ MySQL นั้นไม่ค่อยดีนัก ดังนั้นฉันจึงได้เรียนรู้วิธีทำสิ่งนั้นจริงๆ เพราะฉันไม่ใช่คนแบ็กเอนด์เลย ฉันเป็นคนเร่งรีบ ดังนั้นมันจึงไม่อยู่ในการส่งเงินของฉันอย่างแน่นอน นั่นคือคอของป่ามากกว่าใช่ไหม ฉันคิดว่ามันเจ๋งมาก MySQL จริงๆแล้วฉันชอบเขียนมัน เป็นภาษาสอนที่ดีจริงๆ ใช่ไหม

ดรูว์ : มันเยี่ยมมาก ฉันเรียน SQL ที่โรงเรียน

แอนดี้: ว้าว!

Drew: เรากำลังพูดถึงเมื่อ 20 ปีที่แล้ว

Andy: สมัยนั้นพวกเขามีคอมพิวเตอร์ไหม?

Drew: พวกเขาทำใช่ เราต้องไขว่-

Andy: คุณต้องเขียนมันด้วยมือเหรอ?

Drew: เราต้องไขลานมัน! เราทำ. แต่ฉันบอกคุณสำหรับนักพัฒนา มันเหมือนกับการเรียนรู้ตารางเวลาของคุณ: หนึ่งในสิ่งที่ดูเหมือนเป็นงานที่น่าเบื่อ แต่เมื่อคุณคล่องแคล่ว มันจะมีประโยชน์ครั้งแล้วครั้งเล่า

แอนดี้: ค่ะ อย่างแน่นอน มีความแตกต่างที่จับต้องได้จริงๆเช่นกัน คุณเห็นความแตกต่างของความเร็วจริงๆ ฉันชอบทำงานกับ Node มาก เพราะมันเร็วมาก แต่ Node และ MySQL เป็นเพียง... ไม่ใช่ตัวเลือกทั่วไป แต่ฉันคิดว่ามันเป็นทางเลือกที่ดีทีเดียว ฉันคิดว่ามันใช้งานได้ดีจริงๆ ดังนั้นฉันจึงมีความสุขกับสิ่งนั้น อย่างที่คุณทราบ ฉันไม่ชอบเขียน PHP นั่นจะไม่มีวันเป็นทางเลือก

Drew: ถ้าคุณผู้ฟังที่รัก อยากฟังเพิ่มเติมจาก Andy คุณสามารถติดตามเขาทาง Twitter ที่เขาอยู่ที่ hankchizljaw คุณสามารถค้นหา Piccalilli ได้ที่ piccalil.li ซึ่งคุณจะพบบทความที่อธิบาย CUBE CSS และแน่นอนว่าเราจะเพิ่มลิงก์ไปยังลิงก์ทั้งหมดในรายการบันทึกย่อของรายการด้วย

Drew: ขอบคุณที่มาร่วมงานกับเราในวันนี้ Andy คุณมีคำพรากจากกันบ้างไหม?

แอนดี้: อยู่อย่างปลอดภัยและสวมหน้ากากของคุณ