IFrames (HTML) ล้าสมัยหรือไม่ [ปิด]

ได้รับข้อความที่ขัดแย้งเกี่ยวกับเรื่องนี้หวังว่าจะไม่ ฉันนึกไม่ถึงว่าการสนับสนุนจะหยุดลงเนื่องจากมีเว็บไซต์นับล้าน ๆ แห่งใช้มัน

คำถามเพิ่มเติมเกี่ยวกับเรื่องนี้:

1. เหตุใดพวกเขาจึงควรยกเลิกแท็กนี้
2. ทางเลือกอื่นสำหรับมัน?

ในความคิดของฉันW3C เพิ่มปืนในการทิ้ง iframes จากหลักประเภท Strict HTML และ XHTML ในทางทฤษฎีคุณจะใช้<object>องค์ประกอบเพื่อเพิ่มสิ่งแปลกปลอมลงในเอกสารของคุณ แต่ความแตกต่างและข้อ จำกัด ของเบราว์เซอร์ทำให้สิ่งนี้ไม่เริ่มต้นสำหรับนักพัฒนาหลาย ด้วยมากมากขึ้นในทางปฏิบัติ HTML 5 (ซึ่งยังคงเป็นร่าง) iframe ที่จะกลับมาและได้มีสองคุณลักษณะใหม่และที่รักseamlesssandbox

การสนับสนุน<iframe>ยังมีอยู่ใน HTML 5 ดังนั้นฉันไม่คิดว่าสิ่งนี้จะเปลี่ยนแปลงในอนาคตอันใกล้นี้

เพื่อตอบคำถามอื่น ๆ ของคุณ:

1. <iframe>s (เป็นเฟรมโดยทั่วไป) ส่วนใหญ่ไม่เป็นมิตรกับผู้ใช้:
   • ไม่อนุญาตให้เข้าถึงเนื้อหาในเฟรมได้ง่ายผ่านทาง URL (โดยไม่สูญเสียเนื้อหานอกเฟรมอย่างน้อยที่สุด)
   • ผู้ใช้"technophobe"ส่วนใหญ่มักจะหงุดหงิดกับเฟรม
   • เท่าที่ฉันรู้ว่าเบราว์เซอร์แสดงผลช้ากว่า
2. ทางเลือก ได้แก่ การสร้างเพจแบบไดนามิก (SSI, PHP, Rails และอื่น ๆ ) และการใช้ JavaScript / AJAX เพื่อเปลี่ยนเนื้อหาของเช่น a <div>

เพื่อความชัดเจน: ฉันพูดถึง<iframe>ในฐานะองค์ประกอบอินเทอร์เฟซ ไม่ใช่องค์ประกอบที่ซ่อนอยู่สำหรับการโหลดสิ่งอื่น ๆ เช่น Google Mail ทำ

iframe ล้าสมัยสำหรับเค้าโครงเพจ อย่าใช้มันแทนเลย์เอาต์ CSS ที่ดีแม้แต่เลย์เอาต์แบบตารางก็ดีกว่า

เหตุผลที่ดีในการใช้ iframe คือ:

• โฆษณา : ตัวอย่างเช่น AdWords ใช้เทคนิคนี้เหมาะสำหรับการห่อหุ้ม - โฆษณา css จะไม่ทำลายหน้าเว็บของคุณ
• iframe ที่ซ่อนอยู่ : สามารถใช้กับสิ่งที่ใช้งานได้หลายร้อยเช่นการติดตาม ajax-Alternative เป็นต้น

IFrames ไม่ล้าสมัย แต่เหตุผลในการใช้งานนั้นหายาก

• การใช้ IFrames เพื่อแสดงเนื้อหาของคุณเองจะสร้าง "กำแพง" ในการเข้าถึงเนื้อหาในพื้นที่นั้น
• สำหรับโปรแกรมรวบรวมข้อมูลเช่น Google ยังไม่ชัดเจนในทันทีว่า cotent ใน iframe จะได้รับการจัดอันดับสูงราวกับว่าเนื้อหานั้นเป็นเพียงส่วนหนึ่งของหน้า สำหรับหลาย ๆ คนนี่เป็นเหตุผลที่เพียงพอที่จะไม่ใช้มัน
• ทำให้ DOM สำหรับ IFrame ไม่สามารถเข้าถึงได้โดยเครื่องมือเช่น jQuery, prototype เป็นต้น

เหตุผลในการใช้ iframes:

• มันยอดเยี่ยมสำหรับการปิดกั้นเนื้อหาของผู้อื่นจากโดเมนอื่น ๆ แต่ก็ไม่ได้รวมเข้าด้วยกันอย่างราบรื่น (สไตล์ชีทจาวาสคริปต์ ฯลฯ ... )
• บางครั้งการรวมมัลติมีเดียสามารถทำได้ง่ายขึ้นผ่าน iframe ซึ่งต่างจากการใช้แท็กฝัง
• จริงๆกรณีพิเศษจริงๆเช่นกรณีของ gmail ที่พวกเขาใช้สำหรับการจัดการเสียงและประวัติ

ฉันก็จะตอบว่าไม่จำเป็นต้องลบ iframe มันเป็นแท็กที่จำเป็นและจะอยู่ในช่วงเวลาหนึ่ง

ฉันเคยเห็นฟอรัมมากมายที่แนะนำแท็ก Object แทน IFrame ซึ่งอาจใช้ได้ในกรณีส่วนใหญ่

ตัวอย่างเช่นฉันมี PDF ที่แสดงใน IFrame (เนื่องจากมีสิ่งอื่นที่เราต้องแสดงบนหน้านี้นอกจาก PDF เท่านั้น) และสามารถทำให้มันแสดงผลได้ดีโดยใช้ Object

คืออะไร:

<iframe id="confirmed_pdf" class="current_pdf" src="/prescriptions/show_pdf?id=123" height="570" width="480"></iframe>

กลายเป็น:

<object id="confirmed_pdf" class="current_pdf" data="/prescriptions/show_pdf?id=123" type="application/pdf" height="570" width="480">
  <p>[Show this message if displaying the PDF did not work]</p>
</object>

แต่ Object ไม่ใช่ตัวทดแทนที่เหมาะสมในการเติมเต็มข้อกำหนดเพื่อให้พิมพ์ได้เฉพาะส่วน PDF ของหน้า

IFrame เปรียบเสมือนหน้าต่างของตัวเองภายในเพจ (โดยทั่วไปคือหน้าต่างภายในหน้าต่าง) และเมื่อคุณได้รับวัตถุหน้าต่างคุณสามารถเรียก. print () ได้เช่น:

jQuery("#confirmed_pdf").contentWindow.print();

IFrame มีคุณสมบัติ contentWindow นั่นคือสิ่งที่ทำให้การพิมพ์เฉพาะส่วนนั้นทำได้ ออบเจ็กต์ไม่มีคุณสมบัติ contentWindow ดังนั้นจึงไม่มีวิธีที่จะพิมพ์เฉพาะส่วนของหน้า

ดูเหมือนว่าถ้าคุณแค่ใช้ IFrame เพื่อแสดงบางสิ่งก็มีแท็กอื่น ๆ เช่น Object ที่สามารถใช้แทนได้ แต่ถ้าคุณต้องการโต้ตอบกับเนื้อหาของ IFrame ด้วยวิธีใดวิธีหนึ่งอาจจำเป็นต้องใช้ IFrame

IFrames ใช้กับ AJAX เป็นจำนวนมาก ตัวอย่างเช่น GMail ใช้ IFrames ที่ซ่อนอยู่เก้ารายการที่ฉันเชื่อ

IFramesยังไม่ตาย แต่Frameset / Framesกำลังจะตาย

ใน 2 รุ่นล่าสุดของIE (IE7 / IE8) การซูมใน Frames (ไม่ใช่ IFrames) ได้สร้างผลร้าย

โดยทั้งหมดใช้ IFrames แต่ IMHO จะไม่อยู่ใน Framesets / Frames

ที่ บริษัท เดิมของฉันเราได้จัดเตรียมแอปพลิเคชันที่โฮสต์ไว้ซึ่งลูกค้าจะรวมเข้ากับเว็บไซต์ของตนเอง ในบางครั้งพวกเขาจะใช้ IFrame เพื่อทำสิ่งนี้โดยปรับหน้าโฮสต์ของเราให้เข้ากับการออกแบบที่มีอยู่ บางครั้งสิ่งนี้ก็ทำได้อย่างราบรื่น (เช่น IFrame ไม่มีเส้นขอบหรือแถบเลื่อนดูเหมือนเป็นส่วนหนึ่งของหน้าเว็บ) ผมถือว่านี่เป็นการใช้แท็กได้ดี

อาจมีประโยชน์อย่างยิ่งในบางสถานการณ์ แต่มีจำนวน จำกัด โดยเฉพาะอย่างยิ่งการฝังฟังก์ชันการทำงานทั่วไปในหลาย ๆ ไซต์

ตัวอย่างเช่นฉันมีลูกค้าที่ดูแลไซต์อีคอมเมิร์ซสินค้าของสก๊อตแลนด์จำนวนหนึ่ง ในส่วนนี้เราได้พัฒนาแอปพลิเคชั่นง่ายๆสองตัวเพื่อค้นหาชื่อกลุ่มที่เป็นไปได้จากนามสกุลของคุณหรือผ้าตาหมากรุกที่คุณเลือก (หัวเราะคิกคักถ้าคุณต้องการ แต่ผ้าตาหมากรุกมีมูลค่า 700 ล้านเหรียญต่อปีต่อเศรษฐกิจของเรา) ฐานข้อมูลที่อยู่เบื้องหลังนี้มีขนาดใหญ่อย่างน่าประหลาดใจ (เกือบหมื่นแถวในชื่อแกนและตารางผ้าตาหมากรุก) และมีการอัปเดตอย่างสม่ำเสมอ

ดังนั้นเราจึงมีการตั้งค่าแอปพลิเคชันให้ทำงานบนเว็บไซต์เดียวจากนั้นจึงฝังแอปพลิเคชันเหล่านี้ลงในเว็บไซต์อื่นของเราโดยใช้ iframe ทำให้สามารถส่งผ่านพารามิเตอร์จาวาสคริปต์อย่างง่ายเพื่อให้เราสามารถรวมการเลือกผ้าตาหมากรุกหรือกลุ่มเข้ากับฟังก์ชันการทำงานบนไซต์ฝัง iframe ถูกตั้งค่าเป็นขุนนางดังนั้นจึงปรากฏต่อผู้ใช้ปลายทางได้อย่างราบรื่น

แน่นอนว่าจะมีวิธีอื่นในการทำเช่นนี้ แต่การใช้ iframe นั้นง่ายและมีประสิทธิภาพ และไม่ล้าสมัยอย่างแน่นอน

ม้าสำหรับหลักสูตร ... <iframe> ก็เหมือนอย่างอื่น ... เพื่อจุดประสงค์ที่ถูกต้องพวกเขาเป็นเครื่องมือที่เหมาะสม ด้วยจุดประสงค์ที่ไม่ถูกต้องมันเป็นการแฮ็กที่น่าเกลียดหรือแย่กว่านั้น

ใน Ajax <div> s มักเป็นคอนเทนเนอร์ที่เหมาะสมกว่า ในบางสถานที่กิจกรรมการส่งต่อเนื้อหาภายนอกซึ่งเป็นส่วนหนึ่งของไซต์ของคุณเองซึ่งสนับสนุนโดย <iframe> s นั้นไม่เหมาะสม

ทีมของฉันใช้ <iframe> ในวันอื่น ๆ เป็นวิธีที่ดีเยี่ยมในการให้ผู้ใช้เข้าถึงประวัติอีเมล HTML ของพวกเขาอีเมลเป็นหน้า <html> ที่สมบูรณ์ซึ่งเราต้องการแทรกลงในเทมเพลตเว็บของเราได้อย่างง่ายดาย <iframe> เหมาะอย่างยิ่งสำหรับการนำเสนอข้อมูลนั้น] '

ในทางกลับกัน <iframe> s ควรถูกลบหรือปิดใช้งานเกือบตลอดเวลาในเนื้อหาที่ผู้ใช้ส่งซึ่งจะส่งกลับไปที่ไซต์เนื่องจากในบริบทดังกล่าวเป็นปัญหาด้านความปลอดภัยที่สำคัญ

ข้อกำหนด Google Gadget ในปัจจุบันอาศัย iframes: http://code.google.com/apis/gadgets/docs/spec.html

ปัจจุบันเป็นวิธีง่ายๆเพียงวิธีเดียวในการแยกแอปจาวาสคริปต์ที่ดึงมาจากหลายโดเมน / ผู้ให้บริการ

นอกจากนี้วิดเจ็ตจำนวนมากที่ผู้ใช้ฝังในเว็บไซต์จากบุคคลที่สามใช้ iframe

แม้ว่าพวกเขาจะมีข้อเสีย แต่ iframe ก็เป็นวิธีแก้ปัญหาที่ใช้งานได้จริงบนเว็บ ฉันต้องเดาว่าพวกเขาจะมาถึงในอีกสักระยะ

ฉันเพิ่งเปลี่ยนไซต์จาก Frameset ปกติเป็น Iframes เนื่องจากเฟรมปกติไม่สามารถทำสิ่งที่ฉันต้องการได้ ไม่ทำให้เกิดปัญหากับส่วนที่เหลือของโค้ดเบส

ปัญหาด้านการปฏิบัติตามข้อกำหนดและความปลอดภัยยังสามารถผลักดันให้คุณใช้ Iframes รถเข็นช็อปปิ้งเป็นการนำไปใช้งานตาม IFrame ที่ได้รับความนิยมเมื่อคุณต้องการรวมรถเข็นช็อปปิ้งเป็นส่วนหนึ่งของหน้าเว็บบางหน้าโดยไม่ต้องรับผิดชอบทั้งหมดในด้านการประมวลผลการชำระเงิน

โดยทั่วไปแล้วเราจะส่งมอบ Iframe เพื่อผสานรวมข้อมูลอีคอมเมิร์ซและลูกค้าของเราเช่นเดียวกับที่สามารถทำได้

ฉันทำงานให้กับ บริษัท ที่ใช้เฟรมสำหรับทุกอย่างตั้งแต่เมนูแบบดึงลงรายการบล็อกเนื้อหาและอื่น ๆ เพื่อปกปิดความซับซ้อนของแบบฟอร์มเว็บ. net แอปพลิเคชันช้ามากและทำงานบน IE เท่านั้น อย่าทำอย่างนี้