<आधार> हानिकारक है।

<base>



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

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

वह किस बारे में बात कर रहा है?

पता ब्राउज़र example.com/blog/record1



example.com/blog/record1



, ../css/blog.css



लिंक को हल करने का प्रयास करेगा example.com/blog/css/blog.css



example.com/blog/css/blog.css



शायद यह इतना बुरा नहीं है, लेकिन ऐसी स्थिति में जहां पता कुछ ऐसा होगा example.com/blog/tags/test



example.com/blog/tags/test



, उसी लिंक में हल होगा example.com/blog/tags/css/blog.css



example.com/blog/tags/css/blog.css



जाहिर है, हालांकि कई यूआरएल पर एक ही फाइल की उपस्थिति को लागू किया जा सकता है, यह स्पष्ट रूप से करने योग्य नहीं है। भले ही css



फ़ोल्डर लेआउट टेम्प्लेट के रूप में एक ही स्थान पर हो, रिश्तेदार संबोधन समस्या दूर नहीं होगी।

जैसा कि आमतौर पर ऐसे मामलों में होता है

दुनिया भर के वेब प्रोग्रामर और टेक्नोलॉजिस्ट इस कठिन परिस्थिति में <base>



टैग को याद करते हैं। विनिर्देश के अनुसार:

BASE



तत्व लेखकों को दस्तावेज़ के आधार यूआरआई को स्पष्ट रूप से निर्दिष्ट करने की अनुमति देता है।

यदि कोई BASE



तत्व निर्दिष्ट किया गया है, तो यह HTML दस्तावेज़ के HEAD



खंड में मौजूद होना चाहिए, बाहरी संसाधनों को संदर्भित करने वाले तत्वों से पहले। BASE



तत्व में निर्दिष्ट पथ जानकारी केवल उस दस्तावेज़ में यूआरआई को प्रभावित करती है जिसमें तत्व मौजूद है।

समाधान शानदार ढंग से सरल प्रतीत होता है: base href="http://example.com/templates/"



तत्व में base href="http://example.com/templates/"



निर्दिष्ट करके, हम ब्राउज़र को उपरोक्त सभी संबंधित URL को उसी स्थान पर स्थित वास्तविक जीवन की फ़ाइलों के लिंक के लिए हल करने के लिए बाध्य करेंगे। हमारे रिश्तेदार पथ में निर्देशिका पेड़ की यात्रा करने की आदत से छुटकारा पाने से, हम इन समस्याओं से पूरी तरह से छुटकारा पा लेंगे।

क्या गलत है?

इस तरह के उद्देश्यों के लिए <base>



का उपयोग करते समय सामने आई समस्याओं की एक संक्षिप्त सूची है:

1. साइट अन्य डोमेन से काम करना बंद कर देती है - जब आप ब्राउज़ करने की कोशिश करते हैं www.example.com



www.example.com
   
   
   
   ब्राउज़र संसाधनों को खींचने की कोशिश करेगा example.com



example.com
   
   
   
   ( www के बिना )। CSS और छवियों के लिए, यह अभी तक डरावना नहीं है, लेकिन स्क्रिप्ट के साथ (विशेष रूप से इंटरनेट एक्सप्लोरर के लिए HTC), कुकीज़, ActiveX, फ्लैश (यदि यह सर्वर के साथ बातचीत का अर्थ है), साथ ही साथ https के माध्यम से पहुंच के मामले में, उपयोगकर्ता अधिक या कम गंभीर होगा समस्याओं। किसी साइट को किसी अन्य डोमेन पर ले जाने की कठिनाइयों के बारे में भी सोचें (या किसी अन्य साइट के लिए उसके इंजन का उपयोग करके)।
2. <Base>
   
   
   
   लिंक में उपयोग किए गए सापेक्ष पते को भी प्रभावित करता है, जो अब आधार पथ के अनुसार भी हल हो गए हैं। भले ही आप base href="
   
   
   
   निर्दिष्ट करें example.com



example.com



/"
   
   
   
   , पहली समस्या में निर्दिष्ट डोमेन के बीच टकराव बना रहता है।
3. मनोवैज्ञानिक योजना की समस्या: एक बड़े ब्रांचिंग, टेम्प्लेट की मॉड्यूलर संरचना या कोड की एक बड़ी मात्रा के साथ परियोजनाओं में दिया गया मूल पथ एक "ताज़ा" लेआउट डिज़ाइनर को भ्रमित कर सकता है जो परियोजना से अपरिचित है, लेकिन जिसके पास पृष्ठ पर कुछ चित्रों को सम्मिलित करने का कार्य है।
4. सबसे आश्चर्यजनक समस्या: सभी का पसंदीदा IE ब्राउज़र, यदि दस्तावेज़ में एक <base>
   
   
   
   टैग देखा जा रहा है और निर्दिष्ट सीएसएस float
   
   
   
   प्रॉपर्टी के साथ मार्कअप तत्व हैं (उदाहरण के लिए, <div style="float: left;"> !</div>
   
   
   
   ), नहीं आपको ऐसे तत्वों में माउस के साथ पाठ का चयन करने की अनुमति देता है। किस तरह का कनेक्शन हो सकता है यह स्पष्ट नहीं है, लेकिन एक तथ्य है।
5. CSS फिल्टर (उदाहरण के लिए, AlphaImageLoader) में प्रयुक्त पथों को हल करते समय वही IE आधार पथ को अनदेखा करता है और सापेक्ष लिंक को हल करने की कोशिश करता है, जैसे कि कोई <base>
   
   
   
   नहीं था। यदि आप साइट की जड़ को आधार पथ के रूप में निर्दिष्ट करते हैं, तो आप इसे नोटिस नहीं करेंगे, लेकिन इस क्षमता में उपयोग किए गए किसी भी अन्य फ़ोल्डर के साथ, पीएनजी के लिए मानक "दवा" काम करना बंद कर देता है।

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

यह मुझे लगता है कि उपरोक्त कठिनाइयों के संबंध में <base>



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

अर्ध-निरपेक्ष संबोधन

तथ्य यह है कि अगर हम बस सर्वर रूट से संसाधनों को संबोधित करते हैं, /



("स्लेश") प्रतीक से शुरू करते हैं, तो हम बिना किसी <base>



काम कर सकते हैं, जबकि साइट को किसी भी डोमेन से काम करने की अनुमति है और कुछ और फायदे हैं। मैं इस पते को कॉल करता हूं, जैसा कि आम तौर पर इस्तेमाल किए जाने वाले रिश्तेदार के विपरीत है, "अर्ध-निरपेक्ष" (क्योंकि प्रोटोकॉल और डोमेन निर्दिष्ट नहीं हैं, वास्तविक पूर्ण पते के विपरीत)।

यही है, समस्याग्रस्त उदाहरण में निर्दिष्ट CSS फ़ाइल को /templates/css/blog.css



रूप में संबोधित किया जाना चाहिए। ऐसा लिंक किसी भी डोमेन (साथ ही प्रोटोकॉल और पोर्ट) के साथ काम करेगा, क्योंकि डिफ़ॉल्ट ब्राउज़र बेस डॉक्यूमेंट के रूप में तथाकथित दस्तावेज़ की निर्देशिका का उपयोग करेगा (यानी, उदाहरण के लिए, example.com/blog/record1



example.com/blog/record1



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

उसी समय, मैं एक सावधानीपूर्वक अनुक्रम का आह्वान करता हूं: हर जगह, सीएसएस में url()



निर्माण और फ़िल्टर सहित और दस्तावेज़ों के बीच हाइपरलिंक, इस संकेतन का उपयोग किया जाना चाहिए, जब तक हम एक ही डोमेन के भीतर काम करने की बात कर रहे हैं। यह फ़ाइलों के हैंडलिंग में कुछ स्वतंत्रता की अनुमति देगा (उदाहरण के लिए, सीएसएस फ़ाइल को images



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

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

उस समय मैंने फ़्लैश टेक्नोलॉजिस्ट से इस फाइल को /flash/file.txt



रूप में /flash/file.txt



करने के लिए कहकर समस्या हल की। इससे सर्वर पर समस्या का समाधान हो गया, लेकिन इसने स्वयं फ्लैश टेक्नोलॉजिस्ट के जीवन को बर्बाद कर दिया (जब स्थानीय फाइल सिस्टम में काम करते हैं, तो C:/flash/file.txt



जैसे मार्ग में इस तरह के पते की अनुमति है)। बेशक, एक बेहतर उपाय है।

प्वाइंट फ्लैश उसकी जगह पर

जब एक फ़्लैश फिल्म को कार्यान्वित करना होता है जिसे अपने सर्वर के साथ http (उदाहरण के लिए, वेब के माध्यम से फ़ाइलों को पढ़ने) के माध्यम से संवाद करने की आवश्यकता होती है, तो आप विशेष रूप से <base>



का उपयोग किए बिना प्रत्येक फिल्म के लिए एक आधार निर्देशिका निर्दिष्ट कर सकते हैं। ऐसा करने के लिए, फ्लैश ड्राइव एम्बेड कोड में, आपको "अर्ध-निरपेक्ष" रूप में वांछित निर्देशिका के पते के बराबर मूल्य के साथ आधार पैरामीटर निर्दिष्ट करने की आवश्यकता है। अर्थात्, मेरे मामले में, फ्लैश ड्राइव एम्बेड कोड इस तरह दिखता था:

<object …>

<param name="base" value="/flash/">

…

<embed base="/flash/" src="/flash/01.swf" …>

…





"सुविधाजनक" प्रकाशन कोड के साधनों के लिए हबराब्र के लेखकों के लिए विशेष धन्यवाद

वास्तव में, मैं अभी भी बेस डायरेक्टरी को सेट करता हूं, लेकिन मैंने इसे केवल एक फ्लैश फिल्म के लिए किया था, प्रोटोकॉल और डोमेन नाम को निर्दिष्ट किए बिना (उन्हें उसी तरह से प्रतिस्थापित किया जाएगा, जब "सेमी-निरपेक्ष" लिंक को हल करते हुए)। अगली क्लिप के लिए, आप एक अलग निर्देशिका निर्दिष्ट कर सकते हैं, या यदि आप सर्वर के वेब स्थान की मूल निर्देशिका के साथ सहज हैं, तो आप बस " /



" निर्दिष्ट कर सकते हैं। फ्लैश टेक्नोलॉजिस्ट अब वेब सर्वर स्पेस में फ्लैश ड्राइव की स्थिति के बारे में सुनिश्चित कर सकता है और संसाधनों को सुविधाजनक तरीके से इंगित कर सकता है (वैकल्पिक रूप से "अर्ध-निरपेक्ष")।

पुनश्च

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



यदि आप मुझ पर विश्वास नहीं करते हैं, या किसी कारण से इस विषय पर आपकी अपनी राय है - मेरा सुझाव है कि आप बहुत अधिक चर्चा न करें, लेकिन अपने व्यक्तिगत ब्लॉग में अपनी राय व्यक्त करें। यहां केवल मेरा अपना IMHO लिखा है, क्यों <आधार> हानिकारक है, और इसकी अनुपस्थिति में क्या करना है।