คุณไม่จำเป็นต้องใช้ JavaScript เพื่อสิ่งนั้น

 (htmhell.dev)
3 คะแนน โดย GN⁺ 2023-12-03 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ในการสร้างฟังก์ชันเว็บ ควรพิจารณา เทคโนโลยีที่ทรงพลังน้อยกว่า ก่อน ตามลำดับ HTML, CSS, JavaScript ซึ่งช่วยลดปัญหาการโหลดล้มเหลวและการเข้าถึงได้
  • JavaScript สามารถควบคุมพฤติกรรมของเบราว์เซอร์ได้โดยตรง แต่ด้วยทรัพยากรเพิ่มเติมและโอกาสเกิดข้อผิดพลาด จึงทำให้ ผู้ใช้คีย์บอร์ดและเทคโนโลยีช่วยเหลือ ถูกกันออกไปได้ง่าย
  • ฟีเจอร์อย่างสวิตช์จากเช็กบ็อกซ์, datalist, input type="color", details/summary, dialog ที่ในอดีตต้องใช้ JavaScript ตอนนี้สามารถทำได้เป็นส่วนใหญ่ด้วยความสามารถพื้นฐานของ HTML/CSS
  • ความสามารถแบบประกาศ ของ HTML และ CSS เปิดทางให้เบราว์เซอร์รับหน้าที่จัดการพฤติกรรมเนทีฟ การตั้งค่าสภาพแวดล้อมของผู้ใช้ และการรองรับการเข้าถึงได้ จึงให้ค่าเริ่มต้นที่ดีกว่าได้
  • แม้การใช้งานด้วย JavaScript ที่คุ้นเคยจะยังทำงานได้อยู่ ก็ควรตรวจสอบทางเลือก HTML/CSS สมัยใหม่เป็นระยะ และเมื่อเปลี่ยนควรทำ การทดสอบการเข้าถึงได้ ควบคู่กัน

กฎของสิทธิ์ขั้นต่ำ

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

ฟีเจอร์ที่เมื่อก่อนต้องใช้ JavaScript

  • ผู้สร้างเบราว์เซอร์และผู้เขียนสเปกได้ย้ายฟีเจอร์ที่จนถึงไม่กี่ปีก่อนต้องใช้ JavaScript มาไว้ใน CSS และ HTML
  • เว็บรักษา ความเข้ากันได้ย้อนหลัง ดังนั้นวิธีใช้งานที่เคยเรียนรู้แล้วมักยังคงอยู่ในกล่องเครื่องมือและถูกนำมาใช้ซ้ำได้ง่าย
  • แม้จะรู้ว่าฟีเจอร์บางอย่างต้องใช้ JavaScript แต่หากตรวจสอบเป็นครั้งคราวว่ายังเป็นเช่นนั้นอยู่หรือไม่ ก็จะช่วยสร้างเว็บไซต์ที่ดีกว่าได้

สวิตช์แบบกำหนดเองที่ทำด้วยเช็กบ็อกซ์

  • สวิตช์แบบกำหนดเองสามารถสร้างได้ด้วย เช็กบ็อกซ์ พื้นฐานและ CSS แทน div, ตัวจัดการ onclick และสถานะภายใน
  • เมื่อใส่ <input type="checkbox"> ไว้ใน <label> เบราว์เซอร์จะเชื่อมทั้งสองเข้าด้วยกัน
    • คลิกตรงไหนของป้ายกำกับก็จะสลับสถานะเช็กบ็อกซ์
    • ไม่จำเป็นต้องมีตัวจัดการ onclick แยกต่างหาก
  • appearance: none ทำให้เบราว์เซอร์หยุดเรนเดอร์ฟอร์มคอนโทรลตามค่าเริ่มต้น และเปิดให้สไตลิงเองได้
    • สามารถตกแต่ง input เองให้เหมือนพื้นหลังของสวิตช์ได้
    • สามารถใช้ ::before เป็นจุดด้านในที่เลื่อนไปมาได้
  • pseudo-class :checked สามารถเปลี่ยนสีพื้นหลังและตำแหน่งของ ::before ตามสถานะที่ถูกเช็กได้
  • สำหรับผู้ใช้คีย์บอร์ด จำเป็นต้องมี การแสดงโฟกัส
    • การซ่อนโฟกัสด้วย outline: none ไม่ใช่วิธีที่ดี
    • :focus-visible สามารถแสดงวงแหวนโฟกัสที่ดูดีเฉพาะเมื่อมีการโต้ตอบด้วยคีย์บอร์ด
    • ใช้ outline-offset ปรับเส้นขอบโฟกัสให้อยู่นอกหรือในองค์ประกอบได้
  • input:focus { outline-color: transparent; } ทำให้เส้นขอบโปร่งใสในสถานการณ์ทั่วไป และในโหมดคอนทราสต์สูงสามารถกลับมาแสดงด้วยสีที่ผู้ใช้เลือกไว้ได้
  • ดูเพิ่มเติมเกี่ยวกับโหมดสีบังคับได้ที่ forced colors explained

การเติมข้อความอัตโนมัติแบบเนทีฟด้วย datalist

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

ตัวเลือกสีพื้นฐานของ input type="color"

  • เพียงบรรทัดเดียว <input type="color"> ก็ใช้ ตัวเลือกสี แบบเนทีฟของเบราว์เซอร์ได้
  • สามารถทดแทน UI แคนวาสและสไลเดอร์จำนวนมากที่สร้างด้วย JavaScript ได้
  • ตัวเลือกสีเนทีฟของเบราว์เซอร์ Chromium สามารถเลือกสีจากที่ใดก็ได้บนหน้าจอ ไม่ใช่เฉพาะภายในเว็บไซต์
  • ไม่ใช่ผู้ใช้ทุกคนจะใช้ตัวเลือกสีของเบราว์เซอร์ได้ ดังนั้นควรมีวิธีเลือกสีอื่นควบคู่กัน เช่น การป้อนข้อความธรรมดา

อะคอร์เดียนด้วย details และ summary

  • องค์ประกอบ details และ summary ให้ความสามารถ อะคอร์เดียน สำหรับยุบและขยายเนื้อหาเป็นฟีเจอร์พื้นฐานของเบราว์เซอร์
  • พฤติกรรมพื้นฐานเรียบง่าย
    • เนื้อหาภายใน details จะถูกซ่อน ยกเว้น summary
    • เมื่อผู้ใช้คลิก summary เนื้อหาที่เหลือจะแสดงขึ้น
  • แอตทริบิวต์ open กำหนดสถานะเริ่มต้นให้เปิดอยู่
    • ไม่ใช่ค่าที่ถูกตรึงหลังการโต้ตอบของผู้ใช้ แต่สถานะจะเปลี่ยนเมื่อผู้ใช้เปิดและปิด
  • สามารถสไตลิงเครื่องหมายสามเหลี่ยมพื้นฐานได้ด้วย summary::marker
    • สามารถเปลี่ยนเนื้อหาเป็นอีโมจิ ฯลฯ ได้
    • ปรับสีพื้นหลัง ภาพพื้นหลัง ขนาดฟอนต์ เป็นต้นได้
    • คุณสมบัติ CSS จำนวนมากจะไม่ทำงาน และการสไตลิงแบบย้ายไปวางในตำแหน่งที่ต่างไปอย่างสิ้นเชิงจะถูกจำกัด
  • ใน Safari จำเป็นต้องใช้ pseudo-element ::-webkit-details-marker
  • การเปลี่ยนเนื้อหาของ marker อาจส่งผลต่อวิธีที่เทคโนโลยีช่วยเหลือประกาศอะคอร์เดียน ดูเพิ่มเติมได้ที่ details/summary inconsistencies
  • summary คลิกได้ แต่โดยค่าเริ่มต้นจะไม่แสดงเคอร์เซอร์ pointer เหมือนลิงก์และไม่ได้ดูเหมือนปุ่ม จึงควรเพิ่มสถานะ hover และ focus เพื่อแสดงให้เห็นว่าคลิกได้

โมดัลด้วย dialog

  • alert(), prompt(), confirm() ใช้แจ้งหรือขอการยืนยันจากผู้ใช้ได้ แต่จะล็อก เธรดหลัก และสไตลิงให้เข้ากับดีไซน์ได้ยาก
  • หากสร้างไดอะล็อกเอง การจัดการด้านการเข้าถึงได้จะซับซ้อน
    • ต้องคงโฟกัสไว้ภายในไดอะล็อก
    • ต้องบอกว่าเป็นโมดัล
    • ต้องป้องกันไม่ให้ผู้ใช้หลุดออกไปโดยไม่ตั้งใจ
    • อาจชนกับวิดเจ็ตที่มี z-index สูงมาก
  • องค์ประกอบ dialog ของเบราว์เซอร์ให้ไดอะล็อกแบบเนทีฟ
  • ปัจจุบันยังต้องใช้ JavaScript เพื่อเปิดไดอะล็อก
    • การเปลี่ยนแปลงเพื่อให้เปิดได้โดยไม่ใช้ JavaScript กำลังดำเนินอยู่ แต่ยังไม่ได้กำหนดในสเปกหรือใช้งานอย่างสมบูรณ์
    • สามารถเปิดไดอะล็อกด้วยฟังก์ชัน showModal() ได้
  • dialog เปิดอยู่ใน top layer
    • top layer เป็นเลเยอร์ใหม่ที่แยกจาก HTML
    • องค์ประกอบในเลเยอร์นี้จะแสดงอยู่ด้านบนเสมอ ไม่ขึ้นกับ z-index และการซ้อนของ stacking context
    • ดูคำอธิบายแนวคิดได้ที่ Top layer ของ MDN
  • dialog ไม่มี UI สำหรับปิดให้โดยค่าเริ่มต้น จึงต้องใส่ UI เอง
    • เมื่อ form method="dialog" ถูกส่ง เบราว์เซอร์จะปิดไดอะล็อก
    • หากใส่ value ต่างกันให้ปุ่มส่งสองปุ่ม ก็สามารถใช้เหมือนไดอะล็อกยืนยันได้
    • ในอีเวนต์ close สามารถอ่าน dialog.returnValue เพื่อตรวจสอบค่าของปุ่มที่ผู้ใช้กดได้
    • อ่านข้อมูลฟอร์มเพิ่มเติมได้ด้วย FormData
  • dialog::backdrop เป็นเลเยอร์ระหว่างไดอะล็อกกับส่วนที่เหลือของหน้า
    • สามารถทำให้พื้นหลังมืดลงหรือเบลอ เพื่อดึงความสนใจของผู้ใช้ไปที่ไดอะล็อก
    • เนื่องจากเบราว์เซอร์จัดวางให้ จึงไม่ต้องจัดการการเลื่อน องค์ประกอบแบบ fixed หรือการเปลี่ยนขนาดเบราว์เซอร์เอง

ฟีเจอร์ที่ทำได้ด้วย JavaScript น้อยลง

  • ยังมีฟีเจอร์อีกมากที่ช่วยลดการใช้ JavaScript ได้
    • การเลื่อนแบบนุ่มนวลเนทีฟด้วย scroll-behavior: smooth
      • มีเงื่อนไขให้ใช้เฉพาะเมื่อ prefers-reduced-motion: no preference ตรงกัน
    • คารูเซลเนทีฟด้วย scroll-snap
    • องค์ประกอบแบบ “in-view” ด้วย position: sticky
    • container queries
  • ยังมีฟีเจอร์ที่จะเพิ่มเข้ามาในอนาคตด้วย
    • แอนิเมชันตามการเลื่อน
    • เลย์เอาต์ Masonry ที่สร้างด้วย grid-template-rows: masonry โดยไม่ต้องใช้ masonry.js
    • select ที่สไตลิงได้เต็มรูปแบบผ่านองค์ประกอบใหม่ selectlist
    • selector :has() ที่ช่วยลดโค้ด JavaScript สำหรับการเลือกองค์ประกอบได้หมวดหนึ่ง
  • ดูเนื้อหาที่เกี่ยวข้องเพิ่มเติมได้ในวิดีโอบรรยาย Stop Using JavaScript for That: Moving Features from JS to CSS and HTML.
  • เมื่อต้องเปลี่ยนวิธีใช้งานที่ผ่านการตรวจสอบแล้วไปเป็นวิธีใหม่ ควรทดสอบการเข้าถึงได้เป็นพิเศษเพื่อไม่ให้ใครถูกกันออกไป

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

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

 
GN⁺ 2023-12-03
ความคิดเห็นบน Hacker News

  • สิ่งที่บทความนี้ขาดไปคือ เหตุผลที่ใช้ JavaScript ในกรณีแบบนี้เป็นเพราะความเข้ากันได้ดีกว่า
    JavaScript รุ่นใหม่สามารถทรานส์ไพล์ได้ แต่การทำ polyfill ให้ฟีเจอร์ CSS หรือ HTML ที่ขาดไปนั้นยากกว่ามาก และในบางกรณีก็เป็นไปไม่ได้ แถม polyfill เหล่านั้นสุดท้ายก็ใช้ JavaScript อยู่ดี
    แม้แต่ MDN ก็มีคำเตือนมากมายให้ทดสอบ appearance อย่างถี่ถ้วน แม้กระทั่ง appearance: none หากรองรับเฉพาะเบราว์เซอร์ใหม่ ๆ ก็อาจสำคัญน้อยลง แต่ Safari เวอร์ชันเก่า ๆ ยังอยู่ยาวกว่าที่คิด
    datalist ไม่ทำงานอะไรเลยบน Firefox Android และสำหรับผมมันดูเหมือนเป็นแค่กล่องป้อนข้อมูลที่ไม่มีแม้แต่คำแนะนำ
    ตัวเลือกสีดูดี แต่ไม่เป็นมาตรฐานอย่างมาก จึงเป็นปัญหาร้ายแรงสำหรับธุรกิจส่วนใหญ่ ไม่ใช่แค่นักออกแบบบ่นเท่านั้น แต่ฝ่ายซัพพอร์ตลูกค้าจะช่วยผู้ใช้ได้ยากขึ้นด้วย Chromium ยังมีฟีเจอร์ให้ดูดสีจากหน้าเว็บหรือเลือกสีใดก็ได้ แต่ Firefox Android ให้แค่สีรุ้ง สีเทา และขาวดำประมาณนั้น
    บทความเองก็ยอมรับความไม่สอดคล้องกันของ details และ dialog หวังว่าสักวันหนึ่งเบราว์เซอร์ที่ไม่รองรับฟีเจอร์เหล่านี้ หรือรองรับไม่สอดคล้องกัน จะไม่ถูกใช้งานอีกต่อไป แต่ในระยะนี้องค์ประกอบเหล่านี้คงเหมาะจะใช้แค่ในโปรเจกต์ส่วนตัวที่ควบคุมเบราว์เซอร์ที่รองรับได้อย่างสมบูรณ์เท่านั้น

    • ผมเห็นด้วยยากกับคำว่า ตัวเลือกสี ไม่เป็นมาตรฐาน
      บน iPhone เมื่อกดปุ่ม จะมีตัวเลือกสีแบบเนทีฟของระบบจริง ๆ แสดงขึ้นมา เป็นคอนโทรลเดียวกับที่ OS ให้มาและเห็นได้ในหลายแอป และผมชอบมันมากกว่าสิ่งที่ทำขึ้นเองมาก
    • คำว่าความเข้ากันได้ดีกว่านั้นถูกต้องก็ต่อเมื่อเราตั้งสมมติฐานว่าผู้ใช้ทุกคนต้องใช้ JavaScript
      ผมชอบเว็บที่ไม่มี JavaScript มากกว่าเยอะ และมันยังส่งผลต่ออายุแบตเตอรี่โน้ตบุ๊กเป็นชั่วโมง ๆ ด้วย บางไซต์เข้ากับสิ่งนี้ไม่ได้ จึงเรนเดอร์เป็นหน้าว่าง หรือบ่นว่าต้องใช้ JavaScript เพื่อแสดงข้อความ
      ในทางกลับกัน Amazon ยังมีเวอร์ชันจำลองของไซต์อีคอมเมิร์ซที่ไม่ใช้ JavaScript แสดงให้เห็นว่าแม้แต่งานขนาดใหญ่แบบนั้นก็ทำได้โดยไม่ต้องใช้ JavaScript
    • องค์ประกอบ dialog ตอนนี้มี ขอบเขตการรองรับ ค่อนข้างลึกแล้ว และ polyfill สำหรับผู้ใช้ไม่กี่เปอร์เซ็นต์ที่ใช้ Firefox หรือ Safari ช่วงปี 2021 ก็ถือว่าโอเคพอ
      ถ้าจะทำโมดัล ขอแนะนำอย่างยิ่ง และการปรับปรุงด้านการเข้าถึงทำได้ยอดเยี่ยม
    • ประเด็นที่ฝ่ายซัพพอร์ตลูกค้าจะช่วยผู้ใช้ได้ยากขึ้นนั้นสำคัญมาก
      ที่ทำงานเก่าของผมเคยถกเรื่องนี้กันอย่างจริงจัง และตัดสินใจใช้ การทำด้วย JS แทนสิ่งอย่าง datalist โดยเฉพาะ datalist เราลองแล้ว แต่ผลลัพธ์ไม่สม่ำเสมอเกินไปจนต้องทิ้ง
      สุดท้ายเพราะความไม่สอดคล้องกันระหว่างเบราว์เซอร์ เราถึงขั้นเลิกซัพพอร์ตเบราว์เซอร์อื่นนอกจาก Chrome ด้วย
    • ไม่ใช่เลย JavaScript ถ้าล้มเหลวก็คือล้มเหลวสนิท จนคอนเทนต์หายไปเลย
      ตัวอย่าง HTML แม้ในเบราว์เซอร์เก่าอาจหน้าตาเพี้ยน แต่คอนเทนต์จริงยังอยู่ ส่วน JS คือไม่มีอะไรเลย ทำลายการเข้าถึงโดยสิ้นเชิง
      ถ้าเป็น HTML อย่างน้อย screen reader ก็ยังอ่านได้ แต่คอนเทนต์ที่สร้างด้วย JS จะขวางสิ่งนั้น เมื่อ JS รัน JS ไม่ได้ ก็ไม่มี polyfill หรือ JS อื่นใดมาช่วย JS ได้ ตั้งแต่แรกมันต้อง “ทำงาน” เท่านั้นถึงจะโอเคต่อการเข้าถึง และถ้าเป็นกรณีนั้น ประเด็นเดิมก็ไร้ความหมายไปแล้ว

  • ผมไม่รู้จัก Datalist มาก่อน แต่อย่างน้อยบน Chrome Android ก็ดูเหมือนจะทำงานไม่ถูกต้อง
    ตัวเลือกแสดงอยู่ในบริเวณคีย์บอร์ดที่ปกติใช้แสดงคำแนะนำเติมข้อความอัตโนมัติ: https://imgur.com/a/Ecb4503
    ผมเพิ่งเคยเห็นวิธีแบบนั้นในฟอร์มคอนโทรลของ UI เว็บบนมือถือเป็นครั้งแรก และนอกจากกรณีแอปเติมรหัสผ่านอัตโนมัติใช้พื้นที่เดียวกัน ก็ไม่เคยเห็นมาก่อน
    มันก็ไม่ได้แย่ ดีกว่าการเลื่อนดรอปดาวน์ JS แบบทำเองลวก ๆ อย่างเคอะเขินมาก แต่ผมไม่มั่นใจว่าผู้ใช้ทั่วไปจะรู้วิธีใช้มันหรือไม่ ดังนั้นบนมือถือผมมองว่าแทบไม่มีหวัง
    บน Firefox Android ไม่รองรับเลย: https://caniuse.com/?search=datalist

    • ผู้ทำเบราว์เซอร์ทั้งหลาย ช่วยทำให้ กำหนดสไตล์ ดรอปดาวน์ datalist ได้หน่อยไม่ได้หรือ?
      อ้างอิง: https://adrianroselli.com/2023/06/under-engineered-comboboxe...
    • นี่แหละคือเหตุผลที่โซลูชันแบบนี้ใช้เวลานานกว่าจะได้รับการยอมรับอย่างแพร่หลาย
      JavaScript มีมาตรฐานค่อนข้างดี แต่ HTML กับ CSS เมื่อเทียบกันแล้วยังน้อยกว่า
    • ผมสงสัยว่าถ้าเพิ่ม autocomplete="off" ให้กับองค์ประกอบ input แล้วพฤติกรรมจะเปลี่ยนไหม
      อย่างไรก็ต้องใช้มันเพื่อให้ datalist ใช้งานได้อย่างถูกต้อง ไม่เช่นนั้นประวัติการเลือกค่าจะถูกต่อท้ายในรายการดรอปดาวน์ ผมสังเกตเห็นใน Chromium
      นอกจากนี้ ในบางสถานการณ์ เช่นเมื่อมีการตั้งค่าเริ่มต้น datalist ก็ยังต้องใช้ JS อยู่ ผมรวบรวม workaround และบันทึกพฤติกรรมเฉพาะของแต่ละเบราว์เซอร์ไว้ในโค้ดเว็บไซต์ LibreOffice ใหม่แล้ว: https://git.libreoffice.org/infra/libreofficeorg/+/835a5cc59...
      ข่าวดีคือ นักพัฒนา Firefox วางแผนจะดูเรื่องการปรับปรุงพฤติกรรมของ datalist จึงอาจทำให้แสดงรายการได้ด้วยการคลิกเพียงครั้งเดียว
    • มองเหนือคีย์บอร์ดหรือยัง?
      ในกรณีของผม ตัวเลือกจะแสดงในพื้นที่เหนือคีย์บอร์ด ซึ่งปกติจะแสดงคำแนะนำคำ
    • การที่ตัวเลือก datalist แสดงอยู่ในคีย์บอร์ดเป็นการเปลี่ยนแปลงที่เพิ่งเกิดขึ้นในช่วงไม่กี่เดือนมานี้
      เมื่อก่อนมันเคย “ปกติ” แต่ดูเหมือนมีใครบางคนอยากเปลี่ยนเพียงเพื่อให้ได้เปลี่ยน

  • โปรดใช้การเลื่อนแบบนุ่มนวลของเนทีฟด้วย scroll-behavior: smooth อย่างจำกัดจริง ๆ
    มันไม่ใช่ไอเดียที่ดีในกรณีใช้งานส่วนใหญ่กว่าที่คิด และมักมีผลข้างเคียงที่ไม่ต้องการอยู่บ่อย ๆ
    แม้จะบอกว่าสร้างแคโรเซลแบบเนทีฟด้วย scroll-snap ได้ แต่แคโรเซลก็ยังเป็นไอเดียที่แย่อยู่ดี ดังนั้นขอบเขตการใช้ scroll-snap อย่างสมเหตุสมผลจึงแคบมาก
    หน้าเว็บที่ใช้ แอนิเมชันตามการเลื่อน ส่วนใหญ่มักจะดีขึ้นถ้าเอามันออก

    • ประเด็นของบทความนี้ไม่ใช่การสั่งให้ใช้องค์ประกอบการออกแบบแบบใดแบบหนึ่ง แต่คือการแสดงวิธีทำให้การออกแบบเหล่านั้น เป็นมิตรกับผู้ใช้ มากขึ้น
      การเลื่อนแบบนุ่มนวลเป็นตัวอย่างที่ดี API แบบเนทีฟเปิดทางให้ผู้ใช้หยุดกลางคันได้ทุกเมื่อ การทำด้วย JS ส่วนใหญ่นั้นกระตุกอย่างเลวร้ายและทำให้ผู้ใช้ลำบาก
      คุณจะตำหนิการเลือกดีไซน์ได้เต็มที่ แต่ถ้าไม่ให้เหตุผลจริง ๆ ว่า “แคโรเซลยังแย่อยู่” เพราะอะไร ก็ยากจะคาดหวังให้คนฟัง
    • ผมก็เกลียดแคโรเซลเหมือนกัน
      แต่ หน้าแรกของ Amazon ใช้แคโรเซลอย่างเด่นชัด และเท่าที่รู้ Amazon ทำ A/B test กับรูปแบบหน้าแรกอย่างไม่ปรานี ถ้าอย่างนั้นก็มีความเป็นไปได้ว่าแคโรเซลทำผลลัพธ์ในการทดสอบได้ดี และจะบอกว่ามัน “แย่” จริง ๆ ในความหมายแบบสากลหรือเป็นกลางก็ค่อนข้างคลุมเครือ
    • ทำไมการเลื่อนแบบนุ่มนวลของเนทีฟถึงไม่ใช่ไอเดียที่ดีในกรณีส่วนใหญ่?
      ปกติหลังจากทำแองเคอร์แบบสารบัญเสร็จ ผมอย่างน้อยก็มักจะเพิ่มมันเข้าไป
    • ยังไงของพวกนั้นก็ไม่จำเป็นต้องใช้ JavaScript อยู่ดี

  • น่าประหลาดใจที่ในปี 2023 เรายังเถียงกันเรื่อง ฟอร์ม และ UX ทั่วไปที่ผู้ใช้ป้อนข้อมูล
    แค่ดูคอมเมนต์เกี่ยวกับ datalist กับตัวเลือกสีก็เห็นแล้ว และผมไม่เข้าใจว่าทำไมพื้นที่นี้ถึงยังไม่ถูกแก้ให้จบ
    สมัยก่อนเคยมีความพยายามใช้ XForms เพื่อแก้เรื่องนี้ในคราวเดียว แต่ก็ไม่ได้ถูกนำไปใช้ในเบราว์เซอร์
    แทนที่จะเป็นอย่างนั้น แทบทุกเฟรมเวิร์กคอมโพเนนต์ CSS/JS ต่างก็จัดชุดองค์ประกอบฟอร์มที่จำกัดและมีความหมายเชิงโครงสร้างต่างกันไปของตัวเอง

    • ผลจากการปฏิเสธ เทคโนโลยี XML คือเว็บถูกกำหนดให้ต้องสร้างเวอร์ชันห่วย ๆ ของสิ่งที่ XML เคยให้ไว้ซ้ำแล้วซ้ำเล่าอย่างไม่รู้จบ
      ดูเหมือนเราคงต้องทำคอนโทรล UI พื้นฐานกันเองไปตลอดชีวิต
    • มันแก้ได้แล้ว ใส่เข้าไปใน React แล้วใช้ชีวิตต่อก็พอ
      ที่ดูเหมือน “ยังไม่ถูกแก้” ก็เพราะบางคนมีความหมกมุ่นแปลก ๆ ที่จะหลีกเลี่ยง JavaScript จนพยายามยัดทางเลือกที่ยังไม่สุกงอมเข้าไปต่างหาก
    • การบอกว่าฟอร์ม “ถูกแก้แล้ว” หมายความว่าอะไร?
      ถ้าจะอยู่กับเทคโนโลยีพื้นฐานที่น่าเบื่อ มันก็ถูกแก้แล้ว แต่ถ้าดื้อจะไปแก้ใหม่ด้วย React แล้วแก้อีกรอบด้วย React hooks แล้วแก้ใหม่ไม่รู้จบ มันก็จะกลายเป็นว่ายังไม่ถูกแก้
    • เพราะ CSRF จึงมีบางอย่างที่มนุษย์ทำได้แต่เราทำไม่ได้
      ความตั้งใจไม่ใช่สิ่งที่โปรแกรมจะตัดสินได้ ดังนั้นในบางสถานการณ์เราจึงมีฟีเจอร์เจ๋ง ๆ ไม่ได้
      ในฟอร์มซับซ้อนล่าสุดที่ผมทำ ต้องทำให้อีเวนต์คลิกเป็นตัวก่อให้เกิดการส่งฟอร์มค่อนข้างตรง ๆ เพื่อให้เบราว์เซอร์ยอมอนุญาต
    • ฟอร์มยังไม่ถูกแก้ เพราะใครสักคนที่ไหนสักแห่งอยากส่งสิ่งที่แตกต่างกันผ่านฟอร์ม
      ผมไม่เคยขอวิธีส่งค่าสีผ่านเว็บเพจเลย

  • ถ้าใช้ details แทน JavaScript, Ctrl+F จะค้นหาและเปิดเนื้อหาข้างในได้
    แอคคอร์เดียน JavaScript เปิดแบบนั้นไม่ได้

    • ถ้าใช้ hidden="until-found" ก็ทำให้แอคคอร์เดียนที่ใช้ JS หรือเนื้อหาที่ซ่อนแบบอื่น ๆ ทำแบบเดียวกันได้ แต่น่าเสียดายที่ตอนนี้มีเฉพาะใน เบราว์เซอร์ที่ใช้ Chromium เท่านั้น: https://developer.chrome.com/articles/hidden-until-found/
    • มีวิธีอื่นไหมที่ซ่อนได้แต่ยังยอมให้ค้นหาเจอ?
    • เพิ่งเจอปัญหาคล้ายกันระหว่างไล่อ่านเอกสาร

  • โดยรวมเห็นด้วยเกือบหมด แต่ dialog ผมยังไม่ได้ลองใช้มากพอเลยไม่มีความเห็น ส่วน datalist ผมมองว่าไม่ใช่ตัวเลือกที่ใช้ได้ถ้าไม่ใช่เครื่องมือภายใน
    มันหน้าตาไม่สวย ทำอะไรได้จำกัด และ กำหนดสไตล์ ก็ไม่ได้ ปัญหาของข้ออ้างส่วนใหญ่ที่ว่า “ก็ใช้ของในตัวไปสิ” คือแบบนี้แหละ date picker ก็เหมือนกัน
    ค่าเริ่มต้นไม่เพียงแย่เท่านั้น แต่ถึงอยากเปลี่ยนก็เปลี่ยนไม่ได้ เมื่อคุณชนกำแพงสักข้อจากกำแพงมากมายในการปรับสไตล์หรือพฤติกรรม เช่น อยากให้สัปดาห์เริ่มที่วันจันทร์ ก็ทำไม่ได้ สุดท้ายตัวเลือกมักเหลือแค่ไลบรารีทดแทนเต็มรูปแบบที่ใช้ JS
    ผมเห็นด้วยกับการใช้ตัวเลือกที่เบากว่า และเห็นด้วยกับลำดับชั้น HTML > CSS > JS แต่ถ้าต้องการทั้ง UI ที่ดูดีและฟีเจอร์ที่ต้องการ บางครั้ง JS ก็เป็นคำตอบเดียว

    • ตอนทำกล่องคำแนะนำการค้นหา ผมเคยคิดว่า datalist อาจช่วยได้
      มันทำงานได้ดีจนถึงวินาทีที่ผมอยากแสดงตัวเลือกที่ไม่ได้ขึ้นต้นอย่างเคร่งครัดด้วยข้อความที่พิมพ์ เช่น ถ้าในอินพุตมีพิมพ์ผิด ตัวเลือกก็ไม่แสดง
      ไม่มีวิธีบังคับให้แสดงรายการทั้งหมด เลยลงเอยด้วยการใช้รายการแบบมีลำดับ
    • ควรจดจำไว้เสมอว่าแนวทางการขยาย มาร์กอัปเชิงความหมาย ที่มีในตัวด้วย JS เป็นแนวทางที่มองไปข้างหน้า
      ตอนผมเริ่มทำเว็บ การเปลี่ยนแปลงหนึ่ง ๆ ใช้เวลาสูงสุดถึง 10 ปี IE6 ก็รั้งเราทุกคนไว้ แต่ตอนนั้น w3c เองก็แทบไม่มีแรงเหมือนกัน ตอนนี้การเปลี่ยนแปลงเร็วขึ้น
      ปีหน้า การกำหนดสไตล์ datalist อาจทำได้โดยไม่ต้องมี prefix ในเบราว์เซอร์หลักทั้งสามตัว แต่ถ้าคุณผูกติดกับโซลูชัน JS แบบคัสตอม ธุรกิจก็จะไม่ยอมจ่ายค่าทำใหม่
      ถ้าขยายฟีเจอร์เนทีฟด้วย JS เมื่อการรองรับเพียงพอแล้วก็สามารถเอา JS ออกได้ด้วยต้นทุนต่ำ จุดไหนที่คอนโทรลเนทีฟพอรับได้ก็ใช้ตอนนี้ แล้วนำ JS มาใช้เหมือน polyfill
    • การตั้งค่าแบบกำหนดเองส่วนใหญ่ที่มักเสนอสำหรับวันเริ่มสัปดาห์หรือ input[type=date] นั้น จริง ๆ แล้วเป็นเรื่องดีเสียกว่าที่นักพัฒนาควบคุมไม่ได้
      ปฏิทินที่เหมาะสมจะแสดงอย่างไรควร ขึ้นกับโลเคล แพลตฟอร์มของผู้ใช้มีความสามารถตั้งค่าและแสดงผลในแบบที่ผู้ใช้น่าจะใช้งานได้อย่างมีประสิทธิภาพที่สุดอยู่แล้ว
      date picker ของแพลตฟอร์มดีกว่าของประหลาดที่ทำขึ้นเอง

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

    • ต่อให้ผู้คนทำตามมาตรฐานเดียวอย่าง HTML ผู้ผลิตเบราว์เซอร์ก็ต้องทำการ implement ให้สอดคล้องกันด้วย
      และยังมีปัญหาเรื่อง “รอให้ผู้คนอัปเดต” อยู่เหมือนเดิม คือหลังจากมีฟีเจอร์ใหม่เข้ามา อาจต้องใช้เวลาหลายปีกว่าจะได้รับการรองรับกว้างพอจนมีประโยชน์
      โดยรวมเห็นด้วยว่ามีการ implement แย่ ๆ และกลไก JavaScript ซับซ้อนอยู่มาก สำหรับเนื้อหาแบบไดนามิกเองก็มีวิธีมาตรฐานอยู่พอสมควรที่จะรักษาการทำงานของปุ่มย้อนกลับไว้ และเท่าที่รู้ เว็บเฟรมเวิร์กยอดนิยมก็รองรับเป็นค่าเริ่มต้น
    • โกรธกันจริงเหรอ?
      ผมอ่านคอมเมนต์อันดับต้น ๆ แล้ว แต่แทบไม่เห็นอะไรที่เรียกได้ว่าโกรธ มีแต่คนยกประเด็นที่สมเหตุสมผลเรื่องการรองรับของเบราว์เซอร์เท่านั้น

  • ถึงจะเป็นก้าวหนึ่งในทิศทางที่ถูกต้อง แต่ CSS ก็เป็นอีกเครื่องมือหนึ่งที่ “artistes” ตามที่ Philip Greenspun เรียก ใช้ในทางที่ผิดเพื่อสร้างหน้าที่อ่านยาก
    ผมไม่ใช่ฝ่ายสนับสนุน Gemini แต่โดยพื้นฐานแล้ว ทุกแง่มุมของ เลย์เอาต์และไทโปกราฟี ควรถูกส่งกลับไปให้เบราว์เซอร์และให้ผู้ใช้ควบคุม นักออกแบบได้แสดงให้เห็นไม่รู้จบแล้วว่าไว้ใจให้จัดการเรื่องนั้นไม่ได้

  • ชอบเจตนานะ สวิตช์ก็ดูดี และ summary/details ก็มีประโยชน์บ้างเป็นครั้งคราว
    แต่ element datalist แทบไม่ใช่ตัวเลือกที่ใช้ได้จริงสำหรับงานที่เกินกว่าของเล่นหรือโปรโตไทป์

  • สิ่งที่ผมชอบในกลุ่ม “CSS ก็พอโดยไม่ต้องใช้ JS” คือ sidebar drawer และ carousel
    ไลบรารีคอมโพเนนต์ TailwindCSS ชื่อ DaisyUI ก็มีคอมโพเนนต์ที่ใช้ได้ทันที
    https://daisyui.com/components/drawer/
    https://daisyui.com/components/carousel/

    • จะบอก screen reader ให้รู้เรื่อง drawer ได้อย่างไร?
      ต้องประกาศให้รู้ว่ามี drawer และเนื้อหาอื่นที่ปรากฏบนหน้า และควรมีสถานะ aria-expanded อยู่ข้าง ๆ ตัวควบคุมที่เกี่ยวข้อง
      นี่ยังเป็นคำถามจริง ๆ อาจมีวิธีก็ได้ หรือบางทีนักพัฒนา collectively อาจมองว่าไม่สำคัญ แต่ผู้ตรวจสอบคงไม่เห็นด้วย
    • เวลาเห็นเฟรมเวิร์กแบบนี้ ตอนแรกก็มักคาดหวังเสมอ แต่เหมือนเฟรมเวิร์กอื่น ๆ ทั้งหมดที่เคยลอง DaisyUI ก็มีปัญหาหลายอย่างบน iOS Safari และเบราว์เซอร์อื่น ๆ
      ผู้เขียนเฟรมเวิร์กแบบนี้ดูเหมือนจะประเมินต่ำไปมากว่าต้องทดสอบมากแค่ไหนจึงจะทำให้ใช้งานได้จริงข้ามเบราว์เซอร์
      เมื่อมีคอมโพเนนต์มากขนาดนั้น แถมยังทำธีมได้อีก ก็ยากจะรับประกันว่าจะยังแก้ไขได้โดยไม่ทำธีมและแอปพลิเคชันเดิมพัง
    • เพิ่งเคยเห็น “Snap to [start|center|end]” ใน components/carousel/ เป็นครั้งแรก
      ตกลงว่า snap คืออะไร และทำงานอย่างไร? หน้าจอของผมไม่ตอบสนองต่อการคลิกด้วยนิ้ว
      ผมคิดว่าวิธีโต้ตอบที่คนไม่รู้จักไม่ใช่เหตุผลที่ดีในการแนะนำไลบรารี UI element