kaxigt.com

Jag skriver om webben för webben

Att validera en sida

Postad: 21 december 2007 | HTML-guider | No Comments
Lästid: 3 minuter

Den här guiden är en första introduktion till web standards, tillgänglighet och användbarhet.

När man validerar sin sida så är det ofta i syftet att standardisera sajten så att den ska vara kompatibel i de flesta webbläsare. Men många glömmer att en väl utformad webbsida som följer web standards även tar hänsyn till såväl tillgänglighet som användbarhet för besökarna.

Det handlar således inte bara om att skapa en sida som är ”ren” utan några fel i kodningen. En valid sida kan trots detta varken vara 100% användarvänlig eller tillgänglig. Det handlar även om utseendet, design, och att ta hänsyn till funktionshindrade människor så de också har en möjlighet att få ta samma del av sidan som de utan funktionshinder.

Det är inte så lätt att ge avkall på script och vissa koder för att få en sida helt validerad kanske Du tänker nu. Men – det går. Faktiskt. Genom att ”peta” in några färdiga koder så förhindrar man webbläsarna att tolka scripten fel – och Du kan exempelvis behålla dina javascript.

Låt oss säga att du väljer att testvalidera din sajt och då upptäcker du en massa varningar trots att du kanske har använt ett WYSWYG-program eller är kunnig att på egen hand skriva dina anteckningar.

Hur kan det nu komma sig att det ändå är fel? Här är några exempel:

  1. Du använder fel doctype
  2. WYSWYG-programmen använder sig inte av standardiseringen som ”standard” utan ger endast var kod för sig. Det innebär att du kan få fler än 1 kod med exempelvis head – body attributet som då skrivs in på sidan.
  3. du har missat en ”alt” tag.
  4. du har glömt att sätta ut en sluttag eller slash.
  5. Du har glömt att avsluta ett eller fler stycken
  6. du använder dubbla attribut som exempelvis body eller head.
  7. css-koderna kan vara inkompatibla med xhtml-koden. Detta gäller framför allt de som tidigare använt en css-mall men övergått till att koda sidan enbart i css. Sluttaggar och andra attribut ser helt annorlunda ut, liksom att javascripten måste skrivas om då de inte alltid är kompatibla med en ren css-skapad sida.
  8. vanlig html-kod i löpande text är inte heller tillåten, exempelvis som att byta font, skapa en radbrytning som <br> (strict) eller att använda table-attributet <table > utan att definiera denna med summary.
  9. detta innebär i sin tur att du inte kan använda dig av target=”_blank” eller border=”0″ i koden för strict
  10. du blandar html-koder och css på samma sida.
  11. i xhtml får du inte använda versaler i koderna utan bara gemener
  12. Du använder fel semantisk struktur

Internet Explorer släpper dessutom ”igenom” många syntaxfel i koderna – så det är inte alls säkert att din sida ser likadan ut i andra webbläsare eller operativsystem som i din egen.

Dessutom finns det fler varianter idag än i dataålderns begynnelse. Därför har begreppet webstandard introducerats och kommit att bli allt vanligare. Man kan välja på olika alternativ men vanligast är transitional och strict. Det sistnämnda har lite mer stramare regler och det hörs ju redan på namnet.

Vill Du testa din sida?

Få bara inte panik när du ser resultatet. Se det istället som att du kan rensa sidan från en massa ”onödig” kod och därigenom underlätta uppladdningen av din sajt. Dessutom får du ju veta om koderna är fullständiga eller inte – och det är oftast av intresse om man vill ha en väl fungerande sida.

De som använder php-include bör uppmärksamma rad och kolumn – validatorn läser av hela sidan och den innefattar alla inklude vilket resulterar i att ni kanske inte finner den specifika raden i ert indexdokument. Kika då i närmaste include och räkna rader eller öppna källan och spara ned hela dokumentet i html-format. Räkna sedan raderna.

Man kan alltså inte ladda upp en includesida som main, footer eller header – och validera denna, validatorn läser enbart hela sidor. Det går även att kopiera sidkällan och klistra in den i ”input” om man inte använder sin URL.

W3C Markup Validation Service