ทำไม element `html` บน caniuse.com ถึงไม่ได้รับการรองรับ 100%

 (anderegg.ca)
2 คะแนน โดย GN⁺ 2024-02-03 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • CanIUse.com เป็นเว็บไซต์ที่ติดตามความเข้ากันได้ของเทคโนโลยีเว็บ แต่กลับแสดงอัตราการรองรับของ element พื้นฐานอย่าง html ไว้ที่ 97.34% ทำให้เกิดข้อสงสัยต่อการตีความตัวเลขนี้
  • อัตราการรองรับนี้ดูเหมือนจะเชื่อมโยงกับ ข้อมูลความเข้ากันได้ของ MDN ที่ CanIUse.com ใช้งานอยู่ และน่าจะได้รับผลจากรายการย่อยบางส่วนในหน้า element html
  • รายการที่เป็นปัญหาคือแอตทริบิวต์ manifest แบบเลือกใช้ และ secure context required ซึ่งทั้งสองอย่างเป็นรายการที่ไม่ได้ถูกทำให้เป็นมาตรฐานหรือถูกยกเลิกไปแล้ว
  • เมื่อมีการปะปนกันระหว่างเบราว์เซอร์ที่ไม่รองรับ เบราว์เซอร์ที่ไม่ทราบสถานะการรองรับ และวิธีจัดการกับเบราว์เซอร์รุ่นเก่า จึงทำให้แม้แต่ element พื้นฐานอย่าง html ก็มีอัตราการรองรับที่ไม่ตรงกับสัญชาตญาณ
  • หากดูตามเกณฑ์ “% of all tracked” และรวม support unknown เข้าไปด้วย ก็อาจมองได้ว่าเป็น 99.98% ทำให้มีความเป็นไปได้เรื่องความคลาดเคลื่อนจากการปัดเศษมากขึ้น แต่ตัวเลขของ CanIUse.com ก็ยังควรอ่านอย่างระมัดระวัง

ข้อสงสัยที่เกิดจากอัตราการรองรับ html 97.34%

  • CanIUse.com ติดตามอัตราการยอมรับของเบราว์เซอร์ต่อเทคโนโลยีเว็บและความเข้ากันได้ของฟีเจอร์ พร้อมแสดงตัวเลขว่าฟีเจอร์นั้นใช้งานได้จริงมากน้อยแค่ไหน
  • อัตราการรองรับของ element html แสดงไว้ที่ 97.34%
    • ซึ่งต่ำกว่า element audio
    • และ element a, p ก็แสดงอัตราการรองรับเท่ากันที่ 97.34%
  • การที่ element พื้นฐานของเว็บซึ่งถูกใช้งานมานานมากแล้วไม่ได้เป็น 100% ทำให้จำเป็นต้องตรวจสอบมากกว่าการดูตัวเลขความเข้ากันได้แบบผิวเผิน

รายการย่อยที่เห็นได้ในตารางความเข้ากันได้ของ MDN

  • ข้อมูลจำนวนมากของ CanIUse.com ดูเหมือนจะดึงมาจาก MDN
  • ในหน้า element html ของ MDN มีส่วนความเข้ากันได้ของเบราว์เซอร์
  • ในตารางนี้ รายการที่มีเครื่องหมาย X สีแดงจำนวนมากมีอยู่สองอย่าง
  • แม้จะจริงที่แทบทุกเบราว์เซอร์ไม่รองรับสองรายการนี้ แต่เพียงเท่านี้ก็ยังไม่อธิบายอย่างชัดเจนว่าทำไมอัตราการรองรับรวมของ element html จึงลดลงมาถึง 97.34%

ความเป็นไปได้จากเบราว์เซอร์รุ่นเก่าและความคลาดเคลื่อนจากการปัดเศษ

  • เบราว์เซอร์บางตัวถูกแสดงเป็น Support Unknown และยอดรวมการใช้งานปัจจุบันของเบราว์เซอร์กลุ่มนี้คือ 1.27%
  • Android Browser 2.1–4.3 ถูกแสดงว่าไม่รองรับ element html แต่มีสัดส่วนการใช้งาน 0%
    • น่าสงสัยว่าการระบุว่าเบราว์เซอร์เก่าเหล่านี้ไม่รองรับ element html นั้นถูกต้องจริงหรือไม่
    • และก็ยังไม่ชัดเจนว่าความคลาดเคลื่อนจากการปัดเศษจะทำให้ 1.27% ขยายไปเป็น 2.66% ได้หรือไม่
  • หากเปลี่ยนเกณฑ์ข้างคำว่า “usage” ที่มุมขวาบนของ CanIUse.com เป็น “% of all tracked” แล้วนำค่าของเบราว์เซอร์ “support unknown” มารวม จะได้ 99.98%
    • ภายใต้เกณฑ์นี้จะเห็นความเป็นไปได้ที่ตัวเลขปัจจุบันเกิดจากความคลาดเคลื่อนในการปัดเศษได้ง่ายขึ้น
    • แต่แนวทางที่ CanIUse.com ใช้จัดการกับเบราว์เซอร์รุ่นเก่าใน element พื้นฐานอย่าง html ก็ยังชวนให้สับสนอยู่ดี
  • CanIUse.com ยังเป็นแหล่งข้อมูลที่มีประโยชน์ แต่ตัวเลขอัตราการรองรับที่แสดงควรถูกอ่านโดยดูบริบทและเกณฑ์การคำนวณประกอบกัน

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

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

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

  • ใน CanIUse มีตัวเลือก "% of all" อยู่เหนืออัตรา Global พอดี ถ้าเปิดไอคอนรูปเฟืองในหน้าฟีเจอร์ จะมีรายละเอียดเพิ่มเติมเกี่ยวกับวิธีคำนวณการใช้งาน ค่าเริ่มต้นคือ All Users ซึ่งถือว่าการใช้งานทั้งหมดของเบราว์เซอร์ที่ caniuse ไม่ได้ติดตามเป็นไม่รองรับ และถ้าเปลี่ยนเป็น All tracked users จะคำนวณเฉพาะเบราว์เซอร์ที่ถูกติดตาม ทำให้ได้ 98.71% ผลรวมของเบราว์เซอร์ที่สถานะการรองรับในกราฟเป็น Unknown คือ 1.27% และเมื่อเอา 1.27% บวกกับ 98.71% จะได้ 99.97999… จึงดูเหมือนมีผลจากการปัดเศษ ปัญหาจริง ๆ คือเบราว์เซอร์เหล่านั้นถูกแสดงเป็น Unknown และในทางปฏิบัติน่าจะถือได้ว่ารองรับองค์ประกอบ ``

    • จาก สตริง User-Agent ที่ “ระบุไม่ได้ชัดเจนว่าเป็นอะไร” ซึ่งปรากฏใน log คำขอของ API SaaS ของเรา ดูเหมือนว่า “เบราว์เซอร์” จำนวนมากใน 1.27% นั้นน่าจะเป็น scraper เฉพาะทางสารพัดชนิดที่บังเอิญเข้ามาในพื้นที่นอกความเชี่ยวชาญของตัวเอง ดังนั้นจึงไม่จำเป็นต้องสรุปว่ามัน parse `` ได้ อาจเป็น JSON scraper ก็ได้
    • มีการใช้ wget กันมาก และถ้ารวมไว้ด้วย เรื่องก็จะต่างออกไป ผมลองดู src/html-url.c แล้ว พบว่าในความเป็นจริงมันไม่รองรับ `` เลย และจัดการเป็น แท็กที่ไม่รู้จัก

  • ผมติดใจที่เดิม MDN เคยย่อมาจาก Mozilla Developer Network แต่ตอนนี้เป็นแค่ MDN เฉย ๆ เลยลองค้นดู แต่ผมก็หา ชื่อเต็ม ไม่เจอเหมือนกัน

    • การเปลี่ยนนั้นเกิดขึ้นราวปี 2017 ชื่อ Mozilla Developer Network ค่อนข้างกำกวม และในการทำแบบสำรวจกับสัมภาษณ์ผู้ใช้ก็พบความสับสน นักพัฒนาเว็บคิดว่าเป็นเอกสารสำหรับนักพัฒนา Mozilla โดยเฉพาะ ซึ่งในช่วงแรก ๆ ก็มีลักษณะเช่นนั้นจริง ๆ จึงไม่ได้ผิดเสียทีเดียว ช่วงหนึ่ง MDN มีเอกสารที่เกี่ยวกับ Mozilla จำนวนมากนอกเหนือจากเอกสาร Web Platform แต่พอถึงปี 2017 เอกสาร Web Platform คิดเป็น 95% ของทราฟฟิก MDN แล้ว และตัวตนหลักก็ไม่ได้เป็นแหล่งข้อมูลสำหรับนักพัฒนา Mozilla อีกต่อไป ดังนั้นจึงเปลี่ยนชื่อเป็น MDN Web Docs เพื่อให้เห็นการเปลี่ยนโฟกัส
    • การเปลี่ยนนี้เกิดขึ้นประมาณวันที่ 15 สิงหาคม 2017 ผมรู้เพราะบังเอิญเห็นช่วงที่แบรนดิ้งเปลี่ยนแล้ว แต่เนื้อหาในหน้ายังไม่ได้เปลี่ยน bug report ที่ผมส่งตอนนั้นอยู่ที่นี่: https://bugzilla.mozilla.org/show_bug.cgi?id=1390381
    • ผมชอบเรียกสิ่งแบบนี้ว่า anachronym เพราะให้ความรู้สึกเหมือนตัวย่อที่ล้าสมัย พูดอย่างเคร่งครัดนี่เป็น initialism มากกว่าจะเป็น acronym แต่ผมก็เคยเขียนบทความที่เกี่ยวข้องไว้ด้วย https://simpsonian.ca/blog/anachronyms/
    • ยังมีหลงเหลืออยู่บ้างในหน้าข้าง ๆ และโค้ดตัวอย่างบางจุด แต่ที่พบก็มีประมาณนี้ “will soon be a proud part of the Mozilla Developer Network (MDN)” — https://developer.mozilla.org/en-US/blog/mdn-observatory/ “Their brilliant but offbeat idea grew into today's Mozilla Developer Network” — https://developer.mozilla.org/en-US/docs/MDN/At_ten const heading = Mozilla Developer Network; — https://developer.mozilla.org/en-US/docs/Learn/Tools_and_tes...
    • ผมจำได้ว่าเมื่อไม่กี่ปีก่อน เอกสารของ Microsoft เริ่มชี้ไปยังเอกสารของ Mozilla อาจเป็นส่วนหนึ่งของการรีแบรนด์ Edge ก็ได้ ถ้าการเปลี่ยนชื่อเป็น MDN เกิดขึ้นระหว่างกระบวนการตกลงกันนั้น ก็อาจเพื่อเลี่ยงความสับสนแบบ “นี่คือ M(ozilla)DN หรือ M(icrosoft)DN กันแน่?” แต่ผมก็ไม่แน่ใจ

  • น่าสนใจที่ได้ยินว่าองค์ประกอบ และ ก็มี อัตรารองรับ 97.34% เท่ากันพอดี องค์ประกอบทั้งสองนี้ก็ใช้ข้อมูลจาก MDN เหมือนองค์ประกอบ ``: https://caniuse.com/mdn-html_elements_a และ https://caniuse.com/mdn-html_elements_p ผมได้อัปเดตบทความให้สะท้อนเรื่องนี้แล้ว

  • ใน CanIUse น่าจะแยก html-manifest ออกมาเป็นฟีเจอร์ต่างหากได้ และอยากย้ำอีกครั้งว่า MDN เป็นแหล่งข้อมูลที่ยอดเยี่ยมจริง ๆ

  • เว็บเพจแรกสุดไม่ได้ใช้ องค์ประกอบ html http://info.cern.ch/hypertext/WWW/TheProject.html

  • เรื่องนี้เกี่ยวกับ HTML ขั้นต่ำที่ถูกต้องหรือเปล่า? ในนั้นไม่มี แท็ก HTML

    • ดูเหมือนไม่ค่อยเกี่ยวกัน `` ก็ออกมาเกือบอัตราเดียวกัน: https://caniuse.com/mdn-html_elements_title น่าจะเป็นปัญหาเรื่องการคำนวณเบราว์เซอร์ที่รู้ปริมาณการใช้งาน แต่ไม่สามารถตรวจสอบสถานะการรองรับได้มากกว่า เพิ่มเติมคือ HTML นั้นจริง ๆ แล้วไม่ valid และจะถูกจัดการเป็น title ว่าง ซึ่ง title ว่างไม่ valid ถ้าเปลี่ยนเป็นอะไรอย่าง . ก็น่าจะผ่านโดยไม่มี error
    • แต่ในนั้นก็มีแท็ก ไม่ใช่หรือ? แค่มันไม่ได้ระบุอย่างชัดเจนเท่านั้น จึงถูกอนุมานขึ้นมา ไม่ว่าจะเปิดหน้านั้นด้วยเบราว์เซอร์ใด ในหน้านั้นก็จะมีแท็ก อยู่
    • ในโปรโตคอลที่สามารถส่ง title ด้วยวิธีอื่นได้ เช่น Subject header ของอีเมล จึงเป็นตัวเลือก ดังนั้น HTML ที่ valid ที่สั้นที่สุดจึงมีแค่ ตัวเดียว เพียงแต่มัน valid เฉพาะในบริบทบางอย่างเท่านั้น

  • คำว่า “ข้อมูลจำนวนมากของไซต์มาจาก MDN” ค่อนข้างกำกวม เมทริกซ์การรองรับฟีเจอร์ที่เชื่อมกับ CanIUse มาจาก repository browser-compat-data ของ MDN ข้อมูลต้นทางขององค์ประกอบ HTML อยู่ที่นี่: https://github.com/mdn/browser-compat-data/blob/main/html/el... แต่ในนั้นไม่มีการทดสอบและข้อมูลการใช้งานที่ CanIUse ใช้อ้างอิงในการคำนวณอัตรารองรับ มีเพียงว่าเบราว์เซอร์เวอร์ชันใดรวมฟีเจอร์ใดไว้บ้าง CanIUse เองก็ชี้ไปยัง repository ของตัวเอง และในนั้นมีข้อมูลจำนวนมาก: https://github.com/fyrd/caniuse แต่ผมหาจุดเริ่มต้นที่ทำให้ค้นได้ง่ายว่าตัวเลขขององค์ประกอบเฉพาะมาจากไหนไม่เจอ ข้อมูลในนั้นก็ดูเหมือนจะจัดตามฟีเจอร์เป็นหลัก คำถามที่แม่นยำกว่าคือ CanIUse เอา การทดสอบองค์ประกอบ HTML และตัวเลขการใช้งาน มาจากที่ไหน และนั่นดูเหมือนเป็นประเด็นหลัก

  • อัตรารองรับขององค์ประกอบ `` ไม่ควรต้องต่ำกว่าหรือเท่ากับองค์ประกอบอื่น ๆ ทั้งหมดอย่างน้อยที่สุดหรือ?

    • ไม่ใช่ องค์ประกอบ ไม่ได้หมายถึง “HTML ทั้งหมด” แต่เป็นเพียงอีกองค์ประกอบหนึ่งที่หมายถึง **องค์ประกอบรากของเอกสาร** เท่านั้น อย่างที่คนอื่นเขียนไว้ มันไม่ได้จำเป็นจริง ๆ ในการสร้างเอกสาร HTML ที่ valid และไม่มี error ด้วยซ้ำ สิ่งที่จำเป็นในตอนนั้นคือ กับ body ที่ valid ประมาณนั้น เปรียบเทียบได้ว่า ความสามารถในการเข้าใจและ parse คำว่า “English” ในชื่อเรียงความอย่างถูกต้อง เป็นคนละเรื่องกับการรู้ความหมายของคำภาษาอังกฤษว่า “fustigate”

  • “ดังนั้นจึงไม่มีคำตอบที่ชัดเจน ถ้ารู้ก็ช่วยบอกด้วย!”

    • ถ้าจะใส่คำอธิบายสนุก ๆ ก็อาจบอกได้ว่า เบราว์เซอร์ลับ[1] ของ Android เป็นตัวสร้าง outlier ที่ดูเหมือนติดตามไม่ได้นี้ :-) [1] https://news.ycombinator.com/item?id=39226754