Fortellinger.netArtikler

Fortellinger.net


Vevutvikling med åpne standarder

Av Wilhelm Joys Andersen, teksten er distribuert under GNU FDL. 12.10.2004. (Denne artikkelen var opprinnelig manuskriptet til et foredrag jeg holdt for BLUG i mai 2004.)

«Konseptet bak verdensveven er prinsippet om universell tilgjengelighet. Hvis du publisererer et dokument på veven, er det viktig at alle kan lese det», sa WWWs oppfinner i 1991. Etter år med nettleserkrig og strevsomme kompatibilitetsproblemer er verdensveven endelig på vei mot å oppfylle dette idealet. Wilhelm Joys Andersen forteller i denne artikkelen om hva åpne vevstandarder er for noe, hvorfor de er viktige, og hvordan du bruker dem.

Begynnelsen

CERN, 1989

Historien vår begynner i 1989 ved forskningssenteret CERN (Det europeiske labratorium for partikkelfysikk) i Sveits. Ved CERN hadde man på slutten av 80-tallet et herlig kaos av forskjellige datasystemer. Forskere fra all verdens land som kom for å leke med senterets partikkelaksleratorer drasset med seg sitt eget datautstyr hjemmefra, og kompatibilitet mellom alle disse eksotiske systemene var unntaket snarere enn regelen. Dette førte til at å få tilgang til noe så essensielt som hverandres forskningsrapporter og testresultater var temmelig vanskelig. At mange reiste tilbake til hjemlandet uten å kopiere dokumentene sine til et fornuftig sted først gjorde heller ikke saken særlig bedre, og mye viktig informasjon gikk tapt.

Den britiske forskeren Tim Berners-Lee fant på noe lurt. Løsningen på CERNs informasjonsutvekslingsproblem, mente han, var å organisere all viktig informasjon i et desentralisert nettverk av hypertekst-dokumenter, med referanser og kryssreferanser - lenker - seg i mellom.

Visjonen om et spindelvev av hypertekst-dokumenter var ikke noen ny idé. Allerede i 1945 snakket Vannevar Bush om en foto-elektronisk maskin som skulle muliggjøre kryssreferanser mellom mikrofilm-dokumenter (Memex), i 1965 beskrev Ted Nelson et futuristisk hypertekstprosjekt (Xanadu), og Doug Engelbart arbeidet i 1968 med sitt oN Line System. Men disse smarte karene var alle langt forut for sin tid. Først da Tim stod ovenfor nevnte problemstilling ved CERN i 1989, lå de materielle forholdene til rette for å faktisk virkeliggjøre denne gamle idéen.

Og virkeliggjort ble den. Ikke bare kom Tim opp med en god idé - han skapte også den første fungerende implementasjonen av den.

HTML

For at informasjonen på informasjonsnettverket Tim skapte skulle være tilgjengelig på alle de sære platformene man benyttet ved CERN, laget han et enkelt, standardisert språk til bruk i hypertekst-dokumentene - et universalspråk som kunne overta for alle de forskjellige inkompatible formatene man fram til da hadde benyttet. Dette språket kalte han HTML, Hypertext Markup Language.

Formålet med dette språket formulerte han slik:

«HTML skal være et universalspråk mellom alle plattformer. Dette forutsetter fravær av systemspesifikk kode, og kontroll over skrifttyper eller farger, for eksempel.»

HTML er et såkalt markeringsspråk i SGML-familien, der en ved hjelp av forskjellige semantiske tagger definerer hvilken rolle forskjellige tekstsnutter har i et dokument - definerer dokumentets struktur.

Her er et eksempel på et utsnitt av et HTML-dokument:

<h1>Matpreferanser</h1>
<p>Jeg liker is.</p>
<p>Jeg liker <em>ikke</em> fisk.</p>

I eksempelet er «Matpreferanser» markert som hovedoverskrift ved hjelp av <h1>-taggen (header 1), etterfulgt av to avsnitt markert med <p>-taggen (paragraph), og ordet «ikke» er uthevet ved hjelp av <em>-taggen (emphasis). Liknende tagger finnes for å markere lister, tabeller, skjemaer, lenker, kodeeksempler, forkortelser, sitater og andre strukturelle elementer man kan finne på å benytte i et dokument.

I tillegg til å utforme HTML, laget Tim en nettverksprotokoll for overføring av hypertekst-dokumenter (HTTP), en enkel, kommandolinjebasert nettleser for å kunne lese dokumentene og en HTTP-tjener for å servere dem.

World Wide Web

Tim innså raskt at HTML hadde potensiale til å være nyttig også utenfor forskningsmiljøet ved CERN. Han gav prosjektet sitt det noe ambisiøse navnet World Wide Web, og annonserte i august 1991 for nyhetsgruppen alt.hypertext hvordan systemet fungerte. I oktober samme år opprettet han epostlisten WWW-Talk.

Interessen for dette nye prosjektet var stor. Mange ønsket å bidra til den videre utviklingen - nye vevtjerene ble satt opp flere og flere steder, og nettlesere som ViolaWWW, MidasWWW, Erwise, Arena, Lynx og Mosaic så dagens lys. Med så mange forskjellige implementasjoner av WWW-teknologien oppstod faren for at universalspråket HTML og HTTP-protokollen skulle bli inkompatible på tvers av implementasjonene. Tim advarte mot at utviklerne av de forskjellige nettleserne skulle kjøre sitt eget løp framfor å koordinere arbeidet:

«Hvis du har en idé til en smart utvidelse av enten HTTP eller HTML, vennligst definer den ordentlig, og diskuter saken her på WWW-Talk. Ikke bare forsøk å publisere noe ferdig før nestemann. Han arbeider nok med det han også, implementert på en annen måte..»

Inkompabiliteter på Verdensveven ville rokke ved selve formålet med dette nettverket:

«Konseptet bak verdensveven er prinsippet om universell tilgjengelighet. Hvis du publisererer et dokument på veven, er det viktig at alle som har tilgang til det kan lese det og lenke til det.»

Mosaic

Lanseringen av nettleseren Mosaic, utviklet ved NCSA under Marc Andreessens ledelse, var det verste og beste som kunne skjedd den unge Verdensveven. Det verste fordi dens utviklere gjorde nettopp hva Tim hadde advart mot. Framfor å først diskutere mulige utvidelser til vevstandardene (for eksempel bruk av bilder på nettsider) med de andre som arbeidet med akkurat det samme, kjørte Mosaic-gjengen sitt eget løp. Mosaic 0.10, lansert i mars 1993, hadde støtte for bildetaggen <img>, som ikke var del av noen HTML-standard. Mosiac 1.0, lansert en måned senere, inneholdt ytterlige tillegg til HTML-språket.

Dette virker gjerne som trivialiteter, og var selvsagt heller ikke verdens undergang. Men det la en farlig presendens. Hva ville vel skje med prinsippet om universell tilgjengelighet om enhver nettleserprodusent kjørte sitt eget løp på denne måten?

(Du vet svaret allerede, ikke sant?)

Men Mosaic var også det beste som kunne skjedd Verdensveven. Lanseringen av en grafisk nettleser for både Unix, Windows og Macintosh la grunnlaget for Verdensvevens eksplosive vekst. Antallet vevtjenere ble tusendoblet på et par år - i juni 1993 fantes der 130 vevtjenere, et år senere 2738. I januar 1996 var tallet passert 100.000, der halvparten var kommersielle. Antallet brukere steg minst like raskt, og de aller, aller fleste benyttet nettleseren Mosaic.

Nettleserkrigen

Mosaic blir til Netscape, Microsoft oppdager Internett

I 1994 startet Marc Andreessen og en håndfull andre firmaet Mosaic Communications, som senere samme år skiftet navn til Netscape Communications. Firmaet var uavhengig av universitetet de tidligere hadde arbeidet ved, og fortsatte utviklingen av den etterhvert svært så utbredte nettleseren. I desember lanserte de Netscape Navigator 1.0, og gjorde et halvt år senere aksjene sine tilgjengelige på børsen. I løpet av én dag steg den totale aksjeverdien til 3 milliarder dollar.

Dette var det vanskelig for Microsoft - som på dette tidspunktet var travelt opptatt med utviklingen av sitt propertiære alternativ til Internett, The Microsoft Network - å overse. Så i desember 1995, på 54-årsdagen for en annen velkjent krigserklæring, erklærte Bill Gates i en tale krig mot Netscape. Fra og med den dagen skulle internett påvirke alt Microsoft bedrev, og utviklingen av nettleseren Internet Explorer ble begynt.

Dette var begynnelsen på det som senere er blitt kjent som «Nettleserkrigen». Det første offeret i konvensjonelle kriger er sannheten. I denne krigen var det de åpne standardene som ble begravet først. Med drømmen om økte markedsandeler som det eneste gjeldende ideal, ignorerte de to partene både standarder og den stadig økende mengden insekter i nettleserne sine, og brukte alt de hadde av ressurser på å raskest mulig spy ut en nettleser med flere fancy (og som regel lite gjennomtenkte) funksjoner, tagger og attributter enn det motstanderen kunne klare å komme opp med.

Konsekvenser

En gammel tysker jeg forresten er stor fan av sa en gang noe sånt som at «historien gjentar seg, første gang som tragedie, andre gang som farse». Han hadde helt rett. Mot slutten av 90-tallet stod man ovenfor omtrent samme problem som Tim Berners-Lee stod ovenfor ved CERN ti år tidligere, bare i langt større skala. Å si at der eksisterte kjedelige kompatibilitetsproblemer igjen er som å påstå at det er litt kjølig på Nordpolen. Ingenting var egentlig kompatibelt med noe som helst lenger - Netscape 4 snakket ett språk, Internet Explorer 4 snakket et annet, Netscape 3 et tredje og Internet Explorer 3 et fjerde. Når en nettside oppførte seg som den skulle i én nettleser, fungerte den som regel ikke i noen andre.

Utallige arbeidstimer ble kastet bort på å lage nettsider som ved hjelp av tungvinte skript fant ut hvilken nettleser brukeren benyttet, og serverte forskjellig kode deretter. Og når det kom en ny versjon av nettleserne nettsiden ikke kjente til - ja, da var det på'n igjen - nettstedet måtte bygges på nytt. Om utviklerne var late eller budsjettene var for trange - og det var de som regel - ble det ofte til at de brydde seg med de to mest brukte nettleserne, og stengte brukere av alle andre nettlesere ute. Tim kommenterte dette slik i 1996:

«Enhver som skriver noe sånt som "Denne siden er tilrettelagt for Nettleser X" på nettstedet sitt, synes å ønske seg tilbake til de kjipe gamle dager, før Verdensveven, da sannsynligheten var liten for at en skulle klare å lese et dokument skrevet på en annen datamaskin, i et annet program eller på annet nettverk.»

Samtidig som nettleserprodusentene var travelt opptatt med å omgjøre begrepet «universell tilgjengelighet» til noe som hørte hjemme i historiebøkene, ble nettet oversvømt av grafiske designere som ikke helt forstod at design for Verdensveven er noe annet enn design for papir. Mens en papiravis ser identisk ut uavhengig av hvem du gir den til, leses en nettside av mennesker som henter informasjonen under vidt forskjellige forutsetninger - forskjellige datamaskiner, nettlesere, skjermstørrelser, visningsinnstillinger, funksjonshemminger, og så videre. Framfor å ta hensyn til dette, var det en urovekkende stor andel av disse vevutviklerne - meg selv inkludert - som ikke brydde seg det minste om at nettsidene deres var like tilgjengelige for mange av deres besøkende som Stoltzekleiven er for rullestolbrukere, så lenge sidene så vakre ut i siste versjon av Netscape og Internet Explorer.

Tilbake (eventuelt fram) til standardene

World Wide Web Consortium

Parallelt med Nettleserkrigen foregikk en kontinuerlig utvikling av standardene, selv om verken nettleserprodusentene eller vevutviklerne brydde særlig seg med dem. I 1994 ble organisasjonen W3C, World Wide Web Consortium, stiftet av Tim Berners-Lee. Organisasjonen hadde - og har fremdeles - som mål å holde i hevd de originale prinsippene bak Verdensveven og videreutvikle standardene. Det har de også gjort - W3C står bak utviklingen av en rekke standarder, blandt andre (X)HTML, CSS, DOM, XML, MathML, PNG og SVG.

Jeg vil her konsentrere meg om de to førstnevnte.

CSS

HTML er som nevnt et språk hvis oppgave er å definere et dokuments struktur - ikke utseende. Dette frustrerte mange vevutviklere, som gjerne ville tilpasse nettsiders utseende for eksempel en bedrifts grafiske profil. Netscapes og Microsofts lite gjennomtenkte utvidelser <font>-taggen, for eksempel) ble derfor tatt varmt imot av mange. Det ble også mindre elengante hack for å dele nettsider opp i kolonner. Resultatet ble grusomt Stygg™ og Fæl™ spaghettikode.

Da var det enda godt at en smart fyr - Håkon Wium Lie - fant en løsning som både standard-puristene som ønsket å beholde HTML som et rent struturspråk og vevutviklerne som ville ha fine farger og skrifttyper kunne være fornøyde med: Cascading Style Sheets. CSS1 ble en W3C-standard i 1996.

I stedet for å rote til HTML-koden med ikke-semantiske presentasjonselementer, kan man ved hjelp av CSS lenke HTML-filen sin til ett eller flere stilsett som definerer hvordan elementene på en nettside ser ut. Deler av en slik CSS-fil kan se for eksempel slik ut:

blockquote {
  font-size: 12px;
  font-family: "trebuchet ms", verdana, sans-serif;
  color: black;
  padding: 20px;
  background-image: url(sitattegn.png);
  background-position: top right;
  background-repeat: none;
}

I eksempelet over definerer vi hvordan en sitatblokk (<blockquote>) skal se ut. Vi definerer at skriftstørrelsen (font-size) skal være 12 piksler. Skrifttypen (font-family), er «Trebuchet MS» om brukeren har denne installert på sin datamaskin. Hvis ikke denne er installert, vises sitatblokken med skrifttypen «Verdana» - og om heller ikke den er installert, benyttes den sans-serif-skrifttypen som er standard i brukerens nettleser. Tekstfargen (color) er svart, og sitatblokken er omgitt av 20 piksler «luft» (padding). Den har også et ikke-repetert (background-repeat) bakgrunnsbilde (background-image) av et sitattegn, posisjonert (background-position) oppe til høyre.

Om vi i HTML-filen vår mangler et semantisk element, for eksempel for å definere en dato ett eller annet ble publisert, kan vi benytte klasser. Her er for eksempel et avsnitt i klassen dato:

<p class='dato'>23. mai 2005</p>

I stilsettet vårt kan vi videre gi avsnitt i klassen dato et gitt utseende:

p.dato {
  text-align: right;
  border-top: 1px dashed black;
}

De første CSS-implementasjonene i nettleserne var - ikke overraskende - svært begrensede, og fulle av feil som gjorde implementasjonene inkompatible med hverandre. Man måtte altså fremdeles servere forskjellig kode til forskjellige nettlesere for å få en nettside til å se ut som man ville.

Nettleserprodusentene går i riktig retning

Mot slutten av 90-tallet ble flere og flere vevutviklere møkk lei av å kaste bort så mye tid på å krangle med nettlesere med elendig og inkompatibel støtte for standardene. Noen av dem stiftet i 1998 organisasjonen WaSP, The Web Standards Project, som hadde som mål å dytte nettleserprodusentene i riktig retning - å få dem til å støtte standardene ordentlig, slik at livet for vevutviklere verden over ville bli en hel del lettere. Først ute med en nettleser som tilstrebet disse idealene var - tro det eller ei - Microsoft. Microsoft Internet Explorer 5 for Apple Macintosh, lansert i mars 2000 og utviklet under Tantek Çeliks ledelse, lå nærmere å støtte standardene enn noen annen nettleser. Siden den gang har det bare gått framover. Microsoft er tilbake som dårligst i klassen, og ting går treigt som pokker. Men framover.

Disse framskrittene fra nettleserprodusentene gjør vevutvikleres liv en hel del enklere, og åpner for at Verdensveven ikke så langt inn i framtiden kan være standardbasert og universelt tilgjengelig, slik det var meningen at den skulle være.

Hvorfor bry seg?

Forutsatt at vevutviklerne kan sitt fag, selvfølgelig. Forutsatt at vevutviklere skjønner at det er slutt på den tiden der man lager forskjellige versjoner av nettsider for forskjellige nettlesere, og stenger ute dem som bruker «feil» nettleser. Forutsatt at vevutviklere verden over forstår at standardbasert utvikling ikke er så dumt.

Hvorfor det ikke er så dumt? Jeg har laget en liste over de seks viktigste grunnene.

1. Tilgjengelighet og kompatibilitet

Det første punktet mitt har en praktisk og en politisk side.

Den praktiske siden kan uttrykkes i én setning: inkompatibilitet er upraktisk. Å ikke kunne kommunisere med hverandre på tvers av systemer og nettverk er et problem. En løsning på dette problemet, er et universalspråk á la HTML; leselig uansett hvilket system man benytter.

Til grunn for den politiske siden er kravet om like rettigheter - i dette tilfellet spesifikt lik rett til informasjon. At man er blind, lam eller bare ikke liker JavaScript skal ikke stenge en ute fra det fantastiske informasjonshavet, verktøyet og kommunikasjonsmiddelet Verdensveven tross alt er. Informasjonen må være fri og tilgjengelig for alle, uavhengig av hudfarge og nettleser. Dette innebærer også at teknologien ikke kontrolleres av ett eller annet stort firma, men er i samfunnets kollektive hender. Dette oppnår vi best ved hjelp av åpne standarder og frie implementasjoner av disse.

2. Makt til brukeren

Noe av det som gjør nettet til en radikalt forskjellig informasjonskanal fra for eksempel TV, aviser og radio, er at det på nett er den enkelte brukeren som har makten. Istedetfor å følge en trøtt sendeplan bestemt av en eller annen redaksjon, velger brukeren selv hva hun vil titte på, hvilke diskusjoner hun vil være med i, eller om hun vil skape sitt eget nettsted. Dette er et svært viktig konsept vi må ta vare på og utvide. Brukeren må ha muligheten til å velge selv ikke bare hva hun skal se, men også hvordan det presenteres. Det er opp til brukeren - ikke deg som vevutvikler - å bestemme hvilken skjermstørrelse eller skrifstørrelse hun skal ha. Da er det en fordel om nettsiden din ikke brekker om brukerens oppsett er forskjellig fra ditt eget. For det er det som regel.

3. Enklere utvikling og vedlikehold

I stedet for å kaste bort tid på å lage en versjon av et nettsted for IE, en for Netscape, en for utskrift, en for fancy mobiltelefoner, en for prosjektorer og en for fandens oldemor, vil jeg kunne lage ett HTML-dokument med et par stilsett, og voilá! - bare se dem funke! Vevstandardene er laget med nettopp det mål for øye. Ikke er det så vanskelig heller.

4. Framover- og bakoverkompatibilitet

Fordi Netscape 4 var så full av propertiært skrot som ikke lenger støttes av noen nettleser, er de fleste nettsidene utviklet spesifikt for denne nettleseren i dag ubrukelige. De som ikke er uleselige, ser ihvertfall ikke lenger ut slik de var ment å se ut. Når nye lettlesere ble sluppet under Nettleserkrigen, måtte man knote rundt med all den gamle koden sin for å få den til å vises korrekt også i de nye versjonene. For å unngå liknende scenarier i framtiden, bør en strebe mot framoverkompatibilitet; derunder holde seg til de satte standardene. Nye versjoner av dem vil komme, men HTML 4.01 eller XHTML 1.0 kommer aldri til å forandres.

Det samme gjelder andre veien. Om en bruker sitter med en nettleser fra tidlig 90-tall, skal innholdet på nettstedet mitt fremdeles være leselig. Det ser neppe så vakkert ut at det gjør noe, men informasjonen er tilgjengelig. Og det er det essensielle her. Om vi følger standardene og skiller innhold og struktur på den ene siden og utforming på den andre siden - et konsept jeg kommer tilbake til - vil innholdet være tilgjengelig uavhengig av hva slags nettleser man benytter.

5. Reduserte båndbreddekrav / høyere hastighet

Nettsurfere er utålmodige dyr. Om nedlastingen av en side tar lang tid, går de heller et annet sted. Derfor er det smart å holde størrelsen på et sett nettsider minimal, slik at sidene laster raskt. Om du tilfeldigvis er en nettbutikk, har du neppe lyst til at potensielle kunder heller skal besøke konkurrenten. Standardbasert kode veier langt mindre enn spaghettikode fra helvete, og laster derfor tilsvarende raskere. Og nei. Alle har ikke like raskt bredbånd som du har. Ihvertfall ikke dem som surfer på nettet på mobiltelefonen sin.

Dessuten er båndbredde kostbart. Jo mindre plass nettsidene tar, jo mindre blir regningen fra nettleverandøren.

6. Bedre plassering i søkemotorer

Den viktigste besøkende på nettsidene mine, Google, er blind. Så hvis de ikke er fullt leselige for blinde, forstår heller ikke Google stort av dem.

Tilgjengelige nettsider på 1-2-3.. 4-5-6-7-8!

Greit. Men hvordan oppnår vi disse tingene i praksis?

Her er noen punkter, sånn omtrent i prioritet rekkefølge:

1. Bruk korrekt syntaks

Det første du bør kreve av deg selv som vevutvikler, er at du skriver kode med korrekt syntaks. Spesifiser hvilken (X)HTML-versjon du benytter, lukk alle tagger du åpner, ikke bruk tagger og attributter som ikke finnes i standardene og spesifiser alternativ tekst til bilder. Skriver du XHTML - sørg for at du sender riktig MIME-type til nettleseren.

Det finnes mange gode verktøy som gjør dette punktet langt enklere. Fargekodingen i Vim, for eksempel, avslører raskt om du har kommet i skade for å bruke en tag som egentlig ikke eksisterer. I tillegg er W3Cs validator et utmerket verktøy for å finne finne feil i koden din.

Men det at du bruker korrekt syntaks er ingen mirakelmedisin som gjør sidene dine universelt tilgjengelige. Du blir heller ikke forfatter av å kunne bøye verb. Men det er et skritt i riktig retning!

2. Skriv semantisk korrekt kode

HTML er - som vi har vært inne på - et språk for å definere et dokuments struktur. Vi har en mengde tagger til rådighet, og markerer med dem overskrifter som overskrifter, lister som lister, sitater som sitater, uthevninger som uthevninger, og så videre.

Mangler du en tag for å beskrive et strukturelement, bruker du klasser. Strukturerer du et intervju eller en FAQ vil du kanskje ha bruk for klasser som <p class='sporsmal'> og <p class='svar'>.

3. Skill struktur og utseende

Dette punktet henger tett sammen med det forrige. Luk ut alle tagger uten semantisk betydning, alle tagger som forsøker å definere noe visuelt. Design lager vi ved hjelp av CSS. Spaghettikode, <font>-tagger og tabeller brukt for å dele en side inn i kolonner klarer vi oss uten. Dette betyr også at du ikke bør kalle klassene dine for ting som gulboks. Det har ingenting med struktur å gjøre. Hvordan høres vel en gul boks ut for dem som benytter lydnettlesere?

Gjøres dette riktig, vil du ikke trenge å røre HTML-filen i dele hele tatt om du bestemmer deg for å redesigne - eller om du bare vil ha 612 forskjellige utforminger av samme HTML-side. En ny CSS-fil vil holde.

Om du gjør dette riktig, kan du også enkelt servere forskjellige stilsett for bruk i forskjellige visningsmedier - for eksempel ett stilsett for visning på skjerm, ett stilsett for visning på bittesmå, håndholte dingser og ett stilsett for utskrift.

4. La designet ditt tilpasse seg brukerens nettleser, ikke omvendt

En nettside med fast bredde på for eksempel 900 piksler er en dårlig idé. Du har ingenting med å bestemme hvor stort brukerens nettleservindu skal være. På nett er det brukeren som bestemmer, og hvis brukeren har et nettleservindu som er 700 eller 1200 piksler, bør sidene dine tilpasse seg den bredden.

Det er viktig å huske på at stilinformasjonen i stilsettet ditt bare er veiledende. Kanskje har ikke brukeren akkurat den skrifttypen du synes er flottest. Kanskje har brukeren stor skjerm eller dårlig syn, og vil øke skriftstørrelsen. Da er det en fordel om det fin-fine, CSS-baserte designet ditt ikke brekker om brukeren vil ha større skrift eller skru av bilder.

Og hold deg innenfor nettleservinduet, er du snill. Ikke åpne nye vinduer om ikke brukeren spesifikt har bedt om det.

5. Styr unna kompliserende navigasjon

Unngå å skjule innholdet ditt bak kompliserende navigasjon. Den fancy Flash- eller JavaScript-menyen din er ikke like fancy for de som av ymse årsaker har disse tingene deaktivert. Google, for eksempel, vil ikke kunne finne fram til undersidene dine. Og hvordan tror du rammer (frames) ser ut på en håndholdt datamaskin eller i søkemotorresultater?

Misforstå meg rett her. Å bruke for eksempel skripting for å gjøre navigasjon enklere og mer elegant er flott dèt, så lenge der finnes et alternativ å falle tilbake på om dette er deaktivert i brukerens nettleser og så lenge det ikke er nødvendig å ha ett eller annet hipt og trendy installert for å få tilgang til informasjonen på et nettsted.

Dette eksempelet viser hvordan skripting kan utvide funksjonaliteten uten å stenge noen ute. Titt på siden både med og uten JavaScript.

6. Bruk <title>-taggen orntli'!

Av alle punktene i denne listen, er det dette punktet jeg er dårligst på å følge selv. Det blir ofte til at tittelen på alle undersidene på et nettsted forblir det samme. Det er en dårlig praksis, for en fornuftig <title>-tag er faktisk ganske viktig. Hvis jeg søker etter informasjon om ett eller annet, klikker jeg heller på en nettside med søkeordene mine i tittelen enn «Bobs hjemmeside», selv om begge sidene inneholder akkurat det jeg leter etter.

7. Definer dokumentets språk

Er det på norsk, bør dette defineres i dokumentet. Da slipper swahili-talende å finne dokumentet ditt i søkemotortreffene sine. Har du et sitat eller et produktnavn et sted i teksten på engelsk, definer også dette. Det høres temmelig snodig ut når en skjermleser forsøker å lese engelsk tekst med norsk uttale.

8. Test nettstedet!

Ser CSSen din ut som den skal i de moderne nettleserne? Er innholdet tilgjengelig i både Lynx og siste versjon av favorittnettleseren din? Virker navigasjonen like intuitiv for alle dem som ikke har vært med å lage den? Funker alt fint om du deaktiverer stilsett, bilder og skripting?

Hindre for utbredelse av standardene

Forfatteren og vevutvikleren Jeffery Zeldman har dessverre helt rett når han påstår at «99% av alle nettsider er gått ut på dato.». Det er flere grunner til at ikke flere følger standarder og retningslinjer for tilgjengelighet - både tekniske og menneskelige.

Den viktigste tekniske faktoren er nettleserparken. Selv om vi har mange gode idéer om hvordan ting burde ha vært, må vi forholde oss til den virkelige, materielle verden. Og i den virkelige verden er der fremdeles en majoritet av brukerne som sitter med nettlesere som fremdeles ikke støtter den snart ti år gamle CSS-teknologien fullt ut. At enkelte nettleserprodusenter på tross av en hær av programmerere og milliarder på bok ikke har klart å fikse disse manglene i programvaren sin er bare tragisk. Men slik er det.

Dette betyr blant annet at det fremdles er nødvendig med en og annen teipløsning for å få nettleserne til å oppføre seg, og at vi enda ikke fullt ut kan bruke de artige mulighetene CSS gir oss. Hvis du for eksempel mekker de interne sidene til skolen eller bedriften, der samtlige maskiner kjører versjon 4-nettlesere og IT-ansvarlig er en imkompetent gjøk, er det fremdeles nødvendig med en god del uggen kode for å få ting til å se ut som de skal. Noen steder vil nok for eksempel tabeller til kolonneinndeling fremdeles være en nødvendighet en stund framover. Greit nok. Nettleserparken er ikke klar for standard-utopia ennå, og det må vi bare forholde oss til. Men gå allikevel så langt i riktig retning som mulig. Ikke la vær å forsøke fordi du ikke kan ta skrittet helt ut med en gang. Kapittel 8 og 10 i Jeffery Zeldmans bok «Desiging With Web Standards» (en bok alle med interesse for disse tingene bør lese) gir en meget god guide til hvordan en på best mulig måte mekker en fungerende hybridløsning. Les og bli vis.

Men kanskje viktigere enn det rent tekniske, er de menneskelige faktorene. Programvare kan oppdateres med noen få tastetrykk. Mennesker er det litt vanskeligere med. Under følger en liste over de vanligste negative holdningene til vevstandarder.

1. «Hæ? Standarder?»

Mange som kaller seg vevutviklere vet ikke engang at standardene eksisterer! Det eneste som kan forandre på det, er god, gammeldags folkeopplysning. Jeg gjør et hederlig forsøk på det gjennom for eksempel denne artikkelen.

2. «Det er mye enklere på gamlemåten!»

Alt er lett når du kan det. Og alt er vanskelig når du ikke kan det. For en nybegynner i dag er det mye enklere å lære seg HTML og CSS fra bunnen av enn det var å lære seg det havet av teipløsninger de av oss som lekte med dette på slutten av 90-tallet fremdeles bærer symptomene av. Overgangen fra å skrive spaghettikode til å følge standarder og retningslinjer for tilgjengelighet krever en betydelig holdningsendring og en ny, grunnleggende forståelse av Verdensveven som medium. Men det er bare til å sette i gang. Forhåpentligvis får du ikke jobb om et par år om du ikke kan bruke teknologien ordentlig.

3. «Vi har ikke budsjett til å følge standardene. Det er så dyrt.»

Om nettstedet ditt i dag er et spaghettikodekaos år 1999 verdig - ja, da stemmer det nok at å gå over til å følge standardene kan bli dyrt. Ikke fordi det tar så mye ressurser å lage et rammeverk for nye, standard-følgende nettsider, men fordi det er et langtekkelig slit å hente ut og konvertere informasjonen fra det gamle formatet. På lengre sikt vil det dog uansett lønne seg, av grunner vi har vært igjennom allerede. For nettsteder med høy trafikk vil ofte reduksjonen av båndbreddebruken alene veie opp for en investering i en real opprydning i gammelt skrot.

I mange land finnes der også opp lovgivning som krever at for eksempel statlige nettsteder skal være tilgjengelige for alle. Section 508 i USA er et eksempel på en slik lov. Å bli saksøkt og bøtlagt for å stenge brukere ute kan raskt bli dyrere enn en oppdatert versjon av nettstedet.

4. «HTML-verktøyet mitt genererer dårlig kode.»

Det beste er selvsagt om du lærer deg HTML og CSS og skriver koden din selv. Da har du full kontroll. Ikke er det så veldig vanskelig heller. Men om det er praktisk umulig, bytt ihvertfall ut det dårlige verktøyet ditt med et bedre. Siste versjon av Macromedia Dreamweaver, for eksempel, er noenlunde oppegående.

5. «Strenge standarder setter grenser for kreativiteten min!»

Denne innvendingen, som selvsagt er skivebom, kommer stort sett fra grafiske designere som ikke har forstått at design for nett er noe helt annet enn design for papir. Alle medier har sine muligheter og sine begrensninger. Men ved å følge retningslinjene lagt fram i denne artikkelen, kan du få et nettsted til å se ut akkurat som du vil i moderne, CSS-støttende nettlesere samtidig som innholdet på sidene er tilgjengelig uansett hvilket system man benytter.

6. «Jeg er timebetalt!»

Endelig et godt poeng! Om du er timebetalt vil nok inntektene per prosjekt du fullfører være en god del lavere om du gjør ting Riktig™. Du kan ikke lenger fakturere kunden for utallige timer kastet bort på meningsløs kodegafling.

Hva kan vi andre gjøre?

Alle som leser denne artikkelen er neppe vevutviklere. Det er dog intet hinder for at samtlige kan gjøre sitt for å gjøre Verdensveven til et bedre sted.

1. Bytt ut dårlige nettlesere

Er du blandt dem som har forsøkt å overtale bestemor til å kjøre Linux? Jeg har en litt enklere oppgave til deg. Installer noe annet enn IE på maskinen hennes. Venner lar ikke venner fyllekjøre, heter det. Venner bør heller ikke la venner bruke dårlige nettlesere med evneveik støtte for standardene.

Der finnes i dag en haug med forskjellige gode nettlesere. De viktigste er:

Internet Explorer bør helst defenestreres. Når dette skrives, er siste versjon av denne nettleseren fire år gammel, og er proppfull av feil og mangler i sin støtte av standardene. Du gjør alle vevutviklere en stor tjeneste ved å fri verden fra dårlige nettlesere som denne.

2. Hyr utviklere som vet hva de holder på med

Dersom bedriften, fotballaget eller partiet planlegger å hyre noen for å lage eller oppdatere et nettsted, er det viktig å være kritisk til hvem man betaler for å gjøre jobben. De fleste bedrifter som arbeider med vevutvikling henger fremdeles igjen i 1999. Styr unna dem. Bruk litt ekstra tid på å finne noen som faktisk vet hva de holder på med. Det vil lønne seg.

3. Spre det glade budskap!

Sist, men definitivt ikke minst, spre det glade budskap! Jo flere som vet om at der finnes et sett standarder for vevutvikling man bør følge, jo bedre.

Innhold

© Fortellinger.net 2001 – 2015. Webhotell fra MinHost