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