लघु पता लगाने की सुविधा

आधुनिक वेब ब्राउज़र क्षमताओं का निर्धारण करने के लिए दो मुख्य तकनीकों का उपयोग करता है:
(ए) उपयोगकर्ता एजेंट को पार्स करें, ब्राउज़र संस्करण का निर्धारण करें और ब्राउज़र संस्करण के अनुसार कोड में स्विच लिखें;
(b) आवश्यक फ़ील्ड / कॉल को आवश्यक विधियों की जाँच करके सुविधाओं के लिए समर्थन निर्धारित करने का प्रयास करें।

ऐतिहासिक रूप से, दूसरा विकल्प अधिक सही माना जाता है, और यह सभी आधुनिक परियोजनाओं द्वारा कार्यान्वित किया जाता है। यह कहने के लिए पर्याप्त है कि jQuery इस तरह से चला जाता है।

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

यह सब अच्छा और सही है, लेकिन केवल छोटी परियोजनाओं के लिए।



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

यहां ट्रांसफॉर्म 3 डी ने आपके लिए क्रोम में काम किया, और फिर 15 वें संस्करण में इसे लिया और तोड़ दिया:
code.google.com/p/chromium/issues/detail?id=119076&can=1&q=transform%203d&sort=-pri&colspec=ID%20Pri%20Mstone%20ReleaseBlock%20OS%20Area%20Feature%20Status%20Owner%20Summary
और उन्होंने इसकी मरम्मत केवल 21 वीं में की।

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

या यहां ओपेरा 10-11 में, सही ढंग से काम करने के लिए संक्रमण के लिए, आपको अपने हाथों से रिफलो को कॉल करना था, पृष्ठ पर कुछ तत्व को घुमाते हुए, अन्यथा एनीमेशन कलाकृतियां दिखाई देंगी। यह कैसे पता लगाने के लिए स्वचालित रूप से?

ब्राउज़रों के अलावा, पटकथा लेखकों की एक विशाल सेना भी है। उदाहरण के लिए, डिफ़ॉल्ट विषय जूमला में! 1.5 अभी भी mootools 1.12 द्वारा उपयोग किया जाता है, जो निम्नलिखित कहता है:

Array.extend({ forEach: function (fn,bind) { for (var i=0, j=this.length; i<j; i++) fn.call(bind,this[i],i,this); } }); 

और ब्राउज़र कार्यान्वयन में , निम्नलिखित लिखा है:

 Array.prototype.forEach = function(fn, scope) { for(var i = 0, len = this.length; i < len; ++i) { fn.call(scope || this, this[i], i, this); } } 

यानी ब्राउज़र कार्यान्वयन, दूसरे पैरामीटर के साथ सेट नहीं किया जाता है, सरणी को संदर्भ के रूप में प्रतिस्थापित करता है, लेकिन mutulzovaya नहीं करता है। और आपका सुंदर पुस्तकालय जो फीचर डिटेक्शन का उपयोग करता है, वह जुमला में IE में बग की तरह काम करता है - क्योंकि ऐरे प्रोटोटाइप में फॉरएच है, लेकिन यह सही तरीके से काम नहीं करता है। यहाँ क्या करना है? फ़ीचर का पता लगाने के लिए फ़ीचर सत्यापन जोड़ें या फ़ॉरचैट में संदर्भों का उपयोग करना बंद करें?

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

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