चक्र। इंटरऑपरेबिलिटी का मतलब सिर्फ मानकों से अधिक है

एक फ़ंक्शन को लागू करने का निर्णय कैसे किया जाता है जो मानकों के विनिर्देश का हिस्सा नहीं है? सभी ब्राउज़र प्रदाताओं की तरह, हमें अक्सर यह निर्णय लेना पड़ता है। यह प्रकाशन मानकों के विनिर्देश अपर्याप्त होने पर एक अंतर-ब्राउज़र बनाने के लिए उपयोग किए जाने वाले कुछ सिद्धांतों को स्पष्ट करने के लिए कई वास्तविक दुनिया जावास्क्रिप्ट उदाहरण प्रदान करेगा।



आदर्श रूप से, मानकों का विनिर्देश आत्मनिर्भर है। एक जावास्क्रिप्ट कार्यान्वयन में केवल ECMAScript विनिर्देश में निर्दिष्ट सब कुछ शामिल होगा, और कुछ भी नहीं। हमारा मानना ​​है कि मानकीकरण संगठनों जैसे एक्मा इंटरनेशनल या डब्ल्यू 3 सी द्वारा प्रकाशित विनिर्देश ब्राउज़र इंटरऑपरेबिलिटी सुनिश्चित करने के लिए आवश्यक हैं। इस तरह के विनिर्देश ब्राउज़र के अधिकारियों को सूचित करते हैं कि उन्हें कौन से कार्यों को लागू करना चाहिए, और वेबसाइट डेवलपर्स - उन्हें किन कार्यों का उपयोग करना चाहिए।



इंटरनेट की वास्तविक दुनिया में, चीजें इतनी स्पष्ट रूप से परिभाषित नहीं हैं। विनिर्देशों शायद ही कभी सही होते हैं, और कभी-कभी उन्हें जानबूझकर अधूरा या अस्पष्ट छोड़ दिया जाता है। ईएस 5 विनिर्देश के संपादक के रूप में हमारा अपना अनुभव हमें यह बताने की अनुमति देता है कि हमेशा ऐसी समस्याएं होती हैं जिन्हें अंतिम समाधान नहीं मिला है। परिणामस्वरूप, किसी भी मानक विनिर्देश में परिभाषित नहीं किए गए कार्यों को व्यापक रूप से लागू और लागू किया जाता है। मौजूदा इंटरनेट पर काम करने वाले एक ब्राउज़र को बनाने की कोशिश करने वाले डेवलपर को कई कार्यों को लागू करना होगा जो मानकों के विनिर्देश द्वारा प्रदान नहीं किए जाते हैं।

एक वास्तविक नियमित अभिव्यक्ति व्याकरण क्या है?

चक्र बनाते समय, ECMAScript 5 (ES5) विनिर्देश का सावधानीपूर्वक पालन किया गया था, जिसमें नियमित अभिव्यक्ति व्याकरण भी शामिल है। लेकिन जब वास्तविक वेबसाइटों पर परीक्षण शुरू हुआ, तो कुछ नियमित अभिव्यक्ति शाब्दिक में वाक्यविन्यास त्रुटियों के कारण काम नहीं करने वाले पृष्ठ सामने आने लगे। उदाहरण के लिए, इस तरह के दाहिने चौकोर कोष्ठक के साथ नियमित अभिव्यक्ति पर एक दुर्घटना हुई:



next = /]/.exec(buffer);







कारण यह था कि ECMAScript रेगुलर एक्सप्रेशन व्याकरण में शामिल] पात्रों की सूची में जिनका उपयोग सीधे मिलान वाले चरित्र के रूप में नहीं किया जा सकता है। विनिर्देश कहता है कि प्रतीक /]/



अमान्य है; इसके बजाय, /\]/



का उपयोग किया जाना चाहिए। यह पता चलता है कि चरित्र पर इस तरह का प्रतिबंध [महत्वपूर्ण है क्योंकि अन्यथा शाब्दिक रूप से /axyz[ad]qwer/



जैसे पार्स करना असंभव होगा। हालांकि, एक एकल ब्रैकेट], जो कि प्रतीक से पहले नहीं है [, वास्तव में विश्लेषण के लिए बाधा नहीं बनता है। हालांकि, मानक अभी भी दावा करता है कि यह अस्वीकार्य है।



व्यवहार में, सभी ब्राउज़र नियमित अभिव्यक्ति जैसे /]/



को स्वीकार करते हैं, और वेबसाइट डेवलपर्स उन्हें लिखते हैं।



आम सहमति समारोह एक ऐसा शब्द है जिसका उपयोग हम उन कार्यों का वर्णन करने के लिए करते हैं जो किसी भी मानक का हिस्सा नहीं हैं, लेकिन सार्वभौमिक रूप से कार्यान्वित किया जाता है जो अंतर-क्षमता प्रदान करता है। सामान्य तौर पर, IE9 और किसी अन्य जावास्क्रिप्ट कार्यान्वयन में वास्तविक वेब सामग्री के साथ काम करने के लिए इस तरह के आम सहमति कार्यों को शामिल करना चाहिए। असली कठिनाई उन्हें पहचानने में है, क्योंकि वे मानकों के विनिर्देश में शामिल नहीं हैं।



हम इस तरह के आम सहमति कार्यों को बनाए रखने की आवश्यकता को समझते हैं और इंटरनेट के लिए प्रासंगिक मानकों के भविष्य के संस्करणों में उनके समावेश को सुनिश्चित करने के प्रयास करेंगे। हालाँकि, सभी जावास्क्रिप्ट एक्सटेंशन को सार्वभौमिक या समान रूप से लागू नहीं किया जाता है।

क्यों IE9 में नामों में _ _ अक्षरों के साथ कोई विधियाँ नहीं हैं?

ईएस 5 में पढ़ने और सेटिंग के तरीकों के लिए समर्थन शामिल है। कुछ वेब ब्राउज़रों में कई सालों से इसी तरह की सुविधाएँ उपलब्ध हैं। इस अवधि के दौरान, ब्राउज़र डेवलपर्स ने ऐसे तरीकों को परिभाषित करने के लिए विभिन्न सिंटैक्स और एप्लिकेशन प्रोग्रामिंग इंटरफेस (एपीआई) के साथ प्रयोग किया। ES5 से पहले, सबसे व्यापक रूप से कार्यान्वित एपीआई ने रीड / सेट विधियों को परिभाषित करने के लिए __defineGetter__ और __defineSetter__ नामों के साथ दो विधियों का उपयोग किया। किसी विधि नाम के दोनों ओर अंडरस्कोर का उपयोग करना एक प्रतीक है जो कुछ ब्राउज़र डेवलपर्स द्वारा प्रयोग किए जाने वाले तरीकों को चिह्नित करने के लिए उपयोग किया जाता है या जो विशिष्ट जावास्क्रिप्ट कार्यान्वयन के अद्वितीय निम्न-स्तरीय क्षमताओं तक पहुंचते हैं।



ECMA TC39 सदस्यों ने सहमति व्यक्त की कि ईएस 5 विनिर्देश में पढ़ना और सेटिंग के तरीकों को शामिल किया जाना चाहिए, क्योंकि उनके लाभ स्पष्ट हैं। हालाँकि, TC39 समिति ने उन्हें परिभाषित करने और __defineXXX__ इंटरफेस के मानकीकरण से परहेज करने के लिए एक नया एपीआई बनाने का फैसला किया।



TC39 ने ऐसा क्यों किया? इस API को प्रदान करने वाले ब्राउज़रों के व्यवहार में महत्वपूर्ण अंतर के कारण। इन विधियों के लिए सामान्य शब्दार्थों पर आधारित मानकीकरण का अर्थ होगा कि कुछ या शायद सभी मौजूदा ब्राउज़र कार्यान्वयनों को उन्हें नए शब्दार्थों के अनुरूप लाने के लिए बदलना होगा। और यह संभवतः विशिष्ट ब्राउज़रों के साथ काम करने के लिए लिखे गए कुछ एप्लिकेशन को गैर-कार्यात्मक बना देगा।



एक और कारण नामकरण सम्मेलनों की तार्किक अखंडता को बनाए रखने की इच्छा है। ECMAScript में कोई अन्य एम्बेडेड नाम अंडरस्कोर के साथ शुरू या समाप्त नहीं होता है। प्रयोगात्मक कार्यों के साथ या विशिष्ट फ़ंक्शन के कार्यान्वयन के साथ ऐसे नामों का कनेक्शन व्यापक रूप से जाना जाता है। एक मानकीकृत समारोह के लिए इस प्रतीक का उपयोग करना भ्रामक होगा और भविष्य के प्रयोगों के लिए इसकी उपयोगिता को कम करेगा।



TC39 समिति ने Object.defineProperty



पद्धति के आधार पर एक नया API विकसित किया है। यह इंटरफ़ेस न केवल पढ़ने और सेट करने के तरीकों की संपत्तियों की परिभाषा का समर्थन करता है, बल्कि अन्य नए ES5 फीचर भी हैं। ES5 विनिर्देश में __DefineXXX__ विधियों को शामिल नहीं किया गया था।



जिन ब्राउज़रों के पास पहले से __defineXXX__ एपीआई कार्यान्वित है, वे संगतता सुनिश्चित करने के लिए इसे अपरिवर्तित समर्थन जारी रख सकते हैं। हालाँकि, ES5 मानक का समर्थन करने वाले ब्राउज़रों की अनुकूलता सुनिश्चित करने के लिए लिखे गए नए कोड में, Object.defineProperty विधि का उपयोग पढ़ने के तरीकों और मूल्यों को निर्धारित करने के लिए किया जाना चाहिए।



विकास टीम को अभी भी IE9 में __defineXXX__ प्रोग्रामिंग इंटरफेस जोड़ने के लिए कहा जा रहा है। यह स्पष्ट क्यों है। कुछ डेवलपर्स के पास पहले से ही कोड है जो इन इंटरफेस का उपयोग करता है, और इस कोड को IE9 में चलाना चाहेंगे। हालांकि, IE9 डेवलपर्स का मानना ​​है कि इन इंटरफेस का समर्थन करना इंटरनेट पर इंटरऑपरेबिलिटी प्रदान करने के मौलिक हित में नहीं होगा। TC39 पहले ही इस API की समीक्षा कर चुका है और यह निष्कर्ष निकाल चुका है कि इसका मानकीकरण अवांछनीय है। यदि IE9 में __defineXXX__ इंटरफेस के लिए समर्थन जोड़ा गया था, तो यह एपीआई इंटरनेट पर एक स्थायी सर्वसम्मति समारोह बनने के करीब होगा; यह अनिवार्य रूप से TC39 के निर्णय को रद्द कर देगा।



दुर्भाग्यवश, अल्पावधि में, यह इस पुराने एपीआई का उपयोग करते हुए वर्तमान में डेवलपर्स के लिए कुछ अतिरिक्त काम करता है। हालाँकि, मौजूदा कोड के लिए एक सरल संगतता पुस्तकालय बनाना जो __defineXXX__ को लागू करता है। Object.defineProperty



विधि का उपयोग करके एक Object.defineProperty



जैसा लगता है।

निष्क्रिय आम सहमति समारोह

जावास्क्रिप्ट कोड में, आप किसी फ़ंक्शन के लिए एक लिंक सेट कर सकते हैं, और आप इसे कोड में भी कॉल कर सकते हैं जो फ़ंक्शन की घोषणा से पहले होता है। यह संभव है क्योंकि जावास्क्रिप्ट तार्किक रूप से कोड के संलग्न शरीर के शीर्ष पर सभी फ़ंक्शन घोषणाओं को "लिफ्ट करता है"। जावास्क्रिप्ट एक ही नाम के साथ कई फ़ंक्शन घोषणाओं के लिए भी अनुमति देता है। एक साधारण परीक्षण फ़ंक्शन पर विचार करें।

  <code> फ़ंक्शन का परीक्षण करेंFuncDeclarationOrder () {</ code> 

  <code> f1 (); </ code> 

  <code> फ़ंक्शन f1 () {चेतावनी ("पहला f1")} </ code> 

  <code> </ code> <code> f1 (); </ code> 

  <code> फ़ंक्शन f1 () {चेतावनी ("दूसरा f1")} </ code> 

  <code> f1 (); </ code> 

  <code>} </ code> 

कॉल के बाद, फ़ंक्शन ने अलर्ट का एक क्रम बनाया: "दूसरा एफ 1", "दूसरा एफ 1", "दूसरा एफ 1"। इसका कारण यह है कि जावास्क्रिप्ट वास्तव में इस फ़ंक्शन को संसाधित करता है जैसे कि इसे निम्नानुसार लिखा गया था:

  <code> फ़ंक्शन का परीक्षण करेंFuncDeclarationOrder () {</ code> 

  <code> फ़ंक्शन f1 () {चेतावनी ("पहला f1")} </ code> 

  <code> फ़ंक्शन f1 () {चेतावनी ("दूसरा f1")} </ code> 

  <code> f1 (); </ code> 

  <code> f1 (); </ code> 

  <code> f1 (); </ code> 

  <code>} </ code> 

ECMAScript विनिर्देश ने ऐतिहासिक रूप से फ़ंक्शन घोषणाओं की नियुक्ति पर केवल एक प्रतिबंध लगाया है। ईसीएमएस्क्रिप्ट मानक में एक नियंत्रण संरचना में एक निर्देश के शरीर के अंदर एक फ़ंक्शन घोषणा को रखने की क्षमता शामिल नहीं है। एक उदाहरण कोड नीचे दिया गया है।

  <code> if (someCondition) {</ code> 

  <code> फ़ंक्शन f1 () {चेतावनी ("f1")} </ code> 

  <code>} </ code> 

जब पार्सिंग, ईसीएमएस्क्रिप्ट विनिर्देश के अनुसार, उपरोक्त कोड एक सिंटैक्स त्रुटि का कारण होगा। हालाँकि, यदि आप इसे किसी भी ब्राउज़र में चलाते हैं, तो ऐसा प्रतीत होता है कि त्रुटि नहीं होगी। फ़ंक्शन की घोषणाओं के लिए समर्थन जहां भी निर्देश की अनुमति है, इंटरनेट पर एक आम सहमति समारोह है। और यदि हां, तो इसे ईएस 5 में शामिल क्यों नहीं किया गया है? ES5 विनिर्देश की धारा 12 वास्तव में इस बारे में कुछ कहती है।



नोट। यह ज्ञात है कि कई आमतौर पर इस्तेमाल किए जाने वाले ईसीएमएस्क्रिप्ट कार्यान्वयन निर्देशों के रूप में फ़ंक्शन घोषणाओं के उपयोग का समर्थन करते हैं। हालांकि, कार्यान्वयन के बीच ऐसे फ़ंक्शन घोषणाओं के लिए लागू किए गए शब्दार्थ में महत्वपूर्ण और अपूरणीय विविधताएं हैं। इन अपूरणीय अंतरों के कारण, एक फ़ंक्शन के रूप में फ़ंक्शन घोषणा के उपयोग से कोड में परिणाम होता है जो कार्यान्वयन के बीच मज़बूती से पोर्टेबल नहीं होता है। यह एक समारोह घोषणा के ऐसे उपयोग को प्रतिबंधित करने या एक अनिवार्य चेतावनी के साथ एक घोषणा के साथ करने के लिए ECMAScript कार्यान्वयनों में अनुशंसित है। ईसीएमएस्क्रिप्ट के भविष्य के संस्करण एक निर्देश के संदर्भ में कार्यों की घोषणा के लिए वैकल्पिक पोर्टेबल साधनों को परिभाषित कर सकते हैं।



इन अपठनीय योगों का क्या अर्थ है? सीधे शब्दों में कहें, विभिन्न ब्राउज़रों का व्यवहार इतना भिन्न था कि सामंजस्य के प्रयास अव्यवहारिक थे।



IE9 क्या करता है? क्या IE9 ES5 विनिर्देश में अनुशंसित कार्यों की ऐसी अनुदेश घोषणाओं को प्रतिबंधित करता है? नहीं, IE9 में इस तरह के विज्ञापनों को IE के पिछले संस्करणों की तरह ही संभाला जाता है।



यह निर्णय क्यों किया गया? क्योंकि ब्राउज़र डेवलपर्स द्वारा पिछले प्रयोगों से पता चला है कि इस तरह के विज्ञापनों को अस्वीकार करने से कई मौजूदा वेब पेजों की निष्क्रियता होती है।



यह भयानक लग सकता है। एक वेब पेज उन कार्यों पर कैसे निर्भर कर सकता है जिनका व्यवहार अलग-अलग ब्राउज़रों में अलग-अलग है और फिर भी, विभिन्न ब्राउज़रों के साथ संगत है? एक संभावित उत्तर: वास्तव में, कोड का उपयोग नहीं किया गया है। यह एक ऐसा कार्य हो सकता है जिसे कभी नहीं कहा जाता है, या जिसके परिणाम पृष्ठ के कामकाज के लिए महत्वपूर्ण नहीं है। दूसरी ओर, यदि जावास्क्रिप्ट कार्यान्वयन इन कार्यों को वाक्यविन्यास त्रुटियों के रूप में मानेगा, तो पूरी स्क्रिप्ट को अस्वीकार कर दिया जाएगा, भले ही फ़ंक्शन कभी भी नहीं कहा गया हो।



डेवलपर्स के लिए इस तरह के एक खतरनाक कार्य का कार्यान्वयन अवांछनीय है। हालांकि, इंटरनेट पर इसका अस्तित्व तय है, इसलिए वस्तुतः कोई विकल्प नहीं है।

कॉन्स्ट के बारे में क्या?

कभी-कभी कोई आश्चर्य होता है कि IE IE की घोषणाओं का समर्थन करेगा। const



एक गैर-मानक जावास्क्रिप्ट एक्सटेंशन है जो "निरंतर नाम" मूल्यों को घोषित करने का एक तरीका प्रदान करता है। एक विशिष्ट अनुप्रयोग कुछ इस तरह दिख सकता है:



const pi=3.14159;







कई ब्राउज़र इस सुविधा का समर्थन करते हैं, लेकिन असामान्य स्थितियों से निपटने और त्रुटियों के रूप में उन्हें परिभाषित करने में महत्वपूर्ण अंतर हैं। ब्राउज़र के व्यवहार में कुछ अंतरों को दिखाने वाला एक उदाहरण यहां "समर्थन" const



:

  <code> // समान नाम के लिए कई कॉन्स्टेंस डिक्लेरेशन के साथ फ़ंक्शन </ code> 

  <code> फ़ंक्शन f () {</ code> 

  <कोड> चेतावनी ('एफ के भीतर क्रियान्वयन'); </ कोड> 

  <code> const x = 1;  // 1 </ code> के रूप में निरंतर x घोषित करें 

  <कोड> अलर्ट (x); </ कोड> 

  <code> const x = 2;  // लगातार x को 2 </ code> के रूप में ओवरराइड करें 

  <कोड> अलर्ट (x); </ कोड> 

  <कोड> x = 3;  // x </ code> के लिए 3 सेट करने का प्रयास करें 

  <कोड> </ कोड> <कोड> चेतावनी (x); </ कोड> 

  <code>} </ code> 

  <कोड> चेतावनी ('कॉल एफ के बारे में');  f (); </ code> 

ब्राउज़र के आधार पर, कोड निम्नलिखित कर सकता है:

• एक सिंटैक्स त्रुटि की रिपोर्ट करें और पृष्ठ को लोड न करें।
• च बुलाते समय अपवाद छोड़ें;
• चेतावनी: '1', '2', '2'। इसका मतलब यह है कि परस्पर विरोधी const
  
  
  
  घोषणाओं की अनुमति है, लेकिन असाइनमेंट की अनदेखी की जाती है;
• अलर्ट '1', '2', '3'। इसका मतलब है कि const
  
  
  
  बिल्कुल वैर की तरह प्रोसेस किया गया है।

वास्तव में, const



डिक्लेरेशन के केवल बहुत सरल अनुप्रयोग विभिन्न ब्राउज़रों के साथ संगत हैं जो घोषणा का समर्थन करते हैं। अधिक जटिल अनुप्रयोगों या परिदृश्यों में से कुछ जो किसी प्रकार की त्रुटि का कारण हो सकते हैं, विभिन्न ब्राउज़रों के बीच संगत नहीं हैं।



वास्तविक जावास्क्रिप्ट कार्यान्वयन केवल तुच्छ उपयोग मामलों की एक छोटी संख्या का समर्थन नहीं कर सकता है। यह कार्यान्वयन एटिपिकल बॉर्डरलाइन मामलों और गलत स्क्रिप्ट के साथ भी करना चाहिए जो वास्तविक वेब पृष्ठों पर उपलब्ध हैं। यह संभावना है कि मानकीकृत विनिर्देश मुख्य रूप से ऐसी स्थितियों के लिए मौजूद हैं। साधारण आम उपयोग के मामलों के साथ क्या करना है आमतौर पर स्पष्ट है। सीमावर्ती मामलों के लिए, संगत कार्यान्वयन के अस्तित्व को सुनिश्चित करने के लिए मानकों के विनिर्देशन की आवश्यकता होती है।



TC39 गंभीरता से ES5 में कास्ट को शामिल करने पर विचार करता है; यह ES5 के शुरुआती प्रोजेक्ट्स में मौजूद है। हालांकि, इसकी परिभाषा और अन्य विज्ञापनों के साथ बातचीत में कई समस्याएं थीं। अंततः, TC39 में एक समझौता किया गया कि कास्ट का मानकीकरण विनिर्देश के "अगले" संशोधन की प्रतीक्षा const



, जो इनमें से कुछ अन्य समस्याओं को हल कर सकता है। संक्षेप में, TC39 समिति ने निर्णय लिया कि एक त्रुटिपूर्ण फ़ंक्शन का मानकीकरण अवांछनीय है। इसके बजाय, उन्होंने भविष्य में const



किसी भी मानकीकरण को स्थगित करने का फैसला किया, जब एक एकल उन्नत डिज़ाइन को सभी ब्राउज़रों में एकीकृत किया जा सकता था।



तो IE9 const



साथ क्या करता है? अब तक, समूह ने उसे समर्थन नहीं देने के निर्णय का पालन किया है। यह अभी तक सर्वसम्मति नहीं है, क्योंकि यह सभी ब्राउज़रों में कभी उपलब्ध नहीं है। मानक के लिए कोई विनिर्देश नहीं है, लेकिन सभी मौजूदा ब्राउज़र कार्यान्वयन के बीच महत्वपूर्ण अर्थ अंतर हैं। इसके अतिरिक्त, यह ज्ञात है कि TC39 ने किसी भी मौजूदा विकल्प को मानकीकृत नहीं करने का निर्णय लिया और ईसीएमएस्क्रिप्ट के भविष्य के संस्करणों में इस मुद्दे पर पुनर्विचार करने का इरादा किया।



ऐसे विज्ञापन का उपयोग करने में सक्षम होने के लिए कई वेबसाइट डेवलपर्स की इच्छा समझ में आती है। हालाँकि, मैं फ़ंक्शन के सशर्त घोषणा के समान एक अन्य स्थिति नहीं बनाना चाहता, जब फ़ंक्शन मौजूद होना चाहिए, लेकिन वेबसाइट डेवलपर्स इसका उपयोग बेहतर होगा यदि वे ब्राउज़र संगतता की परवाह करते हैं। अंततः, ऐसा लगता है कि इंटरनेट के लिए सबसे अच्छा दीर्घकालिक समाधान इसका उपयोग समाप्त करना और इसके पाठ्यक्रम को लेने के लिए मानकीकरण प्रक्रिया की प्रतीक्षा करना है।

निर्णय लेने के लिए राजसी दृष्टिकोण

ये सिर्फ चार ठोस जावास्क्रिप्ट उदाहरण हैं जो प्रदर्शित करते हैं कि IE9 बनाते समय आपको किस तरह के निर्णय लेने हैं। इंटरनेट पर अन्य मानकों और आम सहमति सुविधाओं के साथ कई समान समस्याएं उत्पन्न होती हैं। प्रत्येक मामले में, एक समान विश्लेषण किया जाता है। और मानक क्या कहता है? आपको वास्तव में कितनी वेबसाइटों की आवश्यकता है? क्या यह आम शब्दार्थ के साथ एक आम सहमति समारोह है? क्या कई असंगत फ़ंक्शन विकल्प हैं? क्या मानक समिति इस मुद्दे पर काम करती है? क्या कोई परीक्षण सूट हैं ? क्या दत्तक ग्रहण मानकीकरण प्रक्रियाओं को बढ़ावा देगा या बाधित करेगा? अंततः, यह व्यक्तिपरक निर्णय का विषय है, और इसलिए निर्णय लेने के लिए एक रियायती और सुसंगत दृष्टिकोण सुनिश्चित करने के लिए हर संभव प्रयास करना महत्वपूर्ण है।



PS आपने एचटीएमएल 5 पर पहले ही अनुमान लगा लिया है ?