Hvorfor kompatibilitet
Man skal holde tungen lige i munden, når man udformer websider. Der er mange valg at foretage, mange forskellige standarder og browsere, og ikke mindst kundeønsker, om det nu er de interne eller eksterne af slagsen.
Med de mange muligheder, kan tingene undertiden blive lidt spegede. Hvis man for eksempel benytter de indbyggede JavaScript-muligheder i Macromedias Dreamweaver, kan man komme ud for, at effekterne ikke virker i Netscape 6 eller Opera.
Nogle udviklere har den holdning, at blot websiden fungerer i Internet Explorer 4 eller senere, så er den hellige grav vel forvaret. Det er dog et meget enøjet perspektiv. Der er flere problemer ved denne strategi:
Tabte kunder
Denne holdning argumenteres ofte udfra henvisning til analyse af logfiler, der kan vise, at brugere af Internet Explorer dækker langt størstedelen af brugerne. Men det er jo heller ikke så mystisk, hvis brugere af andre browsere og platforme oplever webstedet i en amputeret form. En af de vigtigste ting, designere og udviklere skal huske er, at brugere, der oplever, at webstedet ikke virker, ikke vender tilbage, hvilket i sidste ende kan betyde en tabt kunde.
Nye medier
Det næste problem er, at der er en fare for at miste fleksibilitet. Ved at udvikle systemer, der er skræddersyet til proprietær teknologi, vil det blive sværere at omstille applikationerne, når standarderne ændrer sig. Med nye medier som web-tv og håndholdte enheder, er det vigtigt at udvikleren er beredt på fleksibilitet og ikke lader sig forføre af proprietære teknologier.
En af årsagerne til forkærligheden for Internet Explorer blandt nogle udviklere og designere er, at det er teknologisk set den mest avancerede browser, der findes, og det er der selvfølgelig ingen grund til at rynke på næsen over. Der er også mange ting - specielt implementeringen af XML, XSLT og CSS, der giver mulighed for at bygge avancerede klientgrænseflader. Men det er som sagt vigtigt at holde sig for øje, hvornår man benytter proprietær teknologi, og hvornår man følger standarderne.
Til sidst skal man huske på, at alle undersøgelser viser, at stort set alle brugere er indifferente i forhold til et websteds grad af "lækkerhed." I alle brugerundersøgelser kommer funktionalitet, navigerbarhed og opdateringsfrekvens ind på førstepladserne over, hvad brugerne vurderer som væsentligt, mens design og layout er placeret et godt stykke længere nede på hitlisten.
Løsninger
Løsningerne
Hvis man ikke kan klare sig uden dynamisk HTML, ActiveX og plug-ins til diverse esoteriske formater, er der ingen vej uden om: Man må bygge to versioner af webstedet. En version i HTML3.2 og en version for de avancerede brugere.
Uanset om man bygger dynamiske websteder eller statiske sider, behøver det ikke at betyde et stort stykke ekstra arbejde, men det kræver, at man strukturerer sit arbejde.
Kompatibilitet på det dynamisk websted
Lad os først se på dynamiske websteder. Her tilbyder de fleste scripting-miljøer en mulighed for at fortælle udvikleren, hvilke egenskaber browseren har.
En browser (eller anden type af HTTP-brugeragent) fortæller gerne serveren, hvem den er. Det kan webserveren benytte til at finde ud af, hvilke egenskaber og funktioner, browseren understøtter. Prøv for eksempel at klikke på linket her og se, hvad der kan siges om din browser.
I Microsofts' ASP-miljø kan man benytte objektet MSWC.BrowserType
Set BrowserType = Server.CreateObject("MSWC.BrowserType")
if (BrowserType.frames = TRUE)
' Frames-kompatible browsere får denne kode
else
' Browsere, der ikke kan vise frames får denne kode.
Der er mere information om MSWC.BrowserType-objektet i Microsofts dokumentation.
PHP, et andet populært scripting-sprog, har objektet get_browser(), der opfylder samme formål. Dokumentationen kan findes her.
Statiske sider
Som tidligere nævnt er det vigtigt at strukturere sit indhold. Selv på de mest intensive DHTML-websteder, er langt størstedelen af indholdet HTML3.2. Hvis for eksempel navigationen er opbygget som en dynamisk drop-down-menu, skal der ikke meget ekstra kode til at bygge en navigation med almindelige links. Her kan man også overveje størrelsen af publikum på de forskellige browsere. Man kan så nedsætte design indsatsen i versionerne for ældre browsere. De fleste brugere er også primært interesseret i funktionalitet, og ikke design.
Statiske websider
I statiske websider kan man benytte JavaScript-omstilling. JavaScript-objekterne appCodeName, appVersion, AppName og userAgent indeholder information om browseren, og så kan udvikleren for eksempel omstille (redirecte) brugere til relevante sider. Web-værktøjer som Macromedia Dreamweaver og Adobe GoLive har disse muligheder indbygget. Hvis man hellere vil kode det i hånden, har Builder.com et lille værktøj, der demonstrerer objekterne.
En ting er at detektere browseren, en anden er at udvikle forskellige versioner. Her kan for eksempel Dreamweavers Library-funktion gøre det nemt at udvikle sider, hvor enkelte dele varieres. Vi har i en tidligere artikel gennemgået denne funktion, der også findes i de fleste andre professionelle web-værktøjer.
