HTML स्पेक से XSLT के उल्लेख हटाने का प्रस्ताव

 (github.com/whatwg)
2 पॉइंट द्वारा GN⁺ 2025-08-20 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • HTML मानक दस्तावेज़ से XSLT से जुड़े उल्लेखों को हटाने के लिए एक Pull Request प्रस्तावित किया गया है
  • प्रस्तावक ने बताया कि Chrome, Firefox, Safari जैसे प्रमुख ब्राउज़रों में संबंधित implementation bugs रिपोर्ट किए गए हैं, और testing व documentation issues पर भी काम चल रहा है
  • विरोधी मतों में मौजूदा वेबसाइट compatibility समस्याओं और <?xml-stylesheet?> हटाने पर XML दस्तावेज़ों के टूटने से जुड़ी readability समस्या की ओर इशारा किया गया
  • कुछ डेवलपर्स ने ज़ोर दिया कि XSLT अब भी सरकारी दस्तावेज़ों, RSS, embedded environments आदि में उपयोग होता है
  • यह चिंता भी उठाई गई कि बड़े browser vendors केंद्रित फैसले वेब की openness और ऐतिहासिक विविधता को कम कर सकते हैं

Pull Request का अवलोकन

  • PR शीर्षक: Remove mentions of XSLT from the html spec
  • प्रस्तावक: mfreed7
  • लक्ष्य: whatwg/html:main
  • संबंधित issue: #11523
  • Chromium, Gecko, WebKit — तीनों में संबंधित implementation bug reports मौजूद हैं
  • MDN दस्तावेज़ और HTML AAM जैसे संबंधित संसाधनों को भी अपडेट किया जाना है

मुख्य विरोधी मत

gucci-on-fleek (2025-08-15)

  • उपयोग आँकड़ों और वेबसाइट के आकार को ध्यान में रखने की दलील
    • बड़े साइट्स अपडेट हो सकते हैं, लेकिन छोटे/व्यक्तिगत साइट्स दशकों से मेंटेन नहीं किए गए हैं, इसलिए स्थायी compatibility टूटने का खतरा है
  • XSLTProcessor() हटाने से केवल JS फीचर सीमित होगा, लेकिन <?xml-stylesheet?> हटाने पर XML दस्तावेज़ बिल्कुल दिखना बंद हो सकते हैं
  • पुराने HTML फीचर्स (<font>, <align>, <xmp>) अब भी काम करते हैं, लेकिन यह दस्तावेज़ को ही तोड़ देने वाला अभूतपूर्व बदलाव होगा
  • पुराने archives, university sites जैसे महत्वपूर्ण संसाधनों तक पहुँच रुकने का जोखिम रेखांकित किया गया

nomis (2025-08-18)

  • XSLT के ठोस उपयोग उदाहरण पेश किए
  • व्यक्तिगत उपयोग के उदाहरण
    • जटिल XML डेटा को HTML tables में बदलना
    • memory constraints वाले microcontrollers पर dynamic XML को static XSLT में बदलना
  • पूरे libxml2 को शामिल करने वाला JS polyfill अव्यावहारिक है, और browser support हटाना वास्तव में दोबारा implementation थोपने जैसा है

jonsterling (2025-08-18)

  • वेब प्लेटफ़ॉर्म को browser vendors द्वारा लगभग एकाधिकार की तरह परिभाषित किए जाने की आलोचना
  • XSLT अब भी विविध और रचनात्मक web use cases में योगदान देता है, और इसे हटाना Open Web को कमजोर कर सकता है
  • "वेब हम सबका है" इस सिद्धांत पर ज़ोर देते हुए इतिहास और विविधता के सम्मान की आवश्यकता बताई

समर्थन और आगे की कार्रवाई

  • domenic (2025-08-19): सकारात्मक प्रतिक्रिया दी और कहा कि DOM spec में XSLT के उल्लेख भी अपडेट होने चाहिए
  • mfreed7 (2025-08-19): जवाब दिया कि DOM spec के लिए अलग PR भी जमा करेंगे

सार

  • XSLT हटाने का प्रस्ताव browser simplification और modernization प्रयासों का हिस्सा है
  • लेकिन विरोधी पक्ष को मौजूदा दस्तावेज़ compatibility, सरकारी/शैक्षणिक डेटा की पहुँच, और open web की विविधता को नुकसान पहुँचने की चिंता है
  • यह चर्चा अब सिर्फ तकनीकी विकल्प तक सीमित नहीं है, बल्कि वेब मानकों पर निर्णय लेने का अधिकार किसके पास है जैसे दार्शनिक सवाल तक पहुँच गई है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-08-20
Hacker News राय

  • कुछ ध्यान देने लायक बातें हैं

    • यह फैसला सिर्फ Chrome की एकतरफा कार्रवाई नहीं है, और issue tracking तथा संबंधित standards meeting के रिकॉर्ड से यह पुष्टि होती है कि सभी प्रमुख browsers के प्रतिनिधियों ने समर्थन जताया है

    • हाल की agenda भी एक Mozilla engineer ने प्रस्तावित की थी

    • PR submit होने का मतलब यह नहीं कि वह तुरंत merge हो जाएगा, और अभी भी काफी unchecked tasks बाकी हैं

    • लेकिन जब कई browser vendors सहमत हैं, तो इसके merge होने की संभावना अधिक है

    • वेब प्लेटफ़ॉर्म से XSLT हटाने पर विचार करने वाला issue community feedback जुटाने के लिए नहीं, बल्कि HTML spec maintainers के बीच चर्चा के लिए है

    • यह issue एक Chrome engineer ने खोला था, लेकिन Mozilla engineers ने इस विषय को कई बार meetings में उठाया था, और vendors के बीच पहले से सहमति भी थी

    • एक गंभीर security vulnerability पहले पाई जा चुकी है

    • libxslt के maintainer ने भी सीधे इस्तीफ़ा दे दिया

    • मैंने शीर्षक से Chrome शब्द हटा दिया

    • मूल रूप से भेजा गया शीर्षक था "Chrome intends to remove XSLT from the HTML spec"

    • Chrome के telemetry data के अनुसार वास्तव में XSLT इस्तेमाल करने वाली websites लगभग नहीं हैं

    • कम से कम data से यह तो पता चलता है कि इस प्रस्ताव का पूरे web पर बड़ा असर नहीं होगा

    • मैं पहले Mozilla और Google (Chrome team) में काम कर चुका developer हूँ

    • मुझे समझ आता है कि Chrome/Blink, Safari/Webkit, Firefox/Gecko सभी XSLT हटाने का समर्थन कर रहे हैं, लेकिन दो projects के पास resources कम हैं, और एक में नई features को ज़बरदस्ती आगे बढ़ाने की प्रवृत्ति बहुत मजबूत है

    • Safari और Firefox developers के पास ऐसे बदलाव का स्वागत करने की वजहें भी हो सकती हैं

    • असली सवाल यह नहीं है कि 'क्या प्रभावशाली लोगों को यह अच्छा विचार लगता है', बल्कि यह है कि 'क्या यह विचार web platform और अरबों users पर नकारात्मक असर डालेगा'

    • अरबों में 0.1% भी निर्भर हों, तो वह काफ़ी बड़ा पैमाना है

    • अगर कोई इसका इस्तेमाल ही नहीं करता, तो polyfill होने की भी कोई वजह नहीं है

    • अगर नई features जोड़ने के लिए हर बार पुरानी features हटानी पड़ें, जैसे कोई zero-sum game हो, तो यह अच्छा नहीं है

    • Google के पास पर्याप्त पूंजी और manpower होने के बावजूद वह जानबूझकर XSLT support न देने का चुनाव कर रहा है

    • कई vendors की सहमति होने पर भी कई बार चीज़ें तुरंत आगे बढ़ाई गईं

    • confirm/prompt हटाने के मामले में भी ऐसा हुआ था, लेकिन अंत में उसे अनिश्चितकाल के लिए टाल दिया गया

    • Google के पास feature removal process पर एक आधिकारिक document है
      Google feature removal doc

    • "vendor-only support" ने वास्तविक usage की स्थिति की ठीक से समीक्षा नहीं की

  • जिन दो threads को मैंने पढ़ा, उनमें Google ने feedback माँगा था, लेकिन लगभग सारा feedback यही था कि "ऐसा मत करो"

    • लेकिन Google का रवैया था, "राय के लिए धन्यवाद, फिर भी हम करेंगे!"

    • अगर issue security की वजह से था, तो open source को support देना, किसी अधिक सुरक्षित library पर migrate करना, या JS sandbox के भीतर इसे बनाए रखना जैसे कई विकल्प थे, लेकिन ज़्यादातर को नज़रअंदाज़ किया गया

    • XSLT 3.0 जैसे नए versions के support की माँग भी लगातार होती रही, पर उसे शामिल नहीं किया गया

    • XSLT open web का समर्थन करने वाली technology है, फिर भी Google पिछले 10 साल से support घटाकर उसे उपेक्षित छोड़ता रहा है और market share में गिरावट को हटाने की वजह की तरह इस्तेमाल करता रहा है

    • अभी जब XSLT फिर से लोकप्रियता पा रहा है, ऐसा लगता है कि open competitors उभरने से पहले ही उसे खत्म करने की मंशा है

    • संबंधित issue

    • इस दावे के जवाब में कि ज़्यादातर feedback "मत करो" था, उस thread को दुर्भावनापूर्ण टिप्पणियों, व्यक्तिगत हमलों आदि के कारण जल्दी lock कर दिया गया था

    • "यह अच्छा विचार है" जैसी राय अक्सर सामान्यतः लिखी नहीं जाती, इसलिए ऐसा लग सकता है कि केवल विरोधी राय ही ज़्यादा थीं

    • सबने बहुत अतिवादी भाषा इस्तेमाल की, इसलिए चर्चा बिखर गई, और यह कुछ हद तक खुद ही बुलाया गया नतीजा था

    • अगर "कृपया मत हटाइए" कहने वाले लोग वास्तविक users नहीं हैं या यह नहीं बता सकते कि इसकी ज़रूरत क्यों है, तो dev team का उनकी बात न मानना तर्कसंगत है

    • feedback माँगना सिर्फ़ साधारण पक्ष-विपक्ष मतदान नहीं है

    • अच्छा होगा अगर XSLT 3.0 support को JS/wasm sandbox में ले जाया जा सके

    • थोड़ा performance loss होगा, लेकिन दोनों तरफ़ के फ़ायदे मिल सकते हैं

    • XML में versioned schemas, namespaces जैसी विशेषताओं की वजह से integration अपेक्षाकृत आसान है

    • Angular जैसे js frameworks के विपरीत इसमें reliable data contracts संभव हैं

    • XML family की maturity की वजह से इतने specialized tools हैं कि व्यवहार में XML/XSD को सीधे text के रूप में संभालना ज़रूरी नहीं पड़ता

    • Google web को पहले से बताने का काम "सवाल पूछने वाले रूप" में करता है कि आगे क्या होने वाला है

  • पिछले संबंधित threads का परिचय

  • यह सवाल उठता है कि क्या browser को किसी खास template engine (XSLT) के लिए built-in support देने की ज़रूरत है

    • यह Jinja जैसे text engine की तरह नहीं है, लेकिन JS/wasm में इसे फिर से implement किया जा सकता है

    • अभी browsers बहुत भारी हो चुके हैं, और नए engines बनाना मुश्किल है

    • काश "minimal browser" के लिए कोई सरल standard होता, जिसमें सिर्फ़ basic tags, layout वगैरह होते

    • WebAudio, Canvas जैसी चीज़ें भी wasm modules के रूप में implement की जा सकती हैं (और ऐसा करने से fingerprinting भी रोकी जा सकती है)

    • XSLT किसी खास engine का नाम नहीं, बल्कि template engine के लिए एक "spec" है, और इसके कई implementations हैं

    • Mozilla, libxslt की जगह transformiix का इस्तेमाल करता है

    • Jinja सिर्फ़ text पर काम करता है, जबकि XSLT node level पर काम करता है, इसलिए वह कहीं अधिक सक्षम है

    • JS transformations, native XSLT transformations की तुलना में बहुत धीमे हैं, और result caching भी कठिन है

    • मैं समझ सकता हूँ कि लोग XSLT को पुराना मानते हैं, लेकिन पिछले 20 साल में यह performance के लिहाज़ से एक secret weapon की तरह काम करता रहा है

    • Google अंततः AMP जैसी किसी alternative से समस्या को ढकने की कोशिश कर सकता है

    • browsers के भारी होने के लिए Google ज़िम्मेदार है

    • XSLT एक language/spec है, engine नहीं

    • JS/wasm implementation पर जाना internal implementation का मामला है, यह वह बात नहीं है जो language को web platform से हटाने पर होती है

    • audio या canvas browser की मूल I/O capabilities हैं, उन्हें wasm में ले जाने से performance और compatibility की गंभीर समस्याएँ होंगी

    • audio का कुछ हिस्सा wasm blob में ले जाया जा सकता है, लेकिन पूरी चीज़ को shift करना कठिन है

    • canvas context या WebGL जैसी चीज़ों का मूल बिंदु GPU के साथ सीधा integration है, इसलिए उन्हें wasm में उसी तरह हासिल नहीं किया जा सकता

    • अंततः ये features लगभग पहले से ही base primitive APIs हैं, इसलिए यह ऐसा क्षेत्र है जहाँ समझौता नहीं किया जा सकता

    • पुराने XSLT code को wasm में package करके legacy sites को बिना तोड़े compatibility बनाए रखने का विचार भी चर्चा में आया था

    • वास्तव में इसे अंदरूनी तौर पर देखा भी गया, लेकिन अंत में न करने का निर्णय लिया गया

    • web से दूर और बहुत कम इस्तेमाल होने वाली features हटाने योग्य हो सकती हैं

    • लेकिन security vulnerabilities को मुख्य तर्क बनाना मुझे सही नहीं लगता

    • जब तक यह भी नहीं देखा गया कि memory-safe package उपलब्ध है या नहीं, तब तक तर्क कमज़ोर लगता है

    • दावा है कि वास्तविक usage rate 0.001% के स्तर पर है

  • HTML spec के बुनियादी वादे को तोड़ना बहुत गंभीर मामला है

    • हैरानी की बात है कि चर्चा इस बिंदु पर गहराई से बात नहीं करती

    • HTML का वादा था, "यह HTML है। आप इस पर भरोसा कर सकते हैं," लेकिन अब बात यह हो गई है, "यह अभी के लिए HTML है, आगे भी रहेगा इसकी कोई गारंटी नहीं"

    • अगर XSLT हटाने की यही दलील है, तो दूसरी पुरानी technologies भी लगातार काटी जा सकती हैं

    • अंततः यह web के 'long tail' को काटने का प्रस्ताव है

    • यह भी सोचना होगा कि आगे जो नई web technologies जुड़ेंगी, वे भी long tail बनकर और अधिक removals का आधार बन सकती हैं

    • पुराने media और software support के मामले में मेरा मानना है कि एक समय ऐसा आता है जब portability, emulation, archive जैसे रास्तों से समाधान करना पड़ता है

    • बदलाव के लिए पर्याप्त समय और tools देना तथा complexity के धीरे-धीरे असहनीय हो जाने से बचना, इन दोनों के बीच संतुलन चाहिए

    • वास्तविक PR में हटाए गए हिस्से देखें तो ऐसा नहीं लगता कि HTML में XSLT support की कोई स्पष्ट अनिवार्यता लिखी थी

    • बात बस इतनी लगती है कि browser support के मुद्दे पर प्रतिक्रिया बड़ी है

    • PR खुद आश्चर्यजनक रूप से छोटा है

    • WHATWG ने HTML को "Living Standard" के रूप में परिभाषित किया है, इसलिए व्यवहार में अब यह implementation standard कम और browser vendors के वर्तमान कामकाज की साझा स्थिति ज़्यादा है

    • इसी वजह से HTML5 जैसी version numbering भी हटा दी गई, और सिर्फ़ "HTML" शब्द का इस्तेमाल होने लगा

    • Living Standard FAQ

    • HTML standard FAQ

    • विडंबना यह है कि HTML/CSS/browser specs में बहुत बड़ी मात्रा में features ठूँसने वालों में Google खुद सबसे प्रमुख रहा है

    • अगर Google लगातार यह कहता कि "browser हल्के होने चाहिए और अजीब चीज़ें JS libraries पर छोड़नी चाहिए," तो यह कदम कुछ हद तक समझ आता, लेकिन ऐसा बिल्कुल नहीं है

  • FTP support हटाए जाने के बाद से XSL का भविष्य लगभग तय ही लग रहा था

    • browsers आम तौर पर attack surface कम करने को सबसे ऊपर रखते हैं

    • मुझे लगता है कि अगला removal target SVG SMIL animation attributes, MathML जैसी XML-संबंधित features हो सकती हैं

    • संबंधित thread

    • SMIL के साथ खास animation start/end timing के आधार पर sequential animation control संभव है, जबकि CSS animations अभी इसमें कमज़ोर हैं

    • CSS में calculation-आधारित timing के अलावा और रास्ता नहीं है

    • Chromium ने भी कभी SMIL हटाने की इच्छा जताई थी, लेकिन CSS पर्याप्त नहीं थी, इसलिए वह कदम बहुत जल्दबाज़ी भरा होता

    • उसके बाद SMIL से जुड़ी कई guide documents बिना update के छोड़ दी गईं

    • मैं पूछना चाहता हूँ कि attack surface कम करना वास्तव में अच्छा है या बुरा

    • engineers और आम users की priorities अलग हो सकती हैं

    • जिज्ञासा है कि FTP feature हटाना आख़िर कब हुआ

    • मेरी जानकारी में अभी भी address bar से ftp:// खोला जा सकता है

  • Blink और WebKit में XSLT implementation बहुत inefficient है

    • यह पूरे document को string में बदलकर फिर दोबारा parse करता है, इसलिए user-space libraries भी शायद काफ़ी मिलती-जुलती performance दे सकती हैं
    • Chromium XSLT implementation उदाहरण1
    • Chromium XSLT implementation उदाहरण2
    • Webkit XSLTProcessor implementation
    • Mozilla अपनी खुद की implementation (xslt engine) का इस्तेमाल करता है
    • compatibility समस्याओं के लिए MathML की तरह ऐसा तरीका एक विकल्प हो सकता है जिसमें बाहरी developers हर browser के implementation में योगदान दें

  • यह निर्णय निराशाजनक है, लेकिन इससे भी ज़्यादा अफ़सोस इस बात का है कि अधिक आधुनिक XSLT integration पर कोशिश नहीं की गई

    • इसका इस्तेमाल असुविधाजनक था, लेकिन अगर browser में यह थोड़ा और विकसित हुआ होता, तो React जैसे frameworks का टक्कर देने वाला competitor बन सकता था

    • XML, बड़ी कंपनियों की जटिलताओं के बिना, standard के रूप में बेहद शक्तिशाली और शानदार technology थी

    • XSLT का इस्तेमाल करके छोटे और सरल xml/data को सीधे html में बदलना सचमुच बहुत अच्छा था

    • अगर सिर्फ़ इतना सा फीचर जुड़ जाता कि चुने गए item को अलग तरह से दिखाया जा सके, तो static documents तक में इसके विविध उपयोग संभव हो सकते थे, यही अफ़सोस है

  • कहा गया कि @whatwg ने चर्चा को "overheated" बताते हुए issue को collaborators तक सीमित करके lock कर दिया

    • देखने में तो चर्चा काफ़ी तर्कसंगत और शांत लगी, इसलिए लगता है कि कहीं "overheated" की परिभाषा vendor के पक्ष या विपक्ष के अनुसार तो नहीं बदलती

    • "overheated" जैसे शब्द को अक्सर इस अर्थ में लिया जाता है कि लोग विरोधी राय से निपटना नहीं चाहते

    • Reddit जैसी दूसरी communities में भी ऐसा होता है

    • वास्तव में नीचे बची हुई 1 comment Google Chrome से जुड़े developer की थी, जिसमें लिखा था, "अच्छा काम किया"

    • थोड़ा असहज सा लगता है

    • issue tracker में शिकायतनुमा गालियाँ, conspiracy theories, political messages आदि की बाढ़ आने के उदाहरण का उल्लेख किया गया

    • ऐसी स्थिति में productive discussion संभव नहीं रहती, और repository maintainers को जल्दी discussion रोकनी पड़ती है

    • सुना है कि उस repository में discussion lock करने का निर्णय वास्तव में एक Apple employee ने लिया था

    • लेकिन लोग इसका दोष उस Google employee पर डाल रहे हैं जिसने यह issue उठाया था

    • Google हाल में community feedback के नाम पर open discussion करता दिखा, लेकिन उसके बाद हर राय को नज़रअंदाज़ करके अपनी बात मनवाने की कोशिश कर रहा है

    • संबंधित issue

  • पुराने web elements पर व्यापक स्तर पर फिर से विचार करने की ज़रूरत है

    • मेरे लिए पुरानी web pages का लगातार ठीक से काम करते रहना अपने आप में बहुत मूल्यवान है

    • HTML/JS की compatibility बनाए रखने की वजह से दशकों पुराने pages भी सिर्फ़ TLS certificate जोड़कर आज भी ठीक से चल जाते हैं

    • लेकिन हर legacy technology को हमेशा के लिए support देना भी संभव नहीं है

    • Flash भी अंततः emulator (Ruffle) के ज़रिए पुरानी games और sites का अनुभव लेने वाले रूप में बदल गया

    • लंबे समय में पुराने rendering पर केंद्रित dedicated browsers या emulators का इस्तेमाल भी एक विकल्प हो सकता है

    • इसके लिए XSLT polyfill extension पहले ही आ चुका है

    • Chrome इसे आधिकारिक रूप से ship या maintain नहीं करना चाहता

    • स्थिति काफ़ी हद तक Ruffle जैसी है