iframes... Godt eller skidt?

Stort set alle browsere understøtter iframes (ej NN4 - men det er gaaaammel), og iframes er jo også en del af den officielle standard.

De er dejlige til mange ting - men personligt bruger jeg dem aldrig til "frontend" sider. Hvorfor? Det er bare en idé jeg har - så løber jeg heller ikke ind i problemer med søgemaskinerne.

Problemer med soegemaskiner? Kan du uddybe den lidt?

gennerelt vil jeg ikke bruge dem... da problemmet som en iframe skal løse, kan afklares på så mange måder at det halve kunne være nok, er der jo ingen grund til at nogen browsere enten ikke kan vise dem korrekt/slet ikke vise dem.

questis>> Hvilke problemer er det du tænker på en I-frame skal løse? Og hvad er det for et hav af andre muligheder vi har?

Selv benytter jeg I-frames. Ikke fordi jeg elsker dem (jeg vil faktisk gerne undgå enhver form for frames), men fordi jeg ikke kunne finde andre muligheder for at holde alt indhold på "forsiden" uden at skulle reloade hele siden eller loade indhold i nye vinduer.

Jeg er så ved at forske lidt i CSS2 til at placere indhold uden at reloade siden, men det er der faktisk færre browsere der understøtter end I-frames i øjeblikket.

getaway>> Undskyld hvis du synes jeg støjede i dit spørgsmål :-)

jeg vil ikke sige du kan det uden reload, men med SSI, mener jeg ens vej er rimeligt sikret, de dækker de behov, jeg har som iframe i sin tid skulle dækk, om en side reloader, er ike et problem for mig/brugerne, så længe man tænker på at bygge en side der ikke er alt for tung.

<ole>

ckh >> Du har fuldstændig ret. Med mindre man har levet sit liv i et skab, kan man nævne masser af tilfælde, hvor iframes er et must - og en løsning uden er umulig. Det vil også gælde, når CSS2 engang bliver bredt implementeret, men dog ikke i så mange tilfælde.

Jeg har set udtalelsen fra questis flere gange og han er tydeligvis ikke klar over, hvad man egentilg kan løse med iframes - eller også har han ikke udsat sig for så mange avancerede opgaver.
Det er lidt synd, han bliver ved med at fremture med sine fejlagtige påstande ... en fejl bliver ikke mere rigtig af at blive gentaget i det uendelige  ;o)

/mvh
</bole>

13/01-2003 01:06:18 krydsede og underbygger min teori om de få avancerede løninger - eller måske manglende fantasi(?)  :)
/mvh

olebole>> hvis du stopper din nedladende tone og kommer ned med snuden til os andre så vi kan snakke sammen, kunne det være vi får noget ud af dette.

hvis du læser mit indlæg 13/01-2003 01:06:18 begrunder jeg mit svar.

lolda

ja olebole>> nu har jeg så givet mig tid til at se mine gamle spm. igennem, med iframes.... og kan ikke lige se hvor du finder problemet, der åbentbart sætter dit pis så meget i kog, at du skal snakke direkte nedladende om mig.... jeg vil da give dig ret i at jeg ikke har været ved at lave de vildeste løsninger, i dhtml, så der kan jeg ikke være med i iframe snakke, men hvad angår folks brug af den, er det jo ikke alle der når de stadie....

mange bruger dem som en mainframe på deres side, eller til menuer og lignende, så der kun skal rettes et sted, og i disse tilfælde, kan SSI lige så godt opfylde kravene som en iframe....

for at vende tilbage til de steder hvor jeg åbentbart mange gange har sagt at iframe ikke skal bruges, kan jeg se 1 gang, hvor jeg virkeligt har rodet mig på dybt vand med dette..... men som man siger en fjer kan blive til mang høns.... og åbentbart også her.

mvh.
Questis

Det kom der ellers noget af en diskussion ud af?
Jeg har paa fornemmelsen at de fleste af Jer bruger iframes, men kan ikke lide det? Hvad med en table der bare udvider sig efter behov? Er det en ide der kan godtages? Eller er det bare yt?

ckh> Synes jeg ikk. Kunne faktisk godt lide det. Bare bliv ved!

getaway >> Iframes er ligesom alle andre HTML-elementer ... der er ting, de er uovertrufne til og der er ting, de ikke er gode til.
Hvis du ikke har specielle grunde til at bruge iframes, bør du nok vælge en anden løsning - som det gælder med de fleste elementer. Man skal tænke over, hvad der skal laves og så vælge det mest formålstjenlige element til opgaven.

Har du bare brug for at vise noget tekst og grafik på siden, kan en tabel være et udmærket bud  ;o)
/mvh

En table der udvider sig efter behov kan vel benyttes ligesom så mange andre løsninger. Det kommer jo altid an på hvor stramt éns design er spændt op :-)

Jeg hører til dem der kan lide at vide hvor hver eneste pixel befinder sig (så vidt det er muligt). Derfor har min eneste mulighed været at benytte I-frames hvor jeg kan loade indholdet i. DHTML har jeg også været inde over, men det var ikke hvad jeg havde behov for (og er det stadig ikke).

SSI, eller hos mig PHP-include, er en integreret del allerede, men det er en helt anden diskussion synes jeg.

olebole > Kan du give eksempler på problemstillinger hvor du mener at iframes vil være den ideelle løsning?

runeevers >> En chat er jo et eksempel, som er oppe masser af gange her på E. At se på en side, der opdaterer hvert 5-10. sekund, er til at få fnat af.
Samtidig nedsætter det performance ganske alvorligt ikke at bruge iframe, da men ved at anvende en sådan kan nøjes med at hente samtalens seneste linie, hvorimod du skal trække hele samtalen ud af databasen og skrive den, hvis du ikke bruger iframe.
I det hele taget, er performance-problematikken ganske væsentlig, når vi taler større sites og dynamisk genererede sider. Der kan nævnes masser af andre eksempler på, at man kan nøjes med at hente hele siden én gang og efterfølgende hente småbidder, når brugeren ønsker at hente yderligere info.

I CMS-systemer er de nærmest et must, da man her kan hente og gemme del-informationer uden at skulle gemme en hel side eller et kompleks af sider.
Samtidig kan man lave et dynamisk CMS med en (eller flere) skjult iframe, hvor alle opdaterings-funktioner kører i forms, der bliver dynamisk genereret og fyret af mod serveren. Det giver en voldsom forbedring af brugeroplevelsen, da man ikke skal vente på svar fra serveren, men blot arbejder videre i sit WYSIWYG-miljø i browseren.
Det betyder også, fru Jensen kan afprøve forskellige design-muligheder, uden at skulle opdatere backend'en og bagefter skal til at rode med besværlige undos.

Derudover kan nævnes f.eks. topbannere, der ofte er tunge og ligger hos mediebureauer, der distribuerer i tusindvis af bannereksponeringer i minuttet, hvilket tit bringer disse servere i knæ. Det øger loadtiden væsentligt på mange sider på nettet, hvor man i stedet kunne lægge banneret i en iframe, der loades på hovedsidens onload-event - og giver brugeren en betydelig bedre oplevelse.

Jeg kan huske, vi på Framfab havde problemer med en dynamisk scroller, da vi byggede HydroTexaco's Erhvervs-site. Nogle af de tidligere NS6-builds (som der stadig er mange af derude) havde voldsomme problemer med clip og overflow. Dette blev løst ved at redirecte NS6'ere til en 100% iframe.
Samme problem opstod i øvrigt på Nikefootball.com og Electrolux, hvor vi også rodede med DHTML, clip og overflow.

Det var nogle grunde og der er såmænd flere endnu, men jeg har også lige lidt til questis ... og det her er vist ved at blive lidt af en dansk stil  :)

questis >> Det, der pisser mig af, er når du kaster dig ud i skråsikre påstande som (13/01-2003 00:39:46):
" [...] da problemmet som en iframe skal løse, kan afklares på så mange måder at det halve kunne være nok, er der jo ingen grund til at nogen browsere enten ikke kan vise dem korrekt/slet ikke vise dem."

Det kunne for ikke indviede opfattes, somom du udtaler dig med professionel vægt, eller ved hvad du taler om - hvilket absolut ikke er tilfældet.
Går vi en tur ind på din egen side:
  http://www.questis.dk/
som du reklamerer for på dit E-minisite, kan man læse følgende:
"Questis.dk lever løsninger inden for internet og intranet. alle vores løsninger bliver holdt op mod W3C standarderne som sikrer stabile og browser kombatible løsninger som kan bruges af alle brugere."

Det lyder jo flot og brugere af E, der ikke ved bedre, kunne få det indtryk, du taler om noget, du har forstand på ... vi kan vel i det mindste blive enige om, du ikke sparer på krudtet, når det gælder selvsikkerhed og skråsikkerhed.

Gør man sig den ulejlighed at se siden i NS6, vil man tydelig se, dette er en vild overdrivelse. Kikker man derudover i koden, ser man, det ikke kun er NS6-brugere, du ikke understøtter. Det gælder såmænd også alle ikke Windows-brugere (uanset browservalg), da du bruger et proprietært Microsoft karaktersæt - i stedet for at bruge det internationalt standardiserede sæt for latinsk alfabet.
Der er i parentes bemærket ikke noget at sige til, 'I' (stor i slavet, hva'?) tilbyder at forære 'jeres' to første kunder en gratis løsning i håb om at kunne få et par referencer.

Hvad betyder forresten: "[...] alle vores løsninger bliver holdt op mod W3C standarderne [...]"? Formodentlig, at de bliver kørt en tur igennem validatoren. Det er ikke nok, da W3C’s validatorer ikke er uden fejl. De er små stykker hjælpeværktøj, men garanterer på ingen måde, din kode er valid, selvom den validerer.
Rekommenationerne er der, man sikrer, koden er valid. Opfylder den, hvad der står der (og glem ikke errata-dokumenterne), er koden OK ... ellers ikke.
Dette er ikke engang nok, da browsere også har fejl – og så må man 'bøje' standarden en anelse – men man skal selvfølgelig vide, hvad man gør og endelig passe på ikke at 'bøje' den forkerte vej.

Jeg har ikke spor imod at brugere på E foreslår nogle ting, de ikke er sikre på, hvis de altså ikke prøver at optræde som 'verdensmestre'. Der skal naturligvis også være plads til ikke professionelle ... det er en _overordentlig_ væsentlig del af E, som det ville være dybt ulykkeligt at miste.
Der, hvor kæden falder af, er når de forsøger at smykke sig med lånte fjer og optræder med påtaget autoritet.
Det er nemlig det materiale, man laver myter af - og myter er der rigelig af i denne branche. Hvor tit ser vi f.eks. ikke folk, der hårdnakket påstår, NS (generelt) ikke kan læse iframes, men skal forsynes med ilayers? NS6+ læser dem som bekendt fint, men kan netop ikke forstå ilayers.
Eller at NS4x ikke kan læse stylesheets. Bevares, den havde ikke CSS implementeret, men den kan nu godt læse en hel del styles, anyhow.

Er der noget, du ikke _ved_ positivt, så hav så meget respekt for andre brugere, der gerne vil lære noget, at du ikke kommer med skråsikre påstande om det og lærer dem noget forkert, men understreger at dine udtalelser bygger på formodninger ... så vil du også selv opnå respekt  ;o)
/mvh

olebole>> alt andet end lige er den valid i følge en validator, alt andet end lige.... at validatoren ikke holder sig op mod W3C's standarder, kan jeg ikke ligge og rode med..... de sider jeg sidder med pt. har ingen problemer haft i dvs. browsere.... skal dog ikke sige hvad de er galt med min nuværende i NS6, da jeg selv sidder med en 7'er pt.

men hvis du så ligger mine to svar sammen i dette spm. kan jeg ikke se hvad der pisser dig sådanne af. i deres helhed, beskriver jeg hvad jeg personligt mener, giver ikke konklusion på at sådanne er det, jeg beskriver sidenhend at mine behov for iframe's dog ikke er så høje, men vi sidder i et lidt åbent spm. som ikke siger hvad det skal bruges til.

endvidere, ved jeg da klart at jeg ikke er på niveau med dig i denne kategori overhovedet ( og kommer det sikkert ikke ) men kan pisse mig ligeså meget af med din entre i dette spm. da du i bund og grund ikke er en skid andet end os andre.... et ganske almindeligt menneske.... med en størrer viden end os andre, som jeg helt klart har respekt for.

mvh.
Questis

Puha... for en diskution. Den kan jo fortsætte i det uendelige, da det sådan set kun er folks egne meninger/holdninger/(ideologier) der gælder :)

Men så vidt jeg kan forstå det, så er iFrames ikke en del af W3C's XHTML 1.0 standard! Tager jeg fejl... eller?

Hvis jeg har ret... så vil jeg påstå, at hvis man ikke kan finde på andre gode grunde, så er det nok til at undlade at bruge iFrames.

martinhrj>> Så vidt jeg kan se er <iframe> tagget en del af xhtml (dog ikke strict, men kun transitional og frameset)

http://www.w3schools.com/xhtml/xhtml_reference.asp

Eller også læser jeg det bare forkert ? :-)

Der må jeg jo gi' mig! Jeg havde kun set efter strict.

Tak for rettelsen :)

lukker også den her... tak for informationerne :D