पब्लिश करने की तारीख: 29 अक्टूबर, 2025
Chrome, ब्राउज़र से XSLT को हटाने और इसका इस्तेमाल बंद करने का प्लान बना रहा है. इस दस्तावेज़ में, 2026 के आखिर में हटाए जाने से पहले, कोड को माइग्रेट करने का तरीका बताया गया है.
Chromium ने आधिकारिक तौर पर XSLT का इस्तेमाल बंद कर दिया है. इसमें XSLTProcessor JavaScript API और XSLT प्रोसेसिंग का निर्देश शामिल है. हम 17 नवंबर, 2026 से वर्शन 158 के लिए सहायता बंद कर देंगे. 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): एंटरप्राइज़ की नीति (ईपी) को टेस्टिंग के लिए उपलब्ध कराया जाएगा. इससे एंटरप्राइज़, XSLT को जल्दी बंद करने की सुविधा को टेस्ट कर सकते हैं. साथ ही, सुविधा हटाए जाने की तारीख के बाद भी उसका इस्तेमाल जारी रख सकते हैं.
- Chrome 152 (25 अगस्त, 2026): टेस्टिंग के लिए ओरिजनल ट्रायल (ओटी) लाइव हो जाता है. इससे साइटें, सुविधा हटाए जाने की तारीख के बाद भी उसका इस्तेमाल जारी रख सकती हैं.
- Chrome 154 (22 सितंबर, 2026): Webview के कैनरी, डेवलपर, और बीटा वर्शन में, XSLT को डिफ़ॉल्ट रूप से बंद करने की सुविधा शुरू हो जाएगी. यह एक तरह की चेतावनी है.
- Chrome 158 (17 नवंबर, 2026): ऑरिजिन ट्रायल और Enterprise की नीति में हिस्सा लेने वाले लोगों को छोड़कर, सभी उपयोगकर्ताओं के लिए स्टेबल वर्शन में XSLT काम करना बंद कर देगा.
- Chrome 176 (17 अगस्त, 2027): ऑरिजिन ट्रायल और एंटरप्राइज़ की नीति काम करना बंद कर देती है. सभी उपयोगकर्ताओं के लिए XSLT बंद है.
एक्सएसएलटी क्या है?
एक्सएसएलटी या एक्सटेंसिबल स्टाइलशीट लैंग्वेज ट्रांसफ़ॉर्मेशन, एक ऐसी भाषा है जिसका इस्तेमाल एक्सएमएल दस्तावेज़ों को बदलने के लिए किया जाता है. आम तौर पर, इन्हें एचटीएमएल जैसे अन्य फ़ॉर्मैट में बदला जाता है. यह कन्वर्ज़न के नियमों को तय करने के लिए, XSLT स्टाइलशीट फ़ाइल का इस्तेमाल करता है. साथ ही, इनपुट के तौर पर इस्तेमाल किए गए डेटा वाली एक्सएमएल फ़ाइल का इस्तेमाल करता है.
ब्राउज़र में, जब XSLT स्टाइलशीट से लिंक की गई कोई एक्सएमएल फ़ाइल मिलती है, तो ब्राउज़र उस स्टाइलशीट में दिए गए नियमों का इस्तेमाल करता है. इससे वह रॉ एक्सएमएल डेटा को व्यवस्थित करता है, उसे फ़ॉर्मैट करता है, और उसे स्ट्रक्चर्ड पेज (अक्सर एचटीएमएल) में बदलता है. इस पेज को उपयोगकर्ता के लिए रेंडर किया जा सकता है.
उदाहरण के लिए, कोई XSLT स्टाइलशीट, इस तरह का एक्सएमएल इनपुट ले सकती है:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl" ?>
<page>
<message>
Hello World.
</message>
</page>
और इस XSL स्टाइलशीट का इस्तेमाल किया गया है:
<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 को XML दस्तावेज़ों को अन्य फ़ॉर्मैट में बदलने के लिए एक भाषा के तौर पर इस्तेमाल करने का सुझाव दिया था. आम तौर पर, वेब ब्राउज़र में दिखाने के लिए, XML दस्तावेज़ों को एचटीएमएल में बदला जाता है. आधिकारिक तौर पर 1.0 वर्शन के सुझाव से पहले, Microsoft ने एक शुरुआती पहल की थी. इसके तहत, मार्च 1999 में रिलीज़ किए गए Internet Explorer 5.0 में, W3C के वर्किंग ड्राफ़्ट के आधार पर मालिकाना हक वाला एक वर्शन शिप किया गया था. आधिकारिक स्टैंडर्ड के मुताबिक, Mozilla ने साल 2000 के आखिर में Netscape 6 में नेटिव XSLT 1.0 सपोर्ट लागू किया. Safari, Opera, और Chrome के बाद के वर्शन जैसे अन्य मुख्य ब्राउज़र में भी, नेटिव XSLT 1.0 प्रोसेसर शामिल किए गए. इससे, क्लाइंट-साइड XML-to-HTML ट्रांसफ़ॉर्मेशन, साल 2000 की शुरुआत में एक अहम वेब टेक्नोलॉजी बन गई.
XSLT भाषा में लगातार बदलाव होते रहे. XSLT 2.0 को 2007 और XSLT 3.0 को 2017 में रिलीज़ किया गया. इनमें रेगुलर एक्सप्रेशन, बेहतर डेटा टाइप, और JSON को प्रोसेस करने की सुविधा जैसी कई नई सुविधाएं जोड़ी गईं. हालांकि, ब्राउज़र के लिए सहायता उपलब्ध नहीं कराई गई. आज, सभी मुख्य वेब ब्राउज़र इंजन सिर्फ़ 1999 के ओरिजनल XSLT 1.0 के साथ काम करते हैं. कोई तकनीकी सुधार न होने के साथ-साथ, वायर फ़ॉर्मैट के तौर पर JSON का इस्तेमाल बढ़ने से क्लाइंट-साइड XSLT का इस्तेमाल काफ़ी कम हो गया है.ये लाइब्रेरी और फ़्रेमवर्क, DOM में ज़्यादा आसानी से और बेहतर तरीके से बदलाव करने की सुविधा देते हैं. वेब ब्राउज़र में XSLT की जगह अब काफ़ी हद तक JavaScript पर आधारित टेक्नोलॉजी ने ले ली है.
XSLT को क्यों हटाया जाना चाहिए?
वेब ब्राउज़र में XSLT 1.0 को शामिल करने से, सुरक्षा से जुड़ा गंभीर और गैर-ज़रूरी जोखिम पैदा होता है. इन बदलावों को प्रोसेस करने वाली लाइब्रेरी, जैसे कि libxslt (Chromium ब्राउज़र इसका इस्तेमाल करते हैं), जटिल और पुराने C/C++ कोडबेस हैं. इस तरह के कोड में मेमोरी की सुरक्षा से जुड़े जोखिमों की आशंका ज़्यादा होती है. जैसे, बफ़र ओवरफ़्लो. इसकी वजह से, आर्बिट्रेरी कोड एक्ज़ीक्यूट हो सकता है. उदाहरण के लिए, सुरक्षा ऑडिट और बग ट्रैकर ने इन पार्सर में बार-बार गंभीर जोखिम की पहचान की है. जैसे, libxslt में CVE-2025-7425 और CVE-2022-22834. क्लाइंट-साइड XSLT अब एक ऐसी खास सुविधा है जिसका इस्तेमाल बहुत कम किया जाता है. इसलिए, इन लाइब्रेरी का रखरखाव और सुरक्षा की जांच, कोर JavaScript इंजन की तुलना में बहुत कम की जाती है. हालांकि, ये लाइब्रेरी गैर-भरोसेमंद वेब कॉन्टेंट को प्रोसेस करके अटैक करने के प्लैटफ़ॉर्म के तौर पर काम कर सकती हैं. दरअसल, हाल ही में हुए कई बड़े सुरक्षा हमलों की मुख्य वजह XSLT ही है, जिसके चलते ब्राउज़र इस्तेमाल करने वाले लोगों के लिए यह लगातार खतरा बना हुआ है. इस पुरानी सुविधा को बनाए रखने से सुरक्षा से जुड़े जोखिम, इसकी सीमित आधुनिक उपयोगिता से कहीं ज़्यादा हैं.
इसके अलावा, क्लाइंट-साइड XSLT का मूल मकसद, डेटा को रेंडर किए जा सकने वाले एचटीएमएल में बदलना था. हालांकि, अब इसकी जगह ज़्यादा सुरक्षित, इस्तेमाल में आसान, और बेहतर तरीके से रखरखाव किए जाने वाले JavaScript एपीआई ने ले ली है. मॉडर्न वेब डेवलपमेंट, डेटा (आम तौर पर JSON) को वापस पाने के लिए Fetch API और XML या एचटीएमएल स्ट्रिंग को ब्राउज़र के सुरक्षित JavaScript सैंडबॉक्स में DOM स्ट्रक्चर में पार्स करने के लिए DOMParser API जैसी चीज़ों पर निर्भर करता है. इसके बाद, React, Vue, और Svelte जैसे फ़्रेमवर्क, इस डेटा को बेहतर तरीके से और सुरक्षित तरीके से रेंडर करते हैं. इस मॉडर्न टूलचेन को लगातार डेवलप किया जा रहा है. साथ ही, JavaScript इंजन में सुरक्षा से जुड़े बड़े निवेश का फ़ायदा मिलता है. इसके अलावा, आज के समय में लगभग सभी वेब डेवलपर इसका इस्तेमाल करते हैं. दरअसल, आज सिर्फ़ 0.02% वेब पेज लोड करने के लिए, एक्सएसएलटी का इस्तेमाल किया जाता है. वहीं, 0.001% से भी कम वेब पेज लोड करने के लिए, एक्सएसएलटी प्रोसेसिंग के निर्देशों का इस्तेमाल किया जाता है.
यह कार्रवाई सिर्फ़ Chrome या Chromium पर नहीं की जा रही है. अन्य दो मुख्य ब्राउज़र इंजन भी वेब प्लैटफ़ॉर्म से XSLT को हटाने की सुविधा देते हैं: WebKit, Gecko.
इन वजहों से, XSLT को बंद करने और हटाने से, सभी उपयोगकर्ताओं के लिए ब्राउज़र के अटैक सरफेस को कम किया जा सकता है. साथ ही, वेब प्लैटफ़ॉर्म को आसान बनाया जा सकता है. इसके अलावा, इंजीनियरिंग संसाधनों को उन टेक्नोलॉजी को सुरक्षित करने पर फ़ोकस करने की अनुमति दी जा सकती है जो वाकई में मॉडर्न वेब को बेहतर बनाती हैं. इससे डेवलपर को कोई नुकसान नहीं होगा.
एक्सएमएल पार्सिंग की सुरक्षा को बेहतर बनाना
libxslt में सुरक्षा से जुड़ी गंभीर समस्याओं की तरह ही, libxml2 में भी हाल ही में गंभीर सुरक्षा समस्याओं की शिकायतें मिली हैं. libxml2 का इस्तेमाल Chromium में एक्सएमएल को पार्स करने, क्रमबद्ध करने, और एक्सएमएल के सही फ़ॉर्मैट की जांच करने के लिए किया जाता है. Chromium में एक्सएमएल पार्सिंग से जुड़ी सुरक्षा की आने वाली समस्याओं को हल करने के लिए, हम libxml2 का इस्तेमाल बंद करने और एक्सएमएल पार्सिंग को रस्ट में लिखी गई मेमोरी-सेफ़ एक्सएमएल पार्सिंग लाइब्रेरी से बदलने का प्लान बना रहे हैं. अहम बात यह है कि हम ब्राउज़र से XML को नहीं हटाएंगे. यहां सिर्फ़ XSLT को हटाने पर विचार किया जा रहा है. हम यह पक्का करना चाहते हैं कि libxml2 को बदलने की प्रोसेस, वेब डेवलपर के लिए पूरी तरह से पारदर्शी हो.
XML + CSS नहीं हटाया जा रहा है
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 है. यह XSLT 1.0 के वेब ब्राउज़र के वर्शन पर निर्भर मौजूदा कोड को काम करने की अनुमति देता है. हालांकि, यह ब्राउज़र की नेटिव XSLT सुविधाओं का इस्तेमाल नहीं करता. पॉलीफ़िल 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>
पॉलीफ़िल, एक्सएसएलटी प्रोसेसिंग के निर्देशों का इस्तेमाल करने वाले एक्सएमएल दस्तावेज़ों को आसानी से बदलने के लिए, अपने-आप काम करने वाला यूटिलिटी फ़ंक्शन भी उपलब्ध कराता है:
इस तरह की ओरिजनल demo.xml फ़ाइल के लिए:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl"?>
<ROOT>
...content...
पॉलीफ़िल को चालू करने और रेफ़र की गई 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> एलिमेंट, पॉलीफ़िल लोड करता है. यह एक्सएमएल दस्तावेज़ के टाइप और एक्सएसएलटी प्रोसेसिंग के निर्देश का पता लगाता है. साथ ही, दस्तावेज़ को बदलकर उसे पारदर्शी तरीके से लोड करता है.
Extension
एक Chrome एक्सटेंशन भी उपलब्ध है. इसे उन ब्राउज़र में जोड़ा जा सकता है जिन पर यह काम करता है. यह एक्सटेंशन, XSLT प्रोसेसिंग के निर्देशों या XSLTProcessor को कॉल करने वाले सभी रॉ एक्सएमएल पेजों पर एक ही XSLT पॉलीफिल लागू करेगा. इसका इस्तेमाल उन ऐप्लिकेशन के लिए किया जा सकता है जिनमें सोर्स XML या XSLT में बदलाव नहीं किया जा सकता, ताकि फ़ंक्शन काम करते रहें.
खास तौर पर, जब XSLT बंद होता है, तब Chrome अब एक चेतावनी बैनर दिखाता है. यह बैनर, एक्सटेंशन के खोज पेज से सीधे तौर पर लिंक होता है, ताकि उपयोगकर्ताओं को एक्सटेंशन ढूंढने में मदद मिल सके:
इस्तेमाल के खास उदाहरण
एचटीएमएल स्टैंडर्ड पर हुई चर्चा में, इस्तेमाल के कई उदाहरणों की पहचान की गई. इस सेक्शन में, इन सभी के बारे में खास तौर पर बताया गया है. इससे उन डेवलपर को आगे बढ़ने के तरीके सुझाए जा सकते हैं जो आज XSLT का इस्तेमाल करने वाली एक्सएमएल संसाधन फ़ाइलें पब्लिश कर रहे हैं.
आरएसएस और ऐटम फ़ीड
कई मौजूदा आरएसएस या ऐटम फ़ीड में, XSLT का इस्तेमाल किया जाता है. इससे रॉ एक्सएमएल फ़ीड को ब्राउज़र में सीधे तौर पर देखने पर, उसे आसानी से पढ़ा जा सकता है. इसका मुख्य इस्तेमाल यह है कि जब कोई उपयोगकर्ता गलती से किसी साइट के आरएसएस फ़ीड लिंक पर क्लिक करता है, तो उसे आरएसएस फ़ीड रीडर में उस लिंक को चिपकाने के बजाय, फ़ॉर्मैट किया गया एचटीएमएल रिस्पॉन्स मिलता है. इसे वह पढ़ सकता है. उसे रॉ एक्सएमएल नहीं मिलता.
इस उदाहरण के लिए, आगे बढ़ने के दो तरीके हैं. इसे करने का "स्टैंडर्ड" एचटीएमएल तरीका यह है कि किसी (एचटीएमएल पर आधारित) साइट में <link rel="alternate" type="application/rss+xml"> जोड़ा जाए. इसके बजाय, साफ़ तौर पर (उपयोगकर्ता को दिखने वाला) <a
href="something.xml"> न जोड़ा जाए, जिस पर उपयोगकर्ता गलती से क्लिक कर सकते हैं. इस समाधान की मदद से, आरएसएस रीडर को फ़ीड मिल जाता है. इसके लिए, उपयोगकर्ता को सिर्फ़ वेबसाइट का यूआरएल चिपकाना होता है. साथ ही, इससे असली उपयोगकर्ताओं को सामान्य एचटीएमएल कॉन्टेंट दिखता है. उन्हें एक्सएमएल संसाधन के लिंक से कोई भ्रम नहीं होता. यह सामान्य वेब पैराडाइम का भी पालन करता है, जिसमें एचटीएमएल इंसानों के लिए और एक्सएमएल मशीनों के लिए होता है. हालांकि, इससे उस मामले को हल नहीं किया जा सकता जहां किसी व्यक्ति के पास कहीं से आरएसएस लिंक है और वह उसे आरएसएस रीडर के बजाय, अपने वेब ब्राउज़र में चिपकाता है.
जब आपको उस समाधान की ज़रूरत नहीं होती है, तो पॉलीफ़िल एक और तरीका उपलब्ध कराता है. जैसा कि पहले बताया गया है, आरएसएस/ऐटम एक्सएमएल फ़ीड में एक लाइन, <script
src="xslt-polyfill.min.js" xmlns="http://www.w3.org/1999/xhtml"></script>, जोड़ी जा सकती है. इससे, एक्सएसएलटी पर आधारित एचटीएमएल में ट्रांसफ़ॉर्मेशन की मौजूदा प्रोसेस बनी रहेगी.
इससे आरएसएस रीडर की, एक्सएमएल को पार्स करने की क्षमता पर कोई असर नहीं पड़ना चाहिए, क्योंकि <script> रूट एलिमेंट का डायरेक्ट चाइल्ड है.
एम्बेड किए गए डिवाइसों के लिए एपीआई आउटपुट
कारोबार के लिए इस्तेमाल किए जाने वाले कुछ एम्बेड किए गए डिवाइस, स्थानीय नेटवर्क पर उपयोगकर्ताओं के इस्तेमाल के लिए, एक्सएमएल डेटा को मेज़र करते हैं या जनरेट करते हैं. इनमें से कुछ डिवाइस, एक ही एक्सएमएल डेटा फ़ीड जनरेट करके ऐसा करते हैं. यह फ़ीड, XSLT का इस्तेमाल करके इसे ऐसे एचटीएमएल फ़ॉर्मैट में बदलता है जिसे आसानी से पढ़ा जा सकता है. इससे एपीआई को सीधे तौर पर ब्राउज़र में देखा जा सकता है. इसके लिए, डिवाइस या ब्राउज़र में किसी अतिरिक्त कोड की ज़रूरत नहीं होती.
यह ऐप्लिकेशन के हिसाब से इस्तेमाल का एक खास उदाहरण है. इसलिए, समाधान का तरीका अलग-अलग हो सकता है. जिन ऐप्लिकेशन में एम्बेड किए गए डिवाइस के सोर्स कोड को अपडेट किया जा सकता है उनके लिए, ऊपर बताए गए किसी भी विकल्प (JSON, Polyfill) का इस्तेमाल किया जा सकता है. हालांकि, खास तौर पर ऐसे कई डिवाइसों को अपडेट करना मुश्किल या नामुमकिन होता है. इसकी कई वजहें हो सकती हैं. ऐसे में, एक्सटेंशन सबसे अच्छा विकल्प है. इसकी वजह यह है कि यह क्लाइंट ब्राउज़र को डिवाइस में बदलाव किए बिना, उसी तरीके से डेटा को पढ़ने की अनुमति देता है.
वेबसाइटों के लिए लेज़ी टेंप्लेटिंग
वेब डेवलपर कभी-कभी क्लाइंट साइड पर XSLT का इस्तेमाल करते हैं, ताकि वे सिमैंटिक मार्कअप पर प्रज़ेंटेशन मार्कअप लागू कर सकें. यह लेज़ी टेंप्लेटिंग लैंग्वेज के तौर पर काम करता है, जो JavaScript के इकोसिस्टम से अलग है.
इस सामान्य समस्या को हल करने के दो तरीके हैं. इस तरह से बनाई गई किसी मौजूदा साइट के लिए, मौजूदा फ़ंक्शन को बनाए रखने का सबसे आसान तरीका सिर्फ़ पॉलीफ़िल जोड़ना है. इसके अलावा, सर्वर साइड पर XSLT ट्रांसफ़ॉर्मेशन किया जा सकता है. साथ ही, क्लाइंट को रॉ एक्सएमएल के बजाय, नतीजे के तौर पर मिले एचटीएमएल को दिखाया जा सकता है. इस तरह की प्रॉपर्टी के लिए, लंबे समय तक काम करने वाला समाधान यह होगा कि उन्हें ज़्यादा आधुनिक JavaScript या JSON पर आधारित फ़्रेमवर्क पर माइग्रेट किया जाए.
अगर आपको Chrome में XSLT के बंद होने से जुड़ी कोई समस्या आ रही है, तो यहां गड़बड़ी की शिकायत करें.
एक्सएसएलटी के इस्तेमाल का पता कैसे लगाएं
आम तौर पर, बंद की गई सुविधाओं (जैसे, XSLT) का पता आपके कोड बेस में कुछ तरीकों से लगाया जा सकता है. इस सेक्शन में, इनमें से दो के बारे में बताया गया है.
Reporting API
Reporting API, वेब ऐप्लिकेशन के लिए एक सामान्य रिपोर्टिंग सिस्टम है. इसका इस्तेमाल, प्लैटफ़ॉर्म की अलग-अलग सुविधाओं और शर्तों के बारे में रिपोर्ट करने के लिए किया जाता है. इसमें किसी सुविधा के बंद होने की जानकारी भी शामिल है. एक्सएसएलटी के बंद होने की रिपोर्ट करने के लिए, इस तरह के कोड स्निपेट का इस्तेमाल किया जा सकता है:
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 पर इस कोड को काम करते हुए देखें.
एंटरप्राइज़ की लेगसी टेक्नोलॉजी रिपोर्ट
किसी एंटरप्राइज़ के एडमिन के लिए, लेगसी टेक्नोलॉजी रिपोर्ट का इस्तेमाल किया जा सकता है. इससे बंद की गई सुविधाओं के इस्तेमाल से जुड़ा डेटा अपने-आप इकट्ठा हो जाता है. साथ ही, इसे उपयोगकर्ता के हिसाब से रिपोर्ट किया जाता है. इस सुविधा को चालू करने के बारे में ज़्यादा जानने के लिए, Google सहायता केंद्र का यह लेख पढ़ें.