Miriam Suzanne เป็นนักเขียน ศิลปิน และนักพัฒนาเว็บในเดนเวอร์ รัฐโคโลราโด ปัจจุบันกำลังทำงานเกี่ยวกับข้อกำหนด CSS ที่น่าสนใจ เช่น Container Queries และ Cascade Layers
โพสต์นี้เป็นส่วนหนึ่งของ Designcember การเฉลิมฉลองการออกแบบเว็บโดย web.dev
Miriam Suzanne เป็นนักเขียน ศิลปิน และนักพัฒนาเว็บในเดนเวอร์ รัฐโคโลราโด เธอเป็นผู้ร่วมก่อตั้ง OddBird (เอเจนซีเว็บ) นักเขียนประจำของ CSS Tricks สมาชิกทีมหลักของ Sass และผู้เชี่ยวชาญที่ได้รับเชิญจาก W3C ในกลุ่มงาน CSS ช่วงหลังๆ มานี้ เธอมุ่งเน้นไปที่การพัฒนาฟีเจอร์ CSS ใหม่ๆ เช่น Cascade Layers, Container Queries และ Scope นอกเวลาทำงาน Miriam เป็นนักเขียนนวนิยาย นักเขียนบทละคร และนักดนตรี เราได้พูดคุยเกี่ยวกับงานของเธอที่เกี่ยวข้องกับ Sass และ CSS
Rachel: ฉันรู้จักผลงานของคุณครั้งแรกจากกรอบตารางกริด Susy อะไรที่ทำให้คุณสร้างกรอบตารางนี้ขึ้นมา
มิเรียม: ย้อนกลับไปเมื่อปี 2008 เลย์เอาต์บนเว็บเป็นประสบการณ์การใช้งานที่แตกต่างออกไปโดยสิ้นเชิง นักพัฒนาซอฟต์แวร์ได้ย้ายจากการจัดวางตารางไปใช้กริดแบบลอยที่มีความหมายมากขึ้น (แต่ยังคงเป็นแบบแฮ็ก) "เฟรมเวิร์กตารางกริด" แบบ 12 คอลัมน์ที่ใช้ได้กับทุกขนาดได้รับความนิยมอย่างมาก ซึ่งมีตารางกริดที่กำหนดไว้ล่วงหน้า (โดยปกติจะเป็นแบบคงที่) พร้อมชุดคลาส CSS ที่กำหนดไว้ล่วงหน้า หากต้องการสิ่งใดที่ปรับแต่งได้มากกว่านี้ คุณก็ต้องทำเอง เห็นได้ชัดว่าเว็บไซต์จำเป็นต้องตอบสนองมากขึ้น แต่ยังไม่มี Media Query และมีปัญหาความเข้ากันได้ของเบราว์เซอร์มากมายเกี่ยวกับโฟลตแบบลื่นไหล
ฉันใช้แนวทาง CSS Systems ของ Natalie Downe ซึ่งเป็นการตอบสนองต่อทั้งขนาดแบบอักษรและวิวพอร์ตอย่างชาญฉลาด แต่ฉันก็รู้สึกหงุดหงิดกับคณิตศาสตร์ที่ซ้ำซากและการแฮ็กเบราว์เซอร์ที่จำเป็น ในขณะเดียวกัน Sass ก็เริ่มได้รับความสนใจ และเหมาะกับสิ่งที่ฉันต้องการอย่างยิ่ง ฉบับร่างแรกของ Susy นั้นเรียบง่ายมาก มีเพียงมิกซ์อิน 2-3 รายการเพื่อคำนวณและเพิ่มแฮ็กที่ฉันต้องการ เป้าหมายคือการทำให้มีขนาดเล็กที่สุดและแสดงเฉพาะโค้ดที่จำเป็น กริดที่ปรับแต่งได้อย่างเต็มที่โดยไม่มีคลาสที่กำหนดไว้ล่วงหน้า
ราเชล: คุณเปลี่ยนจากการทำงานกับตัวประมวลผล CSS ล่วงหน้ามาเป็นการทำงานกับข้อกำหนด CSS ได้อย่างไร คุณคิดว่าการทำงานกับตัวประมวลผลล่วงหน้าเป็นพื้นฐานที่ดีสำหรับการเขียนข้อกำหนดไหม
มิเรียม: จากประสบการณ์ของฉัน ทั้ง 2 ด้านนี้มีความทับซ้อนกันมาก และฉันก็ยังคงใช้งานทั้ง 2 ด้านนี้อยู่ แต่ฉันคิดว่าส่วนใหญ่เป็นเพราะทีม Sass โดยเฉพาะอย่างยิ่งNatalie Weizenbaum ซึ่งมีมุมมองระยะยาวมาก โดยพยายามพัฒนาเครื่องมือที่ผสานรวมกับมาตรฐานเว็บที่กำลังพัฒนาได้อย่างราบรื่น การก้าวข้ามโซลูชัน "แบบตายตัว" ที่เหมาะกับทุกคนและการสร้างความยืดหยุ่นในระยะยาวเป็นสิ่งสำคัญเมื่อคุณคิดถึงอนาคตของมาตรฐานเว็บหลัก
เราจะสร้างเครื่องมือที่คำนึงถึงความหลากหลายของความต้องการและแนวทางของนักพัฒนาซอฟต์แวร์ได้อย่างไร ในขณะที่ยังคงส่งเสริมและอำนวยความสะดวกในการเข้าถึงและข้อควรพิจารณาอื่นๆ ที่สำคัญ
Rachel: เรามีฟีเจอร์มากมายที่กำลังจะเพิ่มเข้ามาใน CSS ซึ่งจะแทนที่ฟังก์ชันการทำงานที่เดิมทีเป็นส่วนหนึ่งของ Sass มีเหตุผลที่หนักแน่นพอที่จะยังใช้ Sass หรือเครื่องมือที่คล้ายกันไหม
มิเรียม: ใช่ สำหรับบางคน แต่ไม่มีคำตอบที่ใช้ได้กับทุกคน เช่น ตัวแปร ตัวแปร Sass มีขอบเขตระดับคำและคอมไพล์ในเซิร์ฟเวอร์ โดยมีโครงสร้างข้อมูลที่จัดระเบียบ เช่น รายการและออบเจ็กต์ การจัดการสี ฯลฯ ซึ่งเหมาะสำหรับตรรกะของระบบการออกแบบที่ไม่จำเป็นต้องเรียกใช้ในเบราว์เซอร์
ตัวแปร CSS มีความทับซ้อนกันอยู่บ้าง แต่ก็ยังจัดเก็บค่าได้เช่นกัน แต่มีจุดแข็งและจุดอ่อนที่อิงตามการเรียงซ้อนที่แตกต่างกันโดยสิ้นเชิง Sass จัดการพร็อพเพอร์ตี้ที่กำหนดเองไม่ได้ และ CSS ก็จัดการข้อมูลที่มีโครงสร้างไม่ได้ ทั้ง 2 อย่างมีประโยชน์และมีประสิทธิภาพ แต่ความต้องการที่เฉพาะเจาะจงของคุณอาจแตกต่างกัน
ฉันคิดว่าการที่ผู้ใช้สามารถกำจัดเครื่องมือที่ไม่จำเป็นออกไปได้เป็นเรื่องดี และบางโปรเจ็กต์อาจไม่จำเป็นต้องใช้ทั้งตัวแปรฝั่งเซิร์ฟเวอร์และฝั่งไคลเอ็นต์ สบายดีสุดๆ เลย แต่การสรุปว่าทั้ง 2 อย่างเหมือนกันและใช้แทนกันได้นั้นเป็นเรื่องง่ายเกินไป จะมี Use Case เสมอที่ต้องใช้ตรรกะการออกแบบบางอย่างในฝั่งเซิร์ฟเวอร์ และบางอย่างในฝั่งไคลเอ็นต์ แม้ว่าเราจะไปถึงจุดที่ภาษาต่างๆ มีฟีเจอร์ที่เหมือนกันโดยพื้นฐานก็ตาม เราจะทำงานร่วมกับผู้ประมวลผลล่วงหน้าในระยะยาว
Rachel: มีอะไรที่ทำให้คุณประหลาดใจเมื่อได้เข้ามาเกี่ยวข้องกับการสร้างมาตรฐานมากขึ้น หรือมีอะไรที่คุณคิดว่าคนทั่วไปอาจไม่ทราบเกี่ยวกับกระบวนการนี้ไหม
มิเรียม: ก่อนที่จะเข้ามาเกี่ยวข้องกับกระบวนการมาตรฐาน ฉันรู้สึกว่ากระบวนการนี้เป็นเหมือนกล่องดำลึกลับและมหัศจรรย์ และไม่แน่ใจว่าจะเกิดอะไรขึ้น ฉันกลัวว่าความรู้เกี่ยวกับส่วนประกอบภายในของเบราว์เซอร์อาจไม่เพียงพอที่จะร่วมสนับสนุนได้ แต่ในความเป็นจริงแล้วทีมไม่ต้องการวิศวกรเบราว์เซอร์เพิ่มเติม โดยต้องการนักพัฒนาแอปและนักออกแบบที่สร้างเว็บไซต์และแอปพลิเคชันในโลกแห่งความเป็นจริง
ฉันรู้สึกประหลาดใจที่พบว่ามีผู้ที่เกี่ยวข้องเพียงไม่กี่คนที่มุ่งเน้นมาตรฐานเป็นหลัก แต่ก็มีผู้ที่พัฒนาหรือออกแบบเว็บไซต์เป็นหลักเพียงไม่กี่คนเช่นกัน W3C ประกอบด้วย "อาสาสมัคร" จากองค์กรสมาชิก (มักจะได้รับค่าตอบแทนจากองค์กรเหล่านั้น แต่ไม่ใช่เป็นงานหลัก) และการเป็นสมาชิกก็มีค่าใช้จ่ายสูง ซึ่งทำให้ผู้เข้าร่วมเบี่ยงเบนไปจากนักออกแบบและนักพัฒนาแอปที่ทำงานในชีวิตประจำวัน โดยเฉพาะอย่างยิ่งผู้ที่ทำงานให้ลูกค้าในเอเจนซีขนาดเล็กหรือทำงานอิสระ บทบาทของฉันในฐานะผู้เชี่ยวชาญที่ได้รับเชิญจะเป็นงานอาสาสมัครทั้งหมด ซึ่งเป็นงานอดิเรกที่มีค่าใช้จ่ายสูง หากฉันไม่พบแหล่งเงินทุนภายนอกสำหรับงานนั้น
ในความเป็นจริง กระบวนการนี้ค่อนข้างเปิดกว้างและเป็นสาธารณะ รวมถึงต้องมีส่วนร่วมของนักพัฒนาแอปด้วย แต่เนื่องจากมีการสนทนาเกิดขึ้นมากมายพร้อมๆ กันอยู่เสมอ จึงอาจเป็นเรื่องยากที่จะหาที่ของคุณ โดยเฉพาะอย่างยิ่งหากคุณไม่ได้ทำงานนี้เป็นงานหลัก
Rachel: Container Query เป็นสิ่งที่นักพัฒนาเว็บหลายคนใฝ่ฝันมานานหลายปี ฉันตื่นเต้นมากที่ได้เห็นว่าเรากำลังจะได้รับสิ่งเหล่านี้ ฉันรู้สึกว่าหลายคนกำลังคิดถึงประโยชน์ของ Container Queries คุณคิดว่าฟีเจอร์นี้มีศักยภาพที่จะปลดล็อกความคิดสร้างสรรค์ได้มากขึ้นด้วยไหม
มิเรียม: แน่นอนค่ะ แต่ฉันไม่คิดว่าทั้ง 2 อย่างนี้จะแยกจากกันโดยสิ้นเชิง เราทุกคนมีเวลาจำกัด และพยายามเขียนโค้ดที่บำรุงรักษาได้และมีประสิทธิภาพ เมื่อทำอะไรได้ยากในทางปฏิบัติ เราก็มักจะมีความคิดสร้างสรรค์น้อยลงกับสิ่งที่ทำได้
อย่างไรก็ตาม ปัจจุบันอุตสาหกรรมเว็บอยู่ภายใต้การครอบงำของผลประโยชน์ขององค์กรขนาดใหญ่ ดังนั้นความกังวลทางธุรกิจจึงได้รับความสนใจมากกว่าศิลปินบนเว็บเสมอ และฉันคิดว่าเราจะสูญเสียโอกาสมากมายหากมองข้ามความคิดสร้างสรรค์บนเว็บในฐานะ Use Case หลักสำหรับฟีเจอร์ต่างๆ ฉันรู้สึกตื่นเต้นมากที่ได้เห็นผู้ที่สร้างสรรค์งานศิลปะด้วย CSS บางคนทดลองใช้ต้นแบบ Container Query Jhey Tompkins ได้สร้างเดโมแบบอินเทอร์แอกทีฟที่ฉลาดเป็นพิเศษของ CSS Venetian Blinds เพื่อเป็นการแสดงความคิดเห็นเกี่ยวกับมีมต่อต้าน CSS แบบเก่า ฉันคิดว่ายังมีอีกหลายอย่างที่ต้องสำรวจในพื้นที่นี้ และฉันก็อดใจรอไม่ไหวที่จะได้เห็นสิ่งที่คนอื่นๆ สร้างสรรค์ขึ้นมา
การสนทนายังมุ่งเน้นไปที่คําค้นหาตามขนาดเช่นกัน เนื่องจากเป็นกรณีการใช้งานดั้งเดิม แต่ฉันก็ตื่นเต้นที่จะได้เห็นสิ่งที่ผู้คนทําด้วยคําค้นหาสไตล์ ซึ่งก็คือความสามารถในการเขียนสไตล์แบบมีเงื่อนไขตามค่าของพร็อพเพอร์ตี้หรือตัวแปร CSS ซึ่งเป็นฟีเจอร์ที่ทรงพลังอย่างยิ่งและยังไม่มีใครสำรวจมากนัก ฉันคิดว่ามันจะเปิดโอกาสให้ครีเอเตอร์ได้สร้างสรรค์ผลงานมากยิ่งขึ้น
Rachel: มีอะไรที่เราทำไม่ได้ (หรือกำลังจะมีวิธีทำ) ใน CSS ที่คุณคิดว่าจะมีประโยชน์ไหม
มิเรียม: ฉันตื่นเต้นมากกับสเปคอื่นๆ ที่ฉันกำลังทำอยู่ เลเยอร์แบบเรียงซ้อนจะช่วยให้ผู้เขียนควบคุมปัญหาความเฉพาะเจาะจงได้มากขึ้น และ Scope จะช่วยให้กำหนดเป้าหมายตัวเลือกได้อย่างแม่นยำยิ่งขึ้น แต่ทั้ง 2 อย่างนี้เป็นข้อกังวลด้านสถาปัตยกรรมระดับสูง ในฐานะศิลปิน ฉันตื่นเต้นกับฟีเจอร์ต่างๆ เช่น สวิตช์ CSS ซึ่งเป็นวิธีประกาศในการสร้างสไตล์แบบอินเทอร์แอกทีฟ หรือ "ไทม์ไลน์" ของคอนเทนเนอร์ ซึ่งช่วยให้เราเปลี่ยนค่าระหว่างเบรกพอยต์ของสื่อหรือคอนเทนเนอร์ได้อย่างราบรื่น ซึ่งมีผลในทางปฏิบัติอย่างมากต่อการจัดรูปแบบตัวอักษรที่ปรับเปลี่ยนตามพื้นที่โฆษณา แต่ก็ยังเปิดโอกาสด้านครีเอทีฟโฆษณามากมายสำหรับงานศิลปะและภาพเคลื่อนไหวที่ปรับเปลี่ยนตามพื้นที่โฆษณาด้วย
ราเชล: มีใครอีกบ้างที่กำลังสร้างสรรค์ผลงานที่น่าสนใจ สนุกสนาน หรือสร้างสรรค์บนเว็บในตอนนี้
มิเรียม: โอ้ ฉันไม่แน่ใจด้วยซ้ำว่าจะตอบคำถามนี้อย่างไรดี เพราะมีผู้คนมากมายที่ทำงานสร้างสรรค์ในสาขาต่างๆ ทั้ง CSSWG และ Open-UI กำลังดำเนินการเกี่ยวกับมาตรฐานที่น่าตื่นเต้นมากมาย รวมถึงงานของคุณเกี่ยวกับการแยกส่วน แต่โดยส่วนตัวแล้วฉันมักจะได้รับแรงบันดาลใจมากที่สุดจากศิลปินบนเว็บและวิธีที่ผู้คนนำเครื่องมือเหล่านี้ไปใช้ในการผลิตในรูปแบบที่ไม่ได้เชื่อมโยงกับการค้าโดยตรง ผู้คนอย่าง Jhey หรือ Lynn Fisher หรือ Yuan Chuan หรืออีกหลายๆ คนที่กำลังขยายขอบเขตของสิ่งที่เทคโนโลยีเว็บทำได้ในเชิงภาพและเชิงโต้ตอบ แม้แต่ผู้ที่ทำงานที่เน้นธุรกิจมากกว่าก็สามารถเรียนรู้เทคนิคทางศิลปะได้มากมาย
นอกจากนี้ ฉันยังชื่นชมผลงานศิลปะบนเว็บเชิงแนวคิดของบุคคลอย่าง Ben Grosser ซึ่งคอยกระตุ้นให้เราพิจารณาอีกครั้งว่าเราต้องการอะไรจากเว็บและโซเชียลมีเดียโดยเฉพาะ เช่น ลองดู minus.social ใหม่ของเขา
Rachel: ติดตามผลงานของ Miriam เกี่ยวกับ CSS ได้ที่ css.oddbird.net และดูสิ่งที่เธอทำอื่นๆ ได้ผ่านเว็บไซต์ที่ miriam.codes และ Twitter @TerribleMia