คณะทำงาน CSS ที่ TPAC: มีอะไรใหม่ใน CSS?

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

TPAC คืออะไร?

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

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

คณะทำงาน CSS

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

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

นี่คือการเลือกสิ่งที่เราพูดถึงซึ่งฉันคิดว่าน่าจะสนใจคุณมากที่สุด

แถบเลื่อน CSS

ข้อกำหนด CSS Scrollbars พยายามกำหนดรูปแบบมาตรฐานในการกำหนดขนาดและสีของแถบเลื่อน หากคุณมี Firefox Nightly คุณสามารถทดสอบได้ หากต้องการดูตัวอย่างด้านล่าง ให้ใช้ Firefox Nightly และเปิดใช้งานแฟล็ layout.css.scrollbar-width.enabled และ layout.css.scrollbar-color.enabled โดยไปที่ https://about:config ใน Firefox Nightly

ข้อมูลจำเพาะทำให้เรามีคุณสมบัติใหม่สองอย่าง: scrollbar-width และ scrollbar-color คุณสมบัติ scrollbar-width สามารถใช้ค่า auto , thin , none , หรือ length (เช่น 1em ) ดูเหมือนว่าค่า length อาจถูกลบออกจากข้อกำหนด อย่างที่คุณจินตนาการได้ นักพัฒนาเว็บอาจสร้างแถบเลื่อนที่ใช้ไม่ได้มากโดยเล่นกับความกว้าง ดังนั้นควรให้เบราว์เซอร์กำหนดความกว้างที่แน่นอนซึ่งสมเหตุสมผล แต่จะแสดงบางหรือหนาแทน แถบเลื่อน Firefox ไม่ได้ใช้ตัวเลือกความยาว

หากคุณใช้ค่า auto เบราว์เซอร์จะใช้แถบเลื่อนเริ่มต้น: thin จะให้แถบเลื่อนแบบบาง และ none แถบเลื่อนที่มองเห็นได้ (แต่องค์ประกอบจะยังสามารถเลื่อนได้)

ในเบราว์เซอร์ที่รองรับ CSS Scrollbars คุณสามารถดูสิ่งนี้ได้ในการสาธิต:

คุณสมบัติ scrollbar-color เกี่ยวข้องกับ - อย่างที่คุณคาดหวัง - สีแถบเลื่อน แถบเลื่อนมีสองส่วนซึ่งคุณอาจต้องการให้สีแยกจากกัน:

• นิ้วหัวแม่มือ
  แถบเลื่อนที่เลื่อนขึ้นและลงเมื่อคุณเลื่อน
• ติดตาม
  พื้นหลังของแถบเลื่อน

ค่าสำหรับคุณสมบัติ scrollbar-color คือ auto , dark , light และ <color> <color>

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

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

ในเบราว์เซอร์ที่รองรับ CSS Scrollbars คุณสามารถเห็นสิ่งนี้ในการสาธิต:

หน่วยอัตราส่วนภาพ

เราใช้ padding hack ใน CSS เพื่อให้ได้กล่องอัตราส่วนกว้างยาว อย่างไรก็ตาม ด้วยการถือกำเนิดของ Grid Layout และวิธีที่ดีกว่าในการปรับขนาดเนื้อหา การมีวิธีที่แท้จริงในการทำอัตราส่วนใน CSS ได้กลายเป็นความจำเป็นเร่งด่วนมากขึ้น .

มีสองประเด็นที่หยิบยกขึ้นมาบน GitHub ซึ่งเกี่ยวข้องกับข้อกำหนดนี้:

• ต้องการหน่วยอัตราส่วนภาพ
• อัตราส่วนภาพ

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

:where() ฟังก์ชั่น Pseudo-Class

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

คลาสหลอก :matches() อาจเป็นสิ่งใหม่สำหรับคุณเนื่องจากเป็นตัวเลือกระดับ 4 อย่างไรก็ตาม อนุญาตให้คุณระบุกลุ่มของตัวเลือกเพื่อใช้ CSS บางส่วนได้ ตัวอย่างเช่น คุณสามารถเขียน:

 .foo a:hover, pa:hover { color: green; }

หรือด้วย :matches()

 :matches(.foo, p) a:hover { color: green; }

หากคุณเคยมีตัวเลือกจำนวนมากเพียงเพื่อตั้งกฎคู่เดียวกัน คุณจะเห็นว่าตัวเลือกนี้จะมีประโยชน์เพียงใด CodePen ต่อไปนี้ใช้ชื่อนำหน้าของ webkit-any และ -moz-any เพื่อแสดงฟังก์ชันการ matches() คุณสามารถอ่านเพิ่มเติมเกี่ยวกับการแข่งขัน () บน MDN

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

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

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

ตรรกะชวเลขสำหรับระยะขอบและช่องว่างภายใน

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

ตัวอย่างเช่น สำหรับระยะขอบทางกายภาพ เรามี:

• margin-top
• margin-right
• margin-bottom
• margin-left

การแมปลอจิคัลสำหรับสิ่งเหล่านี้ (สมมติว่าแนวนอน-tb) คือ:

• margin-block-start
• margin-inline-end
• margin-block-end
• margin-inline-start

เราสามารถมีชวเลขสองค่าได้ ตัวอย่างเช่น ในการตั้งค่าทั้ง margin-block-start และ margin-block-end เป็นชวเลข เราสามารถใช้ margin-block: 20px 1em ค่าแรกแทนขอบเริ่มต้นในมิติบล็อก ค่าที่สองคือขอบสิ้นสุดในมิติบล็อก

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

 @mode "logical";

หรือใช้บล็อกที่ดูเหมือนแบบสอบถามสื่อเล็กน้อย:

 @mode (flow-mode: relative) { }

จากนั้น คำแนะนำต่างๆ สำหรับตัวแก้ไขคำหลัก การใช้เครื่องหมายวรรคตอน หรือการสร้างชื่อคุณสมบัติใหม่:

 margin: relative 1em 2em 3em 4em; margin: 1em 2em 3em 4em !relative; margin-relative: 1em 2em 3em 4em; ~margin: 1em 2em 3em 4em;

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

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

เราไม่สามารถแก้ไขปัญหาได้ ดังนั้นหากคุณมีความคิดว่าข้อใดดีที่สุด หรือเห็นปัญหาที่เรายังไม่ได้อธิบาย โปรดแสดงความคิดเห็นเกี่ยวกับปัญหาใน GitHub

การอภิปรายเกี่ยวกับการทดสอบแพลตฟอร์มเว็บ

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

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

ด้วยการทำงาน!

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

หากคุณสนใจว่า CSS Working Group ทำงานอย่างไร และการคิดค้น CSS ใหม่และจบลงในเบราว์เซอร์อย่างไร ให้ลองดูการนำเสนอ CSSConf.eu ประจำปี 2560 ของฉัน “ CSS มาจากไหน” และข้อมูลจากแฟนตาซีในโพสต์ “An Inside View of the CSS Working Group at W3C”.