वेब ब्राउज़र को बेहतर बनाने में मदद करें

आप चुपचाप अगली डिज़ाइन बना रहे हैं, और इस बार आपने CSS3 और HTML5 को आज़माने का फैसला किया, क्योंकि अब ये नए विनिर्देश पूरी तरह से अधिकांश आधुनिक ब्राउज़रों द्वारा समर्थित हैं। आपने समय-समय पर कोड की एक सभ्य मात्रा का निर्माण किया है, समय-समय पर यह सोचकर कि कैसे नई प्रौद्योगिकियां आपके काम को सरल बनाती हैं, और अचानक यह आपके लिए थोड़ी देर रुकने और अन्य ब्राउज़रों में पृष्ठ के संचालन की जांच करने के लिए हुई। आप पहले से ही नर्वस होना शुरू कर रहे हैं, क्योंकि बकरी स्पष्ट है - एक समान जांच बहुत पहले चरणों में की जानी चाहिए थी। आप अपने पास मौजूद सभी ब्राउज़र लॉन्च करते हैं और अपने कंप्यूटर पर फुसफुसाते हैं "कृपया काम करें।" ब्राउज़र ए, सब कुछ काम करता है। आप मुस्कुराते हैं, राहत महसूस करते हैं। ब्राउज़र बी और सब कुछ ठीक है। आप मुस्कुराते हैं और आपका मूड बढ़ जाता है। ब्राउज़र सी ... "फ़्यू यूयूयूयूयू यू यू यू यू यू यू!"


आपको आश्चर्य हो सकता है, लेकिन यह स्थिति हमेशा वेब डेवलपर की गलती से दूर है। वेब ब्राउज़र बाजार में मौजूदा हथियारों की दौड़ और वेब प्रौद्योगिकियों और विशिष्टताओं के बीच अविश्वसनीय प्रगति के साथ, ब्राउज़र निर्माता समय-समय पर उचित परीक्षण के बिना भी जल्दी में नई सुविधाओं को पेश कर रहे हैं। CSS3 और HTML5 अपने पूर्ववर्तियों की तुलना में बहुत अधिक जटिल हैं, नई सुविधाओं के संभावित संयोजनों की संख्या ऑफ-स्केल है, जो अक्सर बग का कारण है: दो (या अधिक) टुकड़े एक साथ परीक्षण नहीं किए गए थे। नतीजतन, ब्राउज़र डेवलपर्स को बग को ठीक करने के लिए अधिक समय देना चाहिए।

मुझे डेवलपर्स को बग की रिपोर्ट क्यों करनी चाहिए?

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

शायद आपको लगता है कि रिपोर्टिंग बग व्यर्थ है, क्योंकि उन्हें ठीक करने में वर्षों लगेंगे, और उपयोगकर्ताओं को ब्राउज़र के एक निश्चित संस्करण में अपग्रेड करने में और भी अधिक समय लगेगा। मैं आपको एक रहस्य बताता हूं: IE को छोड़कर सभी ब्राउज़रों में, सब कुछ बहुत बेहतर है। आजकल, फ़ायरफ़ॉक्स, ओपेरा, सफारी और क्रोम के उपयोगकर्ता बहुत जल्दी नए संस्करणों के लिए अपडेट करते हैं, ब्राउज़र डेवलपर्स के लिए बड़े हिस्से में धन्यवाद - अपडेट करने की पेशकश के साथ खिड़कियों को परेशान करना, नए संस्करणों का प्रचार या यहां तक ​​कि उपयोगकर्ता के ज्ञान के बिना पूरी तरह से स्वचालित मौन अपडेट (हम क्रोम के बारे में बात कर रहे हैं) )। कीड़े बहुत जल्दी तय हो जाते हैं, खासकर जो डेवलपर्स को विधिवत सूचित किए गए हैं।

बग का कारण जानें

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

यहाँ एल्गोरिथ्म है जिसके द्वारा मैं कोड को न्यूनतम रखता हूँ:

1. अपनी परियोजना को उस रूप में कहीं कॉपी करें जिसमें आपको बग मिला;
2. कोड खोलें और पृष्ठ पर उपयोग की जाने वाली CSS और JS फ़ाइलों की सामग्री को धीरे-धीरे हटाना शुरू करें। अंत में, अगले अनइंस्टॉल के बाद, आप पाएंगे कि बग गायब हो गया है। इस मामले में, हटाए गए कोड के टुकड़े को वापस करें और बाकी सब से छुटकारा पाने की कोशिश करें ताकि बग बना रहे। दुर्लभ मामलों में, CSS और JS को हटाना व्यर्थ हो सकता है, जिसका अर्थ है कि सबसे अधिक समस्या HTML के साथ है;
3. अब आपको कोड के विशिष्ट ब्लॉक को खोजने की आवश्यकता है जो बग पैदा कर रहा है। धीरे-धीरे और सावधानी से कोड के टुकड़ों को टिप्पणी में संलग्न करें जब तक कि समस्या दूर न हो जाए। व्यक्तिगत रूप से, मेरे लिए बाइनरी विधि के साथ ऐसा करना बहुत आसान है: पहले, आधे कोड के बारे में टिप्पणी करें; यदि बग शेष है, तो टिप्पणी-आउट कोड हटा दें, शेष कोड का आधा भाग टिप्पणी करें और प्रक्रिया दोहराएं। दुर्भाग्य से, अतिरिक्त कचरे से कोड की सफाई में देरी हो सकती है - ऐसी परिस्थितियां थीं जब एक बग केवल एक निश्चित तरीके से कुछ कोड को मिलाते समय दिखाई देता था;
4. शेष सीएसएस और जेएस कोड को फ़ाइलों से HTML पेज पर style या script में लपेटकर स्थानांतरित script । यह रिपोर्ट को अधिक सटीक बना देगा;
5. अब अनावश्यक एचटीएमएल को हटाने का समय आ गया है। सबसे पहले, किसी भी पहचान या व्यक्तिगत जानकारी से छुटकारा पाएं, फिर बाकी सब को हटा दें। उदाहरण के लिए, यदि बग सीएसएस के काम से संबंधित है, तो उन सभी तत्वों को हटा दें जो बग के कारण होने वाली शैली पर लागू नहीं होते हैं;
6. title की सामग्री को बग से संबंधित किसी चीज़ में बदलें।

अब आपके पास एक साफ, पठनीय कोड है जो इस या उस त्रुटि का कारण बनता है, लेकिन सबसे पहले आपको इसकी जांच करनी चाहिए। क्या आप सुनिश्चित हैं कि यह मान्य है? ब्राउज़र डेवलपर वेब कोडर्स की त्रुटियों को ध्यान में नहीं रख सकते हैं और अपने उत्पाद को सामान्य रूप से त्रुटि कोड बना सकते हैं। वैकल्पिक रूप से, ऑनलाइन सत्यापनकर्ताओं का उपयोग करें।

यदि आपके पास अतिरिक्त समय है और आप बगरेपोर्ट को उसके आदर्श रूप में लाना चाहते हैं, तो आपको निम्नलिखित कार्य करने चाहिए:

1. कोड में मामूली बदलाव करने की कोशिश करें, ताकि आप बग की सीमा का पता लगा सकें। उदाहरण के लिए, यदि आप पाते हैं कि ब्राउज़र border-radius: 50% सही ढंग से नहीं संभालता है border-radius: 50% , देखें कि क्या कोई बग अलग मूल्य (उदाहरण के लिए, 40%) के साथ दिखाई देता है। यहां तक ​​कि अगर बग दिखाई नहीं देता है, तो रिपोर्ट में अपने प्रयोगों का उल्लेख करना सबसे अच्छा है ताकि डेवलपर्स को उन्हें दोहराना न पड़े;
2. कोड में परिवर्तन करने की कोशिश करें, जो व्यवहार में कुछ भी नहीं बदलना चाहिए, उदाहरण के लिए, em सभी मूल्यों को em से px परिवर्तित करें। फिर, परिणाम की परवाह किए बिना, रिपोर्ट में किए गए कार्यों का उल्लेख करें।

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

क्या मुझे बग की रिपोर्ट करनी चाहिए?

रिपोर्ट प्रकाशित नहीं करने के कई मुख्य कारण हैं:

• वास्तव में, आपने बग के लिए जो गलती की थी, वह नहीं है;
• बग को पहले से ही नवीनतम रात के संस्करण में तय किया गया है;
• इस बग की सूचना पहले ही किसी और ने दे दी है।

तीनों कारणों से चलो।

बग या बग नहीं?

ज्यादातर मामलों में, यदि आपने कचरे से कोड को साफ किया और केवल बग का कारण बनता है, तो आप बहुत आसानी से यह निर्धारित कर सकते हैं कि क्या अवलोकन त्रुटि ब्राउज़र डेवलपर्स के काम का परिणाम है

किसी तरह बहुत पहले मैंने पाया कि outline-color: invert सभी ब्राउज़रों में काम नहीं करता है। सटीक होने के लिए, यह फ़ायरफ़ॉक्स, सफारी और क्रोम के बारे में था। सूचीबद्ध ब्राउज़रों ने इस कोड को अनदेखा नहीं किया है, लेकिन इसे संसाधित किया है जैसे कि मैं currentColor का उपयोग कर रहा था। बेशक, मैंने कोड को साफ किया, त्रुटि को अलग किया, और सूचीबद्ध सभी ब्राउज़रों के बगट्रैकर्स पर रिपोर्ट बनाई। कुछ समय बाद, मुझे बताया गया कि विनिर्देश में एक फुटनोट था जिसमें कहा गया था कि ब्राउज़र डेवलपर्स को इस पैरामीटर को इस तरह से संसाधित करने का अधिकार था, इसलिए यह पता चला कि इसमें बग की तरह गंध नहीं थी। नैतिक यह है कि रिपोर्ट प्रकाशित करने से पहले आपको कथित रूप से टैग किए गए मापदंडों के विनिर्देश को ध्यान से पढ़ने की आवश्यकता है। इसके अलावा, ऐसी विशेषताओं को पहचानते हुए, आप एक डेवलपर के रूप में मूल्यवान अनुभव प्राप्त करते हैं।

एक और मामला था, मैंने CSS3 विनिर्देशों के माध्यम से लिया और यह वर्णन किया गया कि सीमाएँ कैसे काम करती हैं, जहाँ यह लिखा गया था कि CSS3 में आप प्रतिशत का उपयोग करके उनकी चौड़ाई का संकेत दे सकते हैं। बेशक, मेरे हाथ कंघी कर रहे थे और मैंने इस सुविधा का परीक्षण करने का फैसला किया, लेकिन एक भी आधुनिक ब्राउज़र ने मेरे द्वारा पढ़े गए विनिर्देश के अनुसार कोड का प्रतिपादन नहीं किया। मैंने एक बग रिपोर्ट डिज़ाइन की और प्रकाशित की, जिसका उत्तर मुझे यह कहते हुए दिया गया कि यह सुविधा विशिष्टताओं के नवीनतम, देव संस्करण (अर्थात अप्रकाशित) से हटा दी गई थी। इस कहानी का नैतिक सरल है: जब आप बग को विनिर्देशों के साथ तुलना करते हैं, तो प्रकाशित के बजाय देव संस्करण पढ़ें।

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

मुझे अपने व्यवहार में सबसे अपमानजनक मामला याद है। मैंने एक बग रिपोर्ट बनाई और ओपेरा बग ट्रैकर पर प्रकाशित किया, जिसमें स्थिति का वर्णन किया गया था जब pointer-events काम नहीं करती थीं select में संलग्न किया गया था select और परिणामस्वरूप मुझे स्पष्ट रूप से सूचित किया गया था कि pointer-events इस ब्राउज़र द्वारा समर्थित नहीं हैं।

दुर्लभ मामलों में, एक बग वास्तव में एक बग है, लेकिन इसका किसी विशेष ब्राउज़र से कोई लेना-देना नहीं है। मार्कअप भाषाओं के विनिर्देशों में कभी-कभी त्रुटियां भी होती हैं। इस तरह के बगों को एक या दूसरे विनिर्देश के डेवलपर्स की वेबसाइटों को सूचित किया जाना चाहिए (सीएसएस के मामले में, आपको डब्ल्यू 3 सी बग ट्रैकर की आवश्यकता है)। इस तरह के एक विदेशी मामले में भी, उपरोक्त निर्देश अभी भी लागू हैं।

क्या लेटेस्ट नाइटली बिल्ड में बग फिक्स किया गया था?

यदि आपको अभी भी ब्राउज़र के "रात" संस्करण नहीं मिले हैं, तो आपको अभी भी ऐसा करना चाहिए। यहां सबसे लोकप्रिय ब्राउज़रों के सबसे हालिया (संभावित रूप से अस्थिर) बिल्ड की सूची है:

• IE 10 प्लेटफ़ॉर्म पूर्वावलोकन 2
• रात में फ़ायरफ़ॉक्स
• ओपेरा अगला
• क्रोम कैनरी
• वेबकिट रात को बनाता है

जाहिर है, अगर बग ब्राउज़र के नवीनतम रात संस्करण में प्रकट नहीं होता है, तो आपको बग रिपोर्ट नहीं करनी चाहिए। बस स्थिर रिलीज शाखा में तय होने तक इंतजार करें। दूसरे शब्दों में, आप सभी की जरूरत है दृढ़ता, युवा Padawan।

क्या एक समान बग्रेपोर्ट पहले से ही बनाया गया है?

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

यदि रिपोर्ट नहीं मिली है, तो पर्यायवाची का उपयोग करके खोज क्वेरी को बदलने का प्रयास करें, उन सभी संभावित नामों के माध्यम से सोचने का प्रयास करें जिन्हें आप खोज रहे हैं।

किसी रिपोर्ट के साथ आपसे आगे पाया? छोड़ने के लिए जल्दी मत करो, कुछ बगट्रैकर्स (जैसे बुग्जिला) मतदान का समर्थन करते हैं। मुझे यकीन नहीं है कि डेवलपर्स बग रिपोर्ट की रेटिंग को ध्यान में रखते हैं, लेकिन यदि ऐसा है, तो उच्च रेटिंग मिली हुई त्रुटि के तेजी से उन्मूलन में योगदान देता है।

विभिन्न इंजन, विभिन्न बगट्रॉकर्स

प्रत्येक ब्राउज़र का अपना बग ट्रैकर है जो उपयोगकर्ताओं द्वारा पाई गई त्रुटियों को प्रकाशित करने के लिए डिज़ाइन किया गया है:

• इंटरनेट एक्सप्लोरर
• फ़ायरफ़ॉक्स
• ओपेरा जादूगर
• वेबकिट
• क्रोम

कृपया ध्यान दें कि सफारी और क्रोम एक ही वेबकिट इंजन पर आधारित हैं, इसलिए यदि दोनों ब्राउज़र में बग दिखाई देता है, तो आपको वेबकिट बग ट्रैकर को लिखने की आवश्यकता है।

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

एक अच्छी बग रिपोर्ट बनाना

एक अच्छी रिपोर्ट का सबसे महत्वपूर्ण हिस्सा अनावश्यक कचरे से साफ किया गया कोड है। यह सबसे कठिन हिस्सा है, बाकी को पांच मिनट से ज्यादा नहीं लगेगा।

अच्छा संक्षिप्त विवरण

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

जब body{display:table} का उपयोग किया जाता है तो बैकग्राउंड इमेज गायब हो जाती है (फ़ायरफ़ॉक्स में सही सेंटिंग + स्क्रॉलिंग के लिए सामान्य सीएसएस हैक)

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

बुनियादी जानकारी

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

क्या नहीं करना चाहिए

कभी नहीं, कभी भी एक रिपोर्ट में कई अलग-अलग बगों के बारे में जानकारी न दें। यह इस समय समस्या को ठीक करने के लिए भ्रम और अतिरिक्त बाधाएं पैदा करता है।

दो, मैं समझ सकता हूं कि कुछ त्रुटियां वर्कफ़्लो को नाराज़, बाधित और धीमा कर सकती हैं, लेकिन अशिष्टता आपकी मदद नहीं करेगी। शांत रहें, विशेष रूप से रिपोर्ट की चर्चा में, और अपने आप को विचारों को छोड़ दें जैसे "मुझे विश्वास नहीं हो सकता है कि ये मोरन बग की तरह बात कर सकते हैं!"

आगे क्या है?

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

---

मूल लेख: समुदाय की मदद करें: ब्राउज़र कीड़े की रिपोर्ट करें
पोस्ट करनेवाले: Lea Verou
प्रकाशन की तारीख: 09/07/11

---

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