iframes एक भयानक विचार हैं?

Question

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

यह विजेट जावास्क्रिप्ट को थोड़ा और जटिल बनाता है, और मुझे चिंता है कि यह सबसे अच्छा कार्यान्वयन नहीं हो सकता है।

क्या आपके पास कोई सलाह है? यह सुनकर एक बड़ी मदद होगी कि अन्य लोग iframes के बारे में क्या सोचते हैं।

Answer 1

नहीं, iframes के साथ कुछ भी गलत नहीं है। अगर आप तीसरे पक्ष की सामग्री की सेवा शुरू करने जा रहे हैं तो इफ्रेम शायद एक बेहतर विचार है।

आगामी HTML5 spec भी इस तरह की स्थितियों के लिए iframes में अधिक सुरक्षा सुविधाओं का निर्माण करने की योजना बना रहा है, इसलिए मैं अब भी उनका उपयोग करने के लिए अच्छा अभ्यास मानता हूं।

Answer 2

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

Answer 3

हाल ही में एक चीज जो मैंने खोजी है वह है .aspx पेज अंदर एम्बेडेड iframes को कभी-कभी कुकीज़ खोने में समस्याएं होती हैं, जिसके कारण मैं उस एप्लिकेशन में खो गया सत्र राज्य खो देता था।

मेरे लिए, यह एक परिदृश्य में था जहां एक अलग विकास की दुकान मेरे अपने पृष्ठ में मेरे .aspx पृष्ठों में से एक का उपभोग कर रही थी। इसका मतलब है कि हम अलग-अलग सर्वर पर थे, जो मुख्य हो सकते हैं या नहीं भी हो सकते हैं।

जाहिर है यह मूल पृष्ठ के कारण बच्चे पृष्ठ के लिए कुकीज़ को अस्वीकार कर रहा है ... सत्र कुकी के रूप में, सत्र चला जाता है।

कैसे की विशिष्ट यांत्रिकी इस काम करता है एक छोटे से शामिल हैं: More Details

यह समस्या फ़ायर्फ़ॉक्स को प्रभावित नहीं किया था, लेकिन यह IE7 में दिखाने की थी और यह कुछ घंटों के लिए एक असली रहस्य था।

इसके अलावा, मुझे एक बिंदु पर ऊपर दिए गए आलेख का खंडन करना होगा। लेख कहता है कि यदि आप युक्त पेज भी एक .aspx है तो आपको यह नहीं मिलता है ... इस मामले में, यह सच नहीं था क्योंकि दोनों पृष्ठ .aspx थे।

इस स्थिति के बारे में लेख कहता है कि बाकी सब कुछ पर कुछ संदेह है, लेकिन इससे एक संकल्प हुआ, इसलिए यह कुछ भी है।

HttpContext.Current.Response.AddHeader("p3p", "CP=\""IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT\""") 

... और: पृष्ठ की Init घटना में - (मैं इसे कभी नहीं सुना था गोपनीयता प्राथमिकताएं परियोजना) शीर्षक

लेख के रूप में सुझाव दिया है, मैं निम्नलिखित कोड है, जो एक पी 3 पी injects में डाल जिसने समस्या को ठीक किया।

Answer 4

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

Answer 5

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

देखें: overflow property

Answer 6

ज़रूरी नहीं है, जब तक कि iframe के भीतर सामग्री उम्मीद के मुताबिक है।

Answer 7

पहले XMLHttpRequest व्यापक रूप से इस्तेमाल हो गया, लोग जावास्क्रिप्ट और iframes के संयोजन का उपयोग कर रहे थे पूरा पृष्ठ रीफ्रेश कर के बिना एक गतिशील फैशन में सामग्री को सर्व करने की।

ताकि आप इसे snags कि आप हिट होने की संभावना है की एक बहुत कुछ करने के लिए वैकल्पिक हल खोजने का एक अपेक्षाकृत आसान समय होना चाहिए साइटों इस तरह से विकसित करने के बारे में बहुत सारी जानकारी नहीं है।

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

document.domain = 'somedomain.com'; 

इस तरह के कामकाज के बारे में वेब पर बहुत सारी चीज़ें हैं।

गुड लक!

Answer 8

व्यक्तिगत रूप से, मैं से बचूंगा यदि आप बिना किसी परेशानी के कर सकते हैं। जावास्क्रिप्ट का उपयोग करना (या AJAX यदि आपको गतिशील रूप से लोड करने की आवश्यकता है), तो आप आसानी से केवल एक div का उपयोग कर सकते हैं और सामग्री को आवश्यकतानुसार बदल सकते हैं - कुछ मामलों में यह आपको अधिक लचीलापन देगा और आपके जेएस को सरल बना देगा, खासकर यदि बहुत कुछ है अपने विजेट और शेष पृष्ठ के बीच बातचीत का।

कहा कि, मैं दोनों विकल्पों की जांच चाहते हैं, और जे एस पथ बहुत मुश्किल या जटिल लगता है, तो बस iframes के साथ चलते हैं।

Answer 9

उनके साथ केवल एक "वास्तव में खराब" चीज है जिसे मैं जानता हूं।

अपने 3 पार्टी कुछ जावास्क्रिप्ट करता है, कि उनके डोम संशोधित करने के लिए एक सा बहुत जल्दी ... IE6 और IE7 ओह तो बेकार "Operation Aborted" त्रुटि फेंक देंगे, तो बाहर खाली न केवल आइफ्रेम, प्रयास करता है लेकिन पूरे आस-पास के पृष्ठ। (उदाहरण के लिए आपकी साइट के बंद दिखाई देता है)

यह IE8 में तय नहीं है, लेकिन दुर्घटना बेहतर नियंत्रित किया जाता है। सुनिश्चित करें कि यदि आप उन्हें प्रयोग कर रहे हैं वे उन कारणों के लिए आवश्यक कर रहे हैं -

Answer 10

मेरे अनुभव में, iframes या तो हैक्स या समय सेवर कर रहे हैं। यदि आपके पास सामग्री पर नियंत्रण है (या मिररिंग या स्क्रैपिंग के माध्यम से नियंत्रण प्राप्त कर सकते हैं) तो आपको AJAX या सर्वर-साइड का उपयोग करने पर विचार करना चाहिए, बाहरी डेटा को खींचने और पृष्ठ से इसे धक्का देने के लिए - इसमें अधिक लचीला होना समाप्त हो जाएगा, और अधिक मजबूत, और अंत में प्रबंधन करने में आसान है।

Answer 11

तकनीकी रूप से आईफ्रेम के साथ कुछ भी गलत नहीं है जो विकल्प के साथ है। लेकिन अर्थात्, बुराई है।

वेब HTTP पर आधारित है, एक प्रोटोकॉल है जो कहते हैं किसी URL हमेशा एक अद्वितीय ressource की ओर जाता है जाएगा।

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

Answer 12

मैं बहुमत से असहमत होने जा रहा हूं और कहता हूं कि हाँ, iframes बिल्कुल भयानक विचार हैं। कोई भी जिसने वेब डिज़ाइन समुदाय के भीतर कुछ समय के लिए काम किया है, इस बात से सहमत होगा कि iframes शुद्ध बुराई हैं और ABSOLUTELY आवश्यक होने तक टालना चाहिए।

यह मानने के मेरे कारण हैं कि वे बुरे हैं क्योंकि वे वेब पेज के नेविगेशन पैटर्न को तोड़ते हैं। एक आईफ्रेम का उपयोग करके आप ब्राउज़र पर बैक और फॉरवर्ड बटन प्रभावी ढंग से तोड़ सकते हैं और अपने उपयोगकर्ताओं को भ्रमित कर सकते हैं। यह HTTP प्रोटोकॉल के पीछे पूरे विचार को तोड़ देता है; कि एक यूआरएल हमेशा एक अद्वितीय स्थान की ओर ले जाएगा। अगर आईफ्रेम एक घोड़ा था तो वह बहुत पहले सेवानिवृत्त हो गया होगा। गतिशील रूप से सामग्री की सेवा करने के अन्य तरीके हैं और इनका उपयोग इनका उपयोग किया जाना चाहिए।

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

Answer 13

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

सामान्यतः मुझे लगता है कि वे ब्रांडिंग के लिए उपयोग किए जाते हैं या किसी उपयोगकर्ता को साइट पर वापस जाने के लिए सक्षम करते हैं जो उपयोगकर्ता को साइट से रीडायरेक्ट करता है।

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

कृपया ध्यान दें कि कई साइटें उनकी साइट को एम्बेड होने से रोकती हैं और आईफ्रेम बंद कर देती हैं (शीर्ष URL को उनके डोमेन पर रीडायरेक्ट कर रही हैं)।

Answer 14

पुन: "HTTP प्रोटोकॉल के पीछे पूरे विचार; किसी URL हमेशा एक अद्वितीय स्थान के लिए नेतृत्व करेंगे"

मैं सुरक्षा और scaleability लिए एक जैसे URL से अपने पूरे सीएमएस की सेवा (ज्यादातर उपयोग करने के बजाय प्राप्त के पद पैरामीटर)। मैं प्रमाणीकरण के बिना सुरक्षित सामग्री को नहीं देखना चाहता, और एक प्रेषण प्रणाली मेरे लिए विकास को आसान बनाती है क्योंकि मुझे हर नए पृष्ठ के लिए प्रमाणीकरण के बारे में चिंता करने की ज़रूरत नहीं है।

इसके अलावा, कुछ अनुप्रयोगों के लिए एसईओ लागू नहीं है (जैसे वेब-आधारित ईआरपी के लिए)।

मैं PHP उत्पन्न असेंबली पेड़ से सामग्री की सेवा के लिए iFrame का उपयोग करता हूं। मैं नहीं चाहता कि पेड़ (और नोड दृश्यता) ताज़ा हो जब भी उपयोगकर्ता किसी भाग/असेंबली के लिए विवरण देखना चाहता हो।

Answer 15

कई usability and accessability issues with iframes हैं। कुछ ब्राउज़र और स्क्रीन-रीडर के iframes प्रदर्शित कर सकते हैं नहीं है, तो आप विकल्प सामग्री उपलब्ध करानी चाहिए:

<iframe src="content.html"> 
    <p> 
     This content will only be displayed by browsers that do not support 
     iframes. You should provide a link to the content, or in your 
     case an alternative way to use your widget. 
    </p> 
</iframe> 

आप तीसरे पक्ष की सामग्री प्रदर्शित करना शुरू करते हैं, तो आप iframe फोकस हथियाने के बाद यह लोड हो जाए, के लिए बाहर देखना चाहिए। नियमित उपयोगकर्ताओं के लिए मामूली परेशानी होने पर, यह स्क्रीनreaders के साथ ब्राउज़ करने वाले उपयोगकर्ताओं के लिए बहुत भ्रमित हो सकता है।

Answer 16

iframes के साथ एक महत्वपूर्ण समस्या है जो शायद ही कोई उल्लेख हो, लेकिन मेरे द्वारा भरने वाली बग कौन सा है।

हमारे सहयोगी एक गतिशील रूप से बदलती डेटाबेस में निवेश किया काम का एक जीवन भर जो हम गूगल डॉक्स स्प्रेडशीट जो हम तो सामग्री का समर्थन करने का एक बहुत कुछ के साथ हमारी साइट पर प्रदर्शित में लोड किया है।

किसी को मेरे पृष्ठ स्रोत से iframe कोड को पकड़ने और इसे अपने पृष्ठ पर घुमाने के लिए बिल्कुल कुछ भी नहीं है। अब वे हमारे सभी डेटा प्राप्त कर रहे हैं, कुछ मिनट पहले तक ताज़ा हो गए, बिल्कुल कुछ भी नहीं के लिए अपने पृष्ठ पर सेवा दी।

यदि कोई Google आईफ़्रेम किसी विशिष्ट डोमेन से बंधे जा सकता है, तो वह इसे अपने ट्रैक में रोक देगा।

कोई विचार, चमकदार स्पार्क?