Hur ställer sig webbutvecklare, användare - ja alla! - till iframes idag 2010? Har googlat lite och kommit fram till att det bland annat inte är helt SEO-optimalt, utöver att jag själv kan känna dem en aning bökiga emellanåt (scrollning exempelvis). Är det lika illa som att använda vanliga ramar, och så vidare.
Kort och gott - är det (y) eller (n) som gäller (plus lite argument)?
Dåligt: allt vad länkar heter. Kan du inte kopiera adressfältet och hamna på samma ställe som du är på med den adressen så är det värdelöst. Dessutom, om sida1.htm innehåller en iframe som visar sida2.htm, och någon råkar länka till sida2.htm istället för sida1.htm så saknas allt vad menyer heter. Sedan har vi hela SEO-problematiken. Dessutom blir det layout-problem, t.ex. det klassiska "hur kan jag få dynamisk höjd på min iframe beroendet på innehållet i den?"
Jag använder en iframe till administrationsdelen i en webbapplikation jag utvecklar. Det fungerar bra, eftersom man då slipper ladda om trädmenyer och annat runt om när man klickar på en länk.
Vad gäller höjd och liknande justeras den (och resten av gränssnittet) med Javascript när fönstret förändras, vilket gör att den alltid är i rätt storlek. Innehållet i iframen anpassar sig så länge det är möjligt, annars får du scroll i iframen.
Men! Viktigt här är att jag inte skulle använda detta publikt på en webbplats, då finns (ofta) bättre lösningar.
Jag tror fortfarande att det inte är helt ovanligt att man använder iframes (eller <object> för att validera mot xhtml även om det renderas på samma sätt). Men det blir vanligare och vanligare att man använder ajax för att skapa serveranrop och presentera data. En av fördelarna med ajax är att du kan bädda in resultatet på sidan på ett snyggare sätt. Istället för att få en fyrkantig ruta någonstanns kan du uppdatera valda element. Då får dessutom inte problem med history'n i webbläsaren. Du får normalt mindre problem med oönskade serveranrop om du använder ajax. Har du exempelvis varukorgen i en iframe i en webbhandelslösning och användaren klickar uppdatera på sidan händer det ofta att man postar anropet för att lägga senaste varan i varukorgen en gång till och helt plötsligt har du 2 produkter i varukorgen. Använder du ajax har du anropet kopplat till köp-knappen på varan och denna risk försvinner. Potentiella nackdelar med ajax kan vara att det ställer högre krav på plattformen där sidan visas, smartphones och alla andra nya coola gadgets med inbygga webbläsare. Man kan säkert skriva en mindre doktorsomhandling i ämnet utan att komma fram till vad som är "rätt" eller "fel".
I 9.999 fall av 10.000 är frames (vare sig det är vanliga framesets eller iframes) onödiga och skapar bara mer bekymmer. Men i extremt få fall är dom kanonbra.
I detta fall håller jag med Danne V.
iframes är (n)
En frame är en frame oavsett om den är "inline" eller ej - och användning av iframes är ett gissel (om inte annat tillgänglighetsmässigt och användbarhetsmässigt) om man använder dem till att presentera innehåll i någon form.
Att använda iframes idag ligger för mig i paritet med att använda tabell-element för layout, eller font-element för att formattera text - det är d****igt omodernt och en oerhört dålig vana... Samtidigt som det kan ha sina fördelar om man antingen är aningslös, skiter i tillgänglighetsdebatten eller av någon anledning (t.ex. pga kundkrav) är extremt utlämnad till ett designmönster som inte går att realisera billigare med "modernare" webbteknik (och i de lägena har man förmodligen att göra med en aningslös kund eller en omodern designer som inte har koll på vad man kan prestera med webbstandard idag).
Med det sagt
I HTML5 utökas iframe (tyvärr) med nya formatteringsmöjligheter (som t.ex. att ställa in dess höjd efter det laddade dokumentets innehåll med attributet "seamless") - vilket gör att alla de argument emot användning av frames som förekommer i denna tråd i praktiken körs upp därbak på alla som argumenterat emot frames de senaste åren av HTML5-specens upphovsmän.
Så - iframes är i allra högsta grad (n) i min bok, men det jag tycker spelar ingen roll för i HTML5 återinförs och legitimeras iframes trots att det finns moderna alternativ som gör ett bättre jobb att få samma effekt utan de nackdelar som frame-användning innebär.
Så för oss som har insett dess nackdelar och såg fram emot att iframe höll på att strykas ur HTML är det bara att "bend over, spread 'em and pucker up" och inse att iframes kommer att få utökad användning framöver oavsett vad vi tycker eller propagerar för.
Om ni använt ex. Coolite som bygger på Ext Js, så blir det ganska mycket Iframes, eller bara använt kanske Ext js :) Tycker att Iframes är bra så länge det används i Backoffice applikationer, men till publika tycker jag inte om det.
Det här rör en publik webb och där ska jag framföra att man till varje pris underviker det. På intranätet körs det iFrames och de ställer till en hel del problem, när man försöker få det att se vettigt ut.
Tack föra alla synpunker så här långt, fortsätt gära att fylla på med mer. (y)
Varför skulle tillgänglighet vara ett mindre problem i Backoffice- eller intranätssystem?
Att utesluta (eller förvåra för) funktionshindrade är väl diskriminering oavsett ?
"Nej tyvärr - du kan inte jobba som ekonomiassistent hos oss för att vi använder en viss teknik på vårt webbaserade intranät som inte fungerar så bra med dina hjälpmedel"
Eller hur :P
Kort sagt - nästa stora tillgänglighetsutmaning är intranäten.
... och en iframe är en lika dålig idé för ett intranät som för en publik webb...
... men HTML5 legitimerar iframes - så whatever :P
Måtte hin håle ta alla dessa iframe-baserade kartlösningar som sprider sig som ogräs x( x( x(
Har idag vid upprepade tillfällen "råkat" trilla över kartsidor där en Google-Map ligger inlagd med "100% bredd" överst, med textinformation under, vilket fått mig att "råka" panorera runt i kartan istället för att fortsätta scrolla ner på sidan på min högst storleksbegränsade nallefonskärm när jag använt högst naturliga svepgester...
... Vilket I stort sett utan undantag gjort att informationen inte gått att komma åt utan att tappa kontext...
