caniuse.com पर `html` एलिमेंट 100% समर्थित क्यों नहीं है

• CanIUse.com एक ऐसी साइट है जो web technology compatibility को ट्रैक करती है, लेकिन बुनियादी html एलिमेंट का support rate 97.34% दिखता है, जिससे इस संख्या की व्याख्या पर सवाल उठता है
• यह support rate CanIUse.com द्वारा उपयोग किए जाने वाले MDN compatibility data से जुड़ा हुआ है, और ऐसा लगता है कि html एलिमेंट पेज के कुछ sub-items इसका असर डालते हैं
• समस्या वाले items वैकल्पिक manifest attribute और secure context required हैं, और दोनों ही standardize नहीं हुए थे या deprecated हैं
• unsupported, support unknown browsers और पुराने browsers को संभालने के तरीके मिल जाने से html जैसे बुनियादी एलिमेंट में भी intuitive अपेक्षा से अलग support rate दिखाई देता है
• “% of all tracked” मानदंड में support unknown को जोड़ने पर इसे 99.98% माना जा सकता है, इसलिए rounding error की संभावना बढ़ जाती है, लेकिन CanIUse.com के आँकड़ों को फिर भी अधिक सावधानी से पढ़ने की ज़रूरत है

---

html के 97.34% support rate से उठे सवाल

• CanIUse.com web technologies की browser adoption rate और feature compatibility को ट्रैक करता है, और संख्याओं के ज़रिए दिखाता है कि कोई feature वास्तव में कितना इस्तेमाल किया जा सकता है
• html एलिमेंट का support rate 97.34% दिखाया गया है
  • यह audio एलिमेंट से भी कम है
  • a और p एलिमेंट भी इसी 97.34% support rate के साथ दिखते हैं
• वेब के बहुत पुराने और बुनियादी एलिमेंट्स का 100% न होना यह संकेत देता है कि केवल साधारण compatibility number से आगे जाकर देखना चाहिए

MDN compatibility table में दिखने वाले sub-items

• ऐसा लगता है कि CanIUse.com का बहुत सा data MDN से आता है
• MDN के html एलिमेंट पेज में browser compatibility section है
• इस table में जिन items पर लाल X ज़्यादा हैं, वे दो हैं
  • वैकल्पिक manifest attribute
    • deprecated है
    • कभी standardize नहीं हुआ
  • इससे जुड़ा secure context required item
    • Editor’s Draft स्थिति में है
    • यह अभी standardization track पर नहीं है
    • html एलिमेंट से जुड़ा इसका उपयोग भी कभी standardize नहीं हुआ और deprecated है
• लगभग सभी browsers इन दो items को support नहीं करते, यह सही है, लेकिन सिर्फ इससे पूरे html एलिमेंट का support rate 97.34% तक क्यों गिरता है, यह स्पष्ट नहीं होता

पुराने browsers और rounding error की संभावना

• कुछ browsers को Support Unknown के रूप में दिखाया जाता है, और इन browsers की मौजूदा कुल usage share 1.27% है
• Android Browser 2.1–4.3 को html एलिमेंट support न करने वाला दिखाया गया है, लेकिन इसकी usage share 0% है
  • इस बात पर संदेह होता है कि क्या ये पुराने browsers वास्तव में html एलिमेंट को support नहीं करते थे
  • यह भी स्पष्ट नहीं है कि rounding error 1.27% को 2.66% तक बढ़ा सकती है या नहीं
• CanIUse.com के ऊपर दाईं ओर “usage” के पास वाले मानदंड को “% of all tracked” में बदलकर और “support unknown” browser संख्या जोड़ने पर यह 99.98% हो जाता है
  • इस मानदंड में rounding error से मौजूदा संख्या आने की संभावना को अधिक आसानी से देखा जा सकता है
  • फिर भी html जैसे बुनियादी एलिमेंट्स में पुराने browsers को संभालने का तरीका अब भी उलझन पैदा करता है
• CanIUse.com अब भी एक उपयोगी resource है, लेकिन दिखाए गए support rate को उसके context और calculation basis के साथ ही देखना चाहिए

[GN⁺]

Hacker News की टिप्पणियाँ

• CanIUse में Global प्रतिशत के ठीक ऊपर "% of all" विकल्प होता है। फ़ीचर पेज के गियर आइकन को खोलने पर usage calculation का तरीका और विस्तार से दिखता है डिफ़ॉल्ट All Users है, जिसमें caniuse जिन browsers को track नहीं करता उनकी सारी usage को unsupported माना जाता है, और All tracked users पर बदलने से केवल tracked browsers गिने जाते हैं, जिससे 98.71% आता है चार्ट में जिन browsers का support status Unknown है, उनका कुल 1.27% है, और 98.71% में 1.27% जोड़ने पर 99.97999… बनता है, इसलिए rounding का असर लगता है असली समस्या यह है कि वे browsers Unknown दिखाए जाते हैं, और व्यवहार में संभवतः यह मान लेना ठीक होगा कि वे `` element को support करते हैं

  • हमारे API SaaS के request logs में दिखने वाले, “आख़िर यह है क्या” जैसे User-Agent strings को देखकर लगता है कि 1.27% “browsers” का बड़ा हिस्सा कई तरह के special-purpose scrapers हो सकते हैं जो संयोग से अपने सामान्य क्षेत्र से बाहर निकलकर आ गए हों इसलिए यह ज़रूरी नहीं कि वे `` को parse करना जानते हों। वे JSON scrapers भी हो सकते हैं
  • मैं wget काफ़ी इस्तेमाल करता हूँ, और अगर उसे शामिल करें तो बात अलग है। src/html-url.c देखने पर पता चलता है कि यह वास्तव में `` को बिल्कुल support नहीं करता और उसे unknown tag की तरह treat करता है

• MDN पहले Mozilla Developer Network का संक्षेप था, लेकिन अब बस MDN ही है—यह देखकर मैंने खोजा, पर मुझे भी पूरा नाम नहीं मिला

  • यह बदलाव लगभग 2017 में किया गया था। Mozilla Developer Network नाम थोड़ा अस्पष्ट था, और surveys व user interviews में भी भ्रम सामने आया था web developers को लगता था कि यह केवल Mozilla developers के लिए resources हैं, और शुरुआत में इसकी प्रकृति वास्तव में कुछ हद तक ऐसी ही थी, इसलिए यह पूरी तरह ग़लत भी नहीं था काफ़ी समय तक MDN में web platform docs के अलावा Mozilla-संबंधित docs भी बहुत थे, लेकिन 2017 तक web platform docs, MDN traffic का 95% हिस्सा बन चुके थे और यह अब मुख्य रूप से Mozilla developers के लिए resource नहीं रह गया था इसलिए focus में आए बदलाव को दिखाने के लिए नाम बदलकर MDN Web Docs कर दिया गया
  • यह बदलाव लगभग 15 अगस्त 2017 के आसपास हुआ था। मुझे यह इसलिए पता है क्योंकि मैंने संयोग से वह पल देखा था जब branding बदल चुकी थी लेकिन page content अभी नहीं बदला था उस समय दर्ज की गई bug report यहाँ है: https://bugzilla.mozilla.org/show_bug.cgi?id=1390381
  • मुझे इसे anachronym कहना पसंद है। मतलब कुछ वैसा जैसे काल-बाह्य संक्षेप। तकनीकी रूप से यह acronym से ज़्यादा initialism है, लेकिन मैंने इस पर एक लेख भी लिखा है https://simpsonian.ca/blog/anachronyms/
  • कुछ जगहें side pages और example code में अभी भी बची हुई हैं, लेकिन मुझे बस इतना ही मिला “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 docs ने Mozilla docs की ओर इशारा करना शुरू किया था। शायद यह Edge rebranding का हिस्सा रहा हो अगर नाम बदलकर MDN करने का फ़ैसला उसी सहमति-प्रक्रिया के दौरान हुआ हो, तो शायद वे “यह M(ozilla)DN है या M(icrosoft)DN?” जैसी उलझन से बचना चाहते थे, लेकिन पक्का नहीं कह सकता

• दिलचस्प बात यह है कि मैंने सुना है और elements भी बिल्कुल वही 97.34% support rate दिखाते हैं ये दोनों elements भी `` element की तरह MDN से आए data का उपयोग करते हैं: https://caniuse.com/mdn-html_elements_a तथा https://caniuse.com/mdn-html_elements_p मैंने यह बात लेख में जोड़कर उसे update कर दिया है

• CanIUse में html-manifest को एक अलग feature के रूप में अलग करना अच्छा हो सकता है और मैं यह भी दोबारा कहना चाहता हूँ कि MDN वाकई शानदार resource है

• पहली web page में html element का उपयोग नहीं हुआ था http://info.cern.ch/hypertext/WWW/TheProject.html

• क्या इसका संबंध minimal valid HTML से है? उसमें HTML tag नहीं है

  • ज़्यादा संबंध नहीं लगता। `` भी लगभग वही प्रतिशत दिखाता है: https://caniuse.com/mdn-html_elements_title बल्कि यह ज़्यादा इस बात का मामला लगता है कि जिन browsers की usage तो ज्ञात है लेकिन जिनके support status को verify नहीं किया जा सका, उन्हें कैसे गिना जाए और जोड़ दूँ कि वह HTML वास्तव में valid नहीं है और उसे empty title की तरह माना जाता है, जबकि empty title valid नहीं होता। उसे . जैसा कुछ कर दिया जाए तो वह बिना error के pass हो जाएगा
  • फिर भी उसमें tag तो है, है न? बस उसे explicitly नहीं लिखा गया, इसलिए infer किया जाता है। किसी भी browser में खोलो, उस page में tag शामिल हो जाता है
  • ईमेल के Subject header की तरह, ऐसे protocols में जहाँ title किसी दूसरे तरीके से दिया जा सकता है, optional होता है इसलिए सबसे छोटा valid HTML केवल ही है, हालाँकि वह सिर्फ़ कुछ विशेष contexts में ही valid होगा

• “site का बहुत सा data MDN से आता है” यह बात थोड़ी अस्पष्ट है CanIUse से जुड़े feature support matrices, MDN के browser-compat-data repository से आते हैं। HTML elements का source data यहाँ है: https://github.com/mdn/browser-compat-data/blob/main/html/el... लेकिन इसमें वे tests और usage information नहीं हैं जिन्हें CanIUse support rate निकालने के लिए cite करता है; इसमें केवल यह होता है कि किस browser version में कौन-सा feature शामिल था CanIUse अपनी repository की ओर भी इशारा करता है और वहाँ भी बहुत data है: https://github.com/fyrd/caniuse लेकिन किसी विशेष element के numbers कहाँ से आते हैं, इसका कोई आसान entry point मुझे नहीं मिला। वहाँ का data भी मुख्य रूप से feature unit के हिसाब से दिखता है ज़्यादा सटीक सवाल यह है कि CanIUse HTML element tests और usage figures कहाँ से लाता है, और यही मूल मुद्दा लगता है

• क्या `` element का support rate किसी भी दूसरे element से कम-से-कम कम या बराबर नहीं होना चाहिए?

  • नहीं। element “पूरे HTML” का मतलब नहीं है; यह सिर्फ़ **document का root element** है, यानी एक और element जैसा किसी और ने लिखा, error-free valid HTML document बनाने के लिए भी यह वास्तव में अनिवार्य नहीं है; उस स्थिति में ज़रूरत और valid body जैसी चीज़ों की होती है तुलना के लिए, किसी essay title में मौजूद “English” शब्द को सही तरह समझने और parse करने की क्षमता, अंग्रेज़ी शब्द “fustigate” का अर्थ जानने से अलग बात है

• “तो स्पष्ट जवाब नहीं है। अगर आपको पता हो तो बताइए!”

  • मज़ेदार व्याख्या देनी हो तो कहा जा सकता है कि Android का secret browser[1] ही इस untrackable लगने वाली anomaly को बना रहा है :-) [1] https://news.ycombinator.com/item?id=39226754