Browser Feature Detector: ดูให้ชัดว่า browser ของคุณรองรับอะไรจริง ๆ

ตาราง support เขียนไว้สำหรับ browser โดยรวม แต่ user ของคุณใช้ browser ของตัวเองคนละตัว Browser Feature Detector เติมช่องว่างนี้: เปิดหน้าเว็บแล้วเครื่องมือจะสแกนสด ๆ ใน browser ปัจจุบันของคุณ 55+ features ทั้ง CSS properties, JavaScript APIs และ media queries แล้วรายงานว่าอะไรใช้ได้ อะไรใช้ไม่ได้ — แยกกลุ่ม นับจำนวน และ export ออกมาได้ทันที ทุกอย่างทำงานแบบออฟไลน์ใน browser ไม่มีการอัปโหลด ไม่ต้องสมัครบัญชี

caniuse บอกคุณว่าตารางเขียนไว้ว่าอย่างไร — เครื่องมือนี้บอกคุณว่า browser ในมือคุณทำอะไรได้จริง แบบสดและออฟไลน์ ความต่างนี้สำคัญขึ้นทุกปีเพราะ vendor ปล่อย feature ผ่าน flag และ staged rollout วนตามเข้ามาทีละส่วน ฝั่งองค์กรก็ล็อกเวอร์ชันเก่าไว้นาน ช่องว่างระหว่าง "รองรับใน Chrome 140" กับ "รองรับใน Chrome ของคนหน้านี้ตอนนี้" คือแหล่งเพาะบั๊ก compatibility ตัวฉกาจ ตัวเลขเปอร์เซ็นต์ support เป็นเพียงสถิติ แต่ผลสแกนคือข้อเท็จจริงของเครื่องที่อยู่ตรงหน้า

บทความนี้พาไปดูเครื่องมือก่อน แล้วเจาะหลักการเบื้องหลัง: CSS.supports() กับ runtime checks ต่างจาก user-agent sniffing อย่างไร, ทำไม UA strings ถึงโกหก, และวิธีเปลี่ยนผลสแกนเป็น @supports fallback ที่ลื่นไหล

ทำไมต้องใช้ Browser Feature Detector?

• ความจริงจากเครื่อง ไม่ใช่เอกสาร การสแกนถาม browser โดยตรง คำตอบจึงสะท้อน flag, staged rollout และนโยบายองค์กร — สิ่งที่ตาราง support มองไม่เห็นเลย
• ทำงานออฟไลน์ทั้งหมด โหลดหน้าแล้วการตรวจจับไม่ต้องใช้เน็ต เหมาะกับ kiosk, เครื่องทดสอบแบบปิดวง และไวไฟงานสัมมนาที่ต้องลุ้นทุกคลิก
• ผลลัพธ์แยกกลุ่มอ่านง่าย ผลถูกจัดเป็น CSS properties, JavaScript APIs และ media queries เลือกดูเฉพาะเลเยอร์ที่กำลังจะ ship ได้ทันที
• ตัวนับสรุปทันที ตัวเลข supported กับ unsupported สองตัวช่วยให้เห็นรูปร่างรวมของ browser ได้ในไม่กี่วินาที
• Export รายงานได้ คัดลอกผลทั้งหมดไปแปะใน ticket, pull request หรือโน้ต compatibility ของโปรเจกต์
• 100% client-side ไม่มี telemetry ไม่มีอัปโหลด ไม่มีบัญชี browser ถูกถามเรื่องตัวเองเท่านั้น จึงไม่มีอะไรให้รั่วไหล

ฟีเจอร์หลัก

• ข้อเท็จจริง ไม่ใช่คำบอกเล่า ทุกผลลัพธ์มาจาก engine ของ browser เอง — ไม่มีแคช ไม่มีข้อมูลเก่าให้ไปไม่ไว้
• ผลลัพธ์อ่านรู้เรื่อง ทุกรายการระบุชื่อ feature และสถานะ เพื่อนร่วมทีมที่ไม่เคยเปิดเครื่องมือก็อ่าน export ออก

วิธีใช้งาน Browser Feature Detector

1. เปิดเครื่องมือ เข้า Browser Feature Detector จาก browser ที่อยากตรวจ — Chrome บนเดสก์ท็อป, Android WebView หรือ browser บน kiosk ก็ได้
2. รอสแกน การตรวจจับเริ่มเองตอนหน้าโหลด ตัวนับ supported กับ unsupported จะเต็มขึ้นมาในครู่เดียว
3. ไล่ดูทีละกลุ่ม เดินดู CSS properties, JavaScript APIs และ media queries แยกกัน งาน layout ดูฝั่ง CSS งาน platform ดูฝั่ง API
4. ส่องตัวที่หาย รายการที่ไม่รองรับมักน่าสนใจที่สุด: เช็กว่า feature ที่หายไปบล็อกแผนที่วางไว้ หรือแค่ตัด optimization ทิ้งเท่านั้น
5. Export หรือ rescan คัดลอกรายงานเก็บลงเอกสาร แล้วกด Rescan ทุกครั้งที่ browser อัปเดตหรือเปลี่ยนเครื่อง

การทำ feature detection อย่างถูกวิธี

CSS.supports() และ runtime checks เช็กอะไรกันแน่

CSS.supports('display', 'grid') ถาม CSS engine คำถามเดียว: ยอมรับ declaration นี้ไหม? เครื่องมือใช้วิธีนี้กับทุกรายการฝั่ง CSS คำตอบจึงสะท้อน parser support — กฎจะถูกนำไปใช้ได้หรือไม่ ส่วน JavaScript API ถูกสอบตรงที่ runtime: window.HTMLDialogElement มีจริงไหม, 'popover' อยู่ใน HTMLElement.prototype หรือเปล่า? นี่คือ check เดียวกับที่ production code ควรทำ แต่ดูสด ๆ ให้เห็นกับตา

ทำไม user-agent strings ถึงโกหก

การ parse navigator.userAgent แล้วแยก branch ตามผล ล้มเหลวอย่างน้อยสามทาง UA strings เป็นความโกลาหลที่แช่แข็งไว้ — ตัวร้ายส่วนใหญ่ยังอ้างว่าเป็น Mozilla, AppleWebKit และ "like Gecko" พร้อมกันเพราะเหตุผลประวัติศาสตร์ แถม browser ปลอม token ของกันและกันเพื่อความเข้ากันได้ และฟีเจอร์ privacy เริ่มสุ่มหรือตัดข้อมูลใน string นี้ แย่ที่สุดคือ UA string บอกว่า vendor ปล่อยอะไร ไม่ได้บอกว่า user เปิดใช้อะไร: นโยบายองค์กรหรือ GPU driver เก่าก็ทำให้ feature ที่ "ควรรองรับ" ใช้ไม่ได้จริง feature detection ไม่มีปัญหาพวกนี้ เพราะไม่ถามว่า browser อ้างว่าใคร — แต่พิสูจน์ว่า browser ทำอะไรได้

อ่านสามกลุ่ม: CSS, JavaScript APIs และ media queries

กลุ่ม CSS บอกว่า declaration แบบไหนจะถูกให้เกียรติ กลุ่ม JavaScript APIs บอกว่าเรียกความสามารถ platform ใดได้ — dialogs, popovers, structured cloning กลุ่ม media queries บอกว่า browser ตอบสนองสภาพแวดล้อมอย่างไร: dark mode, reduced motion, pointer precision browser หนึ่งอาจแข็งกลุ่มหนึ่งและอ่อนอีกกลุ่ม และโปรไฟล์แบบนี้แหละที่บอกคุณว่าควร ship อะไร

จาก detection สู่ fallback ด้วย @supports

ผลตรวจมีค่าเมื่อมันเปลี่ยนสิ่งที่คุณ ship และสำหรับ CSS ยานพาหนะคือ block @supports เขียน baseline ที่ทุก browser render ได้ก่อน แล้วซ้อนเส้นทางโมเดิร์นไว้ใน @supports (display: grid) และ @supports (backdrop-filter: blur(4px)) browser ที่ผ่านได้ของแต่ง ที่เหลือก็ใช้ baseline ต่อเงียบ ๆ ฝั่ง JavaScript ก็ใช้หลักเดียวกัน: เช็ก API ก่อน ใช้เมื่อมี fallback เมื่อไม่มี สแกน browser เป้าหมายแล้วคุณจะรู้ว่า block ไหนจะทำงานกับ user จริง — และเส้นทาง fallback ไหนยังมี traffic ผ่านจริง

ทดสอบบนเครื่องที่ user ของคุณมีจริง

การสแกนบนแล็ปท็อปนักพัฒนาพิสูจน์แค่เครื่องเดียว นิสัยที่ควรสร้างคือพกความสแกนที่ถูกแสนง่ายติดตัว: เปิดเครื่องมือบน Android เครื่องเก่าในลิ้นชัก, iPad ที่ออฟฟิศ และแล็ปท็อปองค์กรที่ล็อก ESR build การสแกนใช้เวลาไม่กี่วินาที และความต่างที่เจอได้คือความต่างที่ user ประสบจริง

ตัวอย่างการใช้งานจริง

ตัดสินใจว่าจะ ship feature โมเดิร์นหรือไม่

อยากใช้ container queries หรือ Popover API แต่ทีมถกกันว่า support "พอหรือยัง" ลองรัน detector บน browser ที่ลูกค้าใช้จริง ถ้าทุกเป้าหมายผ่าน ก็ ship เส้นทางโมเดิร์นพร้อมเกราะ @supports แล้วปิดวาระได้เลย ถ้าบางตัวไม่ผ่าน ผลสแกนจะบอกว่า fallback ไหนยังต้องทำงานได้

Debug ปัญหาแบบ "เครื่องฉันไม่เป็น"

ticket เล่าว่า dialog render เป็น div เปล่าบนเครื่องลูกค้าหนึ่ง แต่ที่อื่นปกติ ให้ผู้แจ้งเปิด detector ดูสักครั้ง — API ที่หายไปบน browser นั้นเปลี่ยนปริศนา compatibility คลุมเครือให้กลายเป็นการวินิจฉัยบรรทัดเดียว

เขียน fallback CSS อย่างมั่นใจ

ก่อนลบ vendor prefix เก่าหรือ fallback แบบ float ทิ้ง เช็กก่อนว่าตัวแทนโมเดิร์นใช้ได้จริงบน browser ที่ยังเข้าเว็บคุณ ผลสแกนว่ารองรับช่วยให้กุมแนวร่วมกับ @supports gate ได้ ผลสแกนว่าไม่รองรับก็อธิบายได้ว่าทำไมเส้นทางเก่ายังรับ traffic อยู่

ทำ support matrix สำหรับเอกสาร

เครื่องมือภายในมักต้องระบุว่ารองรับ browser ใดและเพราะอะไร รัน detector บนทุก browser ที่รองรับ export รายงาน แล้วแนบไว้ที่หน้า compatibility — matrix กลายเป็นหลักฐานแทนคำบอกเล่า และรีเฟรชได้ในไม่กี่นาทีหลัง browser อัปเดต

แนวปฏิบัติที่ดีที่สุด

• ตรวจ feature ไม่ใช่ตรวจ browser อย่าแยก branch ด้วย user-agent strings ให้แยกด้วยสิ่งที่ runtime พิสูจน์ว่าทำได้
• ใช้ @supports คุม production code ผลสแกนบอกว่าควรเขียน block ไหน เพื่อให้ enhancement ทำงานเฉพาะที่มันเวิร์กจริง
• มี baseline แล้วค่อยเติมของมัน ship เส้นทางที่ใช้ได้โดยไม่ต้องมี feature ที่ detect เจอ แล้วค่อยเพิ่มทีละชั้น
• เช็กซ้ำหลัง OS หรือ browser อัปเดตใหญ่ support เป็นของเคลื่อนที่ Rescan ทุกรอบอัปเดตจะทำให้สมมติฐานไม่หมดอายุ
• สแกนบนเครื่องจริงที่ user ใช้ ผลจากแล็ปท็อปไม่เคยทำนายเครื่อง phone, tablet หรือ kiosk ได้ครบ
• Export ผลแล้วจดวันที่ไว้ รายงานที่มีวันที่เปลี่ยน "น่าจะใช้ได้" ให้กลายเป็น "เราพิสูจน์แล้วว่าอย่างไร"

เริ่มใช้ Browser Feature Detector วันนี้

ถ้าคุณเคย ship feature โดยอิงตัวเลขเปอร์เซ็นต์ support แล้วภาวนาให้มันเวิร์ก ลองพลิกวิธีทำงาน: เปิด Browser Feature Detector สแกน browser ที่คุณสนใจจริง แล้วปล่อยให้ตัวนับเป็นคนตัดสิน ฟรี ทันที ออฟไลน์ทั้งหมด — การเดาเรื่อง compatibility กลายเป็นหลักฐานได้ในราวห้าวินาที

เครื่องมือที่เกี่ยวข้องที่คุณอาจชอบ:

• CSS Selector Tester — ทดสอบ selector กับ HTML ที่ paste พร้อมไฮไลต์และนับ match สด ๆ
• CSS Unit Converter — แปลง px, rem, em, pt และหน่วยอื่น ๆ โดยไม่ต้องออกจาก browser
• Regex Data Generator — สร้างข้อมูลทดสอบสมจริงจาก regex pattern ใดก็ได้ทันที

ตรวจก่อนแล้วค่อย ship — และขอให้ fallback ที่คุณเขียนเป็น fallback ที่ไม่มีใครต้องเจอสักครั้ง

คำถามที่พบบ่อย

ถ: เครื่องมืออัปโหลดข้อมูล browser หรือเครื่องของฉันไปไหนหรือเปล่า?

ตอบ: ไม่ การสแกนทั้งหมดทำงาน client-side ในแท็บของคุณผ่าน CSS.supports, runtime checks และ matchMedia ไม่มีการส่งหรือเก็บข้อมูลใด ๆ ซึ่งเป็นเหตุผลที่เครื่องมือใช้งานได้แม้ไม่มีอินเทอร์เน็ตเลย

ถ: ทำไมผลสแกนถึงขัดกับตาราง support?

ตอบ: ตาราง support บรรยายเวอร์ชันที่ปล่อยโดยรวม แต่ผลสแกนบรรยาย browser ตัวที่อยู่ตรงหน้า flag, นโยบายองค์กร และ driver เก่าสามารถทำให้ feature ที่ "ควรรองรับ" หายไปบนเครื่องใดเครื่องหนึ่งได้ เมื่อสองอย่างขัดกัน ให้เชื่อผลสแกน — เพราะนั่นคือสิ่งที่ code ของคุณจะเจอจริง

ถ: CSS.supports() เช็กอะไรกันแน่?

ตอบ: มันถาม CSS engine ว่ายอมรับคู่ property และ value ที่ให้มาหรือไม่ เช่น display กับ grid ผล true แปลว่า declaration ผ่านการ parse และถูกใช้จริง ผล false แปลว่าจะถูกทิ้ง เครื่องมือจับคู่ check เหล่านี้กับการเช็ก object ฝั่ง JavaScript ด้วย เพื่อครอบคลุมทั้งสองเลเยอร์ของ platform

ถ: ควร rescan บ่อยแค่ไหน?

ตอบ: Rescan ทุกครั้งที่ browser หรือ OS อัปเดต ทุกครั้งที่เปลี่ยนเครื่อง และก่อนตัดสินใจ release ที่ผูกกับ feature เฉพาะตัว การสแกนใช้เวลาไม่กี่วินาที — ถูกกว่าการไล่ debug บั๊กที่ user เจอแทนคุณแน่นอน