Sunt iframe o idee teribilă?

Construiesc un widget și foloseam iframe pentru a prezenta conținut în el. La un moment dat, aș putea să încep să difuzez HTML și JS de la terți, așa că am crezut că iframe-urile ar fi o idee bună.

Aceasta face javascript-ul widgetului un pic mai complicat și mă îngrijorează că aceasta nu ar putea fi cea mai bună implementare.

Aveți vreun sfat? Ar fi un ajutor uriaș pentru a auzi ce cred ceilalți despre iframe.

0

15 răspunsuri

Un lucru pe care l-am descoperit recent este că paginile .aspx încorporate în interiorul iframe-urilor au uneori probleme cu pierderea cookie-urilor, ceea ce a dus la pierderea stării sesiunii într-o aplicație cu care am fost implicată.

Pentru mine, a fost într-un scenariu în care un alt magazin de dezvoltare consuma una dintre paginile mele .aspx pe propria pagină. Aceasta înseamnă că am fost pe servere separate, care pot sau nu pot fi importante.

Se pare că acest lucru a fost cauzat de faptul că pagina părinte respinge cookie-urile pentru pagina copil ... După cum merge și cookie-ul de sesiune, merge și sesiunea.

The specific mechanics of how this works are a little involved: More Details

Această problemă nu a avut impact asupra FireFox, dar a apărut în IE7 și a fost un adevărat mister pentru câteva ore.

De asemenea, trebuie să contrazic articolul pe care l-am legat mai sus la un punct. Articolul spune că nu obțineți acest lucru dacă pagina care conține este, de asemenea, un .aspx ... În acest caz, acest lucru nu era adevărat deoarece ambele pagini erau .aspx.

Asta pune la îndoială orice altceva despre care spune articolul despre această situație, dar a condus la o rezoluție, deci este și ceva.

După cum a sugerat articolul, am introdus următorul cod, care injectează un antet în evenimentul Init al paginii, un p3p (Proiectul Preferințe de confidențialitate - nu am auzit de el)

HttpContext.Current.Response.AddHeader("p3p", "CP=\""IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT\""")

... Și asta a rezolvat problema.

0
adăugat

Personal, aș evita dacă puteți fără prea multă hassle. Folosind Javascript (sau AJAX dacă aveți nevoie să le încărcați dinamic), puteți folosi destul de ușor doar un div și schimbați conținutul după cum este necesar - în unele cazuri acest lucru vă va oferi mult mai multă flexibilitate și vă va simplifica JS, mai ales dacă există o mulțime de interacțiune între widget-ul dvs. și restul paginii.

Acestea fiind spuse, aș investiga ambele opțiuni și dacă traseul JS pare prea complicat sau complicat, mergeți doar cu iframe.

0
adăugat

O bună opțiune este să utilizați proprietatea CSS de tip overflow. Valoarea implicită este vizibilă, însă o puteți seta ascunsă, derulată sau automată. Aș folosi mașina în cazul tău. Dacă conținutul dvs. devine prea mare, acesta va arăta ca și cum ați avea o iframe, dar aceasta este încă pe pagină.

see: overflow property

0
adăugat

Din punct de vedere tehnic, nu există nimic mai greu cu iFrame decât cu alternative. Dar semantic, există rău.

Web-ul se bazează pe HTTP, un protocol care spune că o adresă URL dată va duce întotdeauna la o resursă unică.

Folosind iFrame, puteți servi mai multe resurse resimțite într-o pagină web în spatele unei adrese URL pentru toate acestea. Dacă aveți îngrijorări cu privire la modul în care ar trebui să crească Web-ul, este dificil. În plus, pentru roboții motoarelor de căutare, este complicat.

0
adăugat

Depinde ce face widgetul. Dacă ele au locul lor, ele provoacă puține dureri de cap (nu mai vorbim, făcând-o mai complicată), astfel încât majoritatea oamenilor au tendința de a le evita dacă nu este absolut necesar.

0
adăugat

Există doar un singur lucru "cu adevărat rău" cu ei, despre care știu.

În cazul în care partea dvs. terță face unele JavaScript, care încearcă să-și modifice DOM-ul un pic prea devreme ... IE6 și IE7 va arunca oh atât de nefolositoare " Operația Aborted ", apoi goale nu numai iframe, dar întreaga pagină înconjurătoare . (de exemplu, site-ul dvs. apare în jos)

Nu este fixat în IE8, dar accidentul este mai bine manipulat.

0
adăugat

cadrele ifframe, cum ar fi cadrele, sunt controale doar pentru a fi utilizate pentru sarcina la îndemână. Ca atare, nu este nici bun, nici rău în sine, dar ar putea fi bun sau rău în funcție de sarcina la îndemână și cerințele clientului. Din câte știu, toate browserele moderne (și utilizatorii non-linux) vor putea "vedea și consuma" iframe fără probleme.

0
adăugat

Nu, nimic nu este în regulă cu cadrele iframe. Iframe-urile sunt probabil o idee mai bună dacă veți începe să difuzați conținuturi terțe părți.

Viitoarea spec. HTML5 intenționează, de asemenea, să construiască mai multe caracteristici de securitate în iframe pentru astfel de situații, așadar aș considera că este o practică bună să le folosesc și acum.

0
adăugat
I +1 aici - singurul avertisment, desigur, este să vă asigurați că utilizarea este într-adevăr ideală (mai degrabă decât pur și simplu folosind Ajax pentru a apuca datele necesare - serverul poate apuca întotdeauna și analiza "conținutul terț" extrase prin apeluri out-of-band).
adăugat autor Jason Bunting, sursa

Nu neapărat, atâta timp cât conținutul din cadrul iframe este previzibil.

0
adăugat

Înainte ca XMLHTTPRequest să fie folosit pe scară largă, utilizatorii foloseau o combinație de JavaScript și iframe pentru a servi conținutul într-o manieră dinamică, fără a face reîmprospătarea completă a paginilor.

Există o mulțime de informații despre dezvoltarea de site-uri în acest fel, astfel încât ar trebui să aveți un timp relativ ușor de a găsi soluții pentru o mulțime de snags pe care sunt susceptibile de a lovi.

Singurul lucru pe care l-am găsit a fi o durere este folosirea în mai multe domenii a JavaScript-ului în iframe. Dacă pagina încorporată în iframe este dintr-un domeniu diferit de pagina "părinte", browserele au restricții de securitate împotriva accesului la unul din celălalt. Trucul este pentru ambele pagini să declare

document.domain = 'somedomain.com';

Există o mulțime de lucruri pe Web despre acest tip de soluție.

Mult noroc!

0
adăugat
Cred că pot schimba document.domain numai pentru a fi un domeniu de nivel superior - adică www.acme.com poate schimba domeniul la acme.com, dar nu la google.com. Astfel, acest lucru ajută doar dacă rapoartele comunică între subdomeniile unui singur domeniu. (Am putea greși, dar asta mi-am amintit)
adăugat autor Josh, sursa
@Josh - aveți dreptate, document.domainul va funcționa numai pentru pagini pe același domeniu parental, dar subdomeniu diferit.
adăugat autor Livingston Samuel, sursa
@Josh Ai dreptate, dar poți folosi întotdeauna window.location.href .
adăugat autor nyuszika7h, sursa

Din experiența mea, iframe-urile sunt fie hack-uri, fie economizoare de timp - asigură-te că dacă le folosești, sunt necesare din acele motive. Dacă aveți control asupra conținutului (sau puteți obține control prin oglindire sau răzuire) ar trebui să luați în considerare utilizarea AJAX sau server-side include pentru a trage date externe pe și împingeți-l de pe pagină - va ajunge mai flexibil, mai mult robustă și ușor de gestionat în cele din urmă.

0
adăugat

O să nu fiu de acord cu majoritatea și să spun că da, iframe-urile sunt o idee absolut teribilă . Oricine care a lucrat timp de un timp în cadrul comunității Web Design va fi de acord că iframe-urile sunt rău pur și trebuie evitate dacă nu este esențial ABSOLUTELIC .

Motivele mele pentru a crede că sunt rele sunt pentru că rupe modelul de navigație al unei pagini web. Prin utilizarea unui iframe, puteți rupe efectiv butoanele din spate și înainte din browsere și puteți confunda utilizatorii. Aceasta rupe întreaga idee din spatele protocolului HTTP; că o adresă URL va duce întotdeauna la o locație unică. Dacă iframe-ul ar fi un cal, s-ar fi retras mult timp în urmă. Există și alte modalități de a difuza conținutul în mod dinamic, iar acestea ar trebui folosite în schimb.

Dacă creați un widget , atunci preocupările imediate legate de utilizarea iframe-urilor dispar (rău pentru motoarele de căutare, rău pentru marcare etc.), dar conținutul va fi mai bine difuzat dinamic sau chiar într-o fereastră nouă mai degrabă decât într-o iframe.

0
adăugat
-1 după cum se spune într-un alt răspuns: "nu este nici bun, nici rău în sine, dar ar putea fi bun sau rău în funcție de sarcina la îndemână". De asemenea, problema cu butonul din spate și înainte nu este specifică iframe-urilor, dar apare și cu alte conținuturi dinamice.
adăugat autor Christophe, sursa

Re: "întreaga idee din spatele protocolului HTTP, că o adresă URL va duce întotdeauna la o locație unică"

Îmi servesc întregul CMS din aceeași adresă URL pentru securitate și scalabilitate (folosind mai ales POST în locul parametrilor GET). Nu vreau ca un conținut securizat să fie vizibil fără autentificare, iar un sistem de expediere face ca dezvoltarea să fie mai ușoară pentru mine, deoarece nu trebuie să-mi fac griji cu privire la autentificare pentru fiecare pagină nouă.

De asemenea, pentru anumite aplicații SEO nu este aplicabil (cum ar fi pentru ERP bazat pe web).

Folosesc un iFrame pentru difuzarea conținutului dintr-un copac generat de PHP. Nu vreau ca copacul (și vizibilitățile nodului) să fie refăcute ori de câte ori utilizatorul dorește să vizualizeze detaliile pentru o piesă/ansamblu.

0
adăugat
Mă bucur că nu sunt unul dintre utilizatorii dvs.! (Nu poate fi marcată la toate !)
adăugat autor SamB, sursa

Există mai multe probleme de utilizare și accesibilitate cu iframe . Unele browsere și cititoare de ecran nu pot afișa iframe-uri, așadar trebuie să oferiți un conținut alternativ:

<iframe src="content.html">
    

This content will only be displayed by browsers that do not support iframes. You should provide a link to the content, or in your case an alternative way to use your widget.

</iframe>

Dacă începeți să difuzați conținut de la o terță parte, ar trebui să aveți grijă să focalizați focalizarea după iframe după terminarea încărcării. În timp ce o deranjare minoră pentru utilizatorii obișnuiți, poate fi foarte confuză pentru utilizatorii care navighează prin intermediul ecranatorilor.

0
adăugat

Există o problemă semnificativă cu iframe-uri care abia dacă primesc o mențiune, dar care mă înghită de umplutură.

Colegul nostru are o durată de viață investită într-o bază de date în continuă schimbare pe care am încărcat-o în foile de calcul Google Docs pe care le afișăm apoi pe site-ul nostru alături de o mulțime de materiale de sprijin.

Nu există absolut nimic pentru a opri pe cineva să ia codul iframe din sursa paginii mele și să-l împingă pe pagina ei. Acum ei primesc toate datele noastre, reîmprospătate până acum câteva minute, servite la pagina lor pentru absolut nimic.

Dacă un iframe Google ar putea fi legat de un anumit domeniu, acest lucru ar opri acest lucru în piesele sale.

Orice idei, scântei puternice?

0
adăugat
Acest lucru este destul de vechi, dar dacă sunteți în căutarea unei soluții, atunci mă pot gândi să folosesc antetul X-Frame-Option pentru a restricționa cine poate încărca iframe-ul. Acum, nu puteți aplica în mod evident acest antet pe un document Google docs, deoarece nu îl controlați. Dar ceea ce puteți face este să utilizați în mod direct adresa URL a docs-ului Google, să veniți cu propriul url, care face o redirecționare către serverul docs Google url. Apoi puteți aplica antetul X-Frame-Option adecvat pe adresa proprie
adăugat autor Suhas, sursa
JavaScript, România - Moldova
JavaScript, România - Moldova
328 participanți

Comunitatea Română JavaScript: github.com/js-ro Pentru confort, opriți notificările. Parteneri: @node_ro, @php_ro, @python_ro, @seo_ro, @RomaniaGroup, @ai_ro, @Grupuri_IT Offtop: @holywars_ro Joburi: @js_jobs_ro Sponsored with ❤️ by ciupacabra.com