En stilguide för väven

Skriven av Karl-Johan Norén, kjnoren@hem3.passagen.se, maj 1997.

Detta är allt-i-ett versionen av min En stilguide för väven, lämplig för t ex utskrifter. Vill någon använda denna guide som kurs- eller undervisningsmaterial går det bra, förutsatt att den återges i sin helhet. Kopior för personligt bruk är också tillåtet. Vill någon använda det för annat ändamål, var vänlig kontakta mig.

Skriver du ut den här filen kan du också skriva ut Appendix A som innehåller samtliga URL:er till källorna som nämns i denna guide. Egentligen borde det vara vävläsarnas sak att ordna det, men då de flesta inte klarar av denna mycket enkla sak får ni hålla tillgodo med denna inte helt perfekta lösning.

Den senaste versionen av denna stilguide finns tillgänglig från <http://hem3.passagen.se/kjnoren/stilguide/>.

Introduktion

Detta är ett försök att skriva en någorlunda utförlig och komplett stilguide på svenska för vävsidor. Det är alltså inte något dokument för dig som vill lära dig HTML, utan snarare för dig som vill använda HTML på bästa sätt på väven.

Om du har läst andra stilguider, främst Tim Berners-Lees eller WDGs så kommer du säkert att känna igen dig, men jag har försökt att undvika att göra den här guiden till en översättning, även om mycket av det som nämns där återfinns här. Jag har också använt mina egna erfarenheter av drygt två års vävsidessnickrande, liksom mina erfarenheter som "surfare" på olika plattformar och med olika vävläsare.

Notera dock att det här är en guide, det är inte någon form av anvisningar om hur saker och ting måste göras. Se det som goda råd och idéer, men det är till syvende og sidst du som måste bygga och skriva dina sidor, och se till att de har en form som är anpassad till innehållet.

Innehållsförteckning

Några kommentarer

Jag använder konsekvent "väv" och sammansättningar med det istället för "webb", som i mina öron är oerhört ful svengelska. Likaså använder jag "rutor" istället för "ramar" (frames) eftersom analogin med vanliga fönster då blir tydligare. Ett fönster (dvs vävläsaren) kan ha flera rutor, men flera ramar?

Som så mycket annat på väven är den här stilguiden visserligen färdig, men den är inte klar och den lär aldrig bli det heller. Jag tar gärna emot kommentarer på saker som kan göras tydligare eller är felaktiga, liksom tips om nya ämnen eller frågor. Exempel saknas i många fall, men det ska förhoppningsvis bättra sig med tiden.

Att arbeta med HTML

Den troligen viktigaste, men samtidigt svåraste, lektionen om HTML är hur man arbetar med HTML, istället för emot HTML. Jag talar alltså inte om vilka verktyg man använder, eller vad de olika koderna står för, utan från vilken utgångspunkt man använder språket och vad man vill uppnå med det.

HTML är ett verktyg bland många andra, och precis som andra verktyg har det styrkor och svagheter - det är bra på vissa saker och dåligt på andra. För att förstå vad som är HTMLs styrkor och svagheter måste man förstå filosofin bakom HTML.

Struktur kontra presentation

HTML är ett språk för att beskriva strukturen i en text, vilken roll de olika delarna spelar i dokumentet som helhet. Man anger vad som är rubriker, vad som ingår i de olika styckena, vilka ord som är betonade osv utan att beskriva exakt hur rubrikerna ska synas eller styckena ska skiljas från varandra. Istället få HTML-tolken (som vanligen är en vävläsare) presentera sidan på ett sätt som passar mediet och förhoppningsvis besökaren (läsaren).

Fördelen med detta är att ett HTML-dokument kan presenteras i en mängd olika situationer: med en fullgrafisk vävläsare, på en ren textterminal, med en röstläsare osv. Det gör det också lätt att automatiskt skapa innehållsförteckningar, dispositioner och index från en vävsida, vilket bland annat sökmaskinerna drar nytta av.

Nackdelen är att man som författare ger upp kontrollen över exakt hur presentationen ska bli. Ansvaret för detta ligger istället på vävläsaren, som förhoppningsvis ska presentera innehållet på sidan i enlighet med besökarens önskemål, men tyvärr är de flesta vävläsare bedrövliga på detta.

Är layout möjlig?

Därmed inte sagt att det saknas layoutelement i HTML. En del fungerar som attribut till andra element (t ex ALIGN), en del kan användas för layout (t ex TABLE), en del har inget annat syfte (t ex FONT) - men försöker man uppnå en exakt kontroll över en sidas utseende med HTML så kommer man oundvikligen att slå huvudet i väggen. Det finns inga som helst garantier att sidan kommer att presenteras i enlighet med författarens önskemål - typsnittet kan saknas, skärmen kan vara för liten eller ha för få färger osv osv.

I det absolut värsta fallet gör man sidan oanvändbar för en större eller mindre grupp besökare. Börja därför med en god strukturell beskrivning av dina sidor, och använd sedan layoutdirektiv utöver detta. På så vis kan man behålla flexibilititen och anpassningsbarheten hos HTML.

Annars finns det en bättre lösning än layoutdirektiv direkt i HTML-koden: style sheets, som är betydligt mer kraftfulla för att beskriva en layout, kan anpassas för olika situationer och miljöer, och är gjorda med målet att både författaren och besökaren kan ange sina önskemål om presentationen. Dessa sidor använder för övrigt style sheets. Men precis som layoutdirektiv direkt i HTML-koden kan style sheets missbrukas.

Anpassningsbarhet

Mycket av det som nämns ovan och som jag tar upp senare i den här stilguiden syftar mot en och samma sak: anpassningsbarhet. En välgjord vävsida anpassar sig efter den plattform den visas på och besökarens behov. Om man tror att man behöver ha en separat kopia av alla sidor med enbart text så har man inte förstått poängen med HTML. Om man behöver använda en sådan behärskar man oftast inte HTML.

Eller som Tim Berners-Lee, skaparen av World Wide Web, sa i Technology Review i juli 1996:

Anyone who slaps a "this page is best viewed with Browser X" label on a Web page appears to be yearning for the bad old days, before the Web, when you had very little chance of reading a document written on another computer, another word processor, or another network.

Jag vill poängtera att klassiska grafiska kunskaper från layout eller reklamskapande inte är värdelösa på väven. Men väven är ett nytt och eget medium, skilt från de pappersbaserade. Att försöka använda klassiska grafiska kunskaper direkt på väven utan att först förstå vad väven har för egenskaper, möjligheter och begränsningar är förkastligt. Man måste först förstå vad väven innebär, vilka särskilda krav den ställer och vilka möjligheter den ger.

Fortsatt läsning

Vävplatsen som helhet

En vävplats är en samling vävsidor som är grupperade tillsammans och vanligen behandlar ett gemensamt ämne. Sidorna i den här stilguiden kan sägas utgöra en (mycket liten) vävplats, som ingår i min egen personliga vävplats. Mina sidor är i sin tur en del i DSVs vävplats.

Genom att bygga upp en klar struktur över din egen vävplats gör du det enkelt för de som besöker en del av den att titta på andra delar med, och det blir också enklare att uppdatera och ändra sidorna.

Trädmodellen

Detta är den absolut vanligaste modellen för att bygga upp en vävplats, och också en av de enklaste. Sidorna ordnas hierarkiskt, med en sida som rot (hem-, topp- eller välkomstsida). Rotsidan har sedan länkar till de underliggande sidorna. Lägger man ett antal underliggande sidor i samma katalog (mapp eller directory) har man skapat en gren som i sig har en egen rotsida och underliggande sidor. Alla sidor har en länk till sidan direkt ovanför.

Även om man tycker att man bara har en eller ett fåtal sidor om ett ämne så är det ofta en bra idé att lägga dem i en egen katalog. På så vis ger man utrymme för framtida utökningar och nya sidor, och slipper krånglet med att flytta sidor som det finns massor med länkar till utifrån.

Hur grenarna ska organiseras är inte någon lätt fråga, särskilt inte om man har en flerspråkig vävplats. Är det bara en eller ett fåtal sidor som ska vara tillgängliga på två språk kan man samla dem i samma katalog, annars kan det löna sig att lägga dem var sin katalog. Se också till att namnen på sidorna är konsekventa, t ex att alla engelska sidor i en i övrigt svensk katalog börjar med e-.

Sidorna inom en gren kan också innehålla länkar till de andra sidorna inom samma gren, eller bara sidorna direkt före och efter. På så vis kan man läsa dem i sekvens, utan att behöva backa tillbaka till rotsidan.

Ge vävplatsen en identitet

Det ska märkas att sidorna i din vävplats hör ihop med varandra, och det ska inte vara någon tvekan om när man har lämnat den. Det viktigaste medlet för detta är att ha en konsekvent stil på sidorna. Sidhuvuden och sidfötter ska vara gemensamma för sidorna, och fungera på samma sätt i dem. Gemensam information som länkar till resten av platsen, kontaktinformation till författaren, när sidan senast uppdaterades osv ska återfinnas på samma plats i alla sidorna. En annan god effekt av detta är att sidorna blir lätta att uppdatera och navigera i.

Gör sidorna lätta att navigera

Att sidorna är länkade till varandra löser bara halva problemet. Man måste också kommunicera vart länkarna går, och vilken roll de spelar i sidan som helhet. Oftast kan detta göras direkt i länktexten, men ibland kan det vara lämpligt att bygga upp en fast sekvens eller en "guidad tur" genom sidorna. Likaså bör man göra det möjligt för återkommande besökare eller personer med erfarenhet i ämnet att snabbt nå den information han eller hon är på jakt efter.

En användbar tumregel är trestegsprincipen: man ska kunna nå godtycklig sida i vävplatsen från vilken annan sida i den i tre steg, dvs via högst två mellanliggande sidor. Väl valda indexsidor gör det möjligt att uppnå detta mål även i större vävplatser utan särskilda hjälpmedel. Nästa steg kan vara en samlad innehållsförteckning för alla vävplatsens sidor eller en lokal sökmaskin.

Det vara möjligt att nå platsens välkomstsida, eventuella sökmaskiner och innehållsförteckningar direkt från alla sidor i vävplatsen. Ordlistor, copyright-meddelanden och andra gemensamma resurser kan hanteras på samma sätt.

Man uppnår ytterligare en fördel med detta. Det finns inga som helst garantier att besökaren kommer till en viss sida på det sätt du har förutsett eller väntar dig. Han eller hon kan ha använt en sökmaskin eller en länk utifrån. Länkarna till dina kringliggande sidor gör det då enkelt att nå resten av din plats.

Det är också en bra idé att ge information om vad som är nytt eller har ändrats. Man kan ha en blänkare på rotsidan, en särskild sida med nyheter eller både och. Sidan med nyheter kan också användas för att visa hela utvecklingen av vävplatsen.

Dokumentstorlek

I många fall kan ett ämne eller ett hypertextdokument svara mot flera sidor (den här stilguiden är ett exempel). Det finns både fördelar och nackdelar med att dela upp ett dokument i flera delar, men man bör definitivt sträva mot att varje sida behandlar ett avgränsat ämne. Att slå samman flera skilda ämnen ger lätt sidorna växtvärk, och kan förvirra besökare.

En nackdel med att ha flera små sidor är att varje sida måste hämtas för sig, och varje ny förbindelse över nätverket tar tid. Å andra sidan har stora sidor också nackdelar. De tar tid att hämta och det besökaren söker kan vara var som helst i sidan. Informationen blir också mer svåröverskådlig, och man tvingar besökaren att bläddra runt över stora sjok av information.

Oavsett om man delar upp dokumentet eller samlar det i en stor sida är det därför en fördel att först ha en översikt eller en innehållsförteckning. På så sätt kan en besökare enkelt avgöra om det du erbjuder är av intresse, och kan också snabbt nå det han eller hon är på jakt efter. I vissa fall kan man erbjuda både flera mindre ihoplänkade sidor och en stor sida med all information i ett. Den senare är användbar för t ex utskrifter.

I vilket fall bör man alltid se till att välkomstsidan för en vävplats är högst 60 kB stor, inklusive bilder, länkade style sheets, Java applets osv. Helst bör den inte vara mer än 30 kB stor, gärna mindre.

Kraven kan lättas upp för mer ämnesspecifika sidor, men 60 till 100 kB är i många fall en praktisk övre gräns för enbart HTML-koden och texten. Mer än så och sidan blir oöverskådlig. Man bör också ge en varning om en länkad sida (dvs text och bild) är över en viss storlek, t ex 40 kB. Att ge sidans storlek i kB inom parentes efter länken är fullt tillräckligt.

Fortsatt läsning

Innehållet i vävsidan

Innehållet är det som är värdefullt i din vävsida, och det du ska lägga ner mest arbete på. I den här diskussionen definierar jag innehåll i dess bredaste bemärkelse, både den information som ska kommuniceras, i viss mån hur den presenteras och metainformation som vem som skrev den, när den skrevs, sammanfattningar osv.

Metainformation

Det är en självklarhet att varje sida ska ge information om vem som skrev den, hur man kontaktar författaren och när den senast ändrades. Är en del av sidan inte helt färdig så bör man också tala om det, liksom eventuell copyright och andra juridiska aspekter.

Mycket av denna information kan med fördel samlas med ADDRESS-elementet, på samma plats i alla sidorna och med samma layout. Det gör den lätt att uppdatera och hitta. Länkar till relaterade sidor kan också samlas i anslutning med metainformationen.

Om man behöver använda längre copyright-meddelanden eller meddela en specifik policy är det en bra idé att bryta ut den till en egen sida, och länka till den från ett kort copyright-meddelande. På så vis belastar man inte varje sida med långa identiska texter, och uppdateringen blir också enklare.

Informationen om hur man kontaktar författaren kan med fördel göras som en mailto-länk till författarens e-postadress, eller ett formulär för att skicka e-post. Som länktext bör e-postadressen själv användas. Då undviker man att kontaktinformationen försvinner om sidan skrivs ut eller sparas i textformat, och någon som vill använda ett separat e-postprogram kan använda klippa och klistra för adressen.

Använd HTML rätt

En viktig egenskap i HTML är att man gör strukturen i en sida explicit. Istället för att använda ett radindrag eller en blankrad för att säga att nu är det ett nytt stycke, så använder man elementet P. Istället för att använda t ex Helvetica i 24 punkter för en rubrik så använder man elementet H1. På samma sätt markerar man längre citat, rubriker, listor osv.

Detta har flera trevliga egenskaper. En sida kan presenteras på ett adekvat sätt på en stor mängd plattformar och miljöer. En röstläsare kan säga nytt stycke eller göra en paus för att meddela styckebyte. En grafisk läsare kan använda radindrag. En textläsare kan använda blankrad, osv.

Ett annat viktigt resultat är att sökmaskiner kan använda rubriker och andra element för att indexera din sida korrekt. Undvik definitivt att använda t ex BLOCKQUOTE för att skapa en indentering. Visserligen gör många vävläsare en indentering, men vävläsaren är i sin fulla rätt att säga jag citerar eller sätta > före varje rad i citatet, som är den standard som används i e-post och i nys.

Låt sidan stå på egna ben

Samtidigt som länkar, sökmaskiner och bokmärken gör väven så rik som den är så medför de också krav. Du kan aldrig vara säker på att en besökare har läst en sida som föregår den de är på. Sidan måste vara användbar även i dessa fall - den måste stå på egna ben.

Först och främst ska sidan ha en användbar och tydlig titel. Introduktion säger inte speciellt mycket, men Projekt Runeberg: Introduktion gör det. En väl vald titel är också värdefull för sökmaskiner och personer som länkar till din sida.

Låt heller inte texten på sidan utgå från ett underförstått sammanhang. Se istället till att brödtexten presenterar sig själv, utan hjälp av rubriker och tidigare sidor. Se också till att det finns länkar till de omkringliggande sidorna. På så vis spelar det ingen roll till vilken sida en besökare kommer först - han eller hon kan fortfarande avgöra om dina sidor är användbara och kan få hela ditt budskap.

Fortsatt läsning

Att hantera länkarna

Om själva sidorna i din vävplats är brödet, så är länkarna smöret. Länkarna är det som binder samman sidorna och ser till att din vävplats inte är en isolerad ö skild från omvärlden. Det är ingen större överdrift att påstå att länkarna är väven. HTML-dialekter och sidor kommer och går, men länkarna består.

Namnge dem rätt

En av de viktigaste principerna när man konstruerar ett informationssystem är att den relevanta informationen ska vara lätt att identifiera, samtidigt som den inte ska störa den övriga informationen runtomkring.

Länkar med namnet klicka här eller liknande bryter mot båda principerna ovan. Det finns två intressanta informationsbitar för en länk: att det finns en länk till någonting, och vad länken berör, men dessa två är inte i direkt anslutning till varandra. Man måste titta på området före och efter själva länken för att få dess funktion.

Dessutom blir meningarna ofta klumpigare och mer svårlästa genom användning av klicka här. Visst, det är lätt att skriva med "klicka här", men målet är väl knappast att ha en lättskriven vävplats, utan en lättläst och lättanvänd en? Eller hur?

Länknamn bör vara korta och deskriptiva. Tre eller fyra ord räcker i många fall. Om sidan man länkar till är stor kan man ange dess storlek (text och bild tillsammans) inom parentes efter länken. En vanligt minimivärde som nämns för detta är 40 kB, men man bör definitivt märka alla länkar till sidor på 100 kB eller mer.

Ord man ska försöka undvika i länknamn är bla a information, mer, här, bakåt, tillbaka, framåt och hem. De fyra första säger egentligen ingenting om vad länken handlar om, de fyra senare är i praktiken reserverade för funktioner i vävläsaren. Sidan som tillbaka pekar på är ofta inte densamma som den sida som besökaren var på senast.

Se till att de pekar rätt

Döda länkar är trista länkar. Det enda man får se är ett litet meddelande med HTTP 404 File Not Found på grå bakgrund. Förhoppningsvis står och faller inte din sida med dess länkar, men man bör definitivt ha för vana att kontrollera dem regelbundet och fixa alla som pekar fel på något sätt.

Men en länk kan också vara felaktig och fortfarande peka på någonting. Två fall är väldigt vanliga här. Det första är att det finns kvar en sida med en notis om att den nya adressen är si-och-så, komplett med en länk dit. Ordna dessa med, du kan aldrig veta när en sådan sida försvinner, och du tvingar dina besökare till att följa ytterligare en länk.

Det andra fallet är mindre tydligt, men nog så vanligt. Det är att en del av URL:en pekar fel, men servern som sidan finns på korrigerar felet med en s k redirect. Vanliga sådana fel är att länken pekar på en maskin som sidan tidigare låg på, eller att en avslutande "/" saknas i URL:en. Visserligen korrigeras felet, men det tar tid och nätverksresurser helt i onödan. Vid minsta tvekan, klipp och klistra in URL:en direkt från vävläsaren!

index.html eller inte index.html

Man ser ofta någon som säger att en hemsida "måste" heta index.html eller index.htm. Verkligheten är lite mer komplicerad. När sökvägen i en URL avslutas med "/" pekar den på en katalog, och vad vävservern skickar tillbaka beror på hur den är inställd. Oftast tittar den efter om det finns en fil som heter t ex index.html, default.html eller Welcome.html, och skickar iväg den, om den finns. Denna fil kan kallas för en indexfil.

Finns det inte en fil med ett sådant namn, eller om listan över standardfilnamn är tom, så kan vävläsaren antingen skicka tillbaka en lista över alla filer i katalogen, eller helt enkelt meddela att man inte får titta i den. För att veta exakt på vilket sätt din vävserver fungerar och vilka standardnamn den har så får kontrollera med din vävansvarige eller dokumentationen, eller helt enkelt testa själv.

I vilket fall bör du vara konsekvent vad gäller dina URL:er. Antingen använder du URL:er som pekar på katalogen, eller som pekar direkt på indexfilen. Använder du båda finns det risk för att dina besökare blir förvirrade, eller tvingas ladda ner exakt samma sida två gånger. Du kan använda en länk i formen <A HREF="./">länktext</A> för att peka på den aktuella katalogen.

Länklistor

Det är lätt att göra jättelistan Allan över all världens länkar, men att hålla den uppdaterad är definitivt inte lätt. Dessutom finns det redan stora tjänster för detta i form av Yahoo, olika ämnesspecifika index eller sökmaskiner. Att ens försöka konkurrera med dem är dödfött.

Då är det en bättre idé att göra en relativt kort och personlig lista över länkar - sidor som du själv besöker relativt ofta. På så vis kan du också frigöra din lista med bokmärken i vävläsaren för t ex sidor du ska ta en närmare titt på lite senare. Ännu bättre blir det om du läggger till dina egna kommentarer om sidorna.

Om det saknas en bra lista med länkar till sidor inom ett område du är intresserad av kan du naturligtvis slå slag i saken och försöka göra en mer eller mindre komplett sådan - men tänk på att det är mycket jobb.

Bilder på väven

Hittills har vi mest behandlat text, men bilder fyller också en viktig funktion på väven. De används som prydnader för att göra en sida mer attraktiv, som navigationshjälpmedel eller som en integrerad del av en sidas innehåll.

Bilder i allmänhet

Det första du måste tänka på är att bilder är stora. Även en liten ikon motsvarar lätt hundra ord eller mer. Visserligen säger en bild lika mycket som tusen ord, men i en dator är är den ofta många gånger större. Det är heller inte alla vävläsare som kan visa bilder överhuvudtaget, eller inte kan visa dem direkt på sidan. De kan också göra att sidan tar längre tid att presenteras för mottagaren.

Samtidigt är de ofta också ovärderliga. De gör sidan mer attraktiv och de kan enkelt förklara eller visa saker som inte går att säga i ord. Men hanteringen av bilder på väven kräver planering, noggrannhet och att man tänker efter före.

Det viktigaste är att göra bilderna så utrymmessnåla som möjligt. För att göra detta kan man reducera antalet färger, klippa bort delar som inte behövs eller minska bildens fysiska storlek. Har man ett galleri eller behöver en stor bild skapar man miniatyrer av som länkar till motsvarande fullstora bild. Miniatyerna ger en snabb översikt av vad du har att erbjuda, laddas ner snabbare och låter besökaren själv välja ut vilka bilder han eller hon vill se.

Nästa del är återanvändning. Lägg dina bilder samlat i en katalog, och länka sedan in bilderna därifrån för alla dina sidor. Om du använder samma bild för samma funktion på dina sidor ritas dels sidan upp snabbare eftersom vävläsaren redan har laddat ner bilden en gång, och du ger också dina sidor en starkare identitet. Om det finns ett centralt bildbibliotek i din vävserver ska du definitivt utnyttja det.

Vävläsaren måste också veta hur stor bilden är innan den kan rita upp texten runtomkring. Du kan reservera utrymme för bilden genom att använda attributen HEIGHT och WIDTH till IMG-markören. Men ändra aldrig storlek på bilden med de här värdena - dels får du alltid bättre resultat om du gör det själv, dels är inte vävläsaren tvungen att skala om bilden. Den kan rita om sidan istället.

Sist, men definitivt inte minst, kommer ALT-texten. Ange alltid en ALT-text till alla dina bilder. Jag tar upp mer om ALT-texten nedan.

Logotyper

Om ett företag eller en organisation har en logotyp ska den naturligtvis återfinnas på alla sidorna. Om man dessutom gör den till en länk till rotsidan fyller den ytterligare en funktion. Ofta kan man också ersätta den vanliga rubriktexten, t ex Välkommen till XYZ med logotypen. Om man då placerar bilden i rubriken och ger den en bra ALT-text kommer den också att hanteras rätt av sökmaskiner och (förhoppningsvis) vävläsare som inte laddar ner bilderna. De här sidorna använder för övrigt den metoden.

Ikoner för navigation

Det finns flera skäl till att använda ikoner istället för text för de grundläggande gemensamma länkarna. En ikon syns oftast bättre än en text, vilket är en fördel. Detta kräver dock att ikonerna används konsekvent, dvs samma ikon används för Nästa, Topp osv på alla sidor. Konsekvensen har naturligtvis andra fördelar, som att ge sidorna en identitet och att vävläsaren behöver ladda ner färre bilder. Om man bygger upp en knapprad kan man låta en ikon som pekar på sidan man är på vara kvar, men utan en länk.

ALT-texterna är extra viktiga här - det är inte roligt att se en räcka med [LINK] över hela sidans bredd. Ett problem här är att ikonerna ofta är relativt små, vilket innebär att om du ger ikonen attributen HEIGHT och WIDTH så kan det hända att ALT-texten inte får plats i en del vävläsare. En lösning är att slopa HEIGHT och WIDTH i dessa fall, en annan att skriva extremt korta ALT-texter, t ex > istället för Nästa. Den förra lösningen kan fungera bra om ikonerna är på botten av sidan. Den senare lösningen ger problem för röstläsare. Attributet REL kan troligen användas för att åtgärda detta, men det är endast en handfull vävläsare som stöder REL.

Prydnader

I många fall används bilder bara eftersom de gör sidan snyggare och mer attraktiv. I många fall är det inga problem så länge man tänker på ALT-texter och storleken på bilderna, men tyvärr finns det inga bra och effektiva sätt att använda bilder istället för punkter i listor eller som avdelare. Style sheets går att använda, men stödet för detta fortfarande dåligt.

ALT-texten

ALT-texten är ett av dina viktigaste verktyg för att skapa anpassningsbara vävsidor. Det är långtifrån endast blinda personer eller personer vars vävläsare inte kan visa bilder överhuvudtaget som drar nytta av dem. En stor andel användare av grafiska vävläsare surfar normalt med avstängd automatisk nedladdning av bilder (de flesta uppskattningar pekar på ungefär en tredjedel). En textläsare som Lynx kan hämta och spara bilder, eller visa dem i en separat bildläsare - som oftast är bättre på detta än en grafisk vävläsare.

Tyvärr är ALT-texten begränsad på många sätt, främst beroende på hur IMG-elementet är konstruerat. Det kan innehålla max 1024 tecken och, vad värre är, inte heller några HTML-element. Du kan däremot lägga hela bilden i ett eget element, t ex en rubrik, och ALT-texten kommer då att "ärva" det elementet. Det nya elementet OBJECT i Cougar löser de problemen, men det stöds mycket dåligt.

I vilket fall ska ALT-texten i nästan samtliga fall ersätta bildens funktion, inte beskriva bilden. För rent dekorativa bilder är ALT="" effektivt. För avdelare är ALT="----" bra (repetera -- tills du har 60 eller så), osv.

Fortsatt läsning

Objekt - ljud, Java mm

Ett stort användningsområde för HTML och väven som uppstått nyligen är som bärare av andra medier: ljud, animationer, filmer, Java-applets, JavaScript, ActiveX-kontroller osv osv. Jag kallar alla dessa gemensamt för objekt. Mycket av det som gäller för vanliga bilder gäller också för dessa, men jag ska poängtera några saker som blir extra viktiga.

Begränsat stöd

Många typer av objekt är beroende av insticksprogram (plug-ins), hjälpapplikationer eller så är de begränsade till endast ett fåtal antal plattformar. Många stänger dessutom av tekniker som Java och JavaScript av olika skäl. Du bör därför aldrig göra sidan beroende av de här teknikerna. Om ditt innehåll kräver att du använder objekt av något slag så bör sidan i övrigt meddela det på ett hövligt sätt. Att endast ha en text med Din vävläsare är skit eller motsvarande skadar i slutändan bara dig.

Gör istället ditt bästa för att övertyga besökaren att ditt innehåll behöver objektet. Många har t ex möjlighet att köra Java-applets, men har stängt av det av olika skäl, eller måste starta upp en annan vävläsare. Om du meddelar vad din applet gör så ger du dem anledning att sätta på det just för din sida. Samma angreppssätt kan också användas för andra typer av objekt.

Animationer och annat som rör sig

Vår hjärna är programmerad för att lägga märke till saker som rör sig. En sak som blinkar, ändrar form eller rör sig på något annat sätt får automatiskt en högre prioritet än något som inte gör det. En mycket högre prioritet.

Visst, det drar uppmärksamheten till sig, men din vävsida är inte en neonskylt som man ska lägga märke till när man går förbi. Din besökare tittar redan på din sida. Ditt mål är inte att dra uppmärksamheten till den, utan att kommunicera. Om då din animation eller blinkande text stör besäkaren och hindrar honom eller henne från att läsa texten i lugn och ro motverkar den snarast sitt syfte!

Animationer är inte fel, men ofta är en knappt märkbar animering eller en som bara går en gång effektivare. Kittla intresset och nyfikenheten, dränk det inte!

Ljud

Precis som bilder har ljud sin plats på väven. En vävsida som behandlar musikinstrument är knappast komplett utan exempel på hur instrumenten låter, en sida om en musikgrupp kan ha korta bitar ur gruppens låtar, och ofta kan man ha en enkel välkomsthälsning.

Men det är alltid besökaren som ska ha valet om han eller hon vill lyssna på ljudet! Om man surfar mitt i natten medan resten av familjen sover vill man knappast höra plötsliga eller höga ljud, likaså inte ifall man sitter i en gemensam labsal i en skola. Ge istället en enkel länk till ljudet eller ljuden.

Det finns naturligtvis fall då ljud som laddas ner automatiskt kan vara effektfulla. T ex kan en vävsida om The Beatles spela upp inledningsackordet från Help!. Men tänk då på att ljudet måste vara litet, så att det dyker upp kvickt. Ju kortare det är desto bättre. Sådana här exempel är också så gott som alltid undantagsfall.

Saker man bör undvika

Det jag sagt tidigare om att det här är en guide och inte en anvisning gäller extra mycket för denna del. De tekniker och metoder jag tar upp här är snarare sådana att de antingen kan göras bättre på andra sätt, eller så är de kända för att orsaka problem. Vill du använda dem så får du göra det, men mitt råd är att du vet exakt varför du gör det, och varför du behöver göra det, innan du sätter dig ner och gör det.

Rutor

Rutor (eller ramar som det vanligen kallas) har ett antal stora problem med dagens implementering, både designmässigt och hur de hanteras av vävläsarna. Det är inget fel på själva idén att ha flera samtidiga vyer av en datamängd, tvärtom, men det sätt som den realiserades på av Netscape är ett klassiskt fall av BAD (Broken As Designed).

Det största problemet är att URL:er slutar fungera - de pekar inte på den aktuella vyn utan den ursprungliga vyn - den som definierade rutorna. Det finns ingen relation från de enskilda sidorna tillbaka till den sida som definierade rutorna. Hanteringen av rutorna är också helt inriktad på visuell presentation helt utan plattformsoberoende.

Häftig färghantering

Svarta bakgrunder är ofta snygga, men är det lätt att läsa texten på dem? Använder man dessutom färgad text i någon mån blir det hela ännu mer svårläst, och personer som lider av någon sorts färgblindhet kan få svart text på svart bakgrund. Närmare tio procent av alla män lider av någon rödgrön färgblindhet i någon grad.

En vävsida ska kunna vara användbar i svartvitt precis som en färgfilm kan visas på en svartvit TV. Detta oavsett om begränsningen ligger i människan eller i maskinen.

Det man särskilt måste uppmärksamma är att kontrasten mellan texten och bakgrunden ska vara stor, att länkarna är lätta att urskilja och att du inte riskerar att göra någon del av texten osynlig. Det sista är en risk om man inte anger alla färger som sidan använder. Ange antingen inga färger, eller alla färger. Om du använder en bakgrund ska du se till att texten fortfarande är lättläst på bakgrunden, och att dina valda färger matchar den.

Föråldrad information

Som jag nämnde tidigare i den här stilguiden så finns det få saker som är så trista som länkar som inte leder någonstans. Men döda länkar är bara en liten del av problemet - en sida med föråldrad information är minst lika illa.

Det är minst lika viktigt att sidorna hålls uppdaterade och fräscha som att de finns överhuvudtaget. Tänk också på att hålla dem uppdaterade är ett stort arbete som tar tid. Det är ytterligare ett skäl till att starta smått - genom att utveckla vävplatsen i lugn takt inser man hur mycket underhåll den behöver, och sitter inte med en mängd sidor som ingen ordnar ta hand om.

Hårdkodade sidor

Redan tidigt med NCSA Mosaic började det dyka upp sidor som var noggrant grafiskt designade för att uppnå en viss presentation. De utgick ofta från att alla använde samma bredd på vävläsarens fönster, samma vävläsare och exakt samma typsnitt. Stämde inte detta blev allt en enda röra. I takt med att vävläsare som Netscape införde mer element för layout och att olika HTML-verktyg började marknadsföras som WYSIWYG har det här blivit allt vanligare.

Vanliga exempel på detta är att använda FONT-elementet för att skapa rubriker och bestämma typsnitt, och att använda tabeller för att skapa en specifik layout av sidan. Problemet med dessa sidor är att de slänger bort den viktigaste egenskapen en vävsida har: anpassningsbarheten.

Istället för att låta vävläsaren presentera sidan och dess innehåll i enlighet med de möjligheter den har så blir sidan i många fall endast användbar i specifika situationer. En hårdkodning innebär inte bara att man förutsätter en specifik vävläsare, utan vanligen också att automatisk laddning av bilder är på, att vissa typsnitt är installerade, en viss storlek på vävläsarens fönster, ett visst färgdjup på skärmen, en viss storlek på texten osv osv.

Resultatet är en sida som dels blir svårare att hålla aktuell och uppdaterad, dels inte blir användbar för många. Tänk också på att även om din vävläsare inte presenterar ett visst element som du vill ha det, så kanske en annan vävläsare presenterar det rätt, och några besökare gillar det sätt du ogillar.

Istället för att använda <BR> och en liten gif-bild för att skapa ett radindrag så klaga hos tillverkarna av vävläsaren att deras vävläsare inte kan anpassas för att visa <P> som du vill ha det! De flesta vävläsare är faktiskt bedrövliga på att presentera sidor, och att fixa designen i HTML-koden är en återvändsgränd.

Stora tabeller

En vanlig variant av de hårdkodade sidorna är de som utnyttjar en eller ett par stora tabeller för att visa innehållet. Detta innebär inte bara de vanliga nackdelarna med hårdkodade sidor, utan medför också problem som är inbyggda i hur tabeller hanteras i HTML.

Om man går till en sida som har en enda stor tabell, t ex Pagina med en grafisk vävläsare som stöder tabeller så ser du att även när en stor del av sidan har laddats ner, så syns det knappast någonting på skärmen! Orsaken är att tabellen i sin helhet måste vara tillgänglig för vävläsaren innan den kan rita upp den. Ingår det bilder kan det dröja ännu längre om de saknar attributen HEIGHT och WIDTH.

Det här är något som definitivt inte är lyckat. Visserligen är det ok om det dröjer med att sidan dyker upp i sin helhet, men det bör åtminstone dyka upp någon text inom tio sekunder. Kan din sida inte klara att få fram någon rubrik och lite text på den tiden är det risk att besökaren helt enkelt tröttnar.

I HTML 4.0 finns det en ny och förbättrad tabellhantering som låter vävläsaren rita upp tabellen inkrementellt, dvs allteftersom den kommer in. Men knappast någon vävläsare stöder detta idag, och en sådan tabell blir knappast heller lika snygg som en som ritas upp på konventionellt sätt. Den är därför knappast ett alternativ för layout idag.

Ett annat vanligt problem med att göra sidan som en tabell är att man tvingar besökaren att bläddra horisontellt för att läsa innehållet, något som är helt förkastligt. Låt din besökare själv bestämma vad som är lämplig fönsterbredd för honom eller henne!

Fortsatt läsning

Kontrollera sidorna

Det finns få saker som är så enerverande som att upptäcka att man måste göra om en vävsida när en ny version av ens vävläsare dyker upp. Till skillnad från människor är också datorer dumma, så gör du misstag i din HTML-kod kan du lätt göra hela sidan oläslig.

Validera din sida

Att validera en HTML-sida innebär att man kontrollerar om sidans HTML-kod är syntaktiskt korrekt och rätt stavat. Enkelt uttryckt gör man en grammatisk kontroll av HTML-koden i enlighet med ett antal formella regler.

Varje standard av HTML har sin egen uppsättning formella regler. Vilken standard som ska användas görs med en doctype-deklaration allra först i sidan - före <HTML>. Vilken dokumenttyp (DTD) du ska använda bestäms av vilka koder du använder, men det vanligaste är nog den för HTML 3.2 Wilbur: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">.

Om man ska rätta alla fel eller ej är en samvetsfråga. I vissa fall kan felaktig HTML vara önskvärd eller till och med nödvändig. En god tumregel är att om du vet vad som kommer att ge ett fel, varför det ger ett fel och varför du använder konstruktionen ifråga i förväg så kan det passera. Annars inte.

Låt en kompis kolla sidorna

Man blir lätt blind inför sina egna alster. Det är en gammal sanning för alla författare, och minst lika sann på väven. På det här sättet kan du undvika alla sorters fel i innehållet i dina sidor, både språkliga och faktamässiga.

Ett annat sätt är att lägga undan texten i några dagar och sedan gå tillbaka till den för att läsa om den och rätta felen. Det här är inte lika bra som att låta en kompis kolla dem, men det fungerar. Likaså är det ofta önskvärt med en stavningskontroll (det ska sägas att jag själv är en slarver vad gäller detta). HTML-koderna kan ställa till problem, men det går i nödfall att öppna sidan i sin vävläsare och sedan spara texten i en vanlig textfil.

Använd mer än en vävläsare

Olika vävläsare reagerar olika på olika konstruktioner. Detta gäller särskilt då de råkar ut för felaktig HTML, men också i andra sammanhang. I vilket fall är "Det fungerar bra i Netscape!" en helt oacceptabel ursäkt för att en besökare som använder en annan vävläsare inte kan använda sidan! Tänk också på att inte bara vävläsarnas namn skiljer dem åt. Olika versioner av samma vävläsare eller samma vävläsare på olika plattformar skiljer sig också, i vissa fall minst lika mycket.

Hur många vävläsare man ska använda är en svår fråga, men att testa dem på Netscape och Internet Explorer är som att säga "vi spelar båda sorters musik: country and western". Både Netscape och Internet Explorer bygger i hög grad på gamla NCSA Mosaic, och beteendet i Internet Explorer har till stora delar skapats efter det i Netscape.

Som minimum bör man ha kollat sidorna dels i en ren textläsare och en grafisk läsare, förhoppningsvis också med automatisk laddning av bilder avslaget. Opera är särskilt värdefull här då den dels har ett riktigt textläge, dels att buggarna i den är helt olika de som finns i Netscape och Internet Explorer, men den finns bara till Windows. Lynx är en ren text-läsare som däremot finns till i stort sett alla plattformar, även MacOS.

Någonstans mellan en kontroll i en vävläsare och en riktig validering kommer olika typer av heuristiska verktyg. De kallas ofta för linters efter programmet lint för att kontrollera C-kod. Det finns flera verktyg, men det vanligaste heter rätt och slätt Weblint. Tyvärr förekommer det en hel del förvirring om vad som är en validator och vad som är ett heuristiskt verktyg, och många del heuristiska verktyg marknadsförs även som validatorer. Det innebär inte att de inte är värdefulla, men man bör vara klar över skillnaden.

Fortsatt läsning

Källor och fortsatt läsning

Det här är en lista på några av de sidor jag använt som källmaterial och som stilguider för mina egna sidor. Av naturliga skäl är det bara ett axplock, men jag har försökt att plocka russinen ur kakan.

Artiklar, referenser och essäer

HTML 4.0 Kollat! Copyright © 1997 Karl-Johan Norén, kjnoren@hem3.passagen.se
Last modified/Senast ändrad: 09 Jan 1999