DrydenMedlem sedan aug. 200218 625 inlägg 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)?
Bättre än vanliga ramar, men inte bra.
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?"
LedelMedlem sedan dec. 2004736 inlägg 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.
På "Facebook-style" så lägger jag den URL som iframen besöker efter ett # i adressfältet, vilket gör att du kommer rätt om du kopierar länken då "huvudsidan" kollar efter detta när den först laddas. (Ex: http://www.app.se/Admin/Default.aspx#Options/EditOption.aspx?OptionId=1)
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.
JojoxxMedlem sedan juni 20004 308 inlägg 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".
jojoxx, det där med två produkter i varukorgen är ju en fantastisk feature ;)
Seriöst så håller jag med om att ajax är bättre i de allra flesta fallen.
Danne VMedlem sedan aug. 20068 090 inlägg 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.
Här är en lista med alla nackdelar: http://apptools.com/rants/framesevil.php
jarvkloMedlem sedan juli 20013 378 inlägg 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.
Tyvärr. :(
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.
DrydenMedlem sedan aug. 200218 625 inlägg 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)
jarvkloMedlem sedan juli 20013 378 inlägg Hmm...
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
jarvkloMedlem sedan juli 20013 378 inlägg 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...
Iframes suger !!!!!!
jarvklo skrev:
Iframes suger !!!!!!
:OO nja, snarare hur folk använder dem.
Men på en publik site kan man gärna undvika dem.
jarvkloMedlem sedan juli 20013 378 inlägg
Fredde Mannen skrev:
:OO nja, snarare hur folk använder dem.
:OO Don't go there - resist the dark side or be prepare to be tempted by frameset and frame as well ...