هل iframes فكرة رهيبة؟

أعمل على تصميم أداة ، وكنت أستخدم إطارات iframes لتقديم محتوى بداخله. في مرحلة ما ، قد أبدأ في تقديم HTML وشبكة JS التابعة لجهة خارجية ، لذلك أعتقد أن iframes ستكون فكرة جيدة.

إنه يجعل جافا سكريبت widget أكثر تعقيدًا قليلاً ، ويساورني القلق من أن هذا قد لا يكون أفضل تنفيذ.

هل لديك اي نصيحة؟ سيكون مساعدة كبيرة لسماع ما يعتقده الآخرون حول إطارات iframe.

0
وأضاف تحرير
الآراء: 1

15 إجابة

شيء واحد اكتشفته مؤخرًا هو أن صفحات aspx المضمنة داخل iframes قد تواجه أحيانًا مشاكل في فقدان ملفات تعريف الارتباط ، مما أدى إلى فقدان حالة جلسة العمل في أحد التطبيقات التي شاركت فيها.

بالنسبة لي ، كان ذلك في سيناريو حيث كان محل تطوير مختلف يستهلك أحد صفحات .aspx الخاصة بي في الصفحة الخاصة بهم. هذا يعني أننا كنا على خوادم منفصلة ، والتي قد تكون أو لا تكون بارزة.

يبدو أن السبب في ذلك يرجع إلى رفض الصفحة الرئيسية لملفات تعريف الارتباط للصفحة الفرعية ... كما هو الحال في ملف تعريف الارتباط للجلسة ، فستظهر الجلسة.

The specific mechanics of how this works are a little involved: More Details

لم تؤثر هذه المشكلة على FireFox ، ولكنها ظهرت في IE7 وكان لغزًا حقيقيًا لبضع ساعات.

أيضا ، لا بد لي من تناقض المادة التي ارتبط بها أعلاه في نقطة واحدة. المقالة تقول أنك لا تحصل على هذا إذا كانت الصفحة التي تحتوي على أيضا. aspx ... في هذه الحالة ، لم يكن ذلك صحيحًا لأن كلا الصفحتين كانتا aspxs.

هذا يثير بعض الشكوك حول كل شيء آخر يقوله المقال عن هذا الوضع ، ولكنه أدى إلى حل ، وهذا شيء كذلك.

كما اقترحت المقالة ، أضع في التعليمة البرمجية التالية ، التي تقوم بحقن p3p (مشروع تفضيلات الخصوصية - لم أسمع به من قبل) رأس في حدث التهيئة للصفحة:

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

... والتي حلت المشكلة.

0
وأضاف

أنا شخصياً أتفادى إذا استطعت دون الكثير من المتاعب. باستخدام Javascript (أو AJAX إذا كنت بحاجة إلى تحميلها ديناميكيًا) ، يمكنك بسهولة استخدام div وتغيير المحتويات حسب الضرورة - في بعض الحالات سوف يمنحك هذا مرونة أكبر وسيبسط JS ، خاصة إذا كان هناك الكثير من التفاعل بين تطبيقك وبقية الصفحة.

ومع ذلك ، سأحقق في كلا الخيارين ، وإذا كان مسار JS يبدو صعبًا أو معقدًا ، فانتقل فقط إلى iframe.

0
وأضاف

خيار جيد هو استخدام خاصية CSS الفائضة. تكون القيمة الافتراضية مرئية ولكن يمكنك تعيينها إلى مخفية أو قابلة للتمرير أو تلقائية. وأود أن استخدام السيارات في قضيتك. إذا كان المحتوى الخاص بك كبيرًا للغاية ، فسيبدو أنه لديك إطار iframe ولكنه ما زال صحيحًا على الصفحة.

see: overflow property

0
وأضاف

من الناحية الفنية ليس هناك ما هو أسوأ مع iFrame أنه مع البدائل. لكن من الناحية اللغوية ، هناك شر.

يعتمد الويب على HTTP ، وهو بروتوكول يفيد بأن عنوان URL المعيّن سيؤدي دائمًا إلى مصدر ressource فريد.

باستخدام iFrame ، أنت تخدم فقط العديد من الموارد التي ذابت في صفحات الويب خلف عنوان URL واحد لجميعهم. إذا كانت لديك مخاوف حول كيفية نمو الويب ، فهذا أمر مزعج. ما هو أكثر من ذلك ، بالنسبة إلى روبوتات محركات البحث ، إنه أمر صعب.

0
وأضاف

يعتمد ما يفعله القطعة. يكون لإطارات iframes مكانها ، ولكنها لا تسبب سوى القليل من مشكلات التصميم (ناهيك عن جعل JS أكثر تعقيدًا) ، لذا يميل معظم الأشخاص إلى تجنبها إلا عند الضرورة القصوى ..

0
وأضاف

هناك شيء واحد فقط "سيئة حقا" معهم وأنا على علم.

إذا كان هناك طرف ثالث يقوم ببعض جافا سكريبت ، فإنه يحاول تعديل DOM الخاصة به في وقت مبكر جدًا ... سيقوم IE6 و IE7 برمي أوه غير مفيد " العملية تم إحباط " ، ثم لا تخرج فقط iframe ، ولكن الصفحة المحيطة بأكملها . (على سبيل المثال ، يظهر موقعك لأسفل)

لم يتم إصلاحه في IE8 ، ولكن يتم التعامل مع التحطم بشكل أفضل.

0
وأضاف

تعد إطارات iframe ، مثل الإطارات ، عناصر تحكم لاستخدامها في المهمة المطروحة. على هذا النحو ، فهي ليست جيدة ولا سيئة في حد ذاتها ، ولكن يمكن أن تكون جيدة أو سيئة بناء على المهمة المطلوبة ومتطلبات العميل. على حد علمي ، ستتمكن جميع المتصفحات الحديثة (والمستخدمين غير اللينويين) من "رؤية واستهلاك" iframes بدون مشكلة.

0
وأضاف

لا ، لا شيء خاطئ في iframes. من المحتمل أن تكون إطارات Iframe فكرة أفضل إذا كنت ستبدأ في عرض محتوى تابع لجهة خارجية.

وتخطط أيضًا مواصفات HTML5 القادمة لبناء مزيد من ميزات الأمان في إطارات iframe لحالات مثل هذه ، لذا سأعتبر استخدامها جيدًا الآن.

0
وأضاف
أنا 1+ هنا - التحذير الوحيد ، بالطبع ، هو التأكد من أن الاستخدام مثالي بالفعل (بدلاً من استخدام أجاكس ببساطة للاستيلاء على البيانات المطلوبة - يمكن للخادم أن يمسك ويحلل "محتوى الطرف الثالث" وأن يكون استرجاعها عبر مكالمات خارج النطاق).
وأضاف المؤلف Jason Bunting, مصدر

ليس بالضرورة ، طالما أن المحتوى داخل إطار iframe يمكن التنبؤ به.

0
وأضاف

قبل استخدام XMLHTTPRequest على نطاق واسع ، كان الناس يستخدمون مزيجًا من جافا سكريبت و iframes لعرض المحتوى بطريقة ديناميكية دون إجراء تحديثات للصفحة الكاملة.

هناك الكثير من المعلومات حول تطوير المواقع بهذه الطريقة لذلك يجب أن يكون لديك وقتًا سهلًا نسبيًا لإيجاد حل بديل للعديد من العوائق التي من المحتمل أن تصل إليها.

الشيء الوحيد الذي وجدته ألمًا هو استخدام جافا سكريبت عبر النطاقات في iframe. إذا كانت الصفحة التي ضمنتها في iframe من نطاق مختلف عن الصفحة "parent" ، فستتوفر لدى المتصفحات قيود أمان ضد السماح لك بالوصول إلى أحدها من الآخر. الحيلة هي لكلا الصفحتين للإعلان

document.domain = 'somedomain.com';

هناك الكثير من الأشياء على الويب حول هذا النوع من الحل.

حظا طيبا وفقك الله!

0
وأضاف
أعتقد أنه يمكنهم فقط تغيير document.domain ليكون نطاقًا أعلى مستوى - أي www.acme.com يمكنه تغيير النطاق إلى acme.com ، لكن ليس إلى google.com. وبالتالي ، فإن هذا يساعد فقط iframes على التواصل عبر النطاقات الفرعية لنطاق واحد. (يمكن أن أكون مخطئا ولكن هذا ما أتذكر)
وأضاف المؤلف Josh, مصدر
Josh - أنت على حق ، سيعمل document.domain فقط للصفحات على نفس المجال الأصلي ولكن نطاقًا فرعيًا مختلفًا.
وأضاف المؤلف Livingston Samuel, مصدر
Josh أنت على حق ، ولكن يمكنك دائمًا استخدام window.location.href .
وأضاف المؤلف nyuszika7h, مصدر

من واقع خبرتي ، يكون iframes إما اختراقات أو موفرين للوقت - تأكد من أنك إذا كنت تستخدمها ، فهي ضرورية لتلك الأسباب. إذا كنت تتحكم في المحتوى (أو يمكنك التحكم من خلال النسخ المطابق أو النسخ) ، فيجب أن تفكر في استخدام AJAX أو جانب من جانب الخادم لسحب البيانات الخارجية إلى الصفحة وإخراجها من الصفحة - سيصبح الأمر أكثر مرونة وأكثر قوية ، وأسهل في إدارتها في النهاية.

0
وأضاف

سأختلف مع الأغلبية وأقول نعم ، إن iframes فكرة فظيعة للغاية . سيوافق أي شخص عمل في مجتمع تصميم الويب لفترة من الوقت على أن إطارات iframes شر خالصة ويجب تجنبها ما لم يكن مطلقًا ضروريًا.

الأسباب التي دفعتني للاعتقاد بأنها سيئة هي أنها تكسر نمط التنقل في صفحة الويب. باستخدام iframe ، يمكنك كسر الأزرار الخلفية والأمامية على المتصفحات بشكل فعال وإرباك المستخدمين. يكسر الفكرة بأكملها وراء بروتوكول HTTP ؛ أن عنوان URL سيؤدي دائمًا إلى موقع فريد. إذا كان iframe حصانًا ، فربما تقاعدت منذ فترة طويلة. هناك طرق أخرى لخدمة المحتوى ديناميكيًا ويجب استخدام هذه بدلاً من ذلك.

إذا كنت تُنشئ عنصر واجهة مستخدم ، فستتلاشى المخاوف المباشرة من استخدام إطارات iframes (سيئ لمحركات البحث ، أو سيئة للإشارة المرجعية ، إلخ) ، لكن أيًا كان المحتوى بطريقة أفضل سيخدم ديناميكيًا أو حتى في نافذة جديدة بدلاً من iframe.

0
وأضاف
-1 كما جاء في إجابة أخرى: "إنها ليست جيدة ولا سيئة في حد ذاتها ، بل يمكن أن تكون جيدة أو سيئة على أساس المهمة المطروحة". وأيضًا ، لا تكون المشكلة المتعلقة بالزر الخلفي والأمامي محددةً بإطارات iframe ، بل تحدث أيضًا مع محتوى ديناميكي آخر.
وأضاف المؤلف Christophe, مصدر

إعادة: "الفكرة بأكملها وراء بروتوكول HTTP ؛ أن عنوان URL سيؤدي دائمًا إلى موقع فريد"

أعرض CMS بالكامل من نفس عنوان URL للأمان والنقر (باستخدام POST بدلاً من معلمات GET). لا أريد ظهور محتوى آمن بدون مصادقة ، كما أن نظام الإرسال يجعل التطوير أسهل بالنسبة لي حيث لا داعي للقلق بشأن المصادقة لكل صفحة جديدة.

أيضا ، بالنسبة لبعض التطبيقات SEO غير قابل للتطبيق (مثل ERP على شبكة الإنترنت).

أستخدم iFrame لعرض المحتوى من شجرة تجميع تم إنشاؤها في PHP. لا أريد تحديث الشجرة (ورؤوس العقدة) كلما أراد المستخدم عرض تفاصيل جزء/تجميع.

0
وأضاف
أنا سعيد لأنني لست من مستخدمي موقعك! (لا يمكن وضع إشارة مرجعية في الكل !)
وأضاف المؤلف SamB, مصدر

هناك مشكلة كبيرة في إطارات iframes التي لا تكاد تذكر ، ولكنها تتسبب في حشوها.

يمتلك زميلنا عمرًا من العمل المستثمر في قاعدة بيانات تتغير بشكل ديناميكي قمنا بتحميلها في جداول بيانات Google Docs ، ثم نعرضها على موقعنا إلى جانب الكثير من المواد الداعمة.

لا يوجد شيء على الإطلاق لمنع شخص ما من الاستيلاء على شفرة iframe من مصدر الصفحة الخاصة بي وتدفعه إلى صفحته. الآن يحصلون على جميع البيانات الخاصة بنا ، منتعشة بشكل صحيح حتى قبل بضع دقائق ، خدم في صفحتهم على الإطلاق شيئا على الإطلاق.

إذا كان من الممكن ربط iframe على Google بنطاق معين ، فسيؤدي ذلك إلى إيقاف ذلك في مساراته.

أي أفكار ، شرارات مشرقة؟

0
وأضاف
هذا قديم تمامًا ولكن إذا كنت لا تزال تبحث عن حل ، يمكنني التفكير في استخدام X-Frame-Option header لتقييد من يمكنه تحميل iframe. الآن ، لا يمكنك تطبيق هذا العنوان بوضوح على عنوان url الخاص بـ Google docs نظرًا لأنك لا تتحكم فيه. ولكن ما يمكنك فعله هو ، بدلاً من استخدام Google docs url مباشرة ، يمكنك إنشاء عنوان url الخاص بك والذي يعيد توجيه الخادم إلى Google docs url. وبعد ذلك يمكنك تطبيق رأس X-Frame-Option الصحيح على عنوان url الخاص بك
وأضاف المؤلف Suhas, مصدر