2009-08-09 138 views
18

是否有任何理由而不是要使用iframe?我目前使用它從不同的服務器(註冊頁面 - 分佈式應用程序的一部分)加載頁面以提供無縫體驗。是否使用iframe被認爲是不好的做法或者它的使用是否正常?不使用IFrame的原因?

+1

看到這個問題:http://stackoverflow.com/questions/362730/are-iframes-considered-bad-practice – 2009-08-09 23:19:25

+6

供參考:多個答案是偉大的。檢查所有這些,不只是接受的。 – Alex 2009-08-09 23:50:19

+0

[This](http://stackoverflow.com/a/362752/1257607)可能會幫助 – DanielV 2015-04-14 12:11:13

回答

16

iframe是一個很好的工具。它享有近乎通用的瀏覽器支持,易於實現並具有許多有用的功能。與其他任何HTML元素一樣,它可能會被濫用,但它可以智能化地運用在可靠的用戶界面中。

有些開發人員可能會反對使用AJAX,在某些情況下這可能是更合適的方法,但AJAX不是萬能的,iframes可以是一個更簡單的實現,它對用戶具有相同的最終結果。先做任何最簡單的事情,只有當你可以驗證如何以及爲什麼不起作用時才做出改變。

+0

我想做AJAX,但正如上面提到的註冊頁面來自不同的子域,我無法做到這一點(跨域問題) – Alex 2009-08-09 21:43:27

+0

@Alex您可以通過編寫自己的Web服務來獲取並重新顯示來自其他域的數據,並從您的AJAX代碼中調用* that *來解決跨域問題。然而,正如我在答覆中所說的,如果iframe已經完成了你所需要的,那麼不要過度設計它,或者花費更多的時間。 – 2009-08-09 21:45:45

12

繼續使用iframe。這就是爲什麼一個例子:

整個VISA驗證的事情真的讓我很煩。我很高興在我信任的某個網站購物,當我重定向到我從未聽說過的某個網站時(不是 visa.com),我必須填寫其他表單並希望我能夠正確重定向回到購物網站。

然後最近我在約翰劉易斯的網站購物,他們帶着通過Visa驗證的頁面在iframe - 精彩!我仍然在看約翰劉易斯的網站,而所有這一切發生的是我被要求提供我的Verified By Visa密碼 - 沒有問題。

雖然作爲網頁開發人員,我知道這和原來的重定向沒有技術上的區別,那裏的用戶體驗是好多了!

+4

這是一個觀點,但我會說相反,當輸入信用卡數據時,我會更願意完全在Visa驗證(PayPal)網頁(地址欄中顯示的網址),而不是使用我的信用卡數據在某人的網站的iframe中。 – 2010-06-08 13:35:55

+2

@Marco Demaio:Visa驗證頁面包含我在註冊該計劃時輸入的安全短語,所以我知道這是真實的。是的,理論上約翰劉易斯的某個人可以代理Verified By Visa內容並嗅探我的結果,但這就是爲什麼我說「我很樂意在我信任的某個網站購物」 - 我相信John Lewis不會那樣做。驗證碼簽證的網址適用於某些您從未聽說過的地址,因此看到它實際上會降低您的信任度。 – RichieHindle 2010-06-09 08:59:12

8

內部框架訪問該父文檔,例如的某些特性使用parent.location.hrefparent.window.locationIE允許限制)將父幀重定向到新位置。

這是偉大的嵌入來自其他服務器的內容時​​(即使你相信它的服務器可能會受到影響),網絡釣魚攻擊。

I幀,也可用於其他各種攻擊:IFrames security summary

3

使用HTML 5,您可以使用跨文檔消息傳遞API將消息從窗口發送到窗口,但現在iFrame是任何需要樣式和腳本加載的AJAX最可行的替代方案數據。

如果你打算只使用文本數據iFrame中,使用AJAX來代替。如果您希望外部CSS或JavaScript在受保護的環境中工作,想要從頭開始樣式化或需要訪問跨域文檔,請使用iFrame。

缺點是I幀的可訪問性一般很爛,雖然可以防止這種通過確保您繼續內嵌框架與針對屏幕外部內容的通知。同時檢查HTML規範以獲取更多可訪問iFrame的其他方法。除此之外,明智的限制腳本,iFrame是一個偉大的工具是負責任和稀疏使用。

最後一個注意事項是,堆滿整個iFrames的頁面絕對不是一個好主意,記住,對於每個加載的iFrame,創建一個DOM,創建HTML請求並創建文檔包裝,在內存中佔用內存和帶寬處理。將頁面上的iFrame保持在最低限度,並避免濫用HTML中的強大工具。

3

IFrames是在網頁中「包含」外部內容的好方法。但是,有一些(小)缺陷:

  • 如果IFrame不是源自同一個域,安全沙箱將導致JavaScript問題。
  • 你不能讓CSS在IFrame和父頁面之間進行協作,除非你自己控制樣式表。
  • 從索引的角度來看,IFrame的內容不存在。
  • 出於同樣的原因,屏幕閱讀器可能不喜歡IFrame。或者他們將無法正確指出IFrame內容的相對含義。

除此之外,他們很棒!我提到的觀點甚至可能被認爲是有利的,如果你仔細考慮它(除了屏幕閱讀器之外):原則上,IFrame不能影響其父頁面的佈局,也不會受到其父頁的影響。

10

優點:

  • 緩慢的第三方內容,如徽章和廣告
  • 安全沙箱
  • 下載腳本平行

缺點幫助

  • 昂貴即使空白
  • 塊頁面的onload
  • 非語義

來源:Best Practices for Speeding Up Your Web Site

+0

您網頁上的任何資源都可以阻止頁面加載,如圖片和視頻。更現代的方法總是使用DOMContentLoaded,該iframe不會阻塞。我不明白這裏的非語義意味着什麼。對於昂貴如果空白,有沒有參考? – texasbruce 2015-03-01 22:54:48

+0

您作爲源提供的鏈接真的很有用:) – Biki 2016-02-08 11:09:48

1

一般來說,I幀是搜索引擎優化的原因,一個壞的經驗。所以,你問有沒有理由不使用iframe?是的,如果你使用iframe,你會在搜索引擎中失去一些有機的位置。

當然,有可用性問題,可以(而且應該)打敗頁面的SEO價值。

0

在許多情況下與他們合作,我真的認爲iframe是goto語句的web編程等價物。也就是說,一般要避免的事情。在一個網站內,它們可能有點用處。但是,跨網站,除了最簡單的內容之外,它們幾乎總是一個糟糕的主意。

考慮可能性...如果用於參數化內容,他們已經創建了一個接口。而在專業網站中,該界面需要SLA和版本管理 - 在急於上網時幾乎總是被忽略。

如果用於活動內容 - 託管腳本的幀 - 則存在(不同的)跨域腳本限制。有些可能會被黑客入侵,但很少一致。如果你的框架內容需要互動,那麼在框架之外這樣做會很困難。

如果與許可內容一起使用,則參與站點需要在主機之間移動授權信息。

因此,儘管在一個站點內偶爾有用,但它們卻不適合混搭。你更好地看待真正的門戶和portlet。更糟的是,他們是每個網絡業餘愛好者的寵兒 - 許多技術經理已經將他們作爲解決許多問題的方法。事實上,他們創造更多。