Houdini: อาจเป็นการพัฒนาที่น่าตื่นเต้นที่สุดใน CSS ที่คุณไม่เคยได้ยินมาก่อน

คุณเคยต้องการใช้คุณลักษณะ CSS บางอย่าง แต่ไม่ได้เพราะ ไม่รองรับเบราว์เซอร์ทั้งหมด หรือไม่ หรือที่แย่กว่านั้นคือรองรับในทุกเบราว์เซอร์ แต่การสนับสนุนนั้นมีปัญหา ไม่สอดคล้องกัน หรือแม้แต่เข้ากันไม่ได้โดยสิ้นเชิง? หากสิ่งนี้เกิดขึ้นกับคุณ – และฉันพนันได้เลย – คุณควรสนใจ Houdini

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

อ่านเพิ่มเติม เกี่ยวกับ SmashingMag:

• ทำไมคุณควรหยุดติดตั้งสภาพแวดล้อม WebDev ของคุณในเครื่อง
• อนาคตของ CSS: คุณสมบัติ CSS ทดลอง
• 53 CSS-เทคนิคที่คุณขาดไม่ได้

แต่นั่นหมายความว่าอย่างไรโดยเฉพาะ? มันเป็นความคิดที่ดีหรือไม่? และจะช่วยให้นักพัฒนาสร้างเว็บไซต์ในปัจจุบันและอนาคตได้อย่างไร

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

ฮูดินี่กำลังพยายามแก้ปัญหาอะไร?

ทุกครั้งที่ฉันเขียนบทความหรือสร้างตัวอย่างเพื่ออวดคุณลักษณะ CSS ใหม่ล่าสุด ย่อมมีคนในความคิดเห็นหรือบน Twitter จะพูดว่า "นี่เยี่ยมมาก! น่าเสียดายที่เราจะไม่สามารถใช้ได้อีก 10 ปี”

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

แม้ว่าฉันจะไม่มีอะไรขัดกับกระบวนการมาตรฐาน แต่ก็ปฏิเสธไม่ได้ว่าอาจใช้เวลานาน!

ตัวอย่างเช่น flexbox ได้รับการเสนอครั้งแรกในปี 2009 และนักพัฒนายังคงบ่นว่าพวกเขาไม่สามารถใช้งานได้ในวันนี้เนื่องจากขาดการสนับสนุนเบราว์เซอร์ จริงอยู่ ปัญหานี้กำลังค่อยๆ หมดไป เพราะเบราว์เซอร์สมัยใหม่เกือบทั้งหมดตอนนี้อัปเดตโดยอัตโนมัติ แต่ถึงแม้จะใช้เบราว์เซอร์ที่ทันสมัย ​​ก็มักจะมีความล่าช้าระหว่างข้อเสนอและความพร้อมใช้งานทั่วไปของคุณลักษณะ

ที่น่าสนใจ นี่ไม่ใช่กรณีในทุกพื้นที่ของเว็บ พิจารณาว่าสิ่งต่าง ๆ ทำงานอย่างไรเมื่อเร็ว ๆ นี้ใน JavaScript:

ในสถานการณ์สมมตินี้ บางครั้งเวลาระหว่างการมีแนวคิดและการนำแนวคิดไปใช้ในการผลิตอาจใช้เวลาหลายวัน ฉันหมายถึง ฉันกำลังใช้ฟังก์ชัน async / await ในการผลิตอยู่แล้ว และฟีเจอร์นั้นยังไม่ได้ใช้งานในเบราว์เซอร์เดียว!

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

เหตุใดเราจึงไม่เขียน CSS Polyfills เพิ่มเติม

ในตอนแรก การเขียน CSS polyfills เพิ่มเติมอาจดูเหมือนเป็นคำตอบ ด้วยโพลีฟิลที่ดี CSS สามารถเคลื่อนไหวได้เร็วเท่ากับ JavaScript ใช่ไหม

น่าเศร้าที่มันไม่ง่ายอย่างนั้น Polyfilling CSS นั้นยากอย่างไม่น่าเชื่อ และในกรณีส่วนใหญ่ เป็นไปไม่ได้ที่จะทำในลักษณะที่ไม่ทำลายประสิทธิภาพโดยสิ้นเชิง

JavaScript เป็นภาษาไดนามิก ซึ่งหมายความว่าคุณสามารถใช้ JavaScript เพื่อ polyfill JavaScript และเนื่องจากมันเป็นไดนามิก มันขยายได้อย่างมาก ในทางกลับกัน CSS แทบจะไม่เคยใช้กับ polyfill CSS ในบางกรณี คุณสามารถแปลง CSS เป็น CSS ในขั้นตอนบิลด์ (PostCSS ทำได้) แต่ถ้าคุณต้องการ polyfill อะไรก็ได้ที่ขึ้นอยู่กับโครงสร้างของ DOM หรือเค้าโครงหรือตำแหน่งขององค์ประกอบ คุณจะต้องเรียกใช้ตรรกะฝั่งไคลเอ็นต์ของ polyfill

ขออภัย เบราว์เซอร์ไม่ได้ทำให้ง่าย

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

ภาพค่อนข้างเยือกเย็น ในฐานะนักพัฒนา คุณไม่สามารถควบคุมวิธีที่เบราว์เซอร์แยกวิเคราะห์ HTML และ CSS และเปลี่ยนให้เป็นโมเดลวัตถุ DOM และ CSS (CSSOM) คุณไม่สามารถควบคุมน้ำตกได้ คุณไม่สามารถควบคุมวิธีที่เบราว์เซอร์เลือกจัดวางองค์ประกอบใน DOM หรือวิธีการวาดองค์ประกอบเหล่านั้นบนหน้าจอ และคุณไม่สามารถควบคุมสิ่งที่ผู้แต่งทำ

ส่วนเดียวของกระบวนการที่คุณมีสิทธิ์เข้าถึงแบบเต็มคือ DOM CSSOM ค่อนข้างเปิดกว้าง อย่างไรก็ตาม ในการอ้างถึงเว็บไซต์ Houdini นั้น “ไม่ได้ระบุไว้ ไม่สอดคล้องกันในเบราว์เซอร์ต่างๆ และขาดคุณสมบัติที่สำคัญ”

ตัวอย่างเช่น CSSOM ในเบราว์เซอร์ในปัจจุบันจะไม่แสดงกฎสำหรับสไตล์ชีตข้ามที่มาและจะละทิ้งกฎ CSS หรือการประกาศที่ไม่เข้าใจ ซึ่งหมายความว่าหากคุณต้องการเติมคุณลักษณะในเบราว์เซอร์ ที่ไม่รองรับ คุณจะใช้ CSSOM ไม่ได้ คุณต้องผ่าน DOM แทน ค้นหาแท็ก <style> และ/หรือ <link rel=“stylesheet”> รับ CSS ด้วยตัวเอง แยกวิเคราะห์ เขียนใหม่ แล้วเพิ่มกลับเข้าไปใน DOM

แน่นอน การอัปเดต DOM มักจะหมายความว่าเบราว์เซอร์ต้องดำเนินการตามขั้นตอนเรียงซ้อน เลย์เอาต์ การลงสี และคอมโพสิตทั้งหมดอีกครั้ง

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

สิ่งนี้จะยิ่งแย่ลงไปอีกเมื่อคุณตระหนักว่า CSS polyfills ส่วนใหญ่ในปัจจุบันมีตัวแยกวิเคราะห์ CSS ของตัวเองและตรรกะการเรียงซ้อนของตัวเอง และเนื่องจากการแยกวิเคราะห์และน้ำตกเป็นสิ่งที่ซับซ้อนมาก โพลีฟิลเหล่านี้มักจะใหญ่เกินไปหรือบั๊กเกินไป

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

แต่ทำไมฉันถึงต้องการปรับเปลี่ยนเอ็นจิ้นการแสดงผลภายในของเบราว์เซอร์

สำหรับฉันนี่เป็นคำถามที่สำคัญที่สุดที่จะตอบในบทความนี้ทั้งหมด ดังนั้น หากคุณเคยอ่านคร่าวๆ มาบ้างแล้ว โปรดอ่านส่วนนี้อย่างช้าๆ และระมัดระวัง!

หลังจากดูส่วนสุดท้ายแล้ว ฉันแน่ใจว่าพวกคุณบางคนกำลังคิดว่า “ฉันไม่ต้องการสิ่งนี้! ฉันกำลังสร้างหน้าเว็บปกติ ฉันไม่ได้พยายามแฮ็คเข้าสู่ภายในของเบราว์เซอร์หรือสร้างบางสิ่งที่แปลกใหม่ ล้ำสมัย หรือล้ำสมัย”

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

• เพื่อทำให้ความแตกต่างระหว่างเบราว์เซอร์เป็นปกติ
• เพื่อประดิษฐ์หรือเติมคุณลักษณะใหม่ ๆ เพื่อให้ผู้คนสามารถใช้งานได้ในปัจจุบัน

หากคุณเคยใช้ไลบรารี JavaScript เช่น jQuery แสดงว่าคุณได้รับประโยชน์จากความสามารถนี้แล้ว! อันที่จริง นี่เป็นหนึ่งในจุดขายหลักของไลบรารีและเฟรมเวิร์กส่วนหน้าเกือบทั้งหมดในปัจจุบัน ที่เก็บ JavaScript และ DOM ที่ได้รับความนิยมสูงสุดห้าแห่งบน GitHub — AngularJS, D3, jQuery, React และ Ember — ทั้งหมดนี้ทำงานอย่างหนักเพื่อทำให้ความแตกต่างระหว่างเบราว์เซอร์เป็นปกติ คุณจึงไม่ต้องคิดมาก แต่ละรายการเปิดเผย API เดียวและใช้งานได้

ตอนนี้ ให้นึกถึง CSS และปัญหาข้ามเบราว์เซอร์ทั้งหมด แม้แต่เฟรมเวิร์ก CSS ยอดนิยม เช่น Bootstrap และ Foundation ที่อ้างว่าเข้ากันได้ข้ามเบราว์เซอร์ ไม่ได้ทำให้บั๊กข้ามเบราว์เซอร์เป็นมาตรฐาน - พวกเขาแค่หลีกเลี่ยง และบั๊กข้ามเบราว์เซอร์ใน CSS ไม่ใช่แค่เรื่องในอดีต แม้กระทั่งทุกวันนี้ ด้วยโมดูลเลย์เอาต์ใหม่ เช่น flexbox เราต้องเผชิญกับความไม่เข้ากันของเบราว์เซอร์หลายตัว

สิ่งสำคัญที่สุดคือ ลองนึกดูว่าชีวิตการพัฒนาของคุณจะเป็นอย่างไรถ้าคุณสามารถใช้คุณสมบัติ CSS ใดก็ได้และรู้ว่ามันจะใช้งานได้เหมือนกันทุกประการในทุกเบราว์เซอร์ และลองนึกถึงคุณลักษณะใหม่ทั้งหมดที่คุณอ่านในโพสต์บนบล็อกหรือฟังเกี่ยวกับการประชุมและการพบปะ — สิ่งต่างๆ เช่น กริด CSS, CSS snap point และการวางตำแหน่งที่เหนียวแน่น ลองนึกภาพถ้าคุณสามารถใช้สิ่งเหล่านี้ได้ทั้งหมดในวันนี้และในลักษณะที่มี ประสิทธิภาพ เทียบเท่ากับคุณสมบัติ CSS ดั้งเดิม และสิ่งที่คุณต้องทำคือคว้าโค้ดจาก GitHub

นี่คือความฝันของฮูดินี่ นี่คืออนาคตที่คณะทำงานพยายามทำให้เป็นไปได้

ดังนั้น แม้ว่าคุณจะไม่เคยวางแผนที่จะเขียน CSS polyfill หรือพัฒนาคุณลักษณะทดลอง คุณอาจต้องการให้คนอื่นสามารถทำได้ เพราะเมื่อมี polyfill เหล่านี้ ทุกคนก็ได้รับประโยชน์จาก polyfill เหล่านี้

ฟีเจอร์ใดบ้างของฮูดินี่ที่อยู่ในระหว่างการพัฒนา?

ฉันได้กล่าวไว้ข้างต้นว่านักพัฒนามีจุดเชื่อมต่อน้อยมากในไปป์ไลน์การเรนเดอร์ของเบราว์เซอร์ จริงๆ แล้ว มีที่เดียวคือ DOM และ CSSOM ในระดับหนึ่ง

เพื่อแก้ปัญหานี้ คณะทำงาน Houdini ได้แนะนำข้อกำหนดใหม่หลายอย่างที่จะให้นักพัฒนาสามารถเข้าถึงส่วนอื่น ๆ ของไปป์ไลน์การเรนเดอร์ได้เป็นครั้งแรก แผนภูมิด้านล่างแสดงไปป์ไลน์และข้อกำหนดใหม่ใดบ้างที่สามารถใช้แก้ไขขั้นตอนได้ (โปรดทราบว่าข้อกำหนดในสีเทามีการวางแผนแต่ยังไม่ได้เขียน)

ส่วนสองสามส่วนถัดไปจะให้ภาพรวมโดยย่อของข้อกำหนดใหม่แต่ละรายการและความสามารถประเภทใดบ้างที่มีให้ ฉันควรทราบด้วยว่าข้อกำหนดอื่น ๆ ไม่ได้กล่าวถึงในบทความนี้ สำหรับรายการทั้งหมด โปรดดูที่เก็บ GitHub ของฉบับร่างของ Houdini

CSS Parser API

ไม่ได้เขียน CSS Parser API ในขณะนี้ สิ่งที่ฉันพูดส่วนใหญ่สามารถเปลี่ยนแปลงได้ง่าย แต่แนวคิดพื้นฐานคือช่วยให้นักพัฒนาสามารถขยายตัวแยกวิเคราะห์ CSS และบอกเกี่ยวกับโครงสร้างใหม่ได้ ตัวอย่างเช่น กฎของสื่อใหม่ คลาสหลอกใหม่ การซ้อน @extends , @apply ฯลฯ

เมื่อ parser รู้เกี่ยวกับโครงสร้างใหม่เหล่านี้ ก็สามารถวางไว้ในตำแหน่งที่ถูกต้องใน CSSOM แทนที่จะทิ้งไป

คุณสมบัติ CSS และค่า API

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

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

พิจารณาตัวอย่างนี้:

 body { --primary-theme-color: tomato; transition: --primary-theme-color 1s ease-in-out; } body.night-theme { --primary-theme-color: darkred; }

ในโค้ดด้านบนนี้ หากมีการเพิ่มคลาส night-theme ในองค์ประกอบ <body> ดังนั้นทุกองค์ประกอบในหน้าที่อ้างอิงถึงค่า –primary-theme-color จะค่อยๆ เปลี่ยนจาก tomato เป็น darkred หากคุณต้องการทำสิ่งนี้ในวันนี้ คุณจะต้องเขียนการเปลี่ยนแปลงสำหรับแต่ละองค์ประกอบเหล่านี้ด้วยตนเอง เนื่องจากคุณไม่สามารถเปลี่ยนคุณสมบัติเองได้

คุณลักษณะที่น่าสนใจอีกอย่างหนึ่งของ API นี้คือความสามารถในการลงทะเบียน "apply hook" ซึ่งช่วยให้นักพัฒนามีวิธีแก้ไขค่าสุดท้ายของคุณสมบัติที่กำหนดเองในองค์ประกอบหลังจากขั้นตอนคาสเคดเสร็จสิ้น ซึ่งอาจเป็นประโยชน์อย่างมากสำหรับ polyfills

CSS พิมพ์ OM

CSS Typed OM ถือได้ว่าเป็นเวอร์ชัน 2 ของ CSSOM ปัจจุบัน เป้าหมายของมันคือการแก้ปัญหามากมายกับโมเดลปัจจุบันและรวมคุณสมบัติที่เพิ่มโดย CSS Parsing API ใหม่และคุณสมบัติ CSS และ Values ​​API

เป้าหมายหลักอีกประการของ Typed OM คือการปรับปรุงประสิทธิภาพ การแปลงค่าสตริงของ CSSOM ปัจจุบันเป็นการแสดง JavaScript ที่พิมพ์อย่างมีความหมายจะทำให้ประสิทธิภาพเพิ่มขึ้นอย่างมาก

CSS Layout API

CSS Layout API ช่วยให้นักพัฒนาสามารถเขียนโมดูลเลย์เอาต์ของตนเองได้ และโดย "โมดูลเลย์เอาต์" ฉันหมายถึงทุกอย่างที่สามารถส่งผ่านไปยังคุณสมบัติการ display CSS วิธีนี้จะทำให้นักพัฒนามีวิธีการจัดวางที่มีประสิทธิภาพเทียบเท่าโมดูลเลย์เอาต์ดั้งเดิม เช่น display: flex และ display: table เป็นครั้งแรกสำหรับนักพัฒนา

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

CSS Layout API ทำงานโดยให้นักพัฒนามีวิธี registerLayout ที่ยอมรับชื่อเลย์เอาต์ (ซึ่งใช้ใน CSS ในภายหลัง) และคลาส JavaScript ที่รวมตรรกะของเลย์เอาต์ทั้งหมด ต่อไปนี้คือตัวอย่างพื้นฐานของวิธีการกำหนด masonry ผ่าน registerLayout :

 registerLayout('masonry', class { static get inputProperties() { return ['width', 'height'] } static get childrenInputProperties() { return ['x', 'y', 'position'] } layout(children, constraintSpace, styleMap, breakToken) { // Layout logic goes here. } }

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

 body { display: layout('masonry'); }

CSS Paint API

CSS Paint API นั้นคล้ายกับ Layout API ด้านบนมาก มันจัดเตรียมวิธีการ registerPaint ที่ทำงานเหมือนกับวิธี registerLayout นักพัฒนาสามารถใช้ฟังก์ชัน paint() ใน CSS ได้ทุกที่ที่ต้องการอิมเมจ CSS และส่งผ่านในชื่อที่ลงทะเบียน

ต่อไปนี้คือตัวอย่างง่ายๆ ที่วาดวงกลมสี:

 registerPaint('circle', class { static get inputProperties() { return ['--circle-color']; } paint(ctx, geom, properties) { // Change the fill color. const color = properties.get('--circle-color'); ctx.fillStyle = color; // Determine the center point and radius. const x = geom.width / 2; const y = geom.height / 2; const radius = Math.min(x, y); // Draw the circle \o/ ctx.beginPath(); ctx.arc(x, y, radius, 0, 2 * Math.PI, false); ctx.fill(); } });

และสามารถใช้ใน CSS ได้ดังนี้:

 .bubble { --circle-color: blue; background-image: paint('circle'); }

ตอนนี้ องค์ประกอบ .bubble จะแสดงโดยมีวงกลมสีน้ำเงินเป็นพื้นหลัง วงกลมจะเป็นศูนย์กลางและมีขนาดเท่ากันกับตัวองค์ประกอบเอง ไม่ว่าจะเกิดอะไรขึ้น

งาน

ข้อมูลจำเพาะหลายรายการด้านบนแสดงตัวอย่างโค้ด (เช่น registerLayout และ registerPaint ) หากคุณสงสัยว่าจะวางโค้ดนั้นไว้ที่ใด คำตอบอยู่ในสคริปต์เวิร์กเล็ต

Worklets นั้นคล้ายกับ Web Worker และอนุญาตให้คุณนำเข้าไฟล์สคริปต์และเรียกใช้โค้ด JavaScript ที่ (1) สามารถเรียกใช้ที่จุดต่างๆ ในไปป์ไลน์การแสดงผล และ (2) เป็นอิสระจากเธรดหลัก

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

การเลื่อนแบบผสมและแอนิเมชั่น

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

สิ่งนี้จะช่วยให้นักพัฒนาสามารถสร้างแอนิเมชั่นการเลื่อนและการป้อนข้อมูลที่มีประสิทธิภาพสูง เช่น ส่วนหัวการเลื่อนแบบติดหนึบและเอฟเฟกต์พารัลแลกซ์ คุณสามารถอ่านเพิ่มเติมเกี่ยวกับกรณีการใช้งานที่ API เหล่านี้พยายามแก้ไขบน GitHub

แม้ว่าจะยังไม่มีข้อมูลจำเพาะอย่างเป็นทางการ แต่ Chrome ได้เริ่มการพัฒนาแบบทดลองแล้ว อันที่จริง ทีมงาน Chrome กำลังใช้ CSS snap point และการกำหนดตำแหน่งแบบติดหนึบโดยใช้พื้นฐานที่ API เหล่านี้จะเปิดเผยในที่สุด สิ่งนี้น่าทึ่งมากเพราะหมายความว่า Houdini API นั้นมีประสิทธิภาพเพียงพอที่จะสร้างคุณลักษณะใหม่ของ Chrome ได้ หากคุณยังมีความกลัวว่าฮูดินี่จะไม่เร็วเท่าเจ้าของภาษา ข้อเท็จจริงนี้เพียงอย่างเดียวน่าจะโน้มน้าวใจคุณให้เป็นอย่างอื่น

หากต้องการดูตัวอย่างจริง Surma ได้บันทึกวิดีโอสาธิตที่ทำงานบน Chrome บิวด์ภายใน การสาธิตเลียนแบบพฤติกรรมของส่วนหัวเลื่อนที่เห็นในแอปมือถือของ Twitter หากต้องการดูวิธีการทำงาน ให้ตรวจสอบซอร์สโค้ด

คุณทำอะไรได้บ้างตอนนี้

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

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

เท่าที่ผมบอกได้ มันไม่ใช่คำถามที่ว่าฮูดินี่จะเป็นไหม แต่เมื่อไหร่ และนั่นคือที่ที่พวกคุณเข้ามาทั้งหมด

ผู้จำหน่ายเบราว์เซอร์ เช่นเดียวกับคนอื่นๆ ที่สร้างซอฟต์แวร์ ต้องจัดลำดับความสำคัญของคุณสมบัติใหม่ และลำดับความสำคัญนั้นมักเป็นหน้าที่ของผู้ใช้ที่ต้องการคุณลักษณะเหล่านั้นมากน้อยเพียงใด

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

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

สมาชิกของคณะทำงาน Houdini (และ W3C โดยทั่วไป) ต้องการความคิดเห็นที่รอบคอบจากนักพัฒนาเว็บจริงๆ คนส่วนใหญ่ที่เข้าร่วมในกระบวนการเขียนข้อมูลจำเพาะคือวิศวกรที่ทำงานบนเบราว์เซอร์ พวกเขามักจะไม่ใช่นักพัฒนาเว็บมืออาชีพ ซึ่งหมายความว่าพวกเขาไม่รู้ว่าจุดปวดอยู่ที่ใด

พวกเขาขึ้นอยู่กับเราที่จะบอกพวกเขา

แหล่งข้อมูลและลิงค์

• CSS-TAG Houdini Editor Draft, W3C เวอร์ชันสาธารณะล่าสุดของ Houdini Draft ทั้งหมด
• CSS-TAG Houdini Task Force Specifications, GitHub ที่เก็บ Github อย่างเป็นทางการที่มีการอัพเดตและการพัฒนาข้อมูลจำเพาะ
• Houdini Samples ตัวอย่าง GitHub Code ที่แสดงและทดลองกับ API ที่เป็นไปได้
• รายชื่อผู้รับจดหมาย Houdini, W3C ที่สำหรับถามคำถามทั่วไป

ขอขอบคุณเป็นพิเศษสำหรับสมาชิก Houdini Ian Kilpatrick และ Shane Stephens สำหรับการทบทวนบทความนี้