Câu trả lời:
Như với tất cả các công nghệ, nó có những thăng trầm. Nếu bạn đang sử dụng iframe để đi xung quanh một trang web được phát triển đúng cách, thì tất nhiên đó là một thực tế tồi. Tuy nhiên đôi khi một iframe được chấp nhận.
Một trong những vấn đề chính với iframe phải thực hiện với dấu trang và điều hướng. Nếu bạn đang sử dụng nó để chỉ nhúng một trang bên trong nội dung của bạn, tôi nghĩ điều đó là tốt. Đó là những gì một iframe dành cho.
Tuy nhiên tôi cũng đã thấy iframe bị lạm dụng. Nó không bao giờ nên được sử dụng như một phần không thể thiếu trong trang web của bạn, mà là một phần nội dung trong một trang web.
Thông thường, nếu bạn có thể làm điều đó mà không có iframe, đó là một lựa chọn tốt hơn. Tôi chắc rằng những người khác ở đây có thể có nhiều thông tin hơn hoặc ví dụ cụ thể hơn, tất cả đều liên quan đến vấn đề bạn đang cố gắng giải quyết.
Như đã nói, nếu bạn bị giới hạn ở HTML và không có quyền truy cập vào một phụ trợ như PHP hoặc ASP.NET, v.v., đôi khi iframe là tùy chọn duy nhất của bạn.
window.postMessage(), ví dụ để triển khai tự động thay đổi kích thước iframe hợp tác.
Chúng không phải là thực hành xấu, chúng chỉ là một công cụ khác và chúng thêm linh hoạt.
Để sử dụng như một yếu tố trang tiêu chuẩn ... chúng tốt, bởi vì chúng là cách đơn giản và đáng tin cậy để tách nội dung trên nhiều trang. Đặc biệt đối với nội dung do người dùng tạo, có thể hữu ích khi "hộp cát" các trang nội bộ thành một iframeđánh dấu quá kém không ảnh hưởng đến trang chính. Nhược điểm là nếu bạn giới thiệu nhiều lớp cuộn (một cho trình duyệt, một cho iframe), người dùng của bạn sẽ cảm thấy thất vọng. Giống như adzm đã nói, bạn không muốn sử dụng iframeđiều hướng chính, nhưng hãy nghĩ về chúng như một văn bản / đánh dấu tương đương với cách một video hoặc một tệp phương tiện khác sẽ được nhúng.
Đối với các sự kiện nền kịch bản, sự lựa chọn thường nằm giữa một ẩn iframevà XmlHttpRequestđể tải nội dung cho trang hiện tại. Sự khác biệt ở đây là iframetạo ra tải trang, do đó bạn có thể di chuyển qua lại trong bộ đệm của trình duyệt với hầu hết các trình duyệt. Lưu ý rằng Google, người sử dụng XmlHttpRequestmọi nơi, cũng sử dụng iframes trong một số trường hợp nhất định để cho phép người dùng di chuyển qua lại trong lịch sử trình duyệt.
Đó là 'thực hành xấu' để sử dụng chúng mà không hiểu nhược điểm của chúng. Bài đăng của Adzm tổng hợp chúng rất tốt.
Trên flipside, gmail sử dụng rất nhiều iFrames trong nền cho một số tính năng thú vị của nó (như tải lên tệp tự động). Nếu bạn nhận thức được những hạn chế của iFrames, tôi không tin rằng bạn sẽ cảm thấy bất kỳ sự ép buộc nào về việc sử dụng chúng.
Đã làm việc với họ trong nhiều trường hợp, tôi thực sự nghĩ rằng iframe là chương trình web tương đương với câu lệnh goto. Đó là, một cái gì đó thường được tránh. Trong một trang web họ có thể là phần nào hữu ích. Tuy nhiên, chéo trang, chúng hầu như luôn là một ý tưởng tồi cho bất cứ điều gì ngoại trừ nội dung đơn giản nhất.
Hãy xem xét các khả năng ... nếu được sử dụng cho nội dung được tham số hóa, họ đã tạo ra một giao diện. Và trong một trang web chuyên nghiệp, giao diện đó yêu cầu quản lý phiên bản và SLA - hầu như luôn bị bỏ qua khi vội vàng để trực tuyến.
Nếu được sử dụng cho nội dung hoạt động - các khung lưu trữ tập lệnh - thì sẽ có các hạn chế tập lệnh tên miền chéo (khác nhau). Một số có thể bị hack, nhưng hiếm khi nhất quán. Và nếu nội dung đóng khung của bạn có nhu cầu tương tác, nó sẽ phải vật lộn để vượt ra ngoài khung.
Nếu được sử dụng với nội dung được cấp phép, thì các trang web tham gia sẽ bị gánh nặng do phải chuyển thông tin quyền lợi ra khỏi băng tần giữa các máy chủ.
Vì vậy, mặc dù, đôi khi hữu ích trong một trang web, chúng khá không phù hợp với bản mashup. Bạn tốt hơn nhiều khi nhìn vào cổng và portlets thực sự. Tồi tệ hơn, họ là con cưng của mọi tài tử web - nhiều người quản lý công nghệ đã bao vây họ như một giải pháp cho nhiều vấn đề. Trong thực tế, họ tạo ra nhiều hơn.
Dựa trên kinh nghiệm của tôi, một mặt tích cực của iframe là khi gọi mã của bên thứ ba, điều đó có thể liên quan đến việc gọi một javascript gọi Document.write();lệnh có lệnh. Như bạn có thể biết, các lệnh này không thể được gọi một cách không đồng bộ do cách phân tích cú pháp (DOM Parser, v.v.). Một ví dụ về điều này là http://sourceforge.net/projects/phpadsnew/ Tôi đã sử dụng iframe để giúp tăng tốc trang web của chúng tôi vì có nhiều cuộc gọi đến phpadsnews và trang web đang chờ phản hồi trước khi tiếp tục hiển thị khác nhau các bộ phận của trang. với iframe tôi có thể cho phép trang web hiển thị các phần khác của trang và vẫn gọi Document.write()lệnh của phpad không đồng bộ. Ngăn chặn và khóa js.
Chắc chắn có sử dụng cho folks iframes. Làm thế nào khác bạn sẽ đặt các tiện ích mạng thời tiết trên trang của bạn? Cách duy nhất khác là lấy XML của họ và phân tích nó, nhưng tất nhiên sau đó bạn cần có điều kiện để đưa ra đồ họa thời tiết vĩnh cửu ... không thực sự đáng giá, nhưng sẽ sạch hơn nếu bạn có thời gian.
Mô hình frameset ban đầu (Frameset và Frame-yếu tố) rất tệ từ quan điểm khả năng sử dụng. IFrame là một phát minh sau này không có nhiều vấn đề như mô hình frameset ban đầu, nhưng nó có nhược điểm.
Nếu bạn cho phép người dùng điều hướng bên trong IFrame, thì các liên kết và dấu trang sẽ không hoạt động như mong đợi (vì bạn đánh dấu URL của trang bên ngoài, nhưng không phải là URL của iframe).
Khi trang chính của bạn tải giao thức HTTP và các phần của trang của bạn cần hoạt động trong giao thức HTTPS, iFrame có thể đánh bại jsonp.
Đặc biệt, nếu dataType của bạn không phải là json và cần được dịch trên máy chủ thành json và được dịch lại trên máy khách thành ví dụ html phức tạp.
Vì vậy, không - iFrame không phải là xấu xa.
Họ không xấu, nhưng thực sự hữu ích. Tôi đã gặp một vấn đề lớn trước đây khi tôi phải nhúng nguồn cấp dữ liệu twitter của mình và nó sẽ không cho phép tôi làm điều đó trên cùng một trang, vì vậy tôi đã đặt nó trên một trang khác và đặt nó dưới dạng iframe.
Chúng cũng tốt vì tất cả các trình duyệt (và trình duyệt điện thoại) đều hỗ trợ chúng. Chúng không thể được coi là một thực hành xấu, miễn là bạn sử dụng chúng một cách chính xác.
Điều đáng chú ý là iframe sẽ, bất kể tốc độ kết nối internet của người dùng của bạn hoặc nội dung của iframe, sẽ gây ra sự chậm chạp nhỏ (0,3 giây) nhưng tốc độ tải xuống trang của bạn rất chậm. Đây không phải là thứ bạn sẽ thấy khi kiểm tra nó cục bộ. Trên thực tế, điều này đúng với bất kỳ yếu tố nào được thêm vào một trang, nhưng iframe dường như tồi tệ hơn.
Tôi đã thấy IFRAME được áp dụng rất thành công như một cách dễ dàng để tạo các menu ngữ cảnh động, nhưng đối tượng mục tiêu của ứng dụng web đó chỉ là người dùng Internet Explorer.
Tôi muốn nói rằng tất cả phụ thuộc vào yêu cầu của bạn. Nếu bạn muốn đảm bảo trang của bạn hoạt động tốt như nhau trên mọi trình duyệt, hãy tránh IFRAME. Nếu bạn đang nhắm mục tiêu đối tượng hẹp và nổi tiếng (ví dụ: trên Intranet cục bộ) và bạn thấy lợi ích khi sử dụng IFRAME thì tôi sẽ nói rằng bạn đồng ý làm điều đó.