Google आपकी पसंदीदा भाषा में कॉन्टेंट का अनुवाद करने के लिए, एआई टेक्नोलॉजी का इस्तेमाल करता है. एआई से मिले अनुवादों में गलतियां हो सकती हैं.

ज़्यादा सुरक्षित ब्राउज़र के लिए XSLT को हटाना

Mason Freed

Dominik Röttsches

पब्लिश होने की तारीख: 29 अक्टूबर, 2025

Chrome, ब्राउज़र से XSLT को बंद करने और हटाने का इरादा रखता है. इस दस्तावेज़ में, साल 2026 के आखिर में कोड हटाए जाने से पहले, उसे माइग्रेट करने का तरीका बताया गया है.

Chromium ने आधिकारिक तौर पर XSLT का इस्तेमाल बंद कर दिया है. इसमें XSLTProcessor JavaScript API और XSLT प्रोसेसिंग निर्देश शामिल हैं. हम वर्शन 158 (17 नवंबर, 2026) से सहायता बंद करने वाले हैं. 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 के कैनरी, Dev, और बीटा वर्शन में, XSLT को डिफ़ॉल्ट रूप से बंद करने की प्रोसेस शुरू हो जाएगी. इससे डेवलपर को पहले से ही चेतावनी मिल जाएगी.
Chrome 158 (17 नवंबर, 2026): ऑरिजिन ट्रायल और Enterprise की नीति में हिस्सा लेने वाले लोगों को छोड़कर, सभी उपयोगकर्ताओं के लिए स्टेबल वर्शन में XSLT काम करना बंद कर देगा.
Chrome 176 (17 अगस्त, 2027): ऑरिजिन ट्रायल और एंटरप्राइज़ की नीति काम करना बंद कर देगी. सभी उपयोगकर्ताओं के लिए XSLT बंद है.

एक्सएसएलटी क्या है?

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 स्टाइलशीट के साथ प्रोसेस करने के लिए किया जा सकता है.

एक्सएसएलटी का इतिहास

वर्ल्ड वाइड वेब कंसोर्शियम (W3C) ने 16 नवंबर, 1999 को एक्सएमएल दस्तावेज़ों को अन्य फ़ॉर्मैट में बदलने के लिए, XSLT को एक भाषा के तौर पर इस्तेमाल करने का सुझाव दिया था. आम तौर पर, एक्सएमएल दस्तावेज़ों को एचटीएमएल में बदला जाता है, ताकि उन्हें वेब ब्राउज़र में दिखाया जा सके. मार्च 1999 में रिलीज़ हुए Internet Explorer 5.0 में, Microsoft ने W3C के वर्किंग ड्राफ़्ट के आधार पर, मालिकाना हक वाले वर्शन को शिप करके, 1.0 के आधिकारिक सुझाव से पहले ही एक शुरुआती पहल की थी. आधिकारिक स्टैंडर्ड का पालन करते हुए, 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++ के पुराने और जटिल कोड बेस हैं. इस तरह के कोड में मेमोरी की सुरक्षा से जुड़े जोखिमों की आशंका ज़्यादा होती है. जैसे, बफ़र ओवरफ़्लो. इसकी वजह से, आर्बिट्रेरी कोड एक्ज़ीक्यूट हो सकता है. उदाहरण के लिए, सुरक्षा ऑडिट और बग ट्रैकर ने इन पार्सर में बार-बार गंभीर जोखिमों की पहचान की है. जैसे, libxslt में CVE-2025-7425 और CVE-2022-22834. क्लाइंट-साइड XSLT अब एक खास सुविधा है, जिसका इस्तेमाल बहुत कम किया जाता है. इसलिए, इन लाइब्रेरी का रखरखाव और सुरक्षा की जांच, कोर JavaScript इंजन की तुलना में बहुत कम की जाती है. हालांकि, ये लाइब्रेरी गैर-भरोसेमंद वेब कॉन्टेंट को प्रोसेस करने की वजह से, ये सीधे तौर पर सायबर हमलों के बड़े खतरे का ज़रिया बनती हैं. दरअसल, हाल ही में हुए कई बड़े सुरक्षा हमलों की मुख्य वजह XSLT ही है, जिसके चलते ब्राउज़र इस्तेमाल करने वाले लोगों के लिए यह लगातार खतरा बना हुआ है. इस पुरानी और कमज़ोर सुविधा को बनाए रखने से सुरक्षा से जुड़े जोखिम काफ़ी बढ़ जाते हैं. इसके मुकाबले, इस सुविधा के फ़ायदे बहुत कम हैं.

इसके अलावा, क्लाइंट-साइड एक्सएसएलटी का मूल मकसद, डेटा को रेंडर किए जा सकने वाले एचटीएमएल में बदलना था. हालांकि, अब इसकी जगह ज़्यादा सुरक्षित, इस्तेमाल में आसान, और बेहतर तरीके से मैनेज किए जाने वाले JavaScript एपीआई इस्तेमाल किए जाते हैं. मॉडर्न वेब डेवलपमेंट, डेटा (आम तौर पर JSON) को वापस पाने के लिए Fetch API और ब्राउज़र के सुरक्षित JavaScript सैंडबॉक्स में, डीओएम स्ट्रक्चर में एक्सएमएल या एचटीएमएल स्ट्रिंग को सुरक्षित तरीके से पार्स करने के लिए DOMParser API जैसी चीज़ों पर निर्भर करता है. इसके बाद, React, Vue, और Svelte जैसे फ़्रेमवर्क, इस डेटा की रेंडरिंग को बेहतर और सुरक्षित तरीके से मैनेज करते हैं. इस मॉडर्न टूलचेन को लगातार डेवलप किया जा रहा है. साथ ही, JavaScript इंजन में सुरक्षा के लिए किए गए बड़े निवेश से इसे फ़ायदा मिलता है. आज के समय में, करीब-करीब सभी वेब डेवलपर इसका इस्तेमाल करते हैं. आज के समय में, सिर्फ़ 0.02% वेब पेज लोड होने के लिए एक्सएसएलटी का इस्तेमाल करते हैं. इनमें से 0.001% से भी कम वेब पेज, एक्सएसएलटी प्रोसेसिंग के निर्देशों का इस्तेमाल करते हैं.

यह कार्रवाई सिर्फ़ Chrome या Chromium के लिए नहीं है: अन्य दो मुख्य ब्राउज़र इंजन भी वेब प्लैटफ़ॉर्म से XSLT को हटाने का समर्थन करते हैं: WebKit, Gecko.

इन वजहों से, XSLT को बंद करने और हटाने से, सभी उपयोगकर्ताओं के लिए ब्राउज़र पर होने वाले हमलों का खतरा कम हो जाता है. साथ ही, वेब प्लैटफ़ॉर्म को आसान बनाया जा सकता है. इससे इंजीनियरिंग संसाधनों को उन टेक्नोलॉजी को सुरक्षित करने पर फ़ोकस करने में मदद मिलती है जो असल में आधुनिक वेब को बेहतर बनाती हैं. इससे डेवलपर की क्षमता पर कोई असर नहीं पड़ता.

एक्सएमएल पार्सिंग की सुरक्षा को बेहतर बनाना

libxslt में सुरक्षा से जुड़ी गंभीर समस्याओं की तरह, हाल ही में libxml2 के ख़िलाफ़ सुरक्षा से जुड़ी गंभीर समस्याओं की शिकायत की गई थी. libxml2 का इस्तेमाल, Chromium में एक्सएमएल को पार्स करने, क्रम में लगाने, और उसकी जांच करने के लिए किया जाता है. 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 को एचटीएमएल डीओएम और सीएसएस में बदला जा सकता है.

JavaScript में क्लाइंट-साइड XSLT

क्लाइंट-साइड (JavaScript पर आधारित) XSLT लाइब्रेरी के कुछ विकल्प उपलब्ध हैं. हालांकि, इनमें से सबसे बड़ी लाइब्रेरी Saxonica ने बनाई है. Saxonica के बारे में पूरी जानकारी देने वाला दस्तावेज़ देखें. यह वेब ब्राउज़र में XSLT 1.0 को लागू करने से कहीं ज़्यादा बेहतर है. इसमें नए v3.0 स्टैंडर्ड के लिए पूरी तरह से सहायता उपलब्ध है. साथ ही, इसमें v4.0 स्टैंडर्ड के लिए भी सहायता उपलब्ध होगी, जिस पर अभी काम चल रहा है.

Polyfill

एक ऐसा polyfill है जो मौजूदा कोड को अनुमति देने की कोशिश करता है. यह कोड, वेब ब्राउज़र के XSLT 1.0 के लागू होने पर निर्भर करता है. इससे ब्राउज़र की नेटिव XSLT सुविधाओं का इस्तेमाल किए बिना, काम जारी रखा जा सकता है. पॉलीफ़िल, GitHub पर मौजूद है.

polyfill में, XSLTProcessor क्लास के लिए, WASM पर आधारित polyfill वाला फ़ंक्शनल रिप्लेसमेंट शामिल होता है. इससे मौजूदा JavaScript कोड पहले की तरह काम करता रहता है:

<script src="xslt-polyfill.min.js"></script>

<script>
const xsltProcessor = new XSLTProcessor();
xsltProcessor.importStylesheet(xsltDoc);
const fragment = xsltProcessor.transformToFragment(xmlDoc, document);
</script>

पॉलीफ़िल, अपने-आप काम करने वाला एक उपयोगिता फ़ंक्शन भी उपलब्ध कराता है. इससे, 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 को लोड करता है. यह एक्सएमएल दस्तावेज़ टाइप और एक्सएसएलटी प्रोसेसिंग निर्देश का पता लगाता है. साथ ही, दस्तावेज़ को बदलकर उसे पारदर्शी तरीके से लोड करता है.

Extension

इसके अलावा, एक Chrome एक्सटेंशन भी है जिसे उन ब्राउज़र में जोड़ा जा सकता है जिन पर यह काम करता है. यह एक्सटेंशन, उन सभी रॉ एक्सएमएल पेजों पर एक जैसा XSLT polyfill लागू करेगा जिनमें XSLT प्रोसेसिंग के निर्देश या XSLTProcessor को कॉल शामिल हैं. इसका इस्तेमाल उन ऐप्लिकेशन के लिए किया जा सकता है जिनमें सोर्स एक्सएमएल या XSLT को बदला नहीं जा सकता. इससे ऐप्लिकेशन की मुख्य सुविधाएं काम करती रहती हैं.

खास तौर पर, XSLT बंद होने पर Chrome अब चेतावनी वाला एक बैनर दिखाता है. यह बैनर, सीधे तौर पर एक्सटेंशन के खोज वाले पेज से लिंक होता है. इससे उपयोगकर्ताओं को एक्सटेंशन ढूंढने में मदद मिलती है:

एक्सएसएलटी का पता चलने पर, Chrome में दिखने वाला मैसेज.

इस्तेमाल के खास उदाहरण

एचटीएमएल स्टैंडर्ड के बारे में चर्चा में, इस्तेमाल के कई उदाहरणों की पहचान की गई. इस सेक्शन में, इनमें से हर एक के बारे में खास तौर पर बताया गया है. इससे उन डेवलपर को आगे बढ़ने के तरीके सुझाए जा सकते हैं जो आज एक्सएसएलटी का इस्तेमाल करने वाले एक्सएमएल रिसॉर्स पब्लिश करते हैं.

आरएसएस और ऐटम फ़ीड

कई मौजूदा आरएसएस या ऐटम फ़ीड में, 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 नेटवर्क से अलग है.

इस सामान्य समस्या को हल करने के दो तरीके हैं. इस तरह से बनाई गई किसी मौजूदा साइट के लिए, सबसे आसान तरीका यह है कि मौजूदा फ़ंक्शन को बनाए रखने के लिए, polyfill जोड़ें. इसके अलावा, सर्वर साइड पर एक्सएसएलटी ट्रांसफ़ॉर्मेशन किया जा सकता है. साथ ही, क्लाइंट को रॉ एक्सएमएल के बजाय, नतीजे के तौर पर मिलने वाला एचटीएमएल दिखाया जा सकता है. ऐसी प्रॉपर्टी के लिए, लंबे समय तक काम करने वाला समाधान यह होगा कि उन्हें ज़्यादा आधुनिक JavaScript या JSON पर आधारित फ़्रेमवर्क पर माइग्रेट किया जाए.

अगर आपको Chrome में 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 पर इस कोड को काम करते हुए देखें.

एंटरप्राइज़ की लेगसी टेक्नोलॉजी रिपोर्ट

किसी एंटरप्राइज़ के एडमिन, लेगसी टेक्नोलॉजी रिपोर्ट का इस्तेमाल करके, बंद की जा चुकी सुविधाओं के इस्तेमाल की जानकारी अपने-आप इकट्ठा कर सकते हैं. साथ ही, इस जानकारी को उपयोगकर्ता के लिए आसान तरीके से रिपोर्ट कर सकते हैं. इस सुविधा को चालू करने के बारे में ज़्यादा जानने के लिए, Google सहायता का यह लेख पढ़ें.