पब्लिश की गई तारीख: 29 अक्टूबर, 2025
Chrome, XSLT को ब्राउज़र से हटाने और इसका इस्तेमाल बंद करने की तैयारी कर रहा है. इस दस्तावेज़ में, साल 2026 के आखिर में XSLT को हटाने से पहले, अपने कोड को माइग्रेट करने का तरीका बताया गया है.
Chromium ने आधिकारिक तौर पर XSLT को बंद कर दिया है. इसमें XSLTProcessor JavaScript API और XSLT प्रोसेसिंग का निर्देश शामिल है. हम वर्शन 158 (17 नवंबर, 2026) से XSLT के लिए सहायता बंद करने की तैयारी कर रहे हैं. The Firefox और WebKit प्रोजेक्ट ने भी अपने ब्राउज़र इंजन से XSLT को हटाने की योजना बनाई है. इस दस्तावेज़ में, XSLT के इतिहास और संदर्भ के बारे में बताया गया है. साथ ही, यह भी बताया गया है कि Chrome को ज़्यादा सुरक्षित बनाने के लिए, हम XSLT को कैसे हटा रहे हैं. इसके अलावा, इसमें ब्राउज़र से इन सुविधाओं को हटाने से पहले, माइग्रेट करने का तरीका भी बताया गया है. अपडेट की गई जानकारी के लिए, Chrome Platform Status की एंट्री भी देखें.
क्या हटाया जा रहा है?
ब्राउज़र में XSLT को लागू करने वाले दो एपीआई हैं. इन दोनों को हटाया जा रहा है:
-
XSLTProcessor
क्लास. उदाहरण के लिए,
new XSLTProcessor(). - XSLT प्रोसेसिंग का निर्देश. उदाहरण के लिए,
<?xml-stylesheet type="text/xsl" ... ?>.
Chrome के लिए टाइमलाइन
Chrome के लिए यह प्लान है:
- Chrome 142 (28 अक्टूबर, 2025): Chrome में, शुरुआती चेतावनी वाले कंसोल मैसेज जोड़े गए हैं.
- Chrome 143 (2 दिसंबर, 2025): एपीआई को आधिकारिक तौर पर बंद किया गया है. कंसोल और Lighthouse में, एपीआई को बंद करने की चेतावनी वाले मैसेज दिखने शुरू हो गए हैं.
- Chrome 145 (2 दिसंबर, 2025 Canary): Canary, Dev, और Beta वर्शन में, XSLT को डिफ़ॉल्ट रूप से बंद किया गया है. यह शुरुआती चेतावनी के तौर पर किया गया है.
- Chrome 146 (10 मार्च, 2026): Enterprise Policy (ईपी) को टेस्टिंग के लिए उपलब्ध कराया गया है. इससे कंपनियां, XSLT को बंद करने की सुविधा की पहले से ही टेस्टिंग कर सकती हैं. साथ ही, वे XSLT को हटाने की तारीख के बाद भी, इसकी सुविधाओं का इस्तेमाल जारी रख सकती हैं.
- Chrome 152 (25 अगस्त, 2026): Origin Trial (ओटी) को टेस्टिंग के लिए उपलब्ध कराया गया है. इससे साइटें, XSLT को हटाने की तारीख के बाद भी, इसकी सुविधाओं का इस्तेमाल जारी रख सकती हैं.
- Chrome 158 (17 नवंबर, 2026): Origin Trial और Enterprise Policy में हिस्सा लेने वाले लोगों को छोड़कर, सभी उपयोगकर्ताओं के लिए स्टेबल वर्शन में XSLT काम करना बंद कर देगा.
- Chrome 176 (17 अगस्त, 2027): Origin Trial और Enterprise Policy काम करना बंद कर देंगी. सभी उपयोगकर्ताओं के लिए XSLT बंद रहेगा.
XSLT क्या है?
XSLT, यानी कि Extensible Stylesheet Language Transformations, एक ऐसी भाषा है जिसका इस्तेमाल एक्सएमएल दस्तावेज़ों को ट्रांसफ़ॉर्म करने के लिए किया जाता है. आम तौर पर, इन्हें एचटीएमएल जैसे अन्य फ़ॉर्मैट में बदला जाता है. यह भाषा, इस कन्वर्ज़न के लिए नियम तय करने के लिए, XSLT स्टाइलशीट फ़ाइल का इस्तेमाल करती है. साथ ही, इसमें इनपुट के तौर पर इस्तेमाल किया जाने वाला डेटा, एक्सएमएल फ़ाइल में मौजूद होता है.
ब्राउज़र में, जब कोई ऐसी एक्सएमएल फ़ाइल मिलती है जो XSLT स्टाइलशीट से लिंक होती है, तो ब्राउज़र उस स्टाइलशीट में मौजूद नियमों का इस्तेमाल करके, रॉ एक्सएमएल डेटा को फिर से व्यवस्थित करता है, उसे फ़ॉर्मैट करता है, और उसे एक स्ट्रक्चर्ड पेज (अक्सर एचटीएमएल) में बदलता है. इस पेज को उपयोगकर्ता के लिए रेंडर किया जा सकता है.
उदाहरण के लिए, XSLT स्टाइलशीट, इस एक्सएमएल इनपुट को ले सकती है:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl" ?>
<page>
<message>
Hello World.
</message>
</page>
और इस एक्सएसएल स्टाइलशीट को:
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="html"/>
<xsl:template match="/page/message">
<body>
<p>Message: <xsl:value-of select="."/></p>
</body>
</xsl:template>
</xsl:stylesheet>
इसके बाद, ब्राउज़र में दिखाने के लिए, इन्हें इस एचटीएमएल में प्रोसेस किया जा सकता है: एचटीएमएल
<body>
<p>Message: Hello World.</p>
</body>
पिछले उदाहरण में दिखाए गए XSL प्रोसेसिंग के निर्देश के अलावा, XSLTProcessor JavaScript API भी है. इसका इस्तेमाल, स्थानीय एक्सएमएल दस्तावेज़ों को स्थानीय XSLT स्टाइलशीट के साथ प्रोसेस करने के लिए किया जा सकता है.
XSLT का इतिहास
वर्ल्ड वाइड वेब कंसोर्शियम (W3C) ने 16 नवंबर, 1999 को XSLT को, एक्सएमएल दस्तावेज़ों को अन्य फ़ॉर्मैट में ट्रांसफ़ॉर्म करने के लिए एक भाषा के तौर पर इस्तेमाल करने का सुझाव दिया था. आम तौर पर, इसे वेब ब्राउज़र में दिखाने के लिए एचटीएमएल में बदला जाता है. आधिकारिक तौर पर वर्शन 1.0 का सुझाव दिए जाने से पहले, Microsoft ने एक शुरुआती पहल की थी. इसके तहत, मार्च 1999 में रिलीज़ हुए Internet Explorer 5.0 में, W3C के वर्किंग ड्राफ़्ट पर आधारित मालिकाना हक वाला इंप्लीमेंटेशन शिप किया गया था. आधिकारिक स्टैंडर्ड के बाद, Mozilla ने साल 2000 के आखिर में Netscape 6 में, XSLT 1.0 के लिए नेटिव सपोर्ट लागू किया था. Safari, Opera, और बाद में Chrome जैसे अन्य मुख्य ब्राउज़र में भी, XSLT 1.0 के नेटिव प्रोसेसर शामिल किए गए थे. इससे, साल 2000 की शुरुआत में, क्लाइंट-साइड एक्सएमएल-टू-एचटीएमएल ट्रांसफ़ॉर्मेशन, वेब टेक्नोलॉजी के तौर पर इस्तेमाल किया जाने लगा था.
XSLT भाषा में लगातार सुधार होते रहे. साल 2007 में XSLT 2.0 और साल 2017 में XSLT 3.0 रिलीज़ हुआ. इनमें रेगुलर एक्सप्रेशन, बेहतर डेटा टाइप, और JSON को प्रोसेस करने की क्षमता जैसी दमदार सुविधाएं जोड़ी गईं. हालांकि, ब्राउज़र के सपोर्ट में कोई सुधार नहीं हुआ. आज, सभी मुख्य वेब ब्राउज़र इंजन, साल 1999 के ओरिजनल XSLT 1.0 के लिए ही नेटिव सपोर्ट देते हैं. कोई तकनीकी सुधार न होने के साथ-साथ, वायर फ़ॉर्मैट के तौर पर JSON का इस्तेमाल बढ़ने से क्लाइंट-साइड XSLT का इस्तेमाल काफ़ी कम हो गया है. इसके अलावा, JavaScript लाइब्रेरी और फ़्रेमवर्क (जैसे, jQuery, React, और Vue.js) के बढ़ने से, DOM को ज़्यादा आसानी से और बेहतर तरीके से मैनेज किया जा सकता है. साथ ही, टेंप्लेटिंग भी बेहतर तरीके से की जा सकती है. वेब ब्राउज़र में XSLT की जगह अब काफ़ी हद तक JavaScript पर आधारित टेक्नोलॉजी ने ले ली है.
XSLT को क्यों हटाया जा रहा है?
वेब ब्राउज़र में XSLT 1.0 को शामिल रखने से, सुरक्षा से जुड़ा एक बड़ा और गैर-ज़रूरी जोखिम बना रहता है. इन ट्रांसफ़ॉर्मेशन को प्रोसेस करने वाली लाइब्रेरी, जैसे कि libxslt (Chromium ब्राउज़र में इस्तेमाल की जाती है), C/C++ के पुराने और जटिल कोडबेस हैं. इस तरह के कोड में, मेमोरी की सुरक्षा से जुड़े जोखिमों की आशंका ज़्यादा होती है. जैसे, बफ़र ओवरफ़्लो. इसकी वजह से, आर्बिट्रेरी कोड एक्ज़ीक्यूट हो सकता है. उदाहरण के लिए, सुरक्षा ऑडिट और बग ट्रैकर ने इन पार्सर में, बार-बार सुरक्षा से जुड़े गंभीर जोखिमों की पहचान की है.जैसे, CVE-2025-7425 और CVE-2022-22834. ये दोनों जोखिम, libxslt में मौजूद हैं. क्लाइंट-साइड XSLT अब एक ऐसी खास सुविधा है जिसका इस्तेमाल बहुत कम किया जाता है. इसलिए, इन लाइब्रेरी का रखरखाव और सुरक्षा की जांच, कोर JavaScript इंजन की तुलना में बहुत कम की जाती है. हालांकि, ये लाइब्रेरी गैर-भरोसेमंद वेब कॉन्टेंट को प्रोसेस करके अटैक करने के प्लैटफ़ॉर्म के तौर पर काम कर सकती हैं. दरअसल, हाल ही में हुए कई बड़े सुरक्षा हमलों की मुख्य वजह XSLT ही है, जिसके चलते ब्राउज़र इस्तेमाल करने वाले लोगों के लिए यह लगातार खतरा बना हुआ है. इस पुरानी और कमज़ोर सुविधा को बनाए रखने से सुरक्षा से जुड़े जो जोखिम होते हैं, वे इसकी सीमित आधुनिक उपयोगिता से कहीं ज़्यादा हैं.
इसके अलावा, क्लाइंट-साइड XSLT का मूल मकसद—डेटा को रेंडर किए जा सकने वाले एचटीएमएल में बदलना—अब JavaScript API की मदद से पूरा किया जा सकता है. ये API, ज़्यादा सुरक्षित, ज़्यादा आसान, और बेहतर तरीके से मेंटेन किए जाते हैं. मॉडर्न वेब डेवलपमेंट में, डेटा (आम तौर पर JSON) को पाने के लिए Fetch API और एक्सएमएल या एचटीएमएल स्ट्रिंग को ब्राउज़र के सुरक्षित JavaScript सैंडबॉक्स में, DOM स्ट्रक्चर में सुरक्षित तरीके से पार्स करने के लिए DOMParser API जैसी चीज़ों का इस्तेमाल किया जाता है. इसके बाद, React, Vue, और Svelte जैसे फ़्रेमवर्क, इस डेटा को असरदार और सुरक्षित तरीके से रेंडर करते हैं. इस मॉडर्न टूलचेन को ऐक्टिव तौर पर डेवलप किया जाता है. साथ ही, इसे JavaScript इंजन में सुरक्षा के लिए किए गए बड़े निवेश का फ़ायदा मिलता है. आज, लगभग सभी वेब डेवलपर इसका इस्तेमाल करते हैं. आज, वेब पेज लोड होने के करीब 0.02% मामलों में ही XSLT का इस्तेमाल किया जाता है. वहीं, XSLT प्रोसेसिंग के निर्देशों का इस्तेमाल, 0.001% से भी कम मामलों में किया जाता है.
यह कार्रवाई सिर्फ़ Chrome या Chromium के लिए नहीं है. अन्य दो मुख्य ब्राउज़र इंजन भी वेब प्लैटफ़ॉर्म से XSLT को हटाने की सुविधा देते हैं: WebKit, Gecko.
इन वजहों से, XSLT को बंद करने और हटाने से, सभी उपयोगकर्ताओं के लिए ब्राउज़र के अटैक सरफेस को कम किया जा सकता है. साथ ही, वेब प्लैटफ़ॉर्म को आसान बनाया जा सकता है. इसके अलावा, इंजीनियरिंग के संसाधनों को उन टेक्नोलॉजी को सुरक्षित करने पर फ़ोकस किया जा सकता है जो मॉडर्न वेब को असल में पावर देती हैं. इससे डेवलपर को क्षमताओं का कोई नुकसान नहीं होता.
एक्सएमएल पार्सिंग की सुरक्षा को बेहतर बनाना
हाल ही में, libxml2 में सुरक्षा से जुड़ी गंभीर समस्याओं की शिकायतें मिली हैं. libxml2 का इस्तेमाल, Chromium में एक्सएमएल को पार्स करने, क्रम से लगाने, और उसकी फ़ॉर्मैटिंग की जांच करने के लिए किया जाता है. libxml2 में सुरक्षा से जुड़ी गंभीर समस्याएं, libxslt में सुरक्षा से जुड़ी गंभीर समस्याओं जैसी ही हैं. Chromium में एक्सएमएल पार्सिंग से जुड़ी सुरक्षा की समस्याओं को हल करने के लिए, हमारा प्लान libxml2 के इस्तेमाल को धीरे-धीरे बंद करने का है. साथ ही, एक्सएमएल पार्सिंग को रस्ट में लिखी गई, मेमोरी-सेफ़ एक्सएमएल पार्सिंग लाइब्रेरी से बदलने का है. अहम बात यह है कि हम ब्राउज़र से एक्सएमएल को नहीं हटाएंगे. फ़िलहाल, सिर्फ़ XSLT को हटाने पर विचार किया जा रहा है. हम यह पक्का करना चाहते हैं कि libxml2 को बदलने की प्रोसेस, वेब डेवलपर के लिए पूरी तरह से पारदर्शी हो.
एक्सएमएल + सीएसएस को नहीं हटाया जा रहा है
XSLT
(<?xml-stylesheet type="text/xsl" ... ?>) को बंद करने और
<?xml-stylesheet ... ?> प्रोसेसिंग के निर्देश के बीच अंतर करना ज़रूरी है. सीएसएस के साथ इस्तेमाल करने पर, यह निर्देश अब भी काम करता है. आपके पास अब भी प्रोसेसिंग के निर्देश का इस्तेमाल करकेtype="text/css", अपने रॉ डेटा पर स्टैंडर्ड लेआउट और डिज़ाइन के नियम लागू करने का विकल्प है,
ठीक वैसे ही जैसे एचटीएमएल के साथ किया जा सकता है. उदाहरण के लिए:
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/css" href="styles.css"?>
<root>
<item>Content here</item>
</root>
माइग्रेट करने का तरीका
माइग्रेट करने के कुछ अन्य तरीके भी हैं.
JSON
ऐसी साइटों के लिए, जो पूरी तरह से एक्सएमएल और एक्सएसएल पर बनी हैं, ट्रांज़िशन करने का कोई एक तरीका नहीं है. माइग्रेशन के विकल्पों में, XSLT प्रोसेसिंग पाइपलाइन को सर्वर साइड पर ले जाना और रेंडर किए गए एचटीएमएल को क्लाइंट को भेजना शामिल है. इसके अलावा, सर्वर-साइड एक्सएमएल एपीआई एंडपॉइंट को JSON पर माइग्रेट करना और JavaScript का इस्तेमाल करके क्लाइंट-साइड रेंडरिंग करना भी शामिल है, ताकि JSON को एचटीएमएल DOM और सीएसएस में बदला जा सके.
JavaScript में क्लाइंट-साइड XSLT
क्लाइंट-साइड (JavaScript पर आधारित) XSLT की कुछ लाइब्रेरी उपलब्ध हैं. हालांकि, Saxonica की लाइब्रेरी सबसे बड़ी है. Saxonica के बारे में पूरी जानकारी के लिए, यह दस्तावेज़ देखें. यह इंप्लीमेंटेशन, वेब ब्राउज़र में XSLT 1.0 के इंप्लीमेंटेशन से कहीं ज़्यादा है. इसमें, v3.0 के नए स्टैंडर्ड के लिए पूरा सपोर्ट दिया गया है. साथ ही, इसमें v4.0 के स्टैंडर्ड के लिए भी सपोर्ट दिया जाएगा. यह स्टैंडर्ड, फ़िलहाल डेवलपमेंट के प्रोसेस में है.
polyfill
एक polyfill उपलब्ध है. इसकी मदद से, मौजूदा कोड को काम करने की अनुमति दी जा सकती है. यह कोड, वेब ब्राउज़र में XSLT 1.0 के इंप्लीमेंटेशन पर निर्भर करता है. हालांकि, यह ब्राउज़र की XSLT की नेटिव सुविधाओं का इस्तेमाल नहीं करता. यह polyfill, GitHub पर मौजूद है.
इस polyfill में, XSLTProcessor क्लास के लिए WASM पर आधारित polyfilled रिप्लेसमेंट शामिल है. इसलिए, मौजूदा JavaScript कोड, बिना किसी बदलाव के काम कर सकता है:
<script src="xslt-polyfill.min.js"></script>
<script>
const xsltProcessor = new XSLTProcessor();
xsltProcessor.importStylesheet(xsltDoc);
const fragment = xsltProcessor.transformToFragment(xmlDoc, document);
</script>
इस polyfill में, एक्सएमएल दस्तावेज़ों को बदलने के लिए, एक ऑटोमैटिक यूटिलिटी फ़ंक्शन भी दिया गया है. इन दस्तावेज़ों में, XSLT प्रोसेसिंग के निर्देशों का इस्तेमाल किया जाता है:
उदाहरण के लिए, demo.xml की ओरिजनल फ़ाइल ऐसी हो सकती है:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl"?>
<ROOT>
...content...
polyfill को इस्तेमाल करने और रेफ़रंस वाली XSLT स्टाइलशीट की मदद से दस्तावेज़ को ट्रांसफ़ॉर्म करने के लिए, एक लाइन जोड़ी जा सकती है:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl"?>
<ROOT>
<script src="xslt-polyfill.min.js"
xmlns="http://www.w3.org/1999/xhtml"></script>
...content...
इस मामले में, नया <script> एलिमेंट polyfill को लोड करता है. यह
एक्सएमएल दस्तावेज़ के टाइप और XSLT प्रोसेसिंग के निर्देश का पता लगाता है. इसके बाद, यह दस्तावेज़ को बदलकर, उसे पारदर्शी तरीके से लोड करता है.
Extension
Chrome का एक एक्सटेंशन भी है. इसे साथ काम करने वाले ब्राउज़र में जोड़ा जा सकता है. यह एक्सटेंशन, XSLT प्रोसेसिंग के निर्देशों या XSLTProcessor के कॉल वाले सभी रॉ एक्सएमएल पेजों पर, XSLT polyfill को लागू करेगा. इसका इस्तेमाल उन ऐप्लिकेशन के लिए किया जा सकता है जिनमें सोर्स एक्सएमएल या XSLT में बदलाव नहीं किया जा सकता, ताकि उनकी सुविधाओं को बनाए रखा जा सके.
खास तौर पर, XSLT के बंद होने पर, Chrome अब एक चेतावनी वाला बैनर दिखाता है. यह बैनर, सीधे एक्सटेंशन के खोज वाले पेज से लिंक होता है, ताकि उपयोगकर्ताओं को एक्सटेंशन ढूंढने में मदद मिल सके:
इस्तेमाल के खास उदाहरण
एचटीएमएल स्टैंडर्ड कीचर्चा में, इस्तेमाल के कई उदाहरणों की पहचान की गई इस सेक्शन में, इनमें से हर उदाहरण के बारे में बताया गया है, ताकि आज XSLT का इस्तेमाल करने वाले एक्सएमएल संसाधन पब्लिश करने वाले डेवलपर को, आगे बढ़ने के लिए सुझाव दिए जा सकें.
आरएसएस और ऐटम फ़ीड
मौजूदा कई आरएसएस या ऐटम फ़ीड में, XSLT का इस्तेमाल रॉ एक्सएमएल फ़ीड को ब्राउज़र में सीधे देखने पर, लोगों के पढ़ने लायक बनाने के लिए किया जाता है. इसका मुख्य उदाहरण यह है कि जब कोई उपयोगकर्ता, किसी साइट के आरएसएस फ़ीड के लिंक पर गलती से क्लिक करता है, तो उसे रॉ एक्सएमएल के बजाय, फ़ॉर्मैट किया गया एचटीएमएल जवाब मिलता है. इस जवाब को वह पढ़ सकता है. ऐसा तब होता है, जब उपयोगकर्ता उस लिंक को अपने आरएसएस रीडर में चिपकाने के बजाय, सीधे उस पर क्लिक कर देता है.
इस उदाहरण के लिए, आगे बढ़ने के दो तरीके हैं. इसे एचटीएमएल के "स्टैंडर्ड" तरीके से करने के लिए,
(एचटीएमएल पर आधारित) साइट में <link rel="alternate" type="application/rss+xml"> जोड़ा जाता है. इसके बजाय, ऐसा <a
href="something.xml"> न जोड़ें जिस पर उपयोगकर्ता गलती से क्लिक कर सकते हैं. यह लिंक, उपयोगकर्ताओं को साफ़ तौर पर दिखता है. इस समाधान से, आरएसएस रीडर को फ़ीड ढूंढने में मदद मिलती है. ऐसा तब होता है, जब कोई उपयोगकर्ता सिर्फ़ वेबसाइट का यूआरएल चिपकाता है. साथ ही, इससे लोगों को सामान्य एचटीएमएल कॉन्टेंट देखने में मदद मिलती है. उन्हें एक्सएमएल संसाधन के लिंक से कोई भ्रम नहीं होता. यह वेब के सामान्य पैराडाइम को भी फ़ॉलो करता है. इसके मुताबिक, एचटीएमएल लोगों के लिए होता है और एक्सएमएल, मशीनों के लिए. ज़ाहिर है, इससे उस मामले में मदद नहीं मिलती जहां किसी उपयोगकर्ता के पास कहीं से आरएसएस लिंक है और वह उसे अपने आरएसएस रीडर के बजाय, वेब ब्राउज़र में चिपका देता है.
जब यह समाधान काम का नहीं होता, तो polyfill एक और तरीका उपलब्ध कराता है. जैसा कि पहले बताया गया है, आरएसएस/ऐटम एक्सएमएल फ़ीड में एक लाइन, <script
src="xslt-polyfill.min.js" xmlns="http://www.w3.org/1999/xhtml"></script> जोड़ी जा सकती है. इससे, एचटीएमएल में XSLT पर आधारित मौजूदा ट्रांसफ़ॉर्मेशन का व्यवहार बना रहेगा.
इससे, आरएसएस रीडर की एक्सएमएल को पार्स करने की क्षमता पर कोई असर नहीं पड़ना चाहिए, क्योंकि
<script> रूट एलिमेंट का डायरेक्ट चाइल्ड है.
एम्बेड किए गए डिवाइसों के लिए एपीआई आउटपुट
कुछ कमर्शियल एम्बेड किए गए डिवाइस, लोकल नेटवर्क पर उपयोगकर्ताओं के लिए एक्सएमएल डेटा को मेज़र करते हैं या जनरेट करते हैं. इनमें से कुछ डिवाइस, एक्सएमएल डेटा का एक डेटा फ़ीड जनरेट करके ऐसा करते हैं. यह फ़ीड, XSLT का इस्तेमाल करके, इसे लोगों के पढ़ने लायक एचटीएमएल फ़ॉर्मैट में बदलता है. इससे, एपीआई को ब्राउज़र में सीधे देखा जा सकता है. इसके लिए, डिवाइस या ब्राउज़र में कोई अतिरिक्त कोड जोड़ने की ज़रूरत नहीं होती.
यह इस्तेमाल का एक ऐसा उदाहरण है जो किसी खास ऐप्लिकेशन के लिए ही होता है. इसलिए, समाधान का फ़ॉर्मैट अलग-अलग हो सकता है. ऐसे ऐप्लिकेशन के लिए, जिनमें एम्बेड किए गए डिवाइस के सोर्स कोड को अपडेट किया जा सकता है, पहले बताए गए कोई भी विकल्प (JSON, Polyfill) काम कर सकते हैं. हालांकि, कई वजहों से, ऐसे कई डिवाइसों को अपडेट करना मुश्किल या नामुमकिन होता है. ऐसे में,
एक्सटेंशन
सबसे अच्छा विकल्प हो सकता है, क्योंकि इससे क्लाइंट ब्राउज़र, डिवाइस में बदलाव किए बिना, डेटा को ठीक उसी तरह से पढ़ सकते हैं.
वेबसाइटों के लिए लेज़ी टेंप्लेटिंग
वेब डेवलपर, कभी-कभी क्लाइंट साइड पर XSLT का इस्तेमाल करके, सिमेंटिक मार्कअप पर प्रज़ेंटेशन मार्कअप लागू करते हैं. यह JavaScript इकोसिस्टम से अलग, लेज़ी टेंप्लेटिंग लैंग्वेज के तौर पर काम करता है.
इस सामान्य समस्या के दो समाधान हैं. इस तरीके से बनी किसी मौजूदा साइट के लिए, सबसे आसान समाधान शायद मौजूदा सुविधाओं को बनाए रखने के लिए, polyfill को जोड़ना है. इसके अलावा, XSLT ट्रांसफ़ॉर्मेशन को सर्वर साइड पर किया जा सकता है. साथ ही, रॉ एक्सएमएल के बजाय, क्लाइंट को एचटीएमएल भेजा जा सकता है. ऐसी प्रॉपर्टी के लिए, ज़्यादा समय तक चलने वाला समाधान यह होगा कि उन्हें JavaScript या JSON पर आधारित किसी मॉडर्न फ़्रेमवर्क पर माइग्रेट किया जाए.
अगर आपको Chrome में, XSLT को बंद करने से जुड़ी कोई समस्या आती है, तो यहां गड़बड़ी की शिकायत करें.
एक्सएसएलटी के इस्तेमाल का पता कैसे लगाएं
आम तौर पर, XSLT जैसी बंद की गई सुविधाओं का पता, आपके कोड बेस में कुछ तरीकों से लगाया जा सकता है. इस सेक्शन में, इनमें से दो तरीकों के बारे में बताया गया है.
Reporting API
Reporting API वेब ऐप्लिकेशन के लिए एक सामान्य रिपोर्टिंग मैकेनिज़्म है. इसका इस्तेमाल, प्लैटफ़ॉर्म की अलग-अलग सुविधाओं और शर्तों के बारे में रिपोर्ट करने के लिए किया जाता है. इसमें, सुविधाओं को बंद करने की जानकारी भी शामिल होती है. XSLT को बंद करने के बारे में रिपोर्ट करने के लिए, इस तरह के कोड स्निपेट का इस्तेमाल किया जा सकता है:
new ReportingObserver((reports, observer) => {
reports.forEach((report) => {
if (report.body.id === "XSLT") {
// XSLT usage was detected - report it back here.
}
});
}, {types: ["deprecation"],buffered: true}).observe();
CodePen पर, इस कोड को काम करते हुए देखें.
एंटरप्राइज़ की लेगसी टेक्नोलॉजी रिपोर्ट
किसी एंटरप्राइज़ के एडमिन के लिए, Legacy Technology Report का इस्तेमाल करके, बंद की गई सुविधाओं के इस्तेमाल की जानकारी को अपने-आप इकट्ठा किया जा सकता है. साथ ही, इसे उपयोगकर्ता के लिए आसान तरीके से रिपोर्ट किया जा सकता है. इस सुविधा को चालू करने के तरीके के बारे में ज़्यादा जानकारी के लिए, Google का यह सहायता लेख देखें.