Risposte:
Come con tutte le tecnologie, ha i suoi alti e bassi. Se stai usando un iframe per aggirare un sito adeguatamente sviluppato, ovviamente è una cattiva pratica. Tuttavia a volte un iframe è accettabile.
Uno dei problemi principali con un iframe riguarda i segnalibri e la navigazione. Se lo stai usando per incorporare semplicemente una pagina all'interno dei tuoi contenuti, penso che vada bene. Ecco a cosa serve un iframe.
Tuttavia, ho visto anche gli iframe abusati. Non dovrebbe mai essere usato come parte integrante del tuo sito, ma come contenuto all'interno di un sito.
Di solito, se puoi farlo senza un iframe, questa è un'opzione migliore. Sono sicuro che altri qui potrebbero avere più informazioni o esempi più specifici, tutto dipende dal problema che stai cercando di risolvere.
Detto questo, se sei limitato a HTML e non hai accesso a un backend come PHP, ASP.NET ecc., A volte un iframe è la tua unica opzione.
window.postMessage(), ad esempio per implementare il ridimensionamento automatico iframe collaborativo.
Non sono cattive pratiche, sono solo un altro strumento e aggiungono flessibilità.
Da usare come un elemento di pagina standard ... sono buoni, perché sono un modo semplice e affidabile per separare il contenuto in più pagine. Soprattutto per i contenuti generati dagli utenti, può essere utile "sandbox" delle pagine interne in un iframemarkup così scadente non influisce sulla pagina principale. Il rovescio della medaglia è che se si introducono più livelli di scorrimento (uno per il browser, uno per il iframe) i tuoi utenti saranno frustrati. Come ha detto adzm, non si desidera utilizzare un iframeper la navigazione principale, ma pensarli come un testo / markup equivalente al modo in cui un video o un altro file multimediale verrebbero incorporati.
Per gli eventi in background di script, la scelta è generalmente tra un nascosto iframee XmlHttpRequestcaricare il contenuto per la pagina corrente. La differenza è che iframegenera un caricamento della pagina, quindi puoi spostarti avanti e indietro nella cache del browser con la maggior parte dei browser. Si noti che Google, che utilizza XmlHttpRequestovunque, utilizza anche iframes in alcuni casi per consentire a un utente di spostarsi avanti e indietro nella cronologia del browser.
È 'cattiva pratica' usarli senza capire i loro svantaggi. Il post di Adzm li riassume molto bene.
D'altra parte, gmail fa un uso pesante di iFrames in background per alcune delle sue funzioni più interessanti (come il caricamento automatico dei file). Se sei a conoscenza dei limiti di iFrame, non credo che dovresti provare alcun complimento per usarli.
Avendo lavorato con loro in molte circostanze, ho davvero pensato che gli iframe fossero l'equivalente della programmazione web dell'istruzione goto. Cioè, qualcosa da evitare in generale. All'interno di un sito possono essere in qualche modo utili. Tuttavia, su più siti, sono quasi sempre una cattiva idea per tutto tranne che per il più semplice dei contenuti.
Considera le possibilità ... se utilizzate per contenuti con parametri, hanno creato un'interfaccia. E in un sito professionale, quell'interfaccia richiede uno SLA e la gestione della versione, che quasi sempre vengono ignorati in fretta per andare online.
Se utilizzato per contenuti attivi - frame che ospitano script - ci sono le (diverse) restrizioni di script tra domini. Alcuni possono essere hackerati, ma raramente in modo coerente. E se i tuoi contenuti incorniciati hanno bisogno di essere interattivi, faranno fatica a farlo oltre il frame.
Se utilizzati con contenuti concessi in licenza, i siti partecipanti sono gravati dalla necessità di spostare le informazioni sui diritti fuori banda tra gli host.
Quindi, anche se occasionalmente utili all'interno di un sito, sono piuttosto inadatti ai mashup. Stai molto meglio guardando portali e portlet reali. Peggio ancora, sono un tesoro di ogni amatore del web - molti manager della tecnologia hanno cercato di risolverli come una soluzione a molti problemi. In effetti, ne creano di più.
Sulla base della mia esperienza, un lato positivo di iframe è quando si chiamano codici di terze parti, che può comportare la chiamata di un javascript che chiama a ha un Document.write();comando. Come forse saprai, questi comandi non possono essere chiamati in modo asincrono a causa di come viene analizzato (parser DOM ecc.). Un esempio di questo è http://sourceforge.net/projects/phpadsnew/ Ho fatto uso di iframe per velocizzare il nostro sito in quanto vi erano più chiamate a phpadsnews e il sito era in attesa di risposta prima di procedere a rendere diverso parti della pagina. con un iframe sono stato in grado di consentire al sito di eseguire il rendering di altre parti della pagina e comunque chiamare il Document.write()comando di phpad in modo asincrono. Prevenzione e blocco js.
Ci sono sicuramente usi per gli iframe. In quale altro modo inseriresti il widget delle reti meteorologiche sulla tua pagina? L'unico altro modo è quello di afferrare il loro XML e analizzarlo, ma ovviamente hai bisogno di condizioni per lanciare la grafica meteorologica perenne ... non ne vale davvero la pena, ma molto più pulito se hai tempo.
Il modello originale di frameset (Frameset e Frame-elements) era pessimo dal punto di vista dell'usabilità. IFrame è stata un'invenzione successiva che non ha avuto tanti problemi come il modello originale del set di cornici, ma ha il suo svantaggio.
Se si consente all'utente di navigare all'interno dell'IFrame, i collegamenti e i segnalibri non funzioneranno come previsto (perché si aggiunge l'URL della pagina esterna ai segnalibri, ma non l'URL dell'iframe).
Quando la tua pagina principale viene caricata nel protocollo HTTP e parti della tua pagina devono funzionare nel protocollo HTTPS, iFrame può battere jsonp a mani basse.
Soprattutto, se il tuo dataType non è nativamente json e deve essere tradotto sul server in json e tradotto sul client in ad es. Html complesso.
Quindi no - iFrame non è malvagio.
Non sono male, ma in realtà utili. Qualche tempo fa ho avuto un grosso problema in cui dovevo incorporare il mio feed di Twitter e non avrei lasciato che md lo facesse sulla stessa pagina, quindi l'ho impostato su una pagina diversa e l'ho inserito come iframe.
Sono anche buoni perché tutti i browser (e browser del telefono) li supportano. Non possono essere considerati una cattiva pratica, purché li usi correttamente.
Vale la pena notare che gli iframe, indipendentemente dalla velocità della connessione Internet degli utenti o dal contenuto dell'iframe, causeranno un piccolo (0,3 secondi circa) ma un notevole rallentamento della velocità di download della pagina. Questo non è qualcosa che vedrai quando lo testerai localmente. In realtà, questo vale per qualsiasi elemento aggiunto a una pagina, ma gli iframe sembrano peggiorare.
Ho visto gli IFRAME applicati con successo come un modo semplice per creare menu di scelta rapida dinamici, ma il pubblico di destinazione di quell'app Web era solo utenti di Internet Explorer.
Direi che tutto dipende dalle tue esigenze. Se desideri assicurarti che la tua pagina funzioni allo stesso modo su tutti i browser, evita gli IFRAME. Se stai prendendo di mira un pubblico ristretto e ben noto (ad es. Sulla Intranet locale) e vedi un vantaggio nell'uso degli IFRAME, direi che è OK farlo.