Chrome और Edge XSLT हटा रहे हैं: क्या टूटेगा और क्या नहीं

मूल लेख ↗ Hacker News चर्चा ↗

Chrome और Edge built‑in XSLT support को deprecate कर रहे हैं, जिससे XML-based sites, styled RSS/Atom feeds, और client-side transformations पर निर्भर niche workflows के टूटने की चिंता बढ़ गई है। हटाने के पक्षधर तर्क देते हैं कि XSLT का उपयोग बहुत कम होता है, इसे बनाए रखना जटिल है, और यह security तथा attack surface का गैर-तुच्छ स्रोत है, खासकर aging XML libraries को देखते हुए; जबकि दूसरे लोग एक शक्तिशाली, declarative templating tool और वेब के abandoned XML/XHTML vision के प्रतीक के खोने पर अफसोस जताते हैं। विकल्पों में server-side transforms, JavaScript या WebAssembly-based XSLT engines, या सरल CSS-based styling शामिल हैं, हालांकि कई लोगों को इसका कोई सच्चा like-for-like replacement नहीं दिखता।

बदलाव का दायरा

  • Chrome अंतर्निहित XSLT को deprecate और हटाने जा रहा है; Chromium fork होने के नाते Edge से भी यही अपेक्षा है कि वह इसका अनुसरण करेगा।
  • Firefox अभी भी काम करता है, लेकिन चेतावनियाँ दर्ज करता है और XSLT को “unship” करने का इरादा भी रखता है।
  • कुल प्रभाव: ब्राउज़र के अंदर XSLT समाप्त हो जाता है; server-side XSLT अप्रभावित रहता है।

हटाने के दिए गए कारण

  • पुरानी, बहुत कम उपयोग होने वाली सुविधा, जिसका attack surface बड़ा और जटिल है।
  • अंतर्निहित XML libraries पुरानी हैं, कम-रखरखाव वाली हैं, और उनमें vulnerabilities का इतिहास रहा है।
  • अरबों उपयोगकर्ताओं के लिए इस code को बनाए रखना महंगा माना जाता है।
  • कुछ लोग मानते हैं कि LLMs रखरखाव को सस्ता बना रहे हैं; दूसरे तर्क देते हैं कि वे exploits ढूँढ़ने की लागत भी घटाते हैं और security/maintenance लागतों को समाप्त नहीं करते।

संदेह और आलोचना

  • कुछ लोग इसे browser-monoculture व्यवहार के रूप में देखते हैं: vendors “बस चीज़ें हटा देते हैं क्योंकि वे परेशान नहीं होना चाहते।”
  • कुछ इसे Flash के पतन जैसी एक प्रवृत्ति के रूप में देखते हैं: असुविधाजनक तकनीक को हटाने के लिए एक security narrative बनाना।
  • अन्य लोग जवाब देते हैं कि अब लगभग कोई भी XSLT का उपयोग या रखरखाव नहीं करता और ongoing support की अपेक्षा करना अव्यावहारिक है।

प्रभाव और टूट-फूट

  • XML+XSLT-आधारित UIs (जैसे कुछ IIS reports, TEI/XML readers, styled RSS/Atom feeds, XSLT-आधारित blogs) Chromium-based browsers में टूटेंगे या खराब होंगे।
  • Chrome पहले से XSLT उपयोग पर एक प्रमुख चेतावनी दिखाता है।
  • XSLT का उपयोग करने वाली सरकारी और नियामक साइटों को जोखिम में बताया गया है (linked issues)।

विकल्प और migration paths

  • XSLT transformation server पर करें और plain HTML serve करें।
  • client-side XSLT processors के रूप में JS या WebAssembly-आधारित processors का उपयोग करें (हालाँकि wrapper code और examples अभी भी अपरिपक्व हैं)।
  • सीमाओं को स्वीकार करते हुए XML/RSS को सीधे CSS से style करें।
  • XSLT templating को JS-आधारित तकनीकों (जैसे, document.currentScript + DOM APIs) या अन्य templating engines से बदलें।

व्यापक XML/XHTML/XSLT बहस

  • कुछ लोग schemas, client-side templating, और अधिक साफ modularity वाले खोए हुए “XML/XHTML future” को याद करते हैं।
  • अन्य तर्क देते हैं कि XHTML/XML/XSLT के tooling खराब थे, सीखने की कठिनाई अधिक थी, syntax verbose था, और उन्हें कभी व्यापक adoption नहीं मिला।
  • Strict XML/XHTML बनाम forgiving HTML पर भारी बहस होती है; strictness को दोनों रूपों में देखा जाता है: एक लाभ (स्पष्ट त्रुटियाँ) और एक बाधा (भंगुर content)।