Jesper Tverskov, 17. oktober 2001
Frames har alle dage været kontroversielle. Fordelene ved frames er svære at få øje på. Tværtimod er traditionelt webdesign med tabeller hurtigere at lave, langt mere fleksibelt og tilpasningsdygtigt og i enhver henseende mere effektivt og funktionelt. I det følgende vil alle argumenterne for og imod frames blive analyseret og revurderet.
1. Indledning
1.1 Hvad er frames
1.2 Argumenterne for frames
1.3 Frames' historie
2. Problemerne med frames
2.1 Frames bygger på en misforståelse
2.2 Frames gør websites mindre tilgængelige
2.3 Frames er dårlig arealudnyttelse
2.4 Frammes stresser brugeren
2.5 Frames besværliggør navigation med tastaturet
2.6 Frames besværliggør udskrivning
2.7 Frames vanskeliggør linking
2.8 Frames giver problemer med søgemaskiner
2.9 Frames fører til løsrevne sider
2.10 Hvorfor stinker frames
3. Alternativer til frames
3.1 Brug tabeller og SSI
3.2 Brug "position: fixed" i CSS2
3.3 Brug iframe- og object-elementet
3.4 Når frames er nødvendige
4. Konklusion: frames bør kun undtagelsesvis anvendes
Internettets organisation for standarder, W3C, har stemplet frames som "deprecated", dvs. som "overflødige, forældede og på vej ud" af HTML/XHTML. Eksperter i brugervenlighed kalder frames afsporet webdesign (usability disaster). "Statens standard for elektroniske publikationer" forbyder anvendelsen af frames i ministerier, direktorater og styrelser.
Men måske er frames bedre end sit rygte, Eksperter har før taget fejl. Hvad er frames, hvad er fordelene ved frames, hvad er problemerne ved frames, er der alternativer til frames.
Frames er én af flere metoder til at opdele en webside i "vinduer", så ét område af en webside, f.eks. en menu, kan fastfryses i forhold til det øvrige indhold, der kan scrolles for sig. Denne i mange sammenhænge legitime hensigt opnås med frames ved et drastisk indgreb i en websides normale funktionsmåde. Med frames erstatter et rammesæt websidens traditionelle "body"-element. Rammesættet opdeler websiden i vinduer, der hver især indlæser indhold, der typisk er selvstændige filer.
Frames er i udgangspunktet problematiske, netop fordi de bryder med ideen bag World Wide Web, der går ud på, at websiden er grundelementet, og at alle websider skal kunne linke direkte til hinanden i et altomfattende spind. Med frames er grundideen at webbet består af websites, og at man ikke skal kunne linke direkte til ny information, men kun til andre websites, hvor man så kan søge videre for at finde information.
Normalt anvendes frames til at opdele en webside i f.eks. tre dele. F.eks. med logo og hovedmenu øverst. Resten af siden er opdelt i to eller flere vinduer, typisk med en undermenu i det ene vindue, der indlæser indhold i de andre. Det er det klassiske framede layout, der findes i mange varianter med to eller flere rammer fordelt udover en webside.
"Det er smart med en fast menu i den ene ramme, der indlæser indholdet i den anden ramme, der kan skrolles uafhængigt af menuen, sådan at menuen altid kan ses og er til rådighed med et enkelt klik med musen. Det giver overblik og lynhurtig betjening og er brugervenligt!"
"Det er jo netop sådan, alle traditionelle edb-programmer virker f.eks. GUI-brugerfladen i MAC og i Windows. Der er vel en god grund til, at programmer virker på denne måde! Når fastfrosne menuer er en fordel i kontorprogrammer, som vi bruger hver dag, så må de da også være det på et website!"
"Frames kan give en marginal hastighedsforøgelse, fordi den del af websidens rammesæt, der ligger fast, f.eks. logo og menu, kun skal indlæses én gang."
"Frames er tilmed en fordel ved udskrivning af websider, fordi du med frames kan nøjes med at udskrive indholdsdelen uden menusystem. Frames kan tilmed sikre, at indholdsdelen udskrives med en bredde, der svarer til A4-sidens dimensioner, hvorimod en udskrivning af hele websiden ofte vil overskride A4-sidens højremargen."
"Frames er gode, fordi de er lette at lave. Det kræver f.eks. ikke en webserver at lave dem. Selv om det er rigtigt, at der med andre metoder kan opnås nogle af de samme fordele som med frames uden mange af ulemperne, så er disse metoder, f.eks. tabeller og Javascript, teknisk og uddannelsesmæssigt mere krævende at implementere, hvorimod frames er folkeeje.
Frames blev et instant hit, da Netscape 2.0 i 1995 lancerede dem som et led i "browserkrigen". Frames er smarte og intuitive: "Sådan skal en hjemmeside bare virke!" Vi kendte dem i forvejen fra edb-programmers grafiske brugerflade, hvor det er en selvfølge, at menulinje og knappaneler ligger fast, mens vi scroller indholdssidens dokumentvindue.
"Frames" var en browserproducents geniale skaktræk, et veritabelt snigløb på den eksisterende Html-specifikation bag om ryggen på W3C. Frames var et forsøg på at gøre sig populær og uundværlig hos brugerne og sikre sin dominans på browsermarkedet. Frames blev da også opfattet som så rigtige, at Microsoft straks valgte at understøtte dem i Internet Explorer 3.0 i 1996.
Mange førende websites gik over til frames, der var den helt store dille i de følgende par år. Der viste sig dog hurtigt problemer med hele konceptet omkring frames. De gjorde det meget vanskeligere at lave sider, der var brugbare i alle browsere ved diverse skærmopløsninger og vinduesstørrelser. Der var problemer med at linke til sider med frames, søgemaskiner havde problemer med at indeksere dem, der var problemer med navigation ved brudte frames, og brugerne havde problemer med at udskrive indhold fra websider med frames.
Allerede før årtusindskiftet var brugen af frames toppet og kraftigt på retur i professionel sammenhæng. Mange store virksomheder er vendt tilbage til traditionelt webdesign, fordi problemerne med at lave websites med frames er for store, eller fordi frames kom til kort hos brugerne i testlaboratoriet.
Frames dominerer stadig blandt websites af typen "mit første website". Det slår næsten aldrig fejl. En nybegynder starter med at lave et par websider på traditionel vis. Når de er på plads, og det vil ofte allerede sige senere samme aften, skrottes de første eksperimenter, og nybegynderen kaster sig over løsninger med frames. Jo mere professionelle hjemmesider bliver og jo mere seriøse deres indhold, jo sjældnere tages frames i dag i anvendelse; men frames er stadig almindelige om end stærkt på retur også i professionel sammenhæng.
Frames nåede at blive så populære, at W3C tog dem med i HTML 4.0 i 1997 dog som "deprecated" (forældede) i en DTD for sig. På internettet kan du finde mange dokumenter, der beskriver problemerne med frames (se henvisninger til slut i denne artikel), men i billigbogshæfterne om webdesign betragtes de som en selvfølge, og i den egentlige faglitteratur er de ofte lemfældigt behandlet bortset fra i litteratur om brugervenlighed, hvor der som regel advares mod frames.
Det er en myte, at det er funktionelt med en menu til alt og alle som fast inventar på hvert eneste skærmbillede. Når vi læser en bog, kan vi sagtens klare os med, at indholdsfortegnelsen kun findes forrest eller bagerst i bogen. Hvis visse webdesignere skulle producere bøger, ville der være en menu til resten af bogen som den ene halvdel af hvert eneste opslag!
I en avis klarer vi os også glimrende helt uden menuer og indholdsfortegnelser. De få, der er, bruger de fleste aldrig. Det tager ingen tid at bladre rundt, frem og tilbage, for at finde, hvad vi leder efter. På nettet har vi selvfølgelig brug for navigation på alle sider, men ikke nødvendigvis som fast inventar på hvert eneste skærmbillede.
I stedet for en kortfattet næsten intetsigende fast menu til alt og alle på hvert eneste skærmbillede, er det i udgangspunktet mere funktionelt med kontekstafhængig navigation til det væsentligste ud fra sammenhængen og til en generel men detaljeret indholdsfortegnelse på en webside for sig. Hellere en grundigere menu uden for skærmbilledet men stadig blot et museklik væk, end en forkrampet menu til det hele, der altid fylder en stor del af skærmen.
Det er vanskeligt at lave funktionelle og pæne websites, der fungerer i flere browserfabrikater ved flere skærmopløsninger og ved flere vinduesstørrelser. Ægte webdesign er en udfordring, der bl.a. omfatter noget så simpelt som at tage Cascading Style Sheets alvorligt. F.eks. skal en bruger kunne sætte punktstørrelsen op i browseren for bedre læsevenlighed, når der er behov for det.
Glem alt om at lave ægte webdesign, hvis du anvender frames. Det er i praksis meget vanskeligt at lave websites med frames, der er pæne og fuldt funktionelle i andet end den browser og opløsning, der blev anvendt ved fremstillingen. Det er et pillearbejde uden lige at gøre framede sider generelt anvendelige i en vifte af browserfabrikater, skærmopløsninger og vinduesstørrelser.
I dag bruger ca. halvdelen af surferne på nettet en skærmopløsning på 1024x768 eller højere. Den anden halvdel bruger 800x600 eller lavere. En af fordelene ved store skærme med høje opløsninger er at websitet ikke behøver at fylde hele browservinduet, og at browservinduet ikke behøver at være maksimeret, så du kan have flere vinduer med forskellige programmer ved siden af hinanden på skærmen.
Derfor bør et godt websites som en selvfølge også være anvendeligt ved en opløsning på 640x480. Selv om kun et par procent af surferne anvender opløsninger lavere end 800x600, så er det ofte denne størrelse browservinduet vil have i et ikke-maksimeret browservinduet. Det er i sidste ende ikke opløsningen, det handler om, men bredden på den del af browservinduet, der har websiden indlæst.
Framede websider er så godt som altid uanvendelige ved lave opløsninger og har som regel meget store skønhedspletter og begrænset funktionalitet blot du fjerner dig en anelse fra den browser og den opløsning websiderne blev designet med. Det er ikke usædvanligt at framede websider reducerer målgruppen med 10-20 pct., blot fordi der er anvendt frames. Framede websider er altid mindre fleksible og tilpasningsdygtige en tilsvarende websider uden frames.
Hovedargumentet for frames er, at det giver tryghed og overblik, at navigationsmenuen altid er synlig og til rådighed med ét museklik samtidigt med at brugeren kan scrolle indholdssiden.
Sådan virker edb-programmer med en grafisk brugerflade, som vi kender fra MAC og Windows. Her er fastfrosne menulinjer og værktøjspaneler standard. Tilsvarende har alle regnearksprogrammer en feature, der kan fastfryse kolonne- eller rækketitler i et stort regneark, da det ellers i praksis kan være umuligt at tyde indholdet i mange af regnearkets celler.
I det omfang traditionelle edb-programmer bliver web-baserede, og det vil de efterhånden blive i stort omgang, så er her i hvert faldt et område, hvor vi vil se faste menuer og værktøjslinjer samtidigt med at indtastningsfeltet eller "kanvassen", der bearbejdes, scrolles uafhængigt af resten af siden. Men det behøver ikke at have noget med frames at gøre. Tænk blot på en formulars indtastningsfelt af type TEXTAREA. Tekstfeltet scroller uafhængigt af resten af siden, men der er ingen frames.
Den traditionelle grafiske brugergrænseflade har altså kun med frames at gøre i den forstand, at det der søges opnået med frames, f.eks. at fastfryse en menu, er en legitim interesse, der kan være relevant også på websites. Som altid er det et spørgsmål om afvejning af fordele og ulemper. Det er bl.a. vigtigt at se på skærmarealets udnyttelse.
Der er enighed om, at computerskærmens beskedne areal, er en af de største begrænsninger for overblikket ved elektronisk layout sammenlignet med f.eks. en avis- eller bogside. Når det tages i betragtning, at browserens menulinjer og knapper i forvejen optager en stor del af det beskedne areal, skal der være meget gode argumenter for yderligere at fastfryse dele af en webside som fast inventar på hvert eneste skærmbillede.
Lad os starte med logoet. Måske det er lovligt prangende og en uøkonomisk anvendelse af pladsen, at det skal være fast inventar på hver eneste webside? Det er ofte mere funktionelt og mindre anmassende, at logoet kun udfolder sig i alt sin vælde på hjemmesiden, den såkaldte forside, og at logoet på øvrige sider, blot er tekst eller reduceret i størrelse.
Det samme gælder navigationssystemet, der med anvendelse af frames let kan fylde en tredjedel eller mere af et skærmbillede eller af et helt website! Fordi pladsen oplagt er trang, vil der være en tendens til, at navigationssystemets menupunkter på websites med frames bliver meget kortfattede grænsende til det intetsigende.
Traditionelt design vil ofte udnytte pladsen bedre og mere fleksibelt. Selv hvis du laver en navigationsmenu både øverst og nederst på en webside, kan de enkelte menupunkter beskrives mere præcist for at reducere fejlnavigation end på mere sammenpressede sider med frames. Disse menuer er også så godt som altid umiddelbart til rådighed for brugeren, der enten befinder sig tæt ved menuen foroven eller forneden, eller som hurtigt kan bringe sig til menuen foroven eller forneden ved et enkelt tryk på tastaturets HOME- eller END-tast.
Når du bladrer en avis igennem, så falder blikket lidt her og der, og du læser lidt her og der. Den enkelte sides helhedsindtryk og detaljer på siden lejrer sig i hukommelsen. Du kan hurtigt finde tilbage og "genkende" dig vej frem. Hvordan ville du have det med en avis, hvor spalterne kunne scrolles uafhængigt af hinanden? Hver eneste side ville eksistere i et utal af kombinationer af spalterne scrollet i forhold til hinanden. Det ville gøre det mere trættende at læse avisen, og det vil være langt vanskeligere at huske placeringen af indhold.
Det samme gør sig gældende med framede websider, der alt andet lige betyder mere stress. Frames stresser ikke blot brugeren visuelt, men, som vi senere skal se, også hvad angår betjening af websitet med tastaturet, og hvad angår udskrivning.
Selv om musen er genial til at betjene edb-programmer og websites, så foretrækker superbrugere i stort omfang at supplere musen med tastaturbetjente genveje. For den erfarne bruger er genvejstaster ofte en langt hurtige og mere effektiv betjeningsmåde end mus.
Hjemmesider er notoriske for at være svære at navigere og betjene uden mus, i hvert fald langt vanskeligere end edb-programmer. Mange hjemmesider er i praksis uanvendelige uden mus, og det gælder først og fremmest websites med frames.
Problemet med frames er, at en webside teknisk består af flere sider, hvor kun én af siderne kan være aktiv ad gangen. En bruger har ofte ikke mulighed for umiddelbart at vurdere, om der er anvendt frames, eller hvilken ramme der er aktiv. Det er let med musen at gøre en anden ramme aktiv ved at klikke i den, men det kan være usikkert hvor, der skal klikkes, fordi det kan være svært at afgøre hvor mange rammer websiden består af, og hvor de begynder og slutter. Med tastaturet kan sider med frames være så godt som umulige at navigere.
Fra websider uden anvendelse af frames er superbrugere vant til at tastaturets HOME- og END-tast straks fører dig til dokumentets top eller bund. Tilsvarende er PageUP- og PageDown-tasterne gode til i spring at bevæge sig et skærmbillede op eller ned, og piletasterne PilOp og PilNed er gode til at scrolle, så du ikke altid skal være afhængig af browservinduets scrollepanel eller af musens scrollehjul.
Når sider er lavet med frames, f.eks. med ét vindue til navigation og ét vindue til indhold, så er det navigationsvinduet, der tilstadighed gøres aktivt, hver gang vi vælger et menupunkt, men det er indholdsvinduet, vi ønsker skal være aktivt, fordi det er her, vi skal bevæge os op og ned for at "scanne" eller læse teksten, osv.
På sider med frames bliver den mere avancerede edb-bruger, der ofte er den mest eftertragtede del af et websites målgruppe, ofte frustreret, fordi tastaturet ikke virker, som vi forventer. Dels kan det tage tid at opdage, at der er anvendt frames, dels kan det være vanskeligt at vurdere, hvor de enkelte vinduer befinder sig, dels er det stressende at være nødt til at tænke på noget så enkelt som at navigere: "Don't let me think!"
Printerproblemet er meget alvorligt ved anvendelse af frames. Brugeren kan i printerdialogboksen vælge mellem at udskrive den aktive ramme, alle rammer for sig, eller hele websiden. Da udskrivning af alle rammer for sig, normalt er meningsløst, og da udskrivning af hele siden normalt giver et utilfredsstillende resultat, fordi websider lavet med frames typisk er for brede til at kunne være på en A4-side, er det normalt altid den aktive ramme, der skal udskrives.
Mange brugere aner ikke, hvad frames er for noget, og andre brugere bliver først opmærksomme på, at der er anvendt frames, når de ser printerdialogboksen. De fleste udskriver erfaringsmæssigt i blinde. Superbrugeren har allerede sørget for, at det, der skal udskrives, er gjort aktivt, eller lukker straks dialogboksen og tjekker efter.
I mange virksomheder udskrives der i et andet rum, end der udskrives fra. Millioner af medarbejdere i tusinder af virksomheder over hele verden oplever hver dag stor frustration, når de kommer ud til printeren. Mange af siderne, der er udskrevet fra websites med frames, er affald.
Sæt forsøgspersoner til at udskrive information fra identiske websites lavet med og uden frames. Det er ikke usædvanligt, at ingen testpersoner er i stand til at udskrive information fra et website med frames i første forsøg, hvorimod alle personer klarer det i første forsøg på websites, hvor der ikke er anvendt frames.
Med ægte webdesign, som framede websider næsten aldrig kan leve op til, tilpasser siderne sig ikke bare skærmen men også printeren. Med Cascading Style Sheets er det let at fintune udskrivningen, der evt. kan anvende eget stylesheet. F.eks. er det ofte irrelevant at udskrive menuer, logoer og grafik. Websites med frames er derimod ofte nød til at lave specielle printervenlige udgaver af websiderne, som kan vælges og udskrives for sig. Printervenlige sider kan være relevante, men ordinære websider bør som hovedregel kunne udskrives tilfredsstillende direkte.
I sin enkleste form består et website med frames af blot ét rammesæt, hvor menuen på hovedsiden med rammesættet indlæser det øvrige indhold side for side. Det er rammesættets URL, der vises i browserens adresselinje, og det er kun rammesættet, der har et "title"-element. Derfor kræver det en ekstra anstrengelse, som de fleste brugere ikke vil kunne finde ud af, at linke til andre sider end til selve rammesættet og dets indlæste default-side.
Det går an at lave "favoritter" (Internet Explorer) og "bogmærker" (Netscape og Opera), men med besvær. Du vil bemærke, at hvis du forsøger at linke til flere websider på det samme website, så fortæller browseren dig, at der allerede eksisterer et bogmærke med det navn. Det er netop fordi, det kun er rammesættet, der har et "title"-element. Du skal derfor selv finde på et bogmærkenavn til de øvrige sider. Hvis du ikke selv finder på nye bogmærkenavne, overskriver siderne hinanden.
Vil du linke til en bestemt webside direkte, må du prøve at finde dens URL andre steder end i adresselinjen, hvor kun rammesættets URL vises. Når du i IE peger på linket, der henter siden, vil URL'en fremgå af bundlinjen, hvor du kan skrive den af med blyant(!). Du kan alternativt lave et bogmærke, og så gå ind i bogmærket og finde sidens URL. Eller det kan være, at websites for at gøre sig helt til grin, på selve websiden oplyser dens URL! Osv., osv. Alt dette linkningsbesvær skyldes som sagt kun, at der anvendes frames.
Ovennævnte problemer eksister selvfølgelig ikke på et website uden frames. Her har hver eneste webside sit eget "title"-element, og den enkelte sides URL vises i browserens adresselinje.
Et website med frames kan faktisk godt laves sådan, at hver side har et "title"-element og en URL, der vises i adresselinjen; men det ses meget sjældent. Det kræver, at der laves en side med et rammesæt til hver eneste indholdsside.
Derimod kan du selv med et rammesæt til hver eneste indholdsside ikke lave avancerede links fra én webside til et bogmærke inde på en anden side. Uden frames er det uproblematisk at linke til en bestemt overskrift, underoverskrift, afsnit eller til et hvilken som helst HTML/XHTML-element. Det er blot at indsætte et ID i elementet eller at bruge et gammeldags NAME-anker.
Det er derfor udelukket at anvende frames til websites med f.eks. rapporter, beretninger, lovgivning, cirkulærer, videnskabelige artikler eller mere seriøse debatindlæg, hvis der skal kunne linkes præcist i form af krydsreferencer, osv. OBS: jeg har kun testet ovenstående én gang, og jeg kan have gjort en fejl. Prøv selv at teste om det kan lade sig gøre udefra at linke til et bogmærke på en webside indlæst i et framesæt.
Mange indekseringsmaskiner forstår ikke frames. Det problem kan dog løses ved at anvende det såkaldte NOFRAME-element, der blot skal indeholde en traditionel menu til indholdet. Tidligere da mange browsere ikke understøttede frames, blev NOFRAME-elementet tilsvarende anvendt til alternativt indhold til browsere, der ikke understøttede frames. Det gør i praksis alle browsere i dag, men ikke alle indekseringsmaskiner.
Når NOFRAME-elementet anvendes, gøres det normalt forkert. I de fleste tilfælde indeholder det blot en venlig tekst om, at din browser ikke understøttet frames, og at du bør downloade en mere moderne browser. Det er bedre med en alternativ menu, fordi den både kan bruges af mennesker og af indekseringsmaskiner, der ikke forstår frames.
NOFRAME-elementet er normalt placeret forkert på websiden, således at alle søgemaskiner, også dem der forstår frames, opfatter teksten som en beskrivelse at websitets indhold. Hver gang du laver en søgning på nettet, kan du blandt resultaterne finde hits, hvor den medfølgende beskrivelse af websitet fortæller noget i retning af: "Din browser understøtter desværre ikke frames, vi opfordrer dig venligst til at downloade en bedre browser." Bruger du frames, er du nødt til at kode på en sådan måde, at søgemaskinerne i stedet finder en beskrivelse af websidens indhold!
Der er yderligere et problem med indekseringsmaskiner nemlig løsrevne sider. Indekseringsmaskinerne har en tendens til at indeksere siden med rammesættet, siden med menuen, der indgår i rammesættet og de enkelte indholdssider hver for sig. Når du søger på nettet finder du derfor ofte løsrevne sider, der vises på skærmen uden siden med rammesæt og uden navigationsmenu. Indholdssiden vises uden sin sammenhæng, og fordi menusystemet mangler, kan du kun med besvær navigere videre til resten af websitet. Du er nødt til at fittelihutle med URL'en.
Dette problem kan dog løses ved på siderne at inkludere et JavaScript, der sikrer at rammesæt og menu altid indlæses. Det sker dog sjældent.
I betragtning af, at nogle af problemerne med frames kan løses, f.eks. problemerne med linkning, søgemaskiner og løsrevne sider, så sker det meget sjældent. Det er først og fremmest derfor, at frames har fået ry for at stinke. Dem der laver websites med frames er enten helt uvidende, hvad angår problemerne med frames, eller de er ligeglade med alt og alle! Derfor signalerer et website med frames altid dårligt håndværk og lav forrentningsmoral indtil det modsatte er bevist.
Websites med frames er kun mulige, hvis der ikke har foreligget selv den mest elementære kravspecifikation i retning af uafhængighed af bestemte platforme, browsere, skærmopløsning og vinduesstørrelse. Man kan se det for sig, da webureauet præsenterede det færdige resultat for kunden: En flot præsentation i den browser og med den opløsning websitet blev lavet i! Dødsmart og meget brugervenligt!
Hovedproblemet med frames er som sagt, at de bygger på en vildfarelse. Det kan være en god idé at inkludere f.eks. en menu, der ligger i en anden fil, på alle sider; men det er normalt ikke en god idé at denne menu er fastfrosset, således at resten af siden kan scrolles uafhængigt af menuen.
Når først du har erkendt dette, er det normalt ikke noget problem at droppe frames, fordi tabeller i langt de fleste tilfælde gør et bedre job, selv om menuen nu ligger fast f.eks. øverst på siden.
Det er kun som undtagelse fra reglen, at der er brug for fastfrosne menuer, fastfrosne række- eller kolonneoverskrifter, eller for vinduer, der kan scrolles uafhængigt af siden. Denne type funktionalitet gør altid en webside mere kompleks, mindre fleksibel og tilpasningsdygtig og mere tidskrævende at lave. Derfor skal du altid tænke dig godt om: Er den ønskede funktionalitet tilstrækkelig ønskværdig til at ulemperne kan retfærdiggøres.
En af hovedårsagerne til at frames har fået en relativ stor udbredelse blandt nybegyndere er, at frames er en let teknik til at inkludere sider på andre sider. Inkludering af sider er en forudsætning for effektivt og administrerbart webdesign.
Den klassiske metode i professionelt webdesign til at inkludere det samme indhold, f.eks. en menu, på mange websider, hedder Server Side Include. SSI har ikke ét eneste, af de problemer, der er så karakteristisk for frames, bl.a. fordi det inkluderede indhold af browseren opfattes som en del af websiden.
SSI kan ikke uden videre bruges til indhold, der skal scrolles uafhængigt af resten af en webside. Men som vi har set, er det meget sjældent, at der er behov for denne type funktionalitet. I dag hvor indholdet af websider efterhånden altid genereres fra en relationel database eller fra et XML datalager, er SSI ikke længere nødvendigt.
Det blev nævnt i pkt. 1.2, "Argumenterne for frames", at frames kan give en marginal hastighedsforøgelse, fordi den del af websidens rammesæt, der ligger fast, f.eks. logo og menu, kun skal indlæses én gang. Det er nok rigtigere at formulere det sådan, at en webside med rammesæt, tager længere tid at indlæse end en webside uden rammesæt, men at der er en marginal hastighedsfordel ved websiden med rammesættet, når den først er indlæst. Hvis logoet er et stort grafikbillede, og hvis menusystemet er grafik, er der en reel hastighedsforøgelse med frames, der så skal vejes op mod ulemperne. Hvis logoet er simpel grafik og menusystemet tekstbaseret er hastighedsfordelen marginal eller ikke eksisterende. Selv den klassiske metode med Server Side Include skal godt nok indlæses på siden hver gang men kun én gang i hukommelsen.
Set med begynderøjne er der to problemer ved SSI. For det første kræver det, at du har din egen webserver, når du laver websiderne, og det krævet at webhotellet, websitet skal ligge på, giver adgang til, at websiden fortolkes, før den sendes til browseren. Det er som hovedregel aldrig tilladt på de gratis eller billigste webhoteller.
Det er en pædagogisk udfordring at sikre, at der ved uddannelse i webdesign altid som minimum er en såkaldt personlig webserver til rådighed, og at websiderne oploades til et webhotel, hvor der kan anvendes SSI og server-side scripting. Som sagt er SSI efterhånden blevet overflødiggjort af teknikker, der genererer websiderne fra relationelle databaser eller XML datalager.
Hvad angår SSI er det påkrævet at advare mod MS Frontpage, der har opfundet en metode til at inkludere indhold på en webside, der intet har med rigtig SSI at gøre. I Frontpage behøver du ikke at bruge en webserver eller et webhotel med adgang til SSI for at inkludere indhold. Til gengæld kan websiderne kun vedligeholdes i Frontpage, og websiderne opdateres ikke automatisk, når det inkluderede indhold opdateres. I modsætning til rigtig SSI skal websiden i Frontpage åbnes og gemmes på ny, hver gang inkluderet indhold forandres.
Den rigtige metode til at fastfryse indhold, f.eks. en menu, vil i fremtiden formentligt være med Cascading Style Sheets. I Cascading Style Sheets (CSS2) kan du med "position: fixed" fastfryse indhold i forhold til browservinduet. Dette indhold ligger derfor fast, når siden scrolles. Bortset fra browseren Opera, der længe har understøttet "position: fixed", har de andre browsere været langsomme til at følge trop, og metoden kan derfor stadig ikke anvendes.
Skal du bruge et vindue, der scroller uafhængigt af resten af siden, kan det opnås med det såkaldte IFRAME-element, der understøttes af 99 pct. af browserne. Iframe-elementet har ikke de samme problemer som frames, fordi der ikke er noget rammesæt. Indholdet inkluderes, som om det var en del af siden.
Det er mere korrekt at bruge object-elementet til at opnå fuldstændigt det samme som iframe-elementet, fordi object-element er den mere generelle metode til at inkludere indhold. Object-elementet understøttes dog i øjeblikket af en mindre procentdel af browsere end IFRAME, der derfor bør anvendes i en overgangsperiode.
Iframe/object kan bruges, hvis du gerne vil sammenligne specifikationer for f.eks. to bilmodeller i hver sit vindue ved siden af hinanden eller til at fastfryse kolonneoverskrifter i f.eks. et stort regnearkslignende skema.
Skal rækkeoverskrifter undtagelsesvis fastfryses i et stort regnearkslignende skema, kan det være nødvendigt at anvende frames. "Position: fixed" i CSS2 kan endnu ikke anvendes, da metoden ikke understøttes af en tilstrækkelig stor procentdel af browserne. Iframe- eller object-elementet kan i øjeblikket heller ikke erstatte frames, hvad angår fastfrosne rækkeoverskrifter, da iframe- og object-elementerne ikke understøtter scrollning på tværs.
På Københavns Lufthavns hjemmeside er der et godt eksempel på en fornuftig anvendelse af frames: som en sjælden undtagelse, når der er en oplagt fordel. På websiderne "ankomster" og "afgange" er det svært at tyde informationerne, hvis overskrifterne ikke fastfryses. Det er gjort med frames. Der er altså ikke tale om at fastfyse en menu, der indlæser indhold, men udelukkende om at fastfryse overskrifter. Der er kun ét rammesæt, men der er jo også kun én indholdsside at indlæse, henholdsvis "ankomster" og "afgange".
Københavns Lufthavn, ankomster
[OBS: Dette link er ikke længere relevant, fordi websitet har droppet frames]
Enhver analyse, der skal afklare om en kontroversiel teknologi skal tages i brug, har form af en sammenligning af alternative teknologiers fordele og ulemper. Det er ikke nok at en teknologi har fordele og kan bruges til noget. Fordelene skulle meget gerne opveje ulemperne. Det er heller ikke nok, at en teknologis fordele opvejer ulemperne, hvis en alternativ teknologi løser samme problem bedre med færre minussider.
Analysen har vist, at frames er mindre fleksible, tilpasningsdygtige, tilgængelige og funktionelle end traditionelt webdesign. Ulemperne med frames er så store, at frames som hovedregel aldrig bør anvendes. Undtagelsen er de sjældne situationer, hvor enten række- eller kolonneoverskrifter i et stort regnearkslignende skema skal fastfryses, for at cellernes indhold giver mening.
Selv når der er behov for at fastfryse menuer eller kolonneoverskrifter, eller for at anvende vinduer, der kan scrolle uafhængigt af den øvrige webside, er alternativerne til frames, bl.a. IFRAME, normalt langt at foretrække.
Henvisninger:
www.google.com/search?q=frames+problems
Copyright © 2001 Klapmusen.dk
The document is made to be a resource. Use it. Link to it. The document will be maintained, the URL is stable.
Opdateret: 31-10-2002 08:56
Status:
Revision:
Debatten er lukket. Send mig en mail.