cjohansen.no

Er validering verdiløst?

Det kan virke som at hver gang jeg nevner validering som noe positivt i mine skriblerier så er det noen som passer på å sette meg på plass og forteller meg hvor liten praktisk nytte validering har. Er validering helt ubrukelig? Har validering ingen verdi for besøkende?

Er validering et kvalitetsstempel?

Gjennom mitt foredrag på Webdagene 2007 og to innlegg på kuttisme.no har jeg pratet om kvalitetssikring av grensesnitt. I forbindelse med disse har jeg tatt opp validering som et verktøy for å kvalitetssikre en levereanse. Jeg har også foreslått at validering mot HTML 4.01 eller XHTML 1.0 bør være et krav i ethvert prosjekt der et webgrensesnitt skal implementeres.

En ting jeg ikke har påstått er at validering er et generelt kvalitetstegn. Det er ingen sammenheng mellom validering og godt eller dårlig design, brukervennlig eller ikke. Validering garanterer ikke en god tjeneste, og tilsvarende kan en løsning være god uten å validere. Et tilsvarende poeng er at en tjeneste ikke trenger å være tilgjengelig selvom man scorer bra mot Norge.nos kvalitetskrav eller WCAG: innholdet kan fortsatt være utilgjengelig fordi avsenderen ikke snakker brukerens språk eller lignende.

Stoler du på nettleserene? Og alle de andre klientene?

Hvis vi leverer kode som ikke validerer så leverer vi kode som ikke er i henhold til W3Cs publiserte standarder. På grunn av dette kan vi ikke ha noen forentning om hvordan en klient vil behandle koden. Som oftest går det greit ettersom nettlesere har god erfaring med dårlig HTML, og de er stort sett i stand til å "reparere" koden "on the fly". Men hvordan kan vi være sikker på at den ødelagte koden vår blir reparert på riktig måte? Det kan vi ikke, og ønsker vi full kontroll er det beste vi kan gjøre å produsere kode som validerer.

Dokumentstruktur som forventet grunnlag

Når design og interaksjon er implementert i CSS og Javascript er disse i høy grad avhengig av dokumentstrukturen vår. Hvis dokumentet ikke validerer kan det være at den faktiske dokumentstrukturen (etter at nettleseren har reparert koden) ikke er helt den vi samme som vi laget til å begynne med. Dette kan bety store problemer for CSS- og/eller Javascript-koden vår. I "beste" fall kan det bety at en egenskap blir stille borte. I verste fall kan det bety at hele siden kneler under et ødelagt design eller Javascript-bugs som gjør siden ubrukelig.

Når du leverer kode som ikke validerer fester du din lit til at nettleserene og andre klienter som skal bruke koden faktisk tolker koden riktig. Det blir som å formulere seg på en kronglete måte for så å håpe at mottakeren forstår hva du egentlig mener.

Har validering verdi for brukerne?

Martin Bekkelund har nylig skrevet at validering ikke har noen som helst verdi for brukerne. Jeg er ikke så sikker på om jeg er enig. Selvfølgelig - validering er ikke en tjeneste eller funksjon brukerne oppsøker nettstedet for å se i seg selv. Men, i følge eksemplene i avsnittet over er det tydelig at validering i enkelte tilfeller kan diktere brukerens opplevelse av nettstedet. Hvis et ødelagt dokument tegnes ut på en uleselig måte for brukeren så har det absolutt verdi for henne at siden validerer, enten brukeren er klar over grunnen eller ei.

Brukere med annet utstyr enn desktop-nettlesere

Det er ikke utenkelig at vi idag, 8 år etter at HTML 4.01 og XHTML 1.0 ble W3C-standarder får nye klienter som er avhengig av et velformet dokument for å vise en tjeneste. Dette er spesielt interessant for håndholdte enheter, og andre miljøer hvor små og enkle applikasjoner er viktig (en XML-parser til XHTML er langt enklere enn en HTML-parser som tolker og retter feil "on the fly"). For disse klientene er det viktig å validere, og brukeren har nytte av det.

Tilgjengelighet

Hvis du er opptatt av tilgjengelighet (noe du bør være dersom du jobber med nett), er det sen selvfølge å lage dokumenter som validerer. Et av de grunnleggende kravene i nevnte WCAG er å "bruke teknologi som er standardisert av W3C, og å bruke det riktig". Hvis du har brukere som er avhengige av spesiell tilrettelegging, noe du høyst sannsynligvis har, så mener ihvertfall W3C at disse brukerne har nytte av god semantisk HTML som validerer i bunnen.

Søkemotorer

Det er også flere som mener at søkemotorer foretrekker sider som validerer (fordi de også kan benytte enklere parsere enn dersom de må rydde opp i alle dokumentene).

Til slutt vil jeg si (som Martin Bekkelund også trekker frem) at utviklerne er de som oftest har størst utbytte av validering, og da som et arbeidsredskap. Men, det er ikke dermed sagt at det ikke er verdifullt også for brukerne dine. Flere gode grunner får du fra W3C.

Tweet this

Muligens relatert

• Hvor er din h1?
• Hva utgjør en god title-tag?

Kommentarer

1. Martin Bekkelund

   (http://www.bekkelund.net/)

   18. november, 16:40

   
   Poenget med min bloggpost var — som du også er inne på her — at validering ikke har noen verdi som en tjeneste for de besøkende. Ikke kan man se på validering som et kvalitetsstempel heller, ettersom elendige løsninger også kan validere.
   
   Jeg tror allikevel at jeg har vært for dårlig til å trekke frem at jeg er av den klare oppfatning av at all kode skal validere, og at det er svært viktig at den gjør det.
   
   Det jeg ville til livs med min artikkel var hvordan uerfarne kritikere alltid drar frem validering som det eneste suksesskriteriet for hvorvidt et nettsted er bra eller ei.

2. Christian

   18. november, 18:46

   
   Hei, Martin! Selvom jeg refererte til deg et par ganger er ikke dette innlegget ment som en kritikk mot deg eller ditt innlegg.
   
   Jeg er hjertens enig i at validering for seg selv ikke beytr noe som helst om noe som helst, men jeg syns det ofte er en nyttig indikator på teknisk kvalitet.
   
   Hvis noen ber meg bedømme teknisk kvalitet på en tjeneste starter jeg alltid med å validere forsiden og å strippe CSS for å kjapt få følelsen av om det er gjort med semantisk HTML eller ikke. Stryker tjenesten på disse to testene er det små sjanser for at jeg blir spesielt imponert under videre undersøkelser :)

3. jegern

   25. november, 13:30

   
   Hvordan skal webutviklere forholde seg til at det som er standard, validert kode likevel ikke vises likt i de viktigste nettleserne?
   
   Er du tilhenger av ulike stilsett for ulike nettlesere, if-tester inne i koden, eller rett og slett å la det skure så lenge det ser bra ut i IE, som tross alt har over 80% av markedet?

4. Christian

   26. november, 07:24

   
   Dette er en problemstilling som heldigvis er langt mindre nå enn for noen år siden, men som selvfølgelig vil bestå så lenge standardene videreutvikles.
   
   I min mening er det stort sett fullt mulig å få ting til å se likt (ikke nødvendigvis identisk) ut i de fleste nettleserene med samme stilsett for alle. Noen ganger må man prøve flere måter å løse samme problem på, men det går stort sett.
   
   Noen ting lar seg bare ikke løse på en pen måte med eldre IE-versjoner (transparent PNG-er for eksempel), og da bruker jeg kondisjonelle kommentarer: http://www.quirksmode.org/css/condcom.html
   for å inkludere eget stilsett til eksempelvis IE6 for å rette opp noen feil i den nettleseren.

Ny kommentar

Navn: *

E-mail: *

URL:

Kommentar:

Dette feltet er ment å beskytte cjohansen.no mot spam. Vennligst oppgi tallet 718 i feltet.

Noe HTML tillatt: strong, em, blockquote, pre, code, ul, ol og li. Lenker ikke tillatt, men URL-er autolenkes. Inline kode-eksempler med <code>, kodeblokker med <pre>.