Vì sao phần tử HTML không được hỗ trợ 100% trên caniuse.com

 (anderegg.ca)
2 điểm bởi GN⁺ 2024-02-03 | 1 bình luận | Chia sẻ qua WhatsApp
  • CanIUse.com là trang theo dõi khả năng tương thích của các công nghệ web, nhưng việc phần tử cơ bản html được hiển thị với mức hỗ trợ 97,34% khiến cách diễn giải con số này trở nên đáng đặt câu hỏi
  • Mức hỗ trợ này có liên quan đến dữ liệu tương thích của MDN mà CanIUse.com sử dụng, và có vẻ bị ảnh hưởng bởi một số mục con trên trang phần tử html
  • Các mục gây vấn đề là thuộc tính manifest tùy chọn và secure context required; cả hai đều là các mục chưa từng được chuẩn hóa hoặc đã bị loại bỏ
  • Khi cách xử lý các trình duyệt không hỗ trợ, trình duyệt chưa rõ có hỗ trợ hay không và các trình duyệt cũ bị trộn lẫn, ngay cả các phần tử cơ bản như html cũng có thể xuất hiện mức hỗ trợ khác với trực giác
  • Theo tiêu chí “% of all tracked”, nếu cộng cả support unknown thì có thể xem là 99,98%, làm tăng khả năng đây là sai số làm tròn, nhưng các con số trên CanIUse.com vẫn cần được đọc thận trọng hơn

Nghi vấn từ mức hỗ trợ html 97,34%

  • CanIUse.com theo dõi tỷ lệ được trình duyệt chấp nhận và khả năng tương thích tính năng của các công nghệ web, đồng thời hiển thị bằng con số mức độ một tính năng có thể thực sự được sử dụng
  • Mức hỗ trợ của phần tử html được hiển thị là 97,34%
    • Đây là con số thấp hơn phần tử audio
    • Các phần tử a, p cũng được hiển thị cùng mức hỗ trợ 97,34%
  • Vì một phần tử nền tảng của web đã được dùng từ rất lâu lại không đạt 100%, cần kiểm tra thêm chứ không thể chỉ nhìn vào con số tương thích đơn giản

Các mục con xuất hiện trong bảng tương thích của MDN

  • Nhiều dữ liệu của CanIUse.com có vẻ được lấy từ MDN
  • Trang html element của MDN có phần tương thích trình duyệt
  • Trong bảng này, có hai mục có nhiều dấu X đỏ
  • Đúng là hầu như mọi trình duyệt đều không hỗ trợ hai mục này, nhưng chỉ riêng điều đó vẫn chưa giải thích rõ vì sao mức hỗ trợ của toàn bộ phần tử html lại giảm xuống đến 97,34%

Trình duyệt cũ và khả năng sai số làm tròn

  • Một số trình duyệt được hiển thị là Support Unknown, và tổng mức sử dụng hiện tại của các trình duyệt này là 1,27%
  • Android Browser 2.1–4.3 được hiển thị là không hỗ trợ phần tử html, nhưng thị phần sử dụng là 0%
    • Việc các trình duyệt cũ này thực sự không hỗ trợ phần tử html là điều đáng nghi
    • Cũng chưa rõ liệu sai số làm tròn có thể làm 1,27% tăng lên thành 2,66% hay không
  • Nếu ở góc trên bên phải CanIUse.com, đổi tiêu chí cạnh “usage” sang “% of all tracked” rồi cộng thêm số liệu của các trình duyệt “support unknown”, kết quả sẽ là 99,98%
    • Với tiêu chí này, có thể dễ thấy hơn khả năng con số hiện tại xuất phát từ sai số làm tròn
    • Tuy nhiên, cách xử lý các trình duyệt cũ đối với một phần tử cơ bản như html vẫn gây bối rối
  • CanIUse.com vẫn là một tài nguyên hữu ích, nhưng các mức hỗ trợ được hiển thị cần được xem cùng với ngữ cảnh và tiêu chí tính toán

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-02-03
Các ý kiến trên Hacker News

  • Trên CanIUse có tùy chọn "% of all" ngay phía trên tỷ lệ Global. Nếu mở biểu tượng bánh răng trên trang tính năng, bạn sẽ thấy chi tiết hơn về cách tính mức sử dụng. Mặc định là All Users, tức coi toàn bộ mức sử dụng của các trình duyệt mà caniuse không theo dõi là không hỗ trợ; nếu đổi sang All tracked users thì chỉ tính các trình duyệt được theo dõi và ra 98,71%. Tổng các trình duyệt có trạng thái hỗ trợ là Unknown trên biểu đồ là 1,27%; cộng 1,27% vào 98,71% thì ra 99,97999… nên có vẻ bị ảnh hưởng bởi làm tròn. Vấn đề thật sự là các trình duyệt đó bị hiển thị là Unknown, và thực tế có lẽ có thể xem là chúng hỗ trợ phần tử ``.

    • Nhìn vào các chuỗi User-Agent “không thực sự xác định được là gì” xuất hiện trong log request của API SaaS bên tôi, có vẻ phần lớn trong số 1,27% “trình duyệt” đó nhiều khả năng là đủ loại scraper chuyên dụng vô tình đi lạc ngoài lĩnh vực chuyên môn của chúng. Vì vậy không thể chắc rằng chúng biết phân tích ``. Cũng có thể là scraper JSON.
    • wget được dùng khá nhiều, và nếu tính cả nó thì câu chuyện khác. Tôi kiểm tra src/html-url.c thì thực tế nó hoàn toàn không hỗ trợ `` mà xử lý như thẻ không xác định.

  • Tôi bị cuốn vào chuyện MDN trước đây là viết tắt của Mozilla Developer Network còn giờ chỉ là MDN, nên đã tìm thử, nhưng tôi cũng không tìm được tên đầy đủ.

    • Thay đổi đó diễn ra khoảng năm 2017. Tên Mozilla Developer Network hơi mơ hồ, và trong khảo sát cũng như phỏng vấn người dùng cũng có sự nhầm lẫn. Các lập trình viên web nghĩ đó là tài liệu chỉ dành cho lập trình viên Mozilla; ban đầu quả thật nó mang tính chất đó khá rõ, nên cũng không hẳn là sai hoàn toàn. Trong một thời gian, MDN có nhiều tài liệu liên quan đến Mozilla ngoài tài liệu nền tảng web, nhưng đến năm 2017, tài liệu nền tảng web đã chiếm 95% lưu lượng của MDN và tài liệu cho lập trình viên Mozilla không còn là bản sắc chính nữa. Vì vậy tên được đổi thành MDN Web Docs để thể hiện sự thay đổi trọng tâm.
    • Thay đổi này diễn ra vào khoảng ngày 15/8/2017. Tôi biết vì tình cờ thấy khoảnh khắc branding đã đổi nhưng nội dung trang thì chưa đổi. Báo cáo lỗi tôi gửi khi đó ở đây: https://bugzilla.mozilla.org/show_bug.cgi?id=1390381
    • Tôi thích gọi những thứ như vậy là anachronym. Nó có cảm giác như một kiểu chữ viết tắt lỗi thời. Nói nghiêm ngặt thì đây là initialism hơn là acronym, nhưng tôi cũng đã viết một bài liên quan. https://simpsonian.ca/blog/anachronyms/
    • Vẫn còn sót lại vài chỗ ở các trang phụ và mã ví dụ, nhưng tôi chỉ tìm được chừng này. “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...
    • Tôi nhớ vài năm trước tài liệu của Microsoft bắt đầu trỏ sang tài liệu Mozilla. Có thể đó là một phần của đợt rebrand Edge. Nếu trong quá trình thỏa thuận đó họ đổi tên thành MDN thì có thể là để tránh nhầm lẫn kiểu “đây là M(ozilla)DN hay M(icrosoft)DN?”, nhưng tôi không chắc.

  • Thú vị là tôi nghe nói các phần tử và cũng có đúng tỷ lệ hỗ trợ 97,34% như vậy. Hai phần tử này cũng dùng dữ liệu từ MDN giống phần tử ``: https://caniuse.com/mdn-html_elements_a và https://caniuse.com/mdn-html_elements_p Tôi đã cập nhật bài viết để phản ánh điều này.

  • Có lẽ CanIUse nên tách html-manifest thành một tính năng riêng. Và tôi cũng muốn nói lại rằng MDN thực sự là một tài nguyên tuyệt vời.

  • Trang web đầu tiên không dùng phần tử html. http://info.cern.ch/hypertext/WWW/TheProject.html

  • Chuyện này có liên quan đến HTML hợp lệ tối thiểu không? Trong đó không có thẻ HTML.

    • Có vẻ không liên quan lắm. `` cũng gần như ra cùng tỷ lệ: https://caniuse.com/mdn-html_elements_title Có vẻ vấn đề đúng hơn là cách tính các trình duyệt đã biết mức sử dụng nhưng chưa xác minh được trạng thái hỗ trợ. Nhân tiện, HTML đó thực ra không hợp lệ và được xử lý như tiêu đề rỗng, mà tiêu đề rỗng thì không hợp lệ. Đổi thành kiểu . thì có lẽ sẽ vượt qua mà không lỗi.
    • Nhưng chẳng phải trong đó vẫn có thẻ sao? Chỉ là không được viết tường minh nên được suy luận ra. Mở trang đó bằng bất kỳ trình duyệt nào thì nó cũng sẽ có thẻ.
    • Trong các giao thức có thể truyền tiêu đề theo cách khác, như header Subject của email, là tùy chọn. Vì vậy HTML hợp lệ ngắn nhất chỉ là một duy nhất, nhưng chỉ hợp lệ trong ngữ cảnh cụ thể.

  • Câu “nhiều dữ liệu của site đến từ MDN” hơi mơ hồ. Ma trận hỗ trợ tính năng được liên kết trên CanIUse đến từ kho browser-compat-data của MDN. Dữ liệu gốc của các phần tử HTML nằm ở đây: https://github.com/mdn/browser-compat-data/blob/main/html/el... Tuy nhiên ở đó không có thông tin về bài test và mức sử dụng mà CanIUse trích dẫn để tính tỷ lệ hỗ trợ; chỉ có phiên bản trình duyệt nào đã bao gồm tính năng nào. CanIUse cũng trỏ tới kho riêng của họ, nơi có rất nhiều dữ liệu: https://github.com/fyrd/caniuse Nhưng tôi không tìm được điểm vào nào để dễ dàng xác định các con số của một phần tử cụ thể đến từ đâu. Dữ liệu ở đó cũng có vẻ chủ yếu theo từng tính năng. Câu hỏi chính xác hơn là CanIUse lấy các bài test phần tử HTML và số liệu mức sử dụng từ đâu, và đó có vẻ là vấn đề cốt lõi.

  • Chẳng phải tỷ lệ hỗ trợ của phần tử `` ít nhất cũng phải thấp hơn hoặc bằng mọi phần tử khác sao?

    • Không. Phần tử không có nghĩa là “toàn bộ HTML”, mà chỉ là một phần tử khác mang nghĩa **phần tử gốc của tài liệu**. Như người khác đã viết, nó thực ra cũng không bắt buộc để tạo một tài liệu HTML hợp lệ không lỗi; khi đó thứ cần là và một phần thân hợp lệ. Ví von thì khả năng hiểu và phân tích đúng từ “English” trong tiêu đề một bài luận là chuyện tách biệt với việc biết nghĩa của từ tiếng Anh “fustigate”.

  • “Vì vậy không có câu trả lời rõ ràng. Nếu bạn biết thì hãy cho tôi biết!”