caniuse.com에서 html 요소가 100% 지원되지 않는 이유

 (anderegg.ca)
2P by GN⁺ | ★ favorite | 댓글 1개
  • CanIUse.com은 웹 기술 호환성을 추적하는 사이트인데, 기본 요소인 html의 지원률이 97.34% 로 표시돼 수치 해석에 의문이 생김
  • 이 지원률은 CanIUse.com이 활용하는 MDN 호환성 데이터와 연결돼 있으며, html 요소 페이지의 일부 하위 항목이 영향을 주는 것으로 보임
  • 문제의 항목은 선택적 manifest 속성과 secure context required로, 둘 다 표준화되지 않았거나 폐기된 항목임
  • 미지원·지원 여부 불명 브라우저와 오래된 브라우저 처리 방식이 섞이면서, html 같은 기본 요소에도 직관과 다른 지원률이 나타남
  • “% of all tracked” 기준에서는 support unknown을 더해 99.98% 로 볼 수 있어 반올림 오차 가능성이 커지지만, CanIUse.com 수치는 더 주의해서 읽을 필요가 있음

html 지원률 97.34%가 만든 의문

  • CanIUse.com은 웹 기술의 브라우저 채택률과 기능 호환성을 추적하고, 기능을 실제로 얼마나 쓸 수 있는지 수치로 보여줌
  • html 요소의 지원률은 97.34% 로 표시됨
    • 이는 audio 요소보다 낮은 수치임
    • a, p 요소도 같은 97.34% 지원률로 표시됨
  • 오래전부터 쓰인 웹의 기본 요소가 100%가 아니라는 점 때문에, 단순한 호환성 수치 이상의 확인이 필요해짐

MDN 호환성 표에서 보이는 하위 항목

  • CanIUse.com의 많은 데이터는 MDN에서 가져오는 것으로 보임
  • MDN의 html 요소 페이지에는 브라우저 호환성 섹션이 있음
  • 이 표에서 빨간 X가 많은 항목은 두 가지임
    • 선택적 manifest 속성
      • 폐기됨
      • 표준화된 적 없음
    • 관련 항목인 secure context required
  • 거의 모든 브라우저가 이 두 항목을 지원하지 않는 것은 맞지만, 이것만으로 html 요소 전체 지원률이 97.34% 까지 내려가는 이유가 명확해지지는 않음

오래된 브라우저와 반올림 오차 가능성

  • 일부 브라우저는 Support Unknown으로 표시되며, 이 브라우저들의 현재 사용량 합계는 1.27% 임
  • Android Browser 2.1–4.3은 html 요소를 지원하지 않는 것으로 표시되지만, 사용량 점유율은 0% 임
    • 이 오래된 브라우저들이 실제로 html 요소를 지원하지 않았다는 표시는 의심스러움
    • 반올림 오차가 1.27%를 2.66%까지 키울 수 있는지도 불명확함
  • CanIUse.com 우측 상단에서 “usage” 옆 기준을 “% of all tracked”로 바꾸고 “support unknown” 브라우저 수치를 더하면 99.98% 가 됨
    • 이 기준에서는 반올림 오차로 현재 수치가 나올 가능성을 더 쉽게 볼 수 있음
    • 다만 html 같은 기본 요소에서 오래된 브라우저를 처리하는 방식은 여전히 혼란스러움
  • CanIUse.com은 여전히 유용한 리소스지만, 표시되는 지원률은 맥락과 계산 기준을 함께 확인해야 함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • CanIUse에는 Global 비율 바로 위에 "% of all" 옵션이 있음. 기능 페이지의 톱니바퀴를 열어보면 사용량 계산 방식이 더 자세히 나옴
    기본값은 caniuse가 추적하지 않는 브라우저의 사용량을 모두 미지원으로 간주하는 All Users이고, All tracked users로 바꾸면 추적 대상 브라우저만 계산해서 98.71%가 됨
    차트에서 지원 여부가 Unknown인 브라우저들의 합은 1.27%인데, 98.71%에 1.27%를 더하면 99.97999…라서 반올림 영향이 있어 보임
    진짜 문제는 그 브라우저들이 Unknown으로 표시된다는 점이고, 실제로는 <html> 요소를 지원한다고 봐도 될 것 같음

    • 우리 API SaaS의 요청 로그에 찍히는, “딱히 무엇인지 식별되지 않는” User-Agent 문자열을 보면 1.27%의 “브라우저” 상당수는 자기 전문 영역을 벗어나 우연히 들어온 각종 특수 목적 스크래퍼일 가능성이 커 보임
      그래서 꼭 <html>을 파싱할 줄 안다고 볼 수는 없음. JSON 스크래퍼일 수도 있음
    • wget을 많이 쓰는데, 포함한다면 얘기는 다름. src/html-url.c를 확인해보니 실제로는 <html>을 전혀 지원하지 않고 알 수 없는 태그로 처리함

  • MDN이 예전에는 Mozilla Developer Network의 약자였는데 이제는 그냥 MDN이라는 점에 꽂혀서 찾아봤지만, 나도 전체 이름을 찾을 수 없었음

    • 그 변경은 2017년쯤 했음. Mozilla Developer Network라는 이름은 다소 애매했고, 설문과 사용자 인터뷰에서도 혼란이 있었음
      웹 개발자들은 Mozilla 개발자 전용 자료라고 생각했는데, 초기에는 실제로 그런 성격이 강했으니 완전히 틀린 것도 아니었음
      한동안 MDN에는 웹 플랫폼 문서 외에도 Mozilla 관련 문서가 많았지만, 2017년에는 웹 플랫폼 문서가 MDN 트래픽의 95%를 차지하게 됐고 더 이상 Mozilla 개발자를 위한 자료가 주된 정체성이 아니었음
      그래서 초점 변화가 드러나도록 이름을 MDN Web Docs로 바꾼 것임
    • 이 변경은 2017년 8월 15일쯤 일어났음. 브랜딩은 바뀌었는데 페이지 내용은 아직 안 바뀐 순간을 우연히 봐서 알고 있음
      그때 올린 버그 리포트가 여기 있음: https://bugzilla.mozilla.org/show_bug.cgi?id=1390381
    • 이런 걸 anachronym이라고 부르는 걸 좋아함. 시대착오적 약어 같은 느낌이라서임. 엄밀히 말하면 이건 두문자어라기보다 이니셜리즘이지만, 관련 글도 썼음
      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인가?” 같은 혼란을 피하려던 걸 수도 있겠지만, 확실히는 모르겠음

  • 흥미롭게도 <a>와 <p> 요소도 정확히 같은 97.34% 지원율을 보인다는 얘기를 들었음
    이 두 요소도 <html> 요소처럼 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 태그가 없음

    • 별 관련은 없어 보임. <title>도 거의 같은 비율로 나옴: https://caniuse.com/mdn-html_elements_title
      오히려 사용량은 알고 있지만 지원 여부를 검증하지 못한 브라우저를 어떻게 계산하느냐의 문제에 가까워 보임
      덧붙이면 그 HTML은 실제로는 유효하지 않고 빈 제목으로 처리되는데, 빈 제목은 유효하지 않음. . 같은 식으로 바꾸면 오류 없이 통과할 것임
    • 그래도 거기에는 <html> 태그가 있는 것 아닌가? 그냥 명시되지 않았을 뿐이라서 추론됨. 어떤 브라우저로 열어도 그 페이지에는 <html> 태그가 들어감
    • 이메일의 Subject 헤더처럼 제목을 다른 방식으로 전달할 수 있는 프로토콜 안에서는 <title>이 선택 사항임
      그래서 가장 짧은 유효 HTML은 그저 <html> 하나뿐이고, 다만 특정 문맥에서만 유효함

  • “사이트의 많은 데이터가 MDN에서 온다”는 말은 약간 애매함
    CanIUse에 연결된 기능 지원 행렬은 MDN의 browser-compat-data 저장소에서 옴. HTML 요소의 원본 데이터는 여기 있음: https://github.com/mdn/browser-compat-data/blob/main/html/el...
    다만 여기에는 CanIUse가 지원율 산정에 인용하는 테스트와 사용량 정보가 없고, 어떤 브라우저 버전이 어떤 기능을 포함했는지만 있음
    CanIUse도 자체 저장소를 가리키고 있고 거기에는 데이터가 많음: https://github.com/fyrd/caniuse
    하지만 특정 요소의 수치가 어디서 오는지 쉽게 찾을 수 있는 진입점은 못 찾겠음. 거기 데이터도 주로 기능 단위로 보임
    더 정확한 질문은 CanIUse가 HTML 요소 테스트와 사용량 수치를 어디서 가져오느냐이고, 그게 핵심 문제처럼 보임

  • <html> 요소의 지원율은 다른 어떤 요소보다도 최소한 낮거나 같아야 하는 것 아닌가?

    • 아님. <html> 요소가 “HTML 전체”를 의미하는 건 아니고, 그냥 문서의 루트 요소를 뜻하는 또 하나의 요소일 뿐임
      다른 사람이 적었듯이 오류 없는 유효 HTML 문서를 만들 때 실제로 꼭 필요한 것도 아니고, 그때 필요한 건 <title>과 유효한 본문 정도임
      비유하자면 에세이 제목에 있는 “English”라는 단어를 제대로 이해하고 파싱하는 능력은, 영어 단어인 “fustigate”의 뜻을 아는 것과 별개임

  • “그래서 명확한 답은 없다. 알고 있다면 알려 달라!”

답변달기