Web-sivuilla on yleensä virheitä. Virheiden määrää voi vähentää tarkistamalla sivuja erilaisilla ohjelmilla, jotka ovat paljon parempia huomaamaan esimerkiksi kirjoitusvirheitä tägeissä kuin ihmiset.
Jos teet useita samaa aihetta käsitteleviä sivuja, niissä esiintyy joitakin yhteisiä aineksia. Esimerkiksi kullakin sivulla on hyvä olla linkki pääsivulle, tekijän nimi yms. Lisäksi haluat ehkä panna aineiston saataville erilaisissa muodoissa, esimerkiksi sekä yhtenä isona dokumenttina että palasiin jaettuna taikka sekä normaalissa HTML-muodossa että muodossa, joka sopii (joissakin tilanteissa) paremmin paperille tulostettavaksi.
Erilaisissa Web-sivujen kirjoittamiseen käytetyissä ohjelmissa voi olla apuneuvoja mainittuihin tarkoituksiin. Mutta usein on tarpeen käyttää erilaisia muita välineitä, jotka voivat olla valmiita "työkaluohjelmia", itse jollakin skripti- tai ohjelmointikielellä kirjoitettavia koodinpätkiä, palvelimen suorittamia operaatioita jne.
Validointi tarkoittaa HTML-dokumentin tarkistamista ohjelmalla, joka tutkii, onko se HTML-kielen määrittelyn mukainen. Täsmällisemmin sanottuna validointi koskee kielen muotosääntöjä (syntaksia), jotka on tarkoin ja yksikäsitteisesti kuvattu SGML-kielellä ns. DTD:ssä (Document Type Definition). "Pakollisiin kuvioihin" HTML-dokumentissa kuuluva dokumenttityypin määrittely tarvitaan ennen muuta juuri tätä varten. Aiheesta kertoo lisää Jori Mäntysalon kirjoitus HTML-validaattori - mikä se on.
Kaikki validaattorit tekevät olennaisesti saman asian eli antavat virheilmoitukset muotosääntöjen vastaisista rakenteista. Ne saattavat poiketa toisistaan mm. sen suhteen, miten selkeitä ilmoituksia ne antavat.
Lisäksi validaattorissa saattaa olla mukana mahdollisuus tehdä haluttaessa joitakin muitakin tarkistuksia.
Tavallisimmin käytetyt validaattorit kansainvälisesti ovat WDG:n validaattori ja W3C:n validaattori. (Aiemmin oli käytettävissä myös LeHTori, jonka ilmoitukset olivat suomenkielisiä. Se on kuitenkin poistunut webistä eikä näytä olevan tulossa takaisin.)
Varoitus: On olemassa ohjelmia, joiden nimessä esiintyy sana "validator" mutta jotka eivät suinkaan ole validaattoreita vaan sekalaisia tarkistimia (esim. "CSE HTML Validator"). Validaattorin käsite on täsmällisesti määritelty, ja ohjelman kutsuminen joksikin, mitä se ei ole, ei ole kovin lupaavaa.
Validointi on erittäin hyödyllistä, mutta pelkän muodon tarkistamista.
Validointi esimerkiksi paljastaa tilanteet, joissa
img
-elementistä puuttuu alt
-määrite, mutta
se ei lainkaan puutu siihen, millainen määritteen arvo on.
(Arvo on validaattorin kannalta pelkkä merkkijono, ja kaikki siis kelpaa
sille - myös mitäänsanomattomat ja aivan harhaanjohtavat tekstit.)
Validointi ei koske edes kaikkia muodollisia asioita. Esimerkiksi
linkkien href
-määritteiden arvoja validaattori ei mitenkään
tutki edes sen kannalta, ovatko ne muodoltaan oikeita
URLeja (saati toimivatko ne).
Monenlaiset lisätarkistukset olisivat siis tarpeen. Valitettavasti kovinkaan hyviä yleisiä tarkistimia, jotka siis käsittelisivät validoinnin ulkopuolelle jääviä ongelmia, ei näytä olevan.
Linkkitarkistimista mainittakoon Windows-ympäristöön saatavissa oleva (maksuton) kuten Xenu's Link Sleuth (jolla voi tarkistaa kokonaisen "saitin", site).
Kannattaa muistaa, että mitkään tarkistimet eivät voi tarkistaa kaikkea. Esimerkiksi linkkitarkistin tarkistaa, että linkki viittaa saatavilla olevaan dokumenttiin eli käytännössä lähettää palvelimelle samanlaisen pyynnön kuin selain lähettää linkkiä seurattaessa, ja katsoo, tuleeko palvelimelta tieto siitä, että dokumentti on saatavilla. Tämä ei mitenkään välttämättä merkitse sitä, että linkin takaa löytyy se dokumentti, jonka joskus sieltä löysit! Sen sisältö on voinut täysin muuttua.
Sivujen esteettömyyttä (saavutettavuutta, accessibility) voi joissakin suhteissa tarkistaa ohjelmilla. Aiheesta kertoo Tieken esteettömyysopas.
Aivan toisentyyppinen tarkistus on oikeinkirjoituksen ja
muun kieliasun automaattinen tarkistaminen. Englannin kielen
kirjoitusvirheiden paljastamisessa voidaan käyttää hyvinkin
yksinkertaisia ohjelmia, esim. Unix-koneiden spell
tai
sitä kehittyneempi ispell
, jota periaatteessa
voidaan käyttää muillekin kielille. Mutta varsinaiseen korjauslukuun,
kieliasun tarkistuksesta puhumattakaan, tarvitaan kehittyneempiä
välineitä, jotka yleensä ovat maksullisia, esim.
Microsoft Word (jossa on kielentarkistustoimintoja) tai
(suomen kielelle)
Kielikoneen
WinMorfo ja
WinVirkku.
Ammattimaiseen tekstien tuottamiseen niiden hankkiminen voi kannattaa.
Ongelmaksi voi jäädä, että tarkistusohjelmat eivät välttämättä osaa
lukea HTML-muotoista dataa eivätkä ainakaan tehdä siihen korjauksia ilman,
että ne sotkevat HTML-merkkauksen.
Jos esimerkiksi käytät Wordiä HTML-dokumentin
kieliasun tarkistamiseen, kannattaa menetellä näin:
tee dokumentista erillinen kopio ja avaa se Wordillä (Word osaa kyllä
lukea standardi-HTML:ää); avaa erilliseen ikkunaan
esim. NotePadiin tai
Emacsiin
dokumentin varsinainen kopio ja tee korjaukset siihen.
Kannattaako sivulle panna jokin symboli tai
teksti merkiksi siitä, että se on validoitu tai muuten tarkistettu?
Varoittava
tositapaus on se, että erään validaattorin Web-osoite joutui
firmalle, joka harrastaa ihan muita asioita.
Tilanne oli kiusallinen monille Web-sivujen tekijöille, jotka olivat
panneet omille sivuilleen linkin osoitteeseen
http://www.webtechs.com/
merkiksi siitä, että sivut on validoitu,
koska linkki osoittikin pornosivuille. (Asia on nyttemmin korjattu.)
- Sivut kannattaa validoida, mutta asiasta ei silti tarvitse
tehdä numeroa sivuillaan.
Monet työtä säästävät välineet ovat sellaisia, että niiden käyttöön perehtymiseen kuluu paljon aikaa ja työtä. Tietokoneet ovat tästä malliesimerkki. "Käsin kirjoittaen olisit tehnyt sen jo." Hyötyä alkaa tulla vasta sitten, kun samantapaisia asioita tehdään usein.
Jonkinlaisen käsityksen tarjolla olevien työkalujen kirjosta antaa W3C:n sivusto World Wide Web and HTMLTools. Ja jotakin kertoo sekin, että sen pääsivu korostaa, että kyseessä on arkistosivu, jota ei enää päivitetä - ilmeisesti pidetään turhana yrittääkään pitää mitenkään ajantasaista listaa näistä työkaluista. (Osaa alasivuista on kyllä näköjään päivitetty melko hiljattainkin.)
On mahdotonta antaa kovinkaan hyviä yleisiä neuvoja työkalujen valinnasta, sillä tarpeet ja edellytykset vaihtelevat niin paljon. Seuraavassa on kuitenkin muutama yleinen suuntaviiva:
Seuraavassa esitetään esimerkkien avulla muutamia työkaluja, joita voi käyttää Web-sivujen tekemisessä.
Yksinkertainen tapa tehdä joukko sivuja, joilla on yhteisiä aineksia ja kenties samanlainen rakennekin, on tehdä sivurunko: Web-sivun "luuranko", joka sisältää sivujoukon yhteisen perusrakenteen mutta ei varsinaista asiasisältöä, joka on eri sivuilla erilainen. Sivurunko helpottaa sivujen tekemistä, kun voi aloittaa valmiista "pohjasta"; samalla se antaa sivuille tiettyä yhtenäisyyttä, joka voi paljonkin helpottaa niiden käyttöä. Sivurunkoa voidaan käyttää siten, että aina kun ruvetaan tekemään uutta sivua, tehdään sivurungosta kopio ja ruvetaan editoimaan sitä.
Runkotiedosto voisi olla vaikkapa seuraavanlainen:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<title></title>
<h2></h2>
<h3>Ainekset (määrät neljään annokseen)</h3>
<h3>Astiat</h3>
<h3>Valmistus</h3>
<h3>Tarjoilu</h3>
<p>Tämä dokumentti kuuluu
<a href="../henkkoht.html">Jukka Korpela</a>n
<a href="index.html">ruokareseptien kokoelma</a>an.
</p>
Kyseessä on tällöin runko, jota voisi käyttää ruokareseptien kirjoittamiseen. Huomaa, että runkoon sisältyy linkki tekijän kotisivulle sekä hakemistotiedostoon jossa on reseptien luettelo. Tällaisten linkkien tarve perusteltiin edellisessä luvussa
Sivurunko kannattaa suunnitella huolella. Sitä kannattaa myös
testata tekemällä ainakin muutama sen mukainen koesivu.
Jos oikeita sivuja tulevat tekemään eri ihmiset, kannattaa myös
testisivut teettää eri ihmisillä.
Yleensä testausvaiheessa havaitaan tarpeelliseksi muuttaa runkoa jossain
määrin. Jos myöhemmin, kun rungon mukaisia sivuja jo on tehty paljon,
havaitaan tarpeeelliseksi muuttaa runkoa, tilanne on hankalampi kuin
rungon muuttaminen suunnitteluvaiheessa. Mutta mahdotonta se ei toki
ole. Jos joka sivulla on vaikkapa kolme keskeistä linkkiä aivan
määrätyllä tavalla tehtyinä - siis suoraan rungosta
kopioituineina - niin kyseisen kohdan muuttaminen vaikkapa
lisäämällä niihin neljäs tai muuttamalla yhden nimi on suhteellisen
helppoa yksinkertaisella editointi- tai
skriptikielellä, esim. Unix-ympäristössä
"työkaluajattelun" mukaisesti vaikkapa
sed
-ohjelmalla ja shell-skriptillä.
Tehokkaampi väline on
Perl-kieli, jolla toisaalta on kokemattomankin melko helppo
tehdä yksinkertaisia muunnoksia.
Rungon muutettavuus edellyttää, että runkoon kuuluvia asioita eivät sivuntekijät ole omavaltaisesti tai vahingossa muuttaneet. Menettelytavat on siis syytä tehdä selviksi. Ja jotta tämä onnistuisi, on suunnittelutyö hyvä tehdä tarpeeksi laajapohjaisesti.
Esimerkiksi jos kymmeniä reseptitiedostojasi kirjoitettuasi huomaisit, että haluat muuttaa kaikki otsikot "Astiat" muotoon "Astiat ja muut välineet", niin tämä kävisi Perl Lessons -tutoriaalissa esitettyä esimerkkiä matkien Unixissa näin:
perl -e 's/Astiat/Astiat ja muut välineet/' -p -i.bak *.html
Usein kuitenkin halutaan tehdä niin, että monille sivulle yhteinen osa kirjoitetaan erilliseen tiedostoon ja sivuille itselleen kirjoitetaan vain viittaus tähän tiedostoon. Tällaista ns. include-piirrettä ei kuitenkaan HTML:ssä ole. Sen sijaan voidaan käyttää erilaisia esiprosessointiohjelmia, joita on monia erityyppisiä - kuriositeettina, mutta ihan mahdollisena käyttää, mainittakoon C-kääntäjän käyttö HTML-dokumenttien yhteydessä.
Esimerkiksi GTML on vanhahko mutta edelleen käyttökelpoinen esiprosessori. Sen käytön alkuun pääsee helposti, ja toisaalta voi sitten opetella myös vaativampia piirteitä, esimerkiksi makroja.
Periaatteessa esiprosessoinnin asemesta voi käyttää Server Side Include (SSI) -piirrettä, jos palvelin tukee sitä; yleensä SSI on kuitenkin turhan tehoton väline tällaiseen tarkoitukseen, koska se merkitsee sitä, että palvelin tekee esiprosessointia vastaavan toimenpiteen joka kerta, kun jokin selain tai muu ohjelma pyytää siltä kyseistä sivua! Aiheesta kertoo lisää Web Authoring FAQ:n kohta How do I include one file in another? Mutta SSI saattaa joissakin tilanteissa olla hyödyllinen, jos on tarvetta sisällyttää dokumenttiin osa, jonka jokin ohjelma tuottaa dynaamisesti sillä hetkellä, kun palvelin on vastaamassa selaimelle. Muun muassa siksi, että SSI on eri palvelinohjelmistoissa erilainen ja eri tavoin konfiguroitavissa, kannattaa lukea sitä koskevat paikalliset ohjeet. Hyvästä yleisesityksestä voi kuitenkin olla apua; ks. Art Sackettin "SSI for The Rest of Us" ja Pankaj Kamthanin Server-Side Includes and its Extensions. Suomeksi aiheesta kertoo esimerkiksi Kuopion yliopiston ATK-keskuksen ohje SSI, Server Side Includes -komennot. Myös Riku Nykäsen suomenkielinen juttu Common Gateway Interface sisältää SSI-osuuden. Jouni Heikniemi on kirjoittanut jutun Server side includet IIS-palvelimessa.
Esiprosessoinnin yksi ongelma on, että on muistettava käsitellä tiedosto(t) aina muutosten jälkeen, jotta muutokset tulisivat voimaan. Tätä voidaan helpottaa erilaisilla välineillä kuten komentotiedostoilla, jolloin esiprosessointi hoituu yhdellä komennolla, vaikka siihen sisältyisikin useita toimenpiteitä (kuten useiden ohjelmien ja komentojen suorittamista). Käytettävät välineet ovat käyttöjärjestelmäkohtaisia; Unixin osalta ks. Unix-oppaan lukua Komentotiedostot.
Etenkin jos jostakin aineistosta pitää tuottaa suuri määrä suhteellisen yksinkertaisia sivuja, kannattaa harkita niiden ohjelmallista tuottamista. Miltei mitä hyvänsä ohjelmointikieltä voidaan käyttää, mutta tietenkin ohjelmoinnin opettelu vaatii oman työnsä. Lisäksi kaikki kielet eivät ole kovin käytännöllisiä tällaisiin tarkoituksiin.
Luvussa Vaativampia taulukoita on muutamia suhteellisen yksinkertaisia Perl-ohjelmia sivujen (tai oikeammin sivun osien) generointiin. Erillinen dokumentti Kuvagallerian teko esittelee hiukan laajemman esimerkin: Perlillä kirjoitettu ohjelma, joka tekee yksinkertaisen sivuston, jossa kukin sivu sisältää yhden kuvan, sen selitystekstin ja eräitä peruslinkkejä.
Edellä kohdassa Pieni on kaunista neuvottiin jakamaan aineisto pienehköiksi sivuiksi. Mutta myös iso on kaunista. Oletetaanpa, että Webissä on esimerkiksi jokin oppikirjamainen esitys taikka kuvaus jonkin yhdistyksen toiminnasta kokonaisuutena taikka tiivistelmät yliopistossa tehdyistä väitöskirjoista. Sellaisen kokonaisuuden esittäminen yhtenä HTML-dokumenttina yhtenä tarjolla olevista vaihtoehdoista voi olla järkevää mm. seuraavista syistä:
Problematiikkaa "iso vai pieni" käsittelee hiukan tarkemmin luonnosmainen kirjoitukseni Creating and maintaining large Web documents.
Parasta siis on, jos aineisto on tarjolla sekä osiin jaettuna että "yhtenä klönttinä", ja mahdollisesti vielä muissa muodoissa, jotka voivat olla joihinkin tarkoituksiin sopivampia (esim. zipattu paketti, PDF-muoto tai paperitulostukseen sopiva PostScript-muoto tms.).
Ensisijaisena vaihtoehtona - johon esimerkiksi sivuista tiedotettaessa viitataan - on kuitenkin yleensä syytä pitää tarjolla osiin jaettua aineistoa, tarkemmin sanoen sen pääsivua (hakemistosivua).
Esimerkkejä vaihtoehtojen tarjoamisesta ovat HTML 4 -spesifikaation eri formaatit (ks. kohtaa Available formats) ja WDG's Distribution Page sekä minun kirjoittamani Nyysiopas.
Ei tietenkään ole kovin mielekästä ylläpitää samaa aineistoa kahdessa tai useammassa muodossa "käsin" eli tekemällä muutokset kuhunkin versioon erikseen. Valitettavasti tarjolla ei taida vielä olla helppokäyttöisiä, tavalliselle sivuntekijälle sopivia ohjelmatyökaluja, joilla "yhdestä klöntistä" voidaan automaattisesti tuottaa osiin jaettu aineisto tai kääntäen. ATK-gurut käyttävät usein Orbia tai WML:ää. Toisaalta hyvin yksinkertaisiin tilanteisiin voisi riittää yksinkertainen työkalu, esim. sentapainen kuin pieni Perl-skripti parin vaihtoehtoisen esitysmuodon tekemiseen esim. kysymys-vastaus-kokoelmasta.