การตรวจจับฟีเจอร์เทียบกับการตรวจสอบเบราว์เซอร์
ใช้การตรวจจับฟีเจอร์แทนการตรวจสอบ user-agent
การตรวจจับฟีเจอร์เทียบกับการตรวจสอบเบราว์เซอร์ เป็นบทเรียน HTML Academy ฟรีบน CoddyKit นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน HTML Academy และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส HTML Academy มีบทเรียนทั้งหมด 4 บทเรียน
สองแนวทางสำหรับความเข้ากันได้
หากต้องการทราบว่าเบราว์เซอร์ปัจจุบันรองรับความสามารถหนึ่งหรือไม่ คุณสามารถ ตรวจจับความสามารถโดยตรง ("IntersectionObserver" in window) หรือ ตรวจสอบสตริงตัวแทนผู้ใช้ (navigator.userAgent.includes("Chrome")) วิธีแรกเชื่อถือได้ ส่วนอีกวิธีเป็นต้นเหตุของข้อผิดพลาดมานาน
เหตุใดการตรวจสอบสตริงจึงล้มเหลว
สตริงตัวแทนผู้ใช้ให้ข้อมูลที่ไม่น่าเชื่อถือ เบราว์เซอร์เอดจ์อ้างตัวว่าเป็นโครม (รวมถึงซาฟารีและไฟร์ฟอกซ์) โครมบนแอนดรอยด์ส่ง UA ที่แตกต่างจากโครมบน iOS เบราว์เซอร์เคารพการ "ตรึง" สตริง UA เพื่อความเป็นส่วนตัว ตรรกะใดก็ตามที่อิงสตริง UA จะพังทุก ๆ สองสามเดือน
รูปแบบการตรวจจับความสามารถ
ตรวจสอบส่วนติดต่อการเขียนโปรแกรมจริงที่โค้ดต้องใช้: if ("IntersectionObserver" in window) { ... } หากมีคุณสมบัตินั้น เบราว์เซอร์ก็รองรับ แต่หากไม่มี ให้ใช้เส้นทางสำรอง การตรวจสอบนี้ตรงไปตรงมา รวดเร็ว และรองรับอนาคต
if ("IntersectionObserver" in window) {
const observer = new IntersectionObserver(handler);
} else {
loadPolyfill().then(() => { /* use IntersectionObserver */ });
}ตรวจจับแล้วจึงใช้งาน
จับคู่การตรวจจับกับทางเลือกสำรองจริง การตรวจพบว่าความสามารถหายไปจะมีประโยชน์ก็ต่อเมื่อคุณมีสิ่งที่จะทำเมื่อความสามารถนั้นหายไป เช่น โหลดโพลีฟิลล์ แสดงทางเลือกแบบคงที่ หรือซ่อนความสามารถนั้นทั้งหมด
การตรวจสอบความสามารถของ CSS
CSS มีการตรวจจับความสามารถของตัวเอง: @supports (display: grid) { ... } บล็อกนี้จะมีผลเฉพาะเมื่อเบราว์เซอร์เข้าใจคู่คุณสมบัติ/ค่าเท่านั้น โปรดใช้เพื่อส่งเลย์เอาต์กริดพร้อมทางเลือกสำรองที่ใช้โฟลตสำหรับเบราว์เซอร์รุ่นเก่ามาก
@supports (display: grid) {
.grid { display: grid; gap: 16px; }
}
@supports not (display: grid) {
.grid > * { float: left; width: 33%; }
}คำใบ้ไคลเอ็นต์ตัวแทนผู้ใช้
เบราว์เซอร์สมัยใหม่เปิดเผยข้อมูลแบบมีโครงสร้างผ่าน navigator.userAgentData (เฉพาะ Chromium) โดยส่งกลับคู่แบรนด์+เวอร์ชันแทนสตริงอิสระ แต่ยังควรเลือกการตรวจจับความสามารถเป็นหลัก คำใบ้ UA มีประโยชน์เฉพาะเมื่อไม่สามารถอนุมานความสามารถจากการตรวจสอบคุณสมบัติได้
เมื่อการตรวจสอบสตริงยอมรับได้
กรณีใช้งานการตรวจจับ UA ที่ถูกต้องและจำกัดคือการเลือกไม่ใช้เบราว์เซอร์ที่มีข้อผิดพลาดที่ทราบอยู่แล้ว เช่น ข้อผิดพลาดของ iOS ซาฟารีในเวอร์ชัน X ถึงอย่างนั้นก็ควรเลือกการไม่ใช้ตามความสามารถ (CSS.supports("aspect-ratio: 1")) การตรวจจับ UA ควรเป็นทางเลือกสุดท้าย
ไลบรารีรูปแบบโมเดิร์นไนเซอร์
โมเดิร์นไนเซอร์รวมการตรวจจับความสามารถจำนวนมากและเปิดเผยผลลัพธ์เป็นคลาสบนองค์ประกอบ <html> (html.flexbox, html.no-flexbox) โครงการสมัยใหม่แทบไม่จำเป็นต้องใช้ เพราะการตรวจจับส่วนใหญ่ทำได้ด้วยคำสั่งบรรทัดเดียว แต่ยังมีประโยชน์สำหรับการย้ายระบบเก่า
การทดสอบทางเลือกสำรอง
เมื่อวางการตรวจจับเรียบร้อยแล้ว โปรดทดสอบทั้งสองเส้นทาง เปิด DevTools แทนค่าความสามารถเป็น undefined และตรวจสอบว่าทางเลือกสำรองทำงานได้ ทางเลือกสำรองที่ไม่เคยทดสอบจะเสื่อมสภาพ เมื่อถึงเวลาที่ผู้ใช้ต้องการใช้ มักล้มเหลวในแบบที่นักพัฒนาไม่เคยคาดคิด
การตรวจจับในเฟรมเวิร์ก
รีแอกต์ วู และเฟรมเวิร์กอื่น ๆ ไม่มีส่วนติดต่อการตรวจจับพิเศษ โปรดใช้ JavaScript แบบปกติภายในเอฟเฟกต์หรือการเริ่มต้นคอมโพเนนต์ แอปที่แสดงผลจากเซิร์ฟเวอร์ต้องตรวจจับบนไคลเอ็นต์ เพราะ "IntersectionObserver" in window มีค่าเป็น undefined ระหว่าง SSR
หลีกเลี่ยงการตรวจสอบ UA เพื่อคาดเดาความสามารถ
บางทีมตรวจสอบ UA เพื่อเดาความสามารถ ("นี่คือ iPhone หรือไม่ จากนั้น then ก็น่าจะมีระบบสัมผัส") ซึ่งเป็นการนำสองสิ่งที่ไม่เกี่ยวข้องกันมาปะปน โปรดตรวจจับระบบสัมผัสโดยตรงผ่าน "ontouchstart" in window หรือเลือกเหตุการณ์ตัวชี้ที่ทำหน้าที่ซ่อนความแตกต่างของรูปแบบการป้อนข้อมูล
ตรวจสอบความรู้
เหตุใดจึงควรเลือกการตรวจจับความสามารถแทนการตรวจสอบสตริงตัวแทนผู้ใช้เพื่อจัดการความสามารถของเบราว์เซอร์
สรุป
โปรดเลือกการตรวจจับความสามารถ ("API" in window) แทนการตรวจสอบสตริงตัวแทนผู้ใช้ CSS มี @supports สำหรับจุดประสงค์เดียวกัน จับคู่การตรวจจับกับทางเลือกสำรองจริงและทดสอบทั้งสองเส้นทางเสมอ การตรวจสอบ UA ควรจำกัดไว้สำหรับการเลือกไม่ใช้เบราว์เซอร์รุ่นที่มีข้อผิดพลาดที่ทราบอยู่แล้ว ไม่ควรใช้เพื่อคาดเดาความสามารถ
คำถามที่พบบ่อย
บทเรียน “การตรวจจับฟีเจอร์เทียบกับการตรวจสอบเบราว์เซอร์” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “การตรวจจับฟีเจอร์เทียบกับการตรวจสอบเบราว์เซอร์” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส HTML Academy ให้อัปเกรดเป็น CoddyKit PRO คอร์ส HTML Academy มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “การตรวจจับฟีเจอร์เทียบกับการตรวจสอบเบราว์เซอร์”
ใช้การตรวจจับฟีเจอร์แทนการตรวจสอบ user-agent คุณปฏิบัติ HTML Academy ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน HTML Academy หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน HTML Academy บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน
บทเรียน “การตรวจจับฟีเจอร์เทียบกับการตรวจสอบเบราว์เซอร์” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน HTML Academy นี้ได้ไหม
ได้ บทเรียน HTML Academy ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- ปรัชญา PE: เริ่มต้นด้วย HTML
- การตรวจจับฟีเจอร์เทียบกับการตรวจสอบเบราว์เซอร์
- Graceful Degradation เทียบกับ Progressive Enhancement
- การสร้างแอคคอร์เดียนแบบ PE