เว็บจะดียิ่งขึ้นด้วย Interop 2024

 (webkit.org)
2 คะแนน โดย GN⁺ 2024-02-03 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Interop 2024 เป็นโครงการความร่วมมือที่ช่วยให้ทีมเอนจินเบราว์เซอร์หลัก ๆ ปรับการใช้งานฟีเจอร์เว็บเดียวกันให้สอดคล้องกันมากขึ้น โดยปีนี้ดำเนินงานใน 17 ด้านสำคัญและ 3 โครงการสำรวจ
  • การปรับปรุงความสามารถในการทำงานร่วมกันวัดด้วยการทดสอบอัตโนมัติ เช่น Web Platform Tests โดย WPT มีการทดสอบมากกว่า 1.8 ล้านรายการ และผ่านมากกว่า 95% ในเบราว์เซอร์หลักทั้งหมด
  • Interop 2023 เพิ่มอัตราการผ่านร่วมกันของเอนจินเบราว์เซอร์หลัก 3 ตัวในชุดทดสอบที่คัดเลือกจาก 48% เป็น 95% และปรับการรองรับ P3 color, Subgrid, Container Queries, :has(), Web Components และ Media Queries 4 ให้สอดคล้องกันอย่างมาก
  • ปีนี้เลือก 16 ข้อจากข้อเสนอ 96 รายการ และรับงานบางส่วนจากปี 2023 มาต่อ โดยโฟกัส 17 ด้าน ได้แก่ Accessibility, CSS Nesting, Custom Properties, IndexedDB, Layout, Popover, URL เป็นต้น
  • Microsoft Edge ถูกเพิ่มเป็นคอลัมน์แยกในแดชบอร์ด Interop ทำให้เปรียบเทียบความคืบหน้ารายเบราว์เซอร์ได้โดยตรงมากขึ้น

วิธีปรับความสามารถในการทำงานร่วมกันของเบราว์เซอร์

  • เว็บถูกออกแบบมาให้ทำงานได้บนอุปกรณ์หลากหลาย ทำให้ผู้คนหลายพันล้านคนใช้เพื่อทำงานร่วมกัน เรียนรู้ และเชื่อมต่อกันได้
  • หากนักพัฒนาต้องการมอบประสบการณ์เดียวกันให้กับทุกเบราว์เซอร์และผู้ใช้ทุกคน การใช้งานเทคโนโลยีเว็บในเบราว์เซอร์ต่าง ๆ ต้องใกล้เคียงกัน
  • ความสอดคล้องในการใช้งานเกิดขึ้นผ่านกระบวนการมาตรฐานเว็บ และพฤติกรรมของเทคโนโลยีเว็บใหม่ ๆ ถูกกำหนดไว้ในเอกสารทางเทคนิคโดยละเอียด
  • การที่เบราว์เซอร์ทำตามมาตรฐานเว็บหรือไม่นั้นตรวจสอบด้วยการทดสอบอัตโนมัติ
    • Web Platform Tests มีการทดสอบมากกว่า 1.8 ล้านรายการ
    • WPT มากกว่า 95% ผ่านในเบราว์เซอร์หลักทั้งหมด

ความเปลี่ยนแปลงที่ Interop 2023 สร้างขึ้น

  • Interop 2023 เริ่มต้นในเดือนมกราคม 2023 โดยมีการทดสอบที่คัดเลือกไว้ 48% ผ่านในเอนจินเบราว์เซอร์หลักทั้ง 3 ตัว
    • เบราว์เซอร์อ้างอิงคือ Chrome และ Firefox เดสก์ท็อปบน Linux ที่เผยแพร่ให้ผู้ใช้แล้ว และ Safari บน macOS Monterey
  • หนึ่งปีต่อมา อัตราการผ่านเพิ่มขึ้นเป็น 95%
    • เบราว์เซอร์อ้างอิงคือ Chrome Dev, Firefox Nightly เดสก์ท็อปบน Linux และ Safari Technology Preview บน macOS Ventura
  • การรองรับฟีเจอร์เว็บหลายอย่างข้ามเบราว์เซอร์ดีขึ้น
    • P3 color ได้รับการรองรับเต็มรูปแบบในทุกเบราว์เซอร์ หลังเริ่มเปิดตัวมา 7 ปี
    • Form controls รองรับโหมดการเขียนแนวตั้งเป็นครั้งแรกในประวัติศาสตร์เว็บ
    • CSS border-image ทำงานได้ตามเจตนาเดิม
    • Subgrid, Container Queries, :has(), Motion Path, CSS Math Functions, inert, @property ได้รับการรองรับในเบราว์เซอร์สมัยใหม่ทั้งหมด
    • Web API ต่าง ๆ ดีขึ้น เช่น Offscreen Canvas, Modules in Web Workers, Import Maps, Import Assertions, JavaScript Modules
    • สเปก Media Queries 4 ทั้งหมดได้รับการรองรับทุกที่ พร้อมไวยากรณ์ที่ง่ายขึ้น
    • Web Components ดีขึ้นในส่วน adoptedStyleSheets, ElementInternals, Form-Associated Custom Elements, Shadow DOM และพฤติกรรมพื้นฐานของ Custom Elements
    • เริ่มคาดหวังการรองรับที่สอดคล้องกันข้ามเบราว์เซอร์สำหรับ CSS pseudo-class เช่น :nth-child(), :nth-last-child(), :modal, :user-valid, :user-invalid ได้
    • Feature queries รองรับการตรวจจับความสามารถของฟอนต์แบบใหม่
    • Font Palettes เสริมการรองรับฟอนต์สี
    • มีความคืบหน้าอย่างมากใน CSS Masking, HTML Forms, Pointer and Mouse Events, Scrolling, Transforms, URL, WebCodecs และชุดบั๊กด้านความเข้ากันได้ของเว็บ
  • จาก 26 ด้านสำคัญของ Interop 2023 มี 20 ด้านที่จบลงด้วยความสำเร็จ
  • ในปี 2024 งานด้าน Custom Properties, Pointer and Mouse Events, URL รวมถึง Layout ซึ่งรวม Flexbox, Grid และ Subgrid จะดำเนินต่อไป

องค์ประกอบของ Interop 2024

  • ในปี 2024 มีการพิจารณาข้อเสนอด้านสำคัญ 96 รายการ และสุดท้ายเลือก 16 รายการ
  • เมื่อรวมข้อเสนอใหม่บางส่วนเข้าด้วยกันและรับงานบางส่วนจากปี 2023 มาต่อ Interop 2024 จึงมี 17 ด้านสำคัญ รวมทั้งหมด
  • คะแนนรวมของ Interop 2024 ตามเกณฑ์เบราว์เซอร์เวอร์ชันเสถียรเริ่มต้นที่ 48% อีกครั้งโดยบังเอิญ
  • ตั้งแต่ปีนี้ Interop dashboard เพิ่มคอลัมน์ของ Microsoft Edge เอง
    • ปัจจุบันคอลัมน์นี้แสดง Edge และ Edge Dev ที่ทำงานบน Windows 10

ขอบเขตที่เน้นในปี 2024

  • Accessibility

    • ในโปรเจกต์สำรวจ Accessibility ของ Interop 2023 ทีม Accessibility ของ Apple ได้สร้างโครงสร้างพื้นฐานสำหรับการทดสอบ Accessibility สำหรับ WPT และเขียน การทดสอบ Accessibility มากกว่า 1,300 รายการ
    • การทดสอบเหล่านี้ถูกนำเข้าเป็นขอบเขตที่เน้นของ Interop 2024 เพื่อผลักดันให้การรองรับ Accessibility ของเบราว์เซอร์ดีขึ้น
    • การทดสอบ Accessibility ใหม่ส่วนใหญ่ครอบคลุม WAI-ARIA
    • โดยมี Roles Model และ Accessible Name and Description Computation เป็นแกนหลัก
    • สิ่งเหล่านี้มอบกลไกที่สอดคล้องกันเพื่อให้ผู้ใช้เทคโนโลยีช่วยเหลือเข้าใจวัตถุประสงค์ขององค์ประกอบและสิ่งที่ทำได้
    • ยังรวมการทดสอบที่เกี่ยวข้องกับ HTML Accessibility API Mappings specification ด้วย
    • กำหนดความหมายด้าน Accessibility เริ่มต้นขององค์ประกอบ HTML และกฎพฤติกรรมของเบราว์เซอร์สำหรับฟีเจอร์อย่าง <label> และข้อความ alt ของรูปภาพ
    • มีการเพิ่มการทดสอบ Accessibility ของ display: contents เข้ามาใหม่ด้วย
    • โหมดการแสดงผลของ CSS นี้มีประโยชน์ในการลบกล่องรอบคอนเทนต์ เมื่อต้องปรับความสัมพันธ์ parent·child·grandchild สำหรับ Flexbox หรือ Grid
    • ในการใช้งานช่วงแรก เมื่อกล่องถูกลบ คอนเทนต์ก็หายไปจาก accessibility tree ทั้งหมดด้วย ทำให้เกิดปัญหากับผู้ใช้เทคโนโลยีช่วยเหลือ
    • เบราว์เซอร์ได้แก้ปัญหาส่วนใหญ่แล้ว แต่ยังไม่ได้แก้ได้สมบูรณ์ในทุกสถานการณ์

  • CSS Nesting

    • CSS Nesting ถูกนำเข้าใน Interop 2024 เพื่อลดความแตกต่างของการใช้งาน และให้เว็บนักพัฒนาสามารถเชื่อมั่นและใช้งานได้
    • ฟีเจอร์การซ้อนของ CSS เปิดตัวในเบราว์เซอร์หลักทั้ง 4 ตัวในปี 2023
    • Chrome, Edge และ Safari เปิดตัวก่อนในเดือนเมษายนและพฤษภาคม
    • Firefox เปิดตัวในเดือนสิงหาคม
    • มาตรฐานเว็บเปลี่ยนไปเล็กน้อยระหว่างเดือนพฤษภาคมถึงสิงหาคม ทำให้ข้อกำหนดแรกเริ่มที่ selector แบบซ้อนทั้งหมดต้องขึ้นต้นด้วยสัญลักษณ์ถูกผ่อนปรนลง
    • นักพัฒนาสามารถใช้ article แทน & article ได้
    • การใช้งานทั้งหมดได้รับการอัปเดตแล้ว แต่ยังมีช่องว่างให้ปรับปรุง interoperability ขณะที่ CSS Working Group กำลังจัดระเบียบรายละเอียดพฤติกรรมที่ซับซ้อนของ Nesting
    • การทดสอบที่ Safari ไม่ผ่านส่วนใหญ่เกี่ยวข้องกับวิธีที่ CSS แบบซ้อนโต้ตอบกับ Shadow DOM และ :host

  • Custom Properties

    • @property at-rule เริ่มเปิดตัวในเบราว์เซอร์ต่าง ๆ ในช่วงไม่กี่ปีที่ผ่านมา
    • ขอบเขต Custom Properties ของ Interop 2023 มีอัตราผ่านการทดสอบร่วมกันของเบราว์เซอร์ stable ทั้งหมดเพิ่มจาก 4% เป็น 7.6% และในเบราว์เซอร์ preview ทั้งหมดผ่าน 90.7%
    • Firefox เป็นเบราว์เซอร์ตัวสุดท้ายที่เพิ่มการรองรับ และขณะนี้กำลังทำงานอยู่ใน Firefox Nightly
    • เนื่องจากงานยังไม่เสร็จ จึงยังคงเป็นขอบเขตที่เน้นต่อไปในปี 2024
    • @property ช่วยให้ประกาศไวยากรณ์ พฤติกรรมการสืบทอด และค่าเริ่มต้นของ CSS custom properties ได้คล้ายกับวิธีที่เอนจินเบราว์เซอร์กำหนด CSS properties
    • สิ่งนี้ทำให้แอนิเมชันที่ก่อนหน้านี้ทำด้วย CSS ไม่ได้เป็นไปได้ เช่น บางส่วนเฉพาะของ gradient หรือ transform

  • Declarative Shadow DOM

    • Declarative Shadow DOM เป็น API แบบ declarative ที่ช่วยสร้างวิดเจ็ตและคอมโพเนนต์ที่นำกลับมาใช้ซ้ำได้ด้วย HTML เพียงอย่างเดียว โดยไม่ต้องใช้ JavaScript
    • Safari 16.4 รองรับตั้งแต่เดือนมีนาคม 2023 และ Chrome 90 รองรับตั้งแต่เดือนเมษายน 2021
    • Firefox มีการใช้งานอยู่ใน Firefox Nightly
    • เป็นหนึ่งในฟีเจอร์ที่ถูกขอมากบ่อยครั้งในแบบสำรวจ State of HTML 2023 และถูกนำเข้าใน Interop 2024 เพื่อให้ได้ interoperability ในทุกเบราว์เซอร์

  • Font size adjust

    • font-size-adjust เป็นตัวอย่างที่แสดงให้เห็นประโยชน์ของการมุ่งเน้นเทคโนโลยีเก่า
    • Firefox นำไปใช้งานครั้งแรกในปี 2008 แต่แทบไม่ถูกใช้หรือพูดถึงในหมู่นักออกแบบเว็บและนักพัฒนา
    • สเปกช่วงแรกเปลี่ยนไปตามเวลา โดยรองรับภาษามากขึ้นผ่านไวยากรณ์แบบสองค่า และปรับปรุงการใช้งานด้วยค่า from-font
    • ทีม WebKit นำเวอร์ชันพื้นฐานไปใช้ใน Safari 16.4 และเพิ่มการอัปเดตใน Safari 17.0
    • Mozilla อัปเดตการใช้งานใน Firefox 118 และตอนนี้ Safari กับ Firefox ผ่านการทดสอบทั้งหมด 100%
    • Chrome เริ่มการใช้งานแบบทดลองในปี 2015 แต่ยังไม่ได้เปิดตัว
    • Font size adjust มอบวิธีปรับให้ฟอนต์หลายตัวในสตริงข้อความเดียวกันดูมีขนาดทางสายตาเท่ากัน
    • ตัวอย่างเช่น ในข้อความ 1.4rem สามารถปรับ x-height, cap height, ความกว้าง ch, ความกว้าง ic และความสูง ic ให้ตรงกันได้
    • มีประโยชน์เมื่อผสมโค้ดกับข้อความทั่วไป หรือผสมหลายภาษาในประโยคเดียว

  • HTTPS URLs for WebSocket

    • WebSocket API มีลักษณะที่ต้องใช้สกีมที่ไม่ใช่ HTTP(S) อย่าง ws: และ wss:
    • เนื่องจากพฤติกรรมของ URL แทบเหมือนกับ HTTP(S) URL จึงอาจทำให้การใช้ API ยุ่งยาก
    • ทีม WebKit ทำให้ API รองรับ HTTP(S) URL ด้วยตามฟีดแบ็กจากเว็บนักพัฒนา และเปิดตัวใน Safari 17.0
    • เดิมทีต้องมีโค้ดที่เปลี่ยนเป็น wss: หรือ ws: ตาม location.protocol แต่ตอนนี้สามารถเขียนแบบ new WebSocket(path) ได้
    • เป้าหมายคือรวมไว้ใน Interop 2024 เพื่อให้เบราว์เซอร์อื่น ๆ นำไปใช้ด้วย

  • IndexedDB

    • IndexedDB เป็น API สำหรับจัดเก็บข้อมูลฝั่งไคลเอนต์ในรูปแบบฐานข้อมูลเชิงวัตถุ
    • เริ่มเปิดตัวในเบราว์เซอร์ตั้งแต่ปี 2011 และมาตรฐานเว็บก็พัฒนามาอย่างต่อเนื่อง
    • version 2 และ version 3 รองรับโดยเบราว์เซอร์หลักทั้งหมด
    • version 2 มี interoperability สมบูรณ์แล้ว แต่ version 3 ยังต้องทำงานเพิ่มเติมเพื่อปรับคุณภาพการใช้งานให้สอดคล้องกัน

  • Layout

    • CSS Grid และ Flexbox ถูกนำเข้าในโปรเจกต์ Interop ดั้งเดิมในปี 2021
    • Subgrid ถูกเพิ่มใน Interop 2023
    • รูปแบบเลย์เอาต์ทั้งสามอยู่ในสถานะที่ดี แต่ยังไม่สมบูรณ์แบบ
    • ในปี 2024 การทดสอบของทั้งสามขอบเขตถูกรวมเป็นขอบเขตที่เน้นเดียวชื่อ Layout
    • งานเพื่อเพิ่ม interoperability ของเคสขอบเขตที่ซับซ้อนยังคงดำเนินต่อไป
    • นักพัฒนาสามารถใช้ Flexbox, Grid และ Subgrid ได้อย่างมั่นใจ และทุกเบราว์เซอร์รองรับอย่างแข็งแรง

  • Pointer and Mouse Events

    • Pointer events จัดการอุปกรณ์อินพุตแบบชี้ตำแหน่ง เช่น เมาส์ ปากกา·สไตลัส และการแตะด้วยนิ้วหนึ่งนิ้วหรือมากกว่า ผ่านโมเดลอีเวนต์ DOM เดียว
    • API นี้เริ่มเปิดตัวในเบราว์เซอร์ตั้งแต่ปี 2012 และถูกนำเข้าในทุกเบราว์เซอร์ภายในปี 2019 แต่ interoperability ยังไม่เสถียร

  • ทีม Interop เริ่มโครงการสำรวจ Pointer and Mouse Events ในปี 2022 เพื่อทำให้ข้อตกลงชัดเจน และเขียนชุดทดสอบที่สะท้อนข้อตกลงนั้น

    • ใน Interop 2023 ชุดทดสอบนี้ถูกนำเข้าเป็นพื้นที่โฟกัส และอัตราการผ่านเพิ่มจาก 34% เป็น 81%
    • ยังมีงานที่ต้องทำต่อ จึงยังคงเป็นพื้นที่โฟกัสในปี 2024

  • Popover

    • แอตทริบิวต์ popover ของ HTML มอบวิธีในตัวของเบราว์เซอร์สำหรับทำให้องค์ประกอบปรากฏในเลเยอร์บนสุดของหน้า
    • เมื่อต้องการสร้างโอเวอร์เลย์ที่คลุมทั้งหน้าเว็บ องค์ประกอบ dialog จะเหมาะสมที่สุด
    • เมื่อต้องการทำให้องค์ประกอบอื่นเป็นข้อความป็อปอัป อินเทอร์เฟซผู้ใช้ หรือคอนเทนต์ที่ปรากฏแล้วหายไป popover จะให้เฟรมเวิร์กสำหรับสิ่งนั้น
    • การรองรับ popover เปิดตัวใน Chrome 114 และ Safari 17.0 ในปี 2023
    • Firefox กำลังพัฒนาการรองรับใน Firefox Nightly

  • Relative Color Syntax

    • Relative Color Syntax เป็นวิธีใหม่ในการกำหนดสี CSS โดยอ้างอิงจากสีอื่น
    • สามารถทำให้สีที่มีอยู่สว่างขึ้นหรือมืดลงตามปริมาณที่กำหนด หรือปรับความอิ่มสีของตัวแปรสีแล้วกำหนดให้กับตัวแปรตัวที่สองได้
    • อาจทรงพลังเป็นพิเศษเมื่อสร้าง design system
    • Safari 16.4 เปิดตัวการรองรับเป็นรายแรกในเดือนมีนาคม 2023
    • Chrome 119 และ Edge 119 เปิดตัวการรองรับในเดือนตุลาคมและพฤศจิกายน 2023
    • ในบรรดาการใช้งานปัจจุบัน ยังไม่มีรายการใดรองรับการใช้ currentcolor ร่วมกับ Relative Color Syntax
    • พื้นที่ Relative Color Syntax ของ Interop 2024 ไม่ได้โฟกัสกว้าง ๆ ที่การรองรับทั้งหมด แต่เจาะจงไปที่การรองรับ currentcolor และการทดสอบพฤติกรรมนอกขอบเขตสี
    • ตรวจสอบว่าจะเกิดอะไรขึ้นบนจอแสดงผลที่ไม่รองรับ P3 color

  • requestVideoFrameCallback

    • องค์ประกอบ <video> มอบความสามารถอันทรงพลังในการใส่วิดีโอบนเว็บ
    • HTMLVideoElement มอบพร็อพเพอร์ตีและเมธอดสำหรับจัดการออบเจ็กต์วิดีโอใน JavaScript
    • requestVideoFrameCallback() ช่วยให้ทำงานเป็นรายเฟรมของวิดีโอได้อย่างมีประสิทธิภาพ
      • การประมวลผลหรือวิเคราะห์วิดีโอ
      • การวาดลงบน canvas
      • การซิงโครไนซ์กับแหล่งเสียง
    • รองรับตั้งแต่ Chrome 83 และ Safari 15.4
    • การรวมไว้ใน Interop 2024 ช่วยให้การใช้งานในเบราว์เซอร์สมบูรณ์และขัดเกลามากขึ้น

  • Scrollbar Styling

    • พื้นที่ Scrollbar Styling ครอบคลุมพร็อพเพอร์ตี CSS สองรายการที่ใช้สำหรับจัดสไตล์ scrollbar
    • scrollbar-width มีค่าให้เลือกสามค่า ได้แก่ auto, thin, none
      • auto คือความกว้างเริ่มต้น
      • thin ให้ scrollbar ที่บางลง
      • none ซ่อน scrollbar โดยยังคงให้เลื่อนคอนเทนต์ได้
    • Firefox 64 ใช้งานการรองรับในเดือนธันวาคม 2018 และเพิ่งเปิดตัวใน Chrome 121 และ Edge 121 ด้วย
    • scrollbar-gutter จองพื้นที่สำหรับ scrollbar เพื่อให้คงเลย์เอาต์เดิมไว้ไม่ว่าจะมี scrollbar อยู่หรือไม่
    • scrollbar-gutter: stable สั่งให้เบราว์เซอร์จองพื้นที่ไว้แม้จะไม่มี scrollbar
    • สามารถป้องกัน layout shift เมื่อสถานะความจำเป็นของ scrollbar เปลี่ยนไปได้
    • เปิดตัวใน Chrome 94, Edge 94 และ Firefox 97 ช่วงปี 2021–2022
    • Safari ต้องทำงานมากที่สุดเพื่อให้พื้นที่โฟกัสนี้เสร็จสมบูรณ์
    • Chrome และ Firefox ผ่านชุดทดสอบ 100% แล้ว
    • Safari เคยเป็นรายแรกที่ให้ความสามารถในการจัดสไตล์ scrollbar ด้วย pseudo-element 9 รายการในรูปแบบ ::-webkit-scrollbar-* เมื่อปี 2009 แต่วิธีนี้ไม่ได้กลายเป็นมาตรฐานเว็บ CSS อย่างเป็นทางการ
    • CSS Working Group เลือกแนวทางที่เรียบง่ายกว่ามาก

  • @starting-style and transition-behavior

    • พื้นที่นี้โฟกัสฟีเจอร์ใหม่สองรายการสำหรับควบคุมแอนิเมชัน
    • ทั้งสองฟีเจอร์เปิดตัวใน Chrome 117 และ Edge 177 ในเดือนกันยายน 2023
    • @starting-style ช่วยให้กำหนดค่าเริ่มต้นขององค์ประกอบเฉพาะได้
    • จำเป็นเมื่อองค์ประกอบกำลังจะผ่าน transition
    • ยังให้วิธี transition เมื่อเข้าออกจาก display:none ด้วย
    • transition-behavior ขยายการจัดการพร็อพเพอร์ตีแบบ discrete ที่เคยทำได้เฉพาะในแอนิเมชัน ให้ทำได้ใน CSS transition
    • เปิดทางให้ transition พร็อพเพอร์ตี display เมื่อแสดงหรือซ่อนองค์ประกอบ

  • Text Directionality

    • ทิศทางการไหลของข้อความเป็นองค์ประกอบสำคัญในการจัดตัวอักษรบนเว็บ
    • บางภาษาไหลจากซ้ายไปขวา บางภาษาไหลจากขวาไปซ้าย
    • dir attribute ช่วยให้ระบุทิศทางบนองค์ประกอบ HTML เป็น left, right, auto ได้
    • auto ขอให้เบราว์เซอร์ประเมินทิศทางจากตัวอักษรแรก
    • จนกระทั่งเมื่อไม่นานมานี้ ปฏิสัมพันธ์ระหว่าง directionality กับ shadow tree ยังไม่ได้ถูกนิยามไว้อย่างดี
    • ปัญหานี้ได้รับการจัดการในระดับมาตรฐานแล้ว และการรวมไว้ใน Interop 2024 เป็นการตรวจสอบความสอดคล้องของการใช้งาน

  • text-wrap: balance

    • นักออกแบบเว็บต้องการวิธีป้องกันบรรทัดที่สั้นมากหรือมีเพียงคำเดียวมานานแล้ว
    • ปัญหานี้ยิ่งยากขึ้นจาก responsive web design และการขาดการควบคุมความกว้างของคอลัมน์
    • text-wrap มีหลายตัวเลือกเพื่อบอกเบราว์เซอร์ว่าจะคำนวณการขึ้นบรรทัดอย่างไรให้เหมาะกับกรณีใช้งานเฉพาะ
    • text-wrap: balance เป็นทางออกที่เหมาะสำหรับหัวเรื่อง
    • จัดวางข้อความไม่กี่บรรทัดให้สมดุล เพื่อให้แต่ละบรรทัดมีปริมาณข้อความใกล้เคียงกัน
    • เปิดตัวใน Chrome 114 และ Firefox 121 และถูกใช้งานแล้วใน Safari Technology Preview
    • Interop 2024 ยังรวมการทดสอบพฤติกรรมของ text-wrap-mode, text-wrap-style และ white-space-collapse
    • CSS Working Group เพิ่งเปลี่ยนวิธีที่ longhand เหล่านี้โต้ตอบกัน ทำให้การรองรับระหว่างเบราว์เซอร์ในตอนนี้ยังไม่สม่ำเสมอ

  • URL

    • URL เป็นหนึ่งในองค์ประกอบพื้นฐานที่สุดของเว็บ และหากไม่มี URL เว็บก็จะไม่เกิดขึ้น
    • เช่นเดียวกับหลายสิ่งที่ถูกประดิษฐ์ขึ้นในประวัติศาสตร์ช่วงต้นของเว็บ การรองรับ URL ก็ยังไม่สามารถทำงานร่วมกันได้อย่างสมบูรณ์
    • WHATWG จัดทำ URL Living Standard ที่ระบุรายละเอียดว่า URL ควรทำงานอย่างไรอย่างถูกต้อง
    • ชุดทดสอบที่รองรับมาตรฐานนี้เป็นพื้นที่โฟกัสของ Interop 2023 และอัตราการผ่านปรับดีขึ้นจาก 77% เป็น 85%
    • งานยังคงดำเนินต่อไปในปี 2024 เพื่อให้เกิดความสามารถในการทำงานร่วมกัน
    • Safari ผ่านชุดทดสอบ 99.7%

โครงการสำรวจและการติดตามความคืบหน้า

  • Interop 2024 ยังมีขอบเขตการสำรวจ 3 ด้านด้วย
    • Accessibility Testing
    • Mobile Testing
    • WebAssembly Testing
  • ขอบเขตการสำรวจคือโจทย์ที่ทีม Interop ต้องทำให้สามารถเขียนและรันการทดสอบได้มากขึ้น
  • โครงการสำรวจ Mobile Testing มีเป้าหมายเพื่อทำโครงสร้างพื้นฐานที่จำเป็นใน WPT ให้เสร็จสมบูรณ์ เพื่อให้สามารถทดสอบเบราว์เซอร์บนระบบปฏิบัติการมือถือได้
    • ในอนาคตอาจมีการรวมคะแนนมือถือไว้ในแดชบอร์ดโครงการ Interop ด้วย
  • ในสามการสำรวจนี้ มีสองรายการที่เป็นโครงการต่อเนื่องจากปีที่แล้ว แต่ในปี 2024 ทั้งหมดเริ่มต้นที่สถานะเสร็จสมบูรณ์ 0%
  • ทีมที่เข้าร่วมได้กำหนดเป้าหมายใหม่สำหรับปีนี้ และแดชบอร์ดจะแสดงความคืบหน้าเทียบกับเป้าหมายนั้น
  • สามารถตรวจสอบความคืบหน้าของ Interop 2024 ได้ที่ แดชบอร์ด Interop 2024
  • ความสามารถในการทำงานร่วมกันเป็นหนึ่งในเสาหลักพื้นฐานที่สร้างความสำเร็จให้เว็บ และการทำงานร่วมกันจะดำเนินต่อไปในปี 2024 โดยต่อยอดจากงานของ Interop 2022 และ 2023

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-02-03
ความคิดเห็นจาก Hacker News

  • ตรงนี้มีการเปลี่ยนแปลงที่เจ๋งจริง ๆ และก็ดีใจที่การรองรับดีขึ้น
    ตัวอย่างเช่น CSS nesting เป็นหนึ่งในเหตุผลหลักที่ทำให้ SASS และ LESS มีประโยชน์ จึงเป็นการเปลี่ยนแปลงครั้งใหญ่ เดิมทีก็เหมาะกว่าอยู่แล้วที่จะเข้ามาเป็นฟีเจอร์หลักของ CSS มากกว่าจะเป็นฟีเจอร์ของ preprocessor เหมือนตัวแปร
    สิ่งที่ทำได้ด้วย custom properties ก็น่าสนใจเสมอ และดูเป็นขั้นต่อไปที่ดีหลังจาก Shadow DOM และ custom elements ส่วน popover ก็ดีเกินคาด การที่ตอนนี้สามารถทำสิ่งอย่าง popup modal ได้โดยไม่ต้องใช้ JavaScript นั้นมีประโยชน์มาก และอาจช่วยลดเวลาที่เสียไปกับการทำ custom modal, dropdown menu, hamburger button ฯลฯ
    แต่ก็อยากให้โปรเจกต์แบบนี้ใส่ใจกับ form มากขึ้นด้วย สภาพปัจจุบันที่ field หลายอย่างจากยุค HTML 5 แตกต่างกันเกินไปในแต่ละเบราว์เซอร์ ต้องพึ่งการ styling ด้วย proprietary pseudo-class เพื่อการแสดงผล และโดยรวมปรับแต่งได้ยากนั้น ดูล้าสมัยอย่างน่าประหลาดสำหรับแพลตฟอร์มที่แทบจะทำอะไรก็ได้

    • ถ้า UI designer สามารถขยับอะไรได้ตามใจ หลายครั้งก็จะไม่อยากได้ modal·menu·button พื้นฐานแบบใหม่เหล่านี้ แม้เมื่อก่อนอาจเคยชอบก็ตาม
      การเปลี่ยนแปลงนี้ช่วยได้ก็จริง แต่ใน UI ดูเหมือนว่า consistency จะถูกมองเป็นจุดอ่อน มากกว่าจะเป็นฟีเจอร์ที่ทุกคนควรมุ่งหวัง
    • CSS nesting คือเหตุผลสุดท้ายที่ยังใช้ CSS preprocessor
      ถ้า Safari 17.2+ แพร่หลายมากขึ้น ก็ใช้ CSS ล้วนได้เลย
      นอกนั้นตัวแปรสำหรับ @media query ก็เป็นอีกเหตุผลหนึ่ง แต่เป็นความต้องการที่พบไม่บ่อยนัก

  • สุดท้ายดูเหมือนว่า JPEG XL จะไม่ถูกรวมเข้ามา เมื่อคิดว่านี่เป็น image format แรกในรอบนานมากที่นำการปรับปรุงโดยรวมอย่างชัดเจนมาให้ ก็เข้าใจได้ค่อนข้างยาก
    เคยหวังว่า Interop จะช่วยหยุดสถานการณ์ที่ Google ขัดขวางการนำไปใช้โดยพฤตินัย แต่คงต้องรอต่อไป ในขณะที่ตัวทดแทนแบบครึ่ง ๆ กลาง ๆ ของ format เก่า ๆ ที่ใช้กันแพร่หลายยังคงเพิ่มขึ้นเรื่อย ๆ

    • เรื่องนี้ผมก็เสียดายเหมือนกัน
      ไม่รู้ว่า Google ไม่พอใจอะไรกับ JPEG XL

  • คำว่า “ทุกเบราว์เซอร์รองรับสี P3 อย่างสมบูรณ์แล้ว” นั้นจริง ๆ แล้วไม่ค่อยตรงนัก
    Firefox ยัง clamp สีทั้งหมดเป็น sRGB ก่อนส่งไปยังอุปกรณ์อยู่ https://bugzilla.mozilla.org/show_bug.cgi?id=1626624#c16

  • ผมทำงานเว็บแค่นาน ๆ ครั้ง จึงอาจไม่ใช่กลุ่มเป้าหมายหลัก แต่ฟีเจอร์ที่ขาดไปและสะดุดตาที่สุดใน WebKit คือการไม่รองรับ SVG favicon
    เข้าใจยากจริง ๆ และการต้องเตรียมไอคอนเฉพาะของ Apple หลายขนาดทั้งหมดก็ค่อนข้างยุ่งยากสำหรับนักพัฒนาเว็บสายเบา ๆ อย่างผม

    • ตอนนี้คงดีใจได้ว่าไม่เหมือนเมื่อก่อนแล้ว ตอนนี้ต้องมี ไอคอนเฉพาะของ Apple แค่อันเดียวก็พอ [1]:
      [1]: https://evilmartians.com/chronicles/how-to-favicon-in-2021-s...
    • พูดถึงเรื่องที่เกี่ยวกันเล็กน้อย Chrome จะไม่ใช้ SVG favicon ถ้ามี ico favicon อยู่ (https://bugs.chromium.org/p/chromium/issues/detail?id=145085...) ดังนั้นจึงแจกจ่าย PNG favicon กับ SVG favicon ควบคู่กัน
    • อ้างอิงเพิ่มเติม Safari รองรับ SVG favicon แบบสีเดียว ในรูปแบบนี้
      ถ้าใช้เครื่องมืออย่าง Vite ก็สามารถทำให้การสร้าง favicon และไอคอนหน้าจอหลักทั้งหมดจากภาพต้นฉบับเดียวเป็นอัตโนมัติได้
    • SVG ไม่ได้ scale ตามวิธีที่ต้องการเสมอไป เช่น แม้จะทำภาพสี่เหลี่ยม 256px เป็นเวกเตอร์แล้ว ก็ไม่ได้หมายความว่าการแปลงเวกเตอร์อย่างเดียวจะทำให้ดูดีที่ 24px ได้
    • ถูกต้อง ไม่ควรต้องสร้างไอคอนเหล่านี้ทั้งหมด
      และถ้า styling รายการได้ก็คงดี เช่น ติดอะไรอย่างธงไว้ที่ element
      CSS page transitions หรือ scroll-driven animations ก็ไม่ได้ถูกพูดถึง ทั้งสองอย่างนี้ก็ช่วยลด boilerplate JavaScript ได้เช่นกัน

  • พออ่านบทความนี้แล้วตื่นเต้นกว่าที่คิดมาก
    สงสัยว่าทำไมในคอนซอร์เทียมที่เข้าร่วมถึงไม่มี พื้นที่เน้น PWA

    • ในอดีต Interop มักจะโฟกัสที่ CSS มากกว่า แต่ก็ค่อย ๆ เปลี่ยนไป
      ถึงอย่างนั้น พื้นที่ทดสอบจำนวนมากก็มีการทดสอบ worker รวมอยู่ด้วย ทำให้สถานะของ PWA ดีขึ้นตามไปด้วย ในปี 2023 มีทั้งส่วน Modules และมีการทดสอบฟีเจอร์เฉพาะทางของ PWA/worker จำนวนมาก API จำนวนไม่น้อยที่เป็นเป้าหมายของการทดสอบและสำรวจ เช่น OffscreenCanvas หรือการทดสอบบนมือถือ ก็เกี่ยวข้องกับแอปพลิเคชัน PWA หลายตัวมาก
      ปีนี้เป็น Interop ที่มีความเป็น CSS-centric ต่ำที่สุดพอ ๆ กับปีที่แล้ว ในมุมของผม มีส่วน IndexedDB, WebSocket และการปรับปรุงด้าน accessibility ที่สำคัญ ซึ่ง PWA พึ่งพาเป็นหลัก พื้นที่สำรวจ 3 อย่างคือ WebAssembly, accessibility และการทดสอบบนมือถือ ก็ล้วนเกี่ยวข้องกับ PWA มาก
      อยากรู้ว่าโดยเฉพาะแล้วอยากให้โฟกัส API ไหนมากขึ้น
    • เท่าที่จำได้ คอนซอร์เทียมมีประมาณ 12 คน และคนเหล่านี้ก็ทำงานในบริษัทเบราว์เซอร์ด้วย
      เป้าหมายคือมารวมตัวกัน แล้วพิจารณา roadmap ปัจจุบันกับปริมาณงาน เพื่อหาฟีเจอร์ที่สามารถทำร่วมกันหรือปรับปรุงได้ในช่วง 1 ปี มอง Interop ได้เหมือน ticket เสริมเล็ก ๆ ที่ทำคั่นระหว่างการพัฒนาฟีเจอร์หลักในงานประจำ
      จนถึงตอนนี้ จุดโฟกัสอยู่ที่รายละเอียดระดับต่ำมาก ๆ ของวิธีที่เบราว์เซอร์เรนเดอร์คอนเทนต์ โดยทั่วไป JavaScript API ถูกทำให้เป็นมาตรฐานและ merge กันที่ “ต้นน้ำ” อยู่แล้ว ดังนั้นพื้นที่ที่ยังมีช่องให้ปรับปรุงมากที่สุดจึงอยู่ตรงนี้
      ก่อนที่จะเกิดกระแสให้ implement ฟีเจอร์ใหม่พร้อมกันในทุก engine ผมคิดว่างานอุดช่องว่างระหว่างเบราว์เซอร์จะยังเกิดขึ้นมากขึ้นเรื่อย ๆ
      อย่างไรก็ตาม เมื่อในที่สุด Apple เพิ่ม web push ให้ Safari บนมือถือแล้ว ก็ถือว่าเข้าใกล้สิ่งที่เว็บแอปส่วนใหญ่ที่ได้ประโยชน์จากฟีเจอร์ PWA ต้องการอยู่พอสมควรแล้ว อยากรู้ว่ายังมีฟีเจอร์ไหนที่ยังไม่มีร่วมกันทุกเบราว์เซอร์แล้วคุณอยากใช้บ้าง
    • อยากรู้ว่าคุณมองว่า พื้นที่เน้น PWA ควรรวมอะไรไว้บ้าง
      ที่อื่นมีลิงก์ https://web.dev/learn/pwa/capabilities และ https://whatpwacando.today แต่ผมคิดว่าฟีเจอร์จำนวนมากในนั้นโดยเนื้อแท้แล้วไม่น่าถือว่าเป็นฟีเจอร์ PWA จริง ๆ ฟีเจอร์จำนวนมากถูกใช้กว้างขวางนอก PWA ด้วย ดังนั้นการจับมันใส่กลุ่ม “PWA” ทำให้ความหมายค่อนข้างเลือน สำหรับเว็บเดเวลลอปเปอร์ กลุ่มอย่าง “storage” หรือ “media” อาจมีความหมายมากกว่า
      ถ้าดูนิยามพื้นฐานของ PWA จะเกี่ยวกับ manifest กับ service worker เป็นหลัก และการนำสองอย่างนี้ไปใช้ร่วมกับ web platform
      manifest ทดสอบอัตโนมัติได้ยาก เนื้อหาของมันแสดงอยู่ในส่วนต่าง ๆ ของ UI เบราว์เซอร์ ซึ่งโดยทั่วไป UI ไม่ได้ถูกระบุไว้ในมาตรฐานเว็บ เพราะ vendor ต้องการอิสระในการตัดสินใจเรื่อง UI ของตัวเอง ดังนั้นจึงใส่เข้ามาได้ยาก และก็ไม่ชัดเจนด้วยว่ามีปัญหา interoperability มากแค่ไหน
      service worker อาจถูกเสนอได้ ช่วงไม่กี่ปีหลังไม่ได้มีการเสนอ แต่ผมก็ไม่ได้คิดว่าช่วงนี้ฝั่งนี้มีปัญหา interoperability มากขนาดนั้น
    • PWA เลี่ยง โมเดล app store ได้ สามารถติดตั้งแอปจากเบราว์เซอร์ได้โดยตรง
      ดังนั้นการถ่วงเรื่องนี้ไว้และจงใจทำให้ประสบการณ์ PWA น่าดึงดูดน้อยลงจึงเป็นประโยชน์ต่อพวกเขา
      ส่วน Firefox ที่ถอดการรองรับ PWA ออกไปนั้นไม่แน่ใจ แต่อาจเป็นเพราะต้นทุนการบำรุงรักษา
    • เพราะเมื่อเทียบกับการใช้งานที่กว้างกว่ามากอย่าง “การแสดงคอนเทนต์” แล้ว PWA เป็น use case เฉพาะกลุ่ม

  • ฟอนต์
    อยากให้มีความพยายามกับ CSS typography มากขึ้น
    โดยเฉพาะต้องการ leading-trim และ margin-trim
    https://medium.com/microsoft-design/leading-trim-the-future-...
    https://developer.mozilla.org/en-US/docs/Web/CSS/margin-trim

    • margin-trim เข้าไปอยู่ใน Safari 16.4 แล้วตั้งแต่เกือบ 1 ปีก่อน [1]
      ชื่อใหม่ของ leading-trim คือ text-box-trim และใน Safari รุ่นล่าสุดยังอยู่หลัง flag
      [1]: https://webkit.org/blog/13966/webkit-features-in-safari-16-4...

  • ผลลัพธ์ที่ใหญ่ที่สุดคือการที่อัปเดต Safari ไม่ต้องผูกกับ อัปเดตระบบปฏิบัติการ อีกต่อไป

    • บน macOS ทำได้
      แต่บน iOS ทำไม่ได้
      และอัปเดต iOS ออกใหม่ทุก 3–4 เดือน ดังนั้นในทางปฏิบัติจึงไม่ใช่ปัญหาบน iOS

  • สงสัยว่านี่เป็นสัญญาณว่า WebKit จะเริ่มไล่ตาม ฟีเจอร์ WebAssembly หรือเปล่า
    ตอนนี้ค่อนข้างตามหลัง Chrome และ Firefox และไม่มีฟีเจอร์ใหญ่ ๆ ที่สำคัญอย่าง multiple memories หรือ garbage collection

    • ทั้งสองอย่างยังไม่ได้อยู่ใน สเปก Wasm และยังอยู่ระหว่างการทำมาตรฐาน
      Google ค่อนข้างเป็นแนว “พร้อม! ยิง! เล็ง! ยิงอีกที!” จึงมักปล่อย implementation ของสเปกที่ยังไม่เสร็จออกมาได้ง่ายกว่า ส่วน Apple ค่อนข้างเป็นแนว “พร้อม! เล็ง! เล็ง! ยิง!” จึงโดยทั่วไปไม่ค่อยอยากทำแบบนั้น สำหรับ Firefox พูดยาก

  • ไม่อยากเชื่อว่า Cookie Store API ยังไม่มี implementation อย่างเป็นทางการ
    นี่ปี 2024 แล้วยังต้อง parse สตริงขนาดใหญ่ที่ยุ่งเหยิงเพื่อเอาคุกกี้ตัวเดียวตามชื่อ มันสมเหตุสมผลตรงไหน

    • อาจเป็นเพราะมี HTML 5 localStorage แล้วหรือเปล่า

  • ผมไม่ค่อยเข้าใจประเด็นของโปรโตคอล WebSocket
    หลังจาก upgrade แล้ว connection ก็ไม่ใช่โปรโตคอล http(s) อีกต่อไป ดังนั้นการอนุญาตให้ใช้ http หรือ https ตรงนี้จะไม่ทำให้เข้าใจผิดหรือ? การใช้ ternary operator หรือการมีค่าที่ต่างจากค่าที่หน้าปัจจุบันย้ายไปมันแย่มากขนาดนั้นเลยหรือ? ดีใจที่มีงาน normalize ฝั่งเบราว์เซอร์ แต่รายการนี้ถึงจะคุ้มที่จะเปลี่ยน ก็ดูมีลำดับความสำคัญค่อนข้างต่ำ