Một nơi nào đó dọc theo dòng tôi chọn khái niệm rằng sử dụng iframe là 'thực hành không tốt'.Liệu iframe được coi là 'thực hành không tốt'?
Điều này có đúng không? Ưu điểm/nhược điểm của việc sử dụng chúng là gì?
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 một khung nội tuyến để có được xung quanh một trang web phát triển đúng, thì tất nhiên đó là thực hành xấu. Tuy nhiên đôi khi một iframe là chấp nhận được.
Một trong những vấn đề chính với khung nội tuyến 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ỉ đơn giản là nhúng một trang bên trong nội dung của bạn, tôi nghĩ rằng đó là tốt. Đó là nội dung của iframe.
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ể tách rời của trang web của bạn, nhưng là một phần của 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ó khung nội tuyến, đó là tùy 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 các ví dụ cụ thể hơn, tất cả đều đến với vấn đề bạn đang cố giải quyết.
Với điều đó đã nói, nếu bạn bị giới hạn đối với HTML và không có quyền truy cập vào chương trình phụ trợ như PHP hoặc ASP.NET v.v., đôi khi khung nội tuyến là tùy chọn duy nhất của bạn.
Chúng không phải là thực hành không tốt, chúng chỉ là một công cụ khác và chúng bổ sung tính linh hoạt.
Để sử dụng làm phần tử trang chuẩn ... chúng tốt, vì chúng là cách đơn giản và đáng tin cậy để tách nội dung thành nhiều trang. Đặc biệt đối với nội dung do người dùng tạo, có thể hữu ích cho các trang nội bộ "sandbox" thành một số iframe do đó đánh dấu 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. Như adzm đã nói, bạn không muốn sử dụng iframe cho đ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 sự kiện nền tập lệnh, lựa chọn thường nằm giữa một số ẩn iframe và XmlHttpRequest để tải nội dung cho trang hiện tại. Sự khác biệt ở chỗ là iframe tạo tải trang, do đó bạn có thể di chuyển về và chuyển tiếp trong bộ nhớ cache của trình duyệt với hầu hết các trình duyệt. Lưu ý rằng Google sử dụng XmlHttpRequest khắp nơi, cũng sử dụng iframe trong một số trường hợp nhất định để cho phép người dùng quay lại và chuyển tiếp trong lịch sử trình duyệt.
Tôi nghĩ rằng điều quan trọng cần đề cập là iframe có thể được sử dụng để nhúng một trang từ một tên miền vào một trang từ một tên miền khác. Nếu trang nhúng muốn theo dõi người dùng bằng cookie và giữ thông tin đó từ miền máy chủ, thì tùy chọn duy nhất của bạn là sử dụng iframe khi JS nằm dưới sự kiểm soát của miền máy chủ. –
@NicholasLeonard Một ví dụ tốt là bạn có thể sử dụng chúng để buộc localstorage dựa trên bộ nhớ cache trang bằng cách làm cho trang chỉ mục một tập lệnh phát hiện nếu trang con nằm trong localstorage. Sau đó, document.write nó từ localstorage nếu nó ở đó và nếu không thêm vào iframe vào trang con đó. Trong trang con đó, có một kịch bản để lưu trữ các phần tử bên ngoài của phần tử HTML thành phần localstorage. Một lý do thực sự tốt để sử dụng phương pháp này là nó cho phép bạn thêm vào một màn hình tải. –
Tôi không đồng ý, * nhưng * Tôi không thể downvote nó, bởi vì nó là một POV quan trọng. –
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 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 sẽ 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 đến một đối tượng hẹp và nổi tiếng (ví dụ: trên mạng nội bộ cục bộ) và bạn thấy một lợi ích khi sử dụng IFRAME thì tôi có thể nói là OK.
Đó là 'thực hành không tốt' để sử dụng chúng mà không hiểu những hạn chế của chúng. Bài viết của Adzm tóm tắt rất tốt.
Trên mặt bích, gmail sử dụng nhiều iFrames ở chế độ nền cho một số tính năng thú vị hơ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ự liên quan nào về việc sử dụng chúng.
Cần lưu ý rằng iframe sẽ không phụ thuộc vào tốc độ kết nối internet của người dùng hoặc nội dung của khung nội tuyến, làm chậm tốc độ tải xuống (0.3s hoặc hơn) nhưng đáng chú ý ở tốc độ tải xuống trang của bạn. Đây không phải là thứ bạn sẽ thấy khi thử nghiệm cục bộ. Trên thực tế, điều này đúng với bất kỳ phần tử nào được thêm vào một trang, nhưng iframe dường như tệ hơn.
Tại sao? Và đó là cách của họ để làm cho iframe tải một khi trang chính được tải xong? –
Tôi không nhớ tại sao chúng lại quá chậm; Tôi đã nghiên cứu này một năm trước đây. Có lẽ bởi vì trình duyệt là cơ bản tạo ra một bối cảnh rendering hoàn toàn mới cho mỗi khung nội tuyến. Để làm cho chúng không tải cho đến khi tải trang hoàn tất, bạn có thể sử dụng iframe trống và sau đó đặt thẻ src iframe sau khi tải trang hoàn tất.Tuy nhiên, lưu ý rằng ngay cả iframe trống sẽ làm chậm hiển thị trang của bạn, mặc dù không tải xuống, do đó mọi thứ sẽ vẫn xuất hiện chậm hơn một chút so với người dùng của bạn. – Brian
Ngược lại, người ta có thể xem xét thảo luận về CDN (Mạng phân phối nội dung) khi tham chiếu tốc độ và iFrames. Hãy xem xét rằng iFrame có thể tải xuống tài nguyên song song và do đó cung cấp tăng tốc độ (tùy thuộc vào trình duyệt). Dưới đây là ít nhất một tham chiếu khác đồng ý với vị trí của tôi. http://developer.yahoo.com/performance/rules.html – Strixy
Mô hình khung hình ban đầu (Frameset và khung thành phần) rất xấu từ quan điểm khả năng sử dụng. IFrame có một phát minh sau đó không có nhiều vấn đề như mô hình khung ban đầu, nhưng nó có nhược điểm của nó.
Nếu bạn cho phép người dùng điều hướng bên trong khung nội tuyến, thì 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 chứ không phải URL của khung nội tuyến).
phải không đồng ý ... một nhận xét rộng như thế này không đủ tiêu chuẩn. – Dawesi
Đã 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ì đó để được nói chung tránh. Trong một trang web, chúng có thể hữu ích một chút. Tuy nhiên, cross-site, chúng hầu như luôn là một ý tưởng tồi cho bất cứ điều gì, nhưng là nội dung đơn giản nhất.
Xem xét các khả năng ... nếu được sử dụng cho nội dung được tham số hóa, chúng đã 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 SLA và phiên bản - 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 - khung tập lệnh máy chủ lưu trữ - sau đó có các giới hạn tập lệnh tên miền chéo (khác). Một số có thể bị tấn công, nhưng hiếm khi nhất quán. Và nếu nội dung khung của bạn có nhu cầu tương tác, nó sẽ phải vật lộn để vượt qua 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ị ảnh hưởng bởi nhu cầu di chuyển thông tin quyền lợi ra khỏi băng giữa các máy chủ.
Vì vậy, mặc dù, thỉnh thoảng hữu ích trong một trang web, chúng khá không phù hợp với mashup. Bạn đang xem xét tốt hơn các cổng thông tin và portlet thực. Tệ hơn nữa, họ là một người yêu thích mọi trang web nghiệp dư - nhiều người quản lý công nghệ đã siezed 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 nữa.
Có chắc chắn sử dụng cho iframes folks. Bạn sẽ đặt tiện ích mạng thời tiết trên trang của mình như thế nào? Cách khác duy nhất là lấy XML của họ và phân tích nó, nhưng sau đó tất nhiên bạn cần điều kiện để ném lên đồ họa thời tiết nóng chảy ... không thực sự đáng giá, nhưng cách dọn dẹp hơn nếu bạn có thời gian.
Dựa trên kinh nghiệm của tôi, mặt tích cực cho iframe là khi gọi mã của bên thứ ba, có thể liên quan đến việc gọi javascript có lệnh Document.write();. Như bạn có thể biết, các lệnh này không thể được gọi là không đồng bộ do cách nó được phân tích cú pháp (DOM Parser, vv). 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ị các phần khác nhau 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 lệnh Document.write() của phpad không đồng bộ. Ngăn chặn và js khóa.
Khi trang chính của bạn tải trong giao thức HTTP và các phần của trang của bạn cần phải hoạt động trong giao thức HTTPS, iFrame có thể đánh bại tay jsonp.
Đặc biệt, nếu dataType của bạn không phải là json nguyên bản và cần được dịch trên máy chủ thành json và được dịch trên máy khách trở lại, ví dụ: html phức tạp.
Vì vậy, nope - iFrame không phải là điều xấu.
Chúng không tệ, nhưng thực sự hữu ích. Tôi đã có một vấn đề lớn một số thời gian trước đây, nơi tôi đã nhúng nguồn cấp dữ liệu twitter của tôi và nó sẽ không cho phép md 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ó như là một khung nội tuyến.
Chúng cũng tốt vì tất cả các trình duyệt (và trình duyệt trên điện thoại) đều hỗ trợ chúng. Họ 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.
"nếu bạn bị giới hạn đối với HTML và không có quyền truy cập vào chương trình 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" ... điều đó không đúng. Bạn có thể nhúng nội dung bên ngoài vào trang của mình bằng cách nhận dữ liệu qua jquery ajax và sau đó điền một div vào dữ liệu đó. – developer747
@ developer747 - Điều đó sẽ không hoạt động nếu nội dung bên ngoài nằm trên một trang web khác do [chính sách gốc tương tự] (http://en.wikipedia.org/wiki/Same_origin_policy). Trong một số trường hợp ít người biết đến, trang web từ xa có thể hỗ trợ [JSONP] (http://en.wikipedia.org/wiki/JSONP); nhưng có lẽ không. –
Tôi cảm thấy như iframe kém hữu ích hơn khung hình trước bởi vì iframe không thể được thay đổi kích thước bởi người dùng - nhưng tôi sẽ không sử dụng bộ khung cho bất kỳ thứ gì ngoài hướng dẫn vì nó không còn tồn tại trong html5 nữa. Ví dụ: [Hướng dẫn của nhà sản xuất trò chơi] (http://docs.yoyogames.com/) –