Web-julkaisemisen opas

Tämä on Web-julkaisemisen yleinen opas, joka keskittyy niihin asioihin, joita kaikki tai ainakin useimmat Web-sivujen tekijät tarvitsevat. Pääpaino on tämän takia HTML-kielellä ja yleisillä suunnitteluperiaatteilla, mutta myös tyyliehdotusten (CSS) käyttöä kuvataan. Muista aiheista, esim. CGI ja JavaScript, pyritään antamaan yleiskuva, jonka pohjalta sivuntekijä voi päättää, kannattaako hänen perehtyä aiheisiin.

Lukijalta ei edellytetä muita esitietoja kuin se, että hän on ainakin jonkin verran lueskellut Web-sivuja eli "surffaillut" Webissä. Toisaalta tämä opas on melko laaja ja perusteellinen. Jos olet esimerkiksi etsimässä vain pikaista johdatusta HTML:ään, suosittelen Veppisivun tekemisen pikaohjetta.

Oppaan rakenteesta on erillinen kuvaus.

Tämän oppaan parhaiten ajan tasalla oleva versio ("taltiokappale", "master copy") on osoitteessa http://jkorpela.fi/webjulk/

Jambalaya: Miten teen Web-sivun

Teksti Webiin

Aloitamme sillä, miten julkaistaan pelkkää tekstiä Webissä. Kuulostaa vaatimattomalta, mutta tässä käsiteltäviä perusasioita tarvitaan muissakin Web-julkaisemisen muodoissa. Sitä paitsi jos jokin aineisto on jo olemassa pelkkänä tekstinä, tässä käsiteltävä tapa julkaista se on nopea. Kun se on tehty, voi sitten seuraavaksi miettiä, miten sen voisi julkaista myös muissa muodoissa.

Oletetaanpa, että minulla on ruokaresepti omassa tietokoneessani, kirjoitettuna jollakin yksinkertaisella editorilla, esimerkiksi Muistio eli NotePad tai Emacs; jos on käytetty tekstinkäsittelyohjelmaa kuten MS Word tai WordPerfect, oletamme, että olen tallentanut tiedoston pelkkänä tekstinä, toiminnon "Save As..." kautta. Reseptin sisältö ja muoto on tässä toistaiseksi epäolennainen. Kysymys on nyt vain siitä, miten saan tekstin Webiin. Mutta seuraavassa on havainnollisuuden vuoksi tekstin alkua:

Oletamme, että tekstit ovat tietokoneella luettavassa muodossa eli hienosti sanottuna digitaalisessa muodossa tai ne kirjoitetaan sellaiseen muotoon tietokoneohjelmalla. Pelkästään paperilla oleva teksti ehkä kannattaa yrittää saada digitaaliseen muotoon skannerilla käyttäen tekstintunnistusta (OCR). Ohjeet löytyvät skannerin manuaaleista. Menettelyn onnistuminen ja se, paljonko tulosta tarvitsee korjailla "käsin", riippuu mm. painoasun laadusta. Mahdollisesti teksti kannattaa tallentaa RTF-muodossa ja ehkä muuntaa siitä HTML-muotoon.

Tekstin kopiointi Webiin

Yleisesti sanottuna tekstin laittaminen Webiin käy näin:

  1. Kopioit tiedoston omasta koneestasi sellaiseen koneeseen, joka toimii Web-palvelimena (Web server). Yleisimmin kopiointi tehdään FTP-ohjelmalla. Siirtäessäsi teksti- tai HTML-tiedostoa huolehdi siitä, että FTP-ohjelma tekee siirron tekstimoodissa, jolloin se huolehtii merkkikoodien erojen vaatimista muunnoksista; tyypillisesti FTP-ohjelmaa määrätään tekstimoodiin käskyllä ascii. Kopiolle voidaan antaa eri nimi kuin alkuperäiselle. Palvelimeen laitettavan kopion nimen on hyvä olla yksinkertainen, mielellään vain pieniä englannin kielen kirjaimia a-z ja niiden jälkeinen eräänlainen tyyppimerkintä kuten pelkkää tekstiä sisältävälle tiedostolle .txt eli kaikkiaan esimerkiksi
    jamba.txt
    Nimeämisestä tarkemmin ks. Jakob Nielsenin kirjoitusta URL as UI. URLien pysyvyyden merkityksestä ks. Tim Berners-Leen kirjoitusta Cool URIs don't change.
  2. Tarvittaessa huolehdit siitä, että tiedoston suojaukset sallivat koko maailman lukea sitä.
  3. Voidaksesi sitten kertoa muille, miten he löytävät tiedostosi, sinun on hankittava tieto siitä, mikä sen Web-osoite eli URL on.

Kuulostaako kovin yleiseltä? Ja mukana on hämäriä teknisiä sanoja, joita et ymmärrä? Niinpä. Tarkemmat tiedot sinun täytyy hankkia sieltä, missä ne tiedetään.

Lue "paikalliset" ohjeet!

Aineiston laittamiseksi Webiin tarvitset yksityiskohtaiset ohjeet palveluntarjoajaltasi. Palveluntarjoaja, englanniksi (Internet) service provider, tarkoittaa organisaatiota, jonka tietokone- ja tietoliikenneresursseja käytät Internet-yhteyksissäsi. Suppeammassa merkityksessä kyse on kaupallisesta yrityksestä, joka tarjoaa resursseja maksua vastaan. Palveluntarjoajina voidaan pitää myös organisaatioita, jotka tarjoavat resurssejaan käytettäväksi maksutta, tavallisimmin pakkomainonnan kera. Usein niiden tarjoaman "palvelun" laatu ja luotettavuus vastaavat hintaa.

Esimerkkeinä siitä, millaisia nämä ohjeet voivat olla, mainittakoon seuraavat:

Valitettavasti palveluntarjoajien ohjeet ovat usein puutteellisia tai ainakin pinnallisia. Mitä teknisemmästä asiasta on kyse, sitä todennäköisemmin joudut itse perehtymään asiaan palvelinohjelmiston (Web server software, HTTP server) dokumentaatiosta. Toivottavasti palveluntarjoaja osaa edes kertoa, mikä palvelinohjelmisto on käytössä (nimi ja versionumero)! Jos ei, niin sen voi selvittää esimerkiksi Delorien sivulla HTTP Header Viewer olevalla lomakkeella. Lisäksi tarvitset tiedon siitä, mitä piirteitä ohjelmistossa on käytössä. Palvelinohjelmistot nimittäin voidaan asentaa eri tavoin, ottaen käyttöön tai jättäen pois erilaisia mahdollisuuksia. Esimerkiksi yleisimmässä palvelinohjelmistossa Apachessa on runsaasti tällaisia konfigurointimahdollisuuksia. Valitettavasti voi käydä niin, että joudut näitäkin asioita selvittelemään itse, kokeilemalla, toimiiko jokin palvelinohjelmiston dokumentaatiossa kuvattu piirre. (Silloin kannattaa testata sitä mahdollisimman yksinkertaisessa muodossa; muutenhan voi käydä niin, että piirre sinänsä toimii mutta tapasi käyttää sitä on väärä!) Eri palvelinohjelmistojen yleiskuvauksia ja alkuperäisdokumentaatioita löytyy WebServer Compare -sivuston sivun Server Directory kautta.

Mitä on saatu aikaan eli mitä on "pelkkä teksti" Webissä

Esimerkkidokumenttimme on osoitteessa http://jkorpela.fi/demot/jamba.txt ja se on siis pelkkää tekstiä (plain text).

Jos katsot esimerkkiä Web-selaimella, huomaat, että selain näyttää sen todellakin pelkkänä tekstinä yhtä ainoaa kirjasinlajia (fonttia) käyttäen. Kirjasinlaji on todennäköisesti tasalevyinen (monospace) kuten vanhimmissa kirjoituskoneissa: kaikki merkit (esim. M ja i) vievät yhtä paljon tilaa vaakasuunnassa. Tälle vastakohtana suhteellinen (proportional) kirjasinlaji on sellainen, jossa esim. M on selvästi leveämpi kuin i. Yleensä suhteellinen fontti on paljon miellyttävämpää lukea ja kauniimpaa.

Toisaalta teksti jakautuu eri riveille juuri sillä tavalla, kuin se alun perin tiedostoon kirjoitettiin. Lisäksi välilyönnit (blankot) säilyvät sellaisinaan. Täten tekstin muotoilu säilyy, mikä mahdollistaa esim. alkeellisen taulukoinnin. HTML-kielessä tilanne on yleensä aivan toinen: rivinvaihdot ja sananvälien leveydet määrää selain muotoillessaan tekstiä näytölle, ja taulukointiin käytetään (paljon kehittyneempää) erityistä taulukkorakennetta. HTML:ssä voidaan kuitenkin tilapäisesti siirtyä "pelkkää tekstiä" -muotoon pre-elementillä.

Pelkkä teksti on siis "valmiiksi muotoiltua" (preformatted). Tämä merkitsee joustamattomuutta siinä mielessä, että tekstin leveys ei mukaudu selaimen ikkunan leveyteen. Lisäksi teksti on melko tylsän näköistä lukea. Toisaalta se on luettavissa käytännöllisesti katsoen millaisella laitteella tahansa, kunhan vain näyttöalueen (ikkunan) leveys riittää.

Web-osoitteet ja muut URLit

Lyhenne URL johtuu sanoista Uniform (tai alkujaan Universal) Resource Locator ja tarkoittaa yleisesti osoitetta, joka viittaa Internetissä olevaan "resurssiin", joka voi olla esimerkiksi tekstidokumentti, HTML-dokumentti, kuva, äänite tai ohjelma. Tavallisimmin URL viittaa Webissä olevaan "resurssiin", jolloin sitä voi kutsua Web-osoitteeksi. Yleisemmin URL voi viitata myös vaikkapa FTP-palvelimeen.

Edellä esimerkkinä mainittu URL eli http://jkorpela.fi/demot/jamba.txt on melko tyypillistä muotoa. Se voidaan jakaa osiin seuraavasti:

http:// Alkuun kuuluva "pakollinen kuvio". Sitä ei pidä jättää pois osoitetta ilmoitettaessa, vaikka monet selaimet löytävät sivun ilman sitäkin silloin, kun osoite näpytellään suoraan selaimelle.
jkorpela.fi Tämä on sen Web-palvelimen Internet-nimi, jossa dokumentti on. Nimi jakautuu kenttiin, joilla on omat merkityksensä, mutta käytännössä riittää, että saat omalta palveluntarjoajaltasi tiedon siitä, mikä käyttämäsi palvelimen nimi on.
/~jkorpela/ Tämä kertoo dokumentin sijainnin palvelimessa. Tämä osa saattaa alkaa muotoa /~käyttäjätunnus/ tai /u/käyttäjätunnus/ tai /home/käyttäjätunnus/ olevalla jaksolla, jolloin se yleensä viittaa tietyn käyttäjän sivuihin. Se, että tilde-merkki ~ on usein otettu osaksi URLien rakennetta, on valitettavaa, koska tämä merkki aiheuttaa monenlaisia sotkuja. Sen asemesta voidaan käyttää merkintää %7e, mutta kokemus on osoittanut, että sekin usein tulkitaan väärin. Toivottavasti et joudu tildesotkun kanssa tekemisiin.
jamba.txt Tämä on tiedoston nimi. Nimen loppuosalla kuten .txt ei periaatteessa ole mitään erityistä merkitystä, mutta käytännössä Web-palvelimet on yleensä ohjelmoitu niin, että ne lähettävät dokumentin mukana tiedon siitä, mitä ns. mediatyyppiä se on. Erityisesti tiedoston nimen loppu .txt on useimmille Web-palvelimelle kehotus lähettää tieto siitä, että dokumentti on pelkkää tekstiä (englanniksi plain text).

Jos URLin lopussa on vinoviiva, se yleensä tarkoittaa sitä, että URL viittaa hakemistossa olevaan oletustiedostoon. Esimerkiksi http://jkorpela.fi/ sattuu tarkoittamaan samaa kuin http://jkorpela.fi/index.html, kuten kohdassa Oletustiedostot tarkemmin kerrotaan. Lopussa oleva vinoviiva ei tällöin suinkaan ole tarpeeton, vaikka URL ehkä toimii ilman sitäkin.

Kirjoitettaessa URL esimerkiksi mainokseen, paperille, meiliviestiin tms. on pyrittävä välttämään sen jakamista tai jakautumista eri riveille. Erityisesti mahdollisen yhdysmerkin kohdalta jakaminen on paha juttu, koska silloin lukija ei tiedä, kuuluuko yhdysmerkki itse URLiin. Etenkin meilissä ja nyyseissä on pyrittävä siihen, että URLin molemmin puolin on joko rivinvaihto tai välilyönti, jotta olisi selvää, mihin URL loppuu. Tarvittaessa pitää rikkoa suomen kielen sääntöjä esim. jättämällä virkkeen lopusta piste pois tai kirjoittamalla välilyönti URLin ja sitä seuraavan välimerkin väliin. - Jos URLin oikea muoto tuntuu "liian tekniseltä", niin esim. mainoksessa voi korostaa sen keskeistä viestiä vaikkapa lihavoinnilla ja poikkeavalla värillä:
http://www.ytv.fi

Syventävää lisätietoa URLeista on oppaan Learning HTML 3.2 by Examples. kohdassa URLs.

Web-sivuilla voidaan useissa tapauksissa käyttää myös suhteellisia URLeja, jotka ovat lyhyempiä kuin edellä kuvatut ns. absoluuttiset URLit. Ne ovat eräänlaisia lyhennemerkintöjä, ja perehdymme niihin linkkien yhteydessä.

Entä muut muodot? Esmes Word?

Samaan tapaan kuin pelkkää tekstiä sisältävän tiedoston voit laittaa Webiin myös esimerkiksi MS Wordillä kirjoitetun, erilaisia muotoiluja sisältävän dokumentin. Silloin on FTP:n käytössä muistettava ennen siirtokäskyä kertoa, että siirrettävä aineisto on ns. binaaridataa; tämä tehdään FTP-ohjelmassa käskyllä binary tai vastaavalla. Word-dokumentin sisältävän tiedoston nimi loppuu yleensä .doc, ja tämä on syytä säilyttää tiedostoa Web-palvelimeen kopioitaessa. Useimmat palvelimet osaavat silloin lähettää selaimelle tiedon siitä, että kyseessä on Word-dokumentti. Joskus tässä menee jotain pieleen, ja silloin on syytä perehtyä WDG:n Web Authoring FAQ:n lukuun Other Media. Suomeksi aiheeseen liittyvää perustietoa on dokumentissani Mediatyypit Internetissä, erityisesti Webissä. Mutta olennaisinta asiassa on saada selville palvelinkohtainen tapa ratkaista kyseinen ongelma.

Jos aineisto on valmiiksi Word-muodossa, niin edellä kuvattu menettely on nopea ja yleensä helppo, ainakin jos joku on näyttämässä, miten se tehdään. Yksinkertaisimmillaan kyse on vain yhden tiedoston kopioinnista sopivaan paikkaan. Mutta olennaisena rajoituksena on, että Word-dokumentit ovat vain sellaisten käyttäjien luettavissa, joilla on itsellään Word-ohjelma tai jokin muu ohjelma, joka pystyy näyttämään Word-dokumentteja, esimerkiksi ns. Word viewer. Esimerkiksi monet hakujärjestelmät eivät ymmärrä Word-muodosta! Lisäksi Word-muoto on joustamaton eikä mukaudu käyttäjän selaimen kokoon eikä käyttäjän parhaina pitämiin muotoiluasetuksiin kirjasinlajien (fonttien) ynnä muun osalta.

Word-dokumentteihin voidaan kyllä kirjoittaa linkkejä, jotka viittaavat muihin dokumentteihin (sen lisäksi, että Word-dokumentteihin voidaan viitata linkeillä).

Erityisesti on syytä varoittaa seuraavasta: Wordissä, Excelissä ja useissa muissa ohjelmissa on sellainen toiminto kuin "Save as HTML", "tallenna Web-sivuna" tms. Jälki on yleensä kelvotonta ja siitä voi olla työlästä muokata kunnollista. Ohjelmat nimittäin kirjoittavat tuottamansa "HTML:n" täyteen kummallista merkkausta, joka yrittää kömpelöillä tekniikoilla säilyttää ulkoasun, esimerkiksi tekstin fontin, taulukon solujen leveydet tarkoin sellaisina, kuin ne ovat sattuneet olemaan dokumentin kirjoittajalla. Kunnollinen muuntaminen HTML-muotoon esim. Word-muodosta HTML-muotoon on usein parasta tehdä niin, että ensin tallennetaan dokumentti pelkkänä tekstinä ja siihen sitten lisätään yksinkertainen HTML-merkkaus dokumentin tarkoitetun tai oletetun rakenteen mukaan. Tosin jos Word- tms. dokumentissa on paljon kursivointeja, lihavointeja ym. tekstin seassa, niin saattaa olla nopeampaa tehdä muunnos Word-muodosta HTML-muotoon RTF-muodon kautta. Vielä yksi mahdollisuus on käyttää HTML-Kit-ohjelmaa, jossa on erityinen toiminto Strip surplus tags in Word 2000 pages.

Excel-taulukon taas voi tallentaa ns. tab separated values -muodossa, jossa alkioiden välissä on tabulointimerkit; tällainen muoto on melko helppo muuntaa HTML-taulukoksi.

Melko yleinen muoto on PDF. Sitä käytetään etenkin laajojen, kirjatyyppisten aineistojen tarjoamiseen Webissä joko yksinään tai vaihtoehtona HTML-muotoiselle versiolle. Etuna ja haittana on, että PDF-muoto "kuljettaa mukana" varsin tarkkaa kuvausta dokumentin esitysasusta. Täten se on samalla tavoin joustamaton kuin esim. edellä käsitelty Word-muoto tai Wordin tuottama "HTML"-muoto mutta ei sentään yritä olla muuta kuin on. PDF:ää käytetään etenkin paperille tulostettavaksi sopivan vaihtoehdon tarjoamiseen. Yksi haitta on, että PDF-muotoinen versio on melko iso, tyypillisesti 4 - 6 kertaa isompi kuin vastaava HTML-versio.

HTML on kuitenkin yleensä paras. Miksi?

Web-dokumenttien luonnollisin muoto on HTML-muoto. Se on tarkoitettu esitysmuodoksi, joka on riippumaton käytettävistä laitteista ja ohjelmista ja joka muun muassa automaattisesti mukautuu selaimen ikkunan kokoon ja käyttäjän fonttivalintoihin. Käyttäjä ei tarvitse muuta ohjelmaa kuin valitsemansa Web-selaimen.

HTML-muotoinen dokumentti sisältää tekstin lisäksi joitakin erityisiä merkintöjä, jotka osoittavat, mikä teksti on otsikkoa, mikä listaa, mikä korostettua jne. Erityisillä merkinnöillä, merkkauksella (englanniksi markup), voidaan dokumenttiin liittää myös mm. kuvia ja viittauksia eli linkkejä muihin dokumentteihin. Näillä yksinkertaisilla perusvälineillä voidaan toteuttaa hyvinkin monipuolisia Web-sivuja.

Jos haluat nopeasti laittaa Webiin dokumentin, joka sinulla on pelkkänä tekstinä, mutta aiot myöhemmin muuntaa sen HTML-muotoon, lue tätä koskevat ohjeet liitteestä Pelkän tekstin esittäminen muodollisesti HTML-dokumenttina.

Rakennetta mukaan (HTML)

Sisällys

Mikä HTML on?

HTML on lyhyesti sanottuna eräs rakenteinen dokumenttien muoto, joka on käsiteltävissä mitä erilaisimmissa tilanteissa, kuten näytettävissä isolla tai pienellä kuvaruudulla, esitettävissä ääneen tai sokeainkirjoituksella ja analysoitavissa ohjelmilla, jotka laativat tietokantoja dokumenttien sisällöstä. HTML-dokumentti sisältää tekstiä, rakenteen osoittavaa merkkausta (esim. <h2>Rakennetta mukaan (HTML)</h2> merkkaa tekstin 2. tason otsikoksi) sekä erityyppisiä viittauksia muihin dokumentteihin, jotka voivat olla myös esim. kuva- tai äänidataa. HTML:n yksityiskohtainen kuvaus sisältyy HTML 4 -spesifikaatioon.

HTML:ää kutsutaan usein kieleksi (language), tarkemmin sanoen merkkauskieleksi (markup language); itse nimi HTML johtuu alun perin sanoista HyperText Markup Language. ATK-alalla käytetty kieli-nimitys on usein varsin harhaanjohtava, etenkin, jos HTML sekoitetaan ohjelmointikieliin tms. Selvempi on siis puhua HTML:stä tiedostomuotona tai tarkemmin sanoen dataformaattina, jossa tekstin oheen on liitetty sen rakennetta osoittavia merkintöjä.

Tarkkoja ollaksemme HTML:n uusin virallinen versio on XHTML 1.0. Kyseessä on kuitenkin vain HTML 4:n uudelleenmäärittely käyttäen XML-metakieltä; itse kielen sisällön osalta se viittaa edellä mainittuun HTML 4 -spesifikaatioon. Tähän sisältyy lähinnä joukko rajoituksia, kuten se, että jotkin asiat pitää kirjoittaa pienin kirjaimin, kun ennen saattoi käyttää isojakin. XML:stä kertoo esimerkiksi Jouni Heikniemen juttu Mikä on XML?

Virallisin tietolähde HTML:ää koskevissa asioissa on W3C:n HTML-aiheinen sivusto, josta siis kannattaa tarkistaa kulloinkin tilanne, jos epäselvyyttä syntyy. HTML:stä olemassa myös virallinen kansainvälinen standardi, nimittäin ISO 15445, joka on määritelty HTML 4.0:n Strict-version osajoukkona; sen käytännön merkitys lienee varsin pieni. Ja mainitaksemme asian, joka vähentää sekavuutta: erinomainen HTML 4:n kuvaus, joka on monin osin helppolukuisempi kuin virallinen spesifikaatio, on WDG:n HTML 4.0 Reference. Tosin se on HTML 4.0:n tasolla, kun uusin versio on 4.01, mutta erot ovat melkoisen pieniä.

HTML:n luonteen ja mahdollisuuksien ymmärtäminen edellyttää, että nähdään, miksi HTML on suunniteltu sellaiseksi kuin on - jossakin mielessä hyvin alkeelliseksi ja rajoittuneeksi. Muutoin sen monet vahvuudet näyttävät heikkouksilta ja puutteilta. Niinpä tämä luku alkaakin kuvauksella siitä, mitä HTML:n yksinkertaisuus mahdollistaa.

Johdanto: esimerkkejä saman jutun eri esitysasuista

Muunnamme edellä mainitun reseptitekstin HTML-muotoiseksi dokumentiksi. Tässä vaiheessa ehkä jo haluat vilkaista, miltä tulos näyttää selaimellasi; se on osoitteessa http://jkorpela.fi/webjulk/jambalaya.html
Seuraavassa on lisäksi kaksi esimerkkiä siitä, miltä dokumentin alku saattaa näyttää muilla selaimilla. Tässä on tarkoituksellisesti valittu selaimen ikkuna melko kapeaksi. Vasemmalla on esitysasu Opera-selaimella eräin asetuksin, oikealla taas Netscape 4:n käyttämä esitysmuoto.

[Esimerkkidokumentti Operalla katsottuna [Esimerkkidokumentti Netscapella katsottuna

Kuvat havainnollistavat sitä, että HTML-dokumentti mukautuu erilaisiin esitystilanteisiin, esimerkiksi erilevyisiin ikkunoihin. Selaimet saattavat esittää esimerkiksi otsikot ja luetelmat ulkonaisesti eri tavoilla. Kirjasinlajit ja -koot voivat vaihdella, samoin sisennykset, värit jne.

Seuraavassa on vertailun vuoksi sivun alkuosan esitys suunnilleen sellaisena, kuin eräs ensisijaisesti tekstipohjaiseen selailuun suunniteltu ohjelma, Lynx, sen näyttää: 

                           Jambalaya suomalaiseen makuun à la Yucca (p1 of 2)

Jambalaya suomalaiseen makuun à la Yucca

   Tämä on miedohko, suomalaiseen makuun sopiva muunnelma jambalayasta. Tässä
   se valmistetaan kahdessa eri astiassa siten, että ruuan perusosa on
   lastenkin mieleen ja toinen osa sisältää voimakkaammasta mausta pitäville
   lisän, joka voidaan yhdistää perusosaan lautasella.

  Ainekset (määrät neljään annokseen)

     * 2 dl pitkäjyväistä riisiä (risottoriisiä)
     * 2 sipulia

Ja vielä yksi esimerkki: kuva siitä, miltä sivun alku voisi näyttää WebTV:ssä (näyte on tehty WebTV:tä simuloivalla PC WebTV Viewer -ohjelmalla):
(Teksti isolla, TV-ruutuun sopivalla fontilla, otsikot vielä isommalla.)

Jokin muu selain voisi esittää tekstin kirjasinlajien suhteen vielä karummin, ilman lihavointejakin, mutta esittäen eritasoiset otsikot eri väreillä. Vielä yhtenä tapana esittää HTML-dokumentin voi mainita ääneen lukemisen, jolla on suuri merkitys näkövammaisille. Ja eikö olisi mukavaa, jos voisit käskeä "selaimen" lukemaan sinulle reseptiä ääneen, kun teet sen mukaan ruokaa? Tietenkin niin, että voit käskeä sitä pitämään taukoa.

Viime kädessä on jokaisen lukijan tai katsojan päätettävissä, miten haluaa selaimen muotoilevan dokumentit, joita hän katselee. Hän voi valita itseään miellyttävän kirjasinlajin (niistä vaihtoehdoista, joita hänen koneessaan on), asettaa kirjasinkoon sopivaksi, määrätä taustavärin jne. - tietenkin niissä puitteissa, jotka käytettävä laite ja ohjelma tarjoavat.

Miten mukautuvuus saavutetaan

Miten edellä havainnollistettu on saavutettu? Yksinkertaisuudella ja loogisuudella. HTML-dokumentti sisältää varsinaisen tekstin lisäksi merkintöjä, jotka mm. ilmoittavat eri tekstipalasten rakenteellisen aseman - puuttumatta mitenkään siihen, mikä niiden ulkoisen esitysasun pitäisi olla.

Seuraavassa käsittelemme muutamia keskeisiä edellä mainituista merkinnöistä eli merkkauksesta (markup). Sitä ennen kuitenkin huomautus: Mukautuvuus ei toki ole ehdotonta. Esimerkiksi ikkunaa ei voida supistaa mielivaltaisen kapeaksi ilman, että luettavuus kärsii vakavasti. Riippuu jutun rakenteesta, missä määrin se asettaa joitakin vähimmäisvaatimuksia. Nämä vaatimukset kannattaa tietysti pitää niin vähäisinä kuin mahdollista. Mutta esimerkiksi tällä sivulla on edellä esimerkkikuvia, jopa kaksi kuvaa rinnakkain (taulukossa). Tämä tekee väistämättä lukemisen kapeasta ikkunasta hankalaksi, koska käyttäjä voi joutua "skrollaamaan vaakasuorassa" nähdäkseen kuvat kokonaan. Aiheesta on hiukan lisää WDG:n Web Authoring FAQ:n kohdassa For what screen size should I write?

Yksinkertainen mutta tärkeä osa mukautuvuutta on kappaleiden muotoilu. Kun selain käsittelee dokumentissa olevan tekstikappaleen, se ei kiinnitä huomiota siihen, miten teksti jakautuu eri riveille HTML-dokumentissa. Rivijaolla siinä ei ole mitään tekemistä sen kanssa, miten teksti rivittyy kuvaruudulle tai paperille. Sen sijaan selain sisäisesti jäsentää tekstin sanojen jonoksi ja "latoo" tekstin niin, että kullekin riville tulee sen verran sanoja kuin sille mahtuu. Tämä tietenkin merkitsee, että käyttäjän kannattaa pitää selaimen ikkuna niin leveänä, että teksti on mukavaa lukea.

Tarkkaavaisen lukijan mieleen ehkä tulee parikin kysymystä. Eikö olisi parempi, että käyttäjä voi säätää tekstipalstan leveyden pienemmäksi kuin ikkunan leveys? Silloinhan sivu, jolla on esim. leveitä kuvia tai taulukoita, olisi paremmin luettavissa. Ja eikö olisi parempi, että selain jakaisi pitkiä sanoja eri riveille? Molempiin kysymyksiin vastaus on, että niin olisi, mutta toistaiseksi niihin ei juurikaan ole toimivia teknisiä ratkaisuja.

Peruskäsitteet: elementit ja tägit

Esimerkkidokumentissamme pääotsikko on merkitty seuraavasti:

<h1>Jambalaya suomalaiseen makuun à la Yucca</h1>

Tämä ilmoittaa, että kyseessä on 1. tason otsikko, englanniksi heading. (Otsikkotasoja käsitellään seuraavassa alaluvussa.) Merkintä <h2> eli h2-elementin alkutägi aloittaa rakenteen ja merkintä </h2> eli kyseisen elementin lopputägi lopettaa sen. Niiden välissä on elementin sisältö. Yleisesti HTML:ssä elementti koostuu alkutägistä, elementin sisällöstä ja lopputägistä. (Tähän on muutama poikkeus: eräät elementit kuten br koostuvat pelkästä alkutägistä. Nämä ns. tyhjät elementit ovat HTML 4.0:ssa seuraavat: area, base, basefont, br, col, frame, hr, img, input, isindex, link, meta, param.)

Otsikkotekstissä esiintyvän aksentillisen kirjaimen à tuottamista käsitellään jäljempänä kohdassa "Ääkköset" ja muut ISO Latin 1 -merkit.

Keskeisimpiä elementtejä

Esimerkkidokumenttimme varsinaisessa sisällössä tulemme toimeen aivan muutamalla elementtityypillä:

h1
ensimmäisen tason otsikko (heading)
h2
toisen tason otsikko
h3
kolmannen tason otsikko
p
kappale (paragraph)
ul
luetelma eli "järjestämätön" lista (unordered list)
ol
numeroitu eli "järjestetty" lista (ordered list)
li
listan alkio (list item)

Kaikki nämä elementit ovat samaa muotoa, kuin edellä esitettiin: alkutägi, sisältö, lopputägi.

Näistä ul- ja ol-elementit ovat sikäli muista poikkeavia, että niiden sisältönä ei ole tavallista tekstiä vaan sisältö koostuu li-elementeistä - joiden sisällä sitten on tekstiä. Esimerkki:

<ul>
<li>iso paistinpannu, miel. korkealaitainen ja kannellinen</li>
<li>keskikokoinen paistinpannu.</li>
</ul>

Tässä on yksi ul-elementti, jonka sisältönä on kaksi li-elementti. Siis luetelma, jossa on kaksi alkiota.

Lopputägi ei useinkaan ole pakollinen. On kuitenkin helpompi opetella kirjoittamaan aina lopputägi kuin opetella melko mutkikkaat säännöt siitä, milloin sen saa jättää pois ja milloin ei. Sitä paitsi XHTML:ssä lopputägi on pakollinen.

Nyt voitkin rauhassa tutustua esimerkkidokumentin varsinaiseen sisältöön HTML-koodina. Se on osoitteessa http://jkorpela.fi/webjulk/jambabody.html, ja alkaa seuraavasti:

Erilaisia listoja (luetelmia)

Edellä kuvattiin lyhyesti eräs listarakenne, ul-elementti. Se sopii hyvin moniin tarkoituksiin ja vastaa "ranskalaisten viivojen" käyttöä, paitsi että selain tyypillisesti ei käytä viivoja vaan pallukoita. Kannattaa kuitenkin katsoa, missä yhteyksissä luetelmia käyttää. Jos luetelma olisi lyhyt, voisi olla sujuvampaa kirjoittaa se normaaliksi tekstiksi. Vertaa seuraavia:

Paraguayn rajanaapurit:

  • Argentiina
  • Bolivia
  • Brasilia

Paraguayn rajanaapurit ovat Argentiina, Bolivia ja Brasilia.

Muita vaihtoehtoja luetelmien esittämiseen ovat

Valinta näiden välillä on usein makuasia ja voi riippua myös käytännön näkökohdista kuten siitä, millaisena selaimet oletusarvoisesti esittävät eri rakenteet. Erityisesti huomattakoon, että määritelmälistan tyypillinen esitysasu sopii huonohkosti lyhyiden määritelmien esittämiseen.

Jos vaihtoehtojen moninaisuus hämää, niin voi noudattaa yksinkertaista sääntöä: luetelma ul-elementiksi, ellei ole ilmeistä syytä, miksi se olisi huono ratkaisu.

Dokumentin kirjoittaminen

Sisällys

Yksinkertainen perusrakenne

Edellä esitellyillä elementeillä voi jo tehdä kiinnostavan dokumentin, jos vain on kiinnostavaa asiaa ja taitoa esittää itse asia. Lisäksi voit aivan hyvin kirjoittaa jutun ensin yksinkertaisella tavalla ja sitten miettiä parannuksia esitystapaan (esim. sanojen korostamista). On paljon helpompi kehitellä yksinkertaista rakennetta hienommaksi kuin tehdä mitään järkevää mutkikkaalle rakenteelle, joka on tehty hätäisesti ja puutteellisin tiedoin. Lisäksi melko yksinkertainen rakenne on yleensä paras myös lopullisena rakenteena.

Ei jutussa välttämättä tarvitse olla sen kummempaa HTML:ää kuin kappale- ja otsikkoelementtejä. Kirjoita kukin tekstikappale tägien <p> ja </p> väliin ja kukin otsikko tägien <hn> ja </hn> väliin; tässä n on otsikon taso (1, 2, 3 tai 4). Jos on selviä luetelmia, niin ne esitetetään ul- tai ol-elementteinä. Tällainen rakenne on jo huomattavasti parempi kuin Web-sivuilla keskimäärin on!

Asiaan käsiksi - miten Webissä kannattaa asiat esittää

Kirjallisen ilmaisun yleisten periaatteiden ohella kannattaa ottaa huomioon, että Web välineenä poikkeaa esimerkiksi kirjoista ja lehdistä. Joissakin suhteissa se tarjoaa paljon suurempia mahdollisuuksia, joissakin taas vakavia rajoituksia.

Kuvien käyttöä käsitellään jäljempänä erikseen. Sivut on syytä suunnitella niin, että ne toimivat myös ilman kuvia. Kun näin tehdään alusta alkaen, saadaan myös nopeammin aineisto Webiin jossain muodossa, ja sitten voidaan ruveta tekemään lisäyksiä.

Jakob Nielsen esitti jo vuonna 1997 hyviä keskeisiä periaatteita Web-sivujen tekemisestä toimiviksi:

Millä ohjelmalla kirjoitan?

HTML-dokumentin voi kirjoittaa millä tahansa tekstieditorilla eli ohjelmalla, jolla voi käsitellä ja tallentaa tekstiä pelkkänä tekstinä. Kyseeseen tulevat esimerkiksi seuraavat:

Muita vaihtoehtoja löytyy esim. Web Authoring FAQ:n kohdan What is everyone using to write HTML? kautta. Huomaa, että ohjelmistonjakelusivusto Tucowsilla on myös "Suomen haarakonttori", josta data siirtyy yleensä nopeammin kuin ulkomailta.

Jos HTML-dokumentin pohjaksi otetaan valmis muussa muodossa oleva aineisto tai palasia sellaisesta, käytetään usein "työkaluja" kuten automaattisia muunnosohjelmia.

On olemassa myös ohjelmia, jotka tuottavat HTML-dokumentteja "näkymättömästi" niin, että kirjoittaja ei lainkaan näe HTML-merkkausta. Usein niiden väitetään olevan "wysiwyg-ohjelmia": What You See Is What You Get, eli tuotetun dokumentin väitetään olevan juuri sellainen, miltä se näyttää kirjoitettaessa. Jo edellä esitetty on toivottavasti osoittanut tämän harhaluuloksi.

Kirjoittamistekniikkaa (rivinvaihdot yms.)

Varsinaisen tekstin voi kirjoittaa melko vapaamuotoisesti. Käytännössä kannattaa kirjoittaa lyhyehköjä, alle 80-merkkisiä rivejä, jotta editointi olisi mukavampaa. Rivinvaihto vastaa HTML:ssä välilyöntiä. Jaoitpa tekstin riveille miten tahansa, selain kuitenkin "latoo" tekstin miten se haluaa ja miten kulloinkin sopii (mm. selaimen ikkunan leveys huomioon ottaen). Seuraavat seikat kannattaa kuitenkin ottaa huomioon:

Mitään siistiä tapaa estää rivinvaihto sanan sisällä ei ole olemassa. Toisaalta selaimet eivät yleensä jaa sanoja eri riveille. Internet Explorer kuitenkin saattaa jakaa yhdysmerkin kohdalta (esim. sanan "kuu-ukko"), mikä on usein ihan hyvä; mutta valitettavasti se menee tässä liiallisuuksiin, erottaen jopa sananalkuisen yhdysmerkin sanasta! Jos siisti ulkoasu on tärkeä, voit käyttää nobr-elementtiä (joka ei kuulu mihinkään viralliseen HTML-kielen määrittelyyn) tähän tapaan: syntymäaika ja <nobr>-paikka</nobr>, <nobr>Latin-1</nobr>. Vastaava koskee sanansisäisiä sulkumerkkejä esim. ilmaisussa "tietokone(järjestelmä)", jonka IE käsittelee kuten ilmaisun "tietokone (järjestelmä)", ellei käytetä nobr-elementtiä. Koska nobr-elementin käyttö kaikkialla, missä IE saattaa sotkea rivitysasioita, olisi tylsää ja rasittavaa, se kannattanee rajoittaa tärkeimpiin tapauksiin kuten sellaisiin otsikoihin ja tiivistelmiin, joissa väärä rivitys olisi erityisen ikävä.

"Pakolliset kuviot"

Dokumenttityypin määrittely

Aivan dokumentin alkuun kuuluu periaatteessa niin sanottu dokumenttityypin määrittely. Sellaisena voi käyttää seuraavaa (juuri tällaisenaan): 

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
  "http://www.w3.org/TR/html4/strict.dtd">
taikka, jos dokumentissa on käytetty määrättyjä ns. ei-suositeltuja (deprecated) piirteitä eli HTML:n Transitional-versiota, 
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
  "http://www.w3.org/TR/html4/loose.dtd">

Periaatteellisesti tällainen määrittely ilmaisee, että kyseessä on HTML-dokumentti, vieläpä määrättyjä muotosääntöjä (syntaksia) noudattava. Teoriassa tällä on merkitystä ohjelmille, jotka voivat käsitellä ja näyttää muillakin SGML-pohjaisilla merkkauskielillä esitettyä aineistoa.

Käytetty HTML:n versio on tässä 4.01. Se poikkeaa aiemmasta 4.0:sta asiallisesti melko vähän mutta sallii joitakin selainten yleisesti tukemia piirteitä, joita 4.0 ei sallinut.

Käytännössä dokumenttityypin määrittelyn suurin merkitys on nykyisin siinä, että se tarvitaan dokumentin määrätynlaista tarkistamista, validointia, varten. Mutta asiaa ei kannata jäädä ihmettelemään - kopioi vain jompikumpi edellä olevista riveistä sellaisenaan. Älä korvaa isoja kirjaimia pienillä äläkö rupea spekuloimaan sillä, mitä EN tarkoittaa. (Se tarkoittaa kyllä englannin kieltä mutta ei siinä mielessä, että dokumentti olisi englanninkielinen, vaan siinä mielessä, että käytetty HTML-kielen versio on kuvattu englanniksi!)

Dokumenttityypin määrittely vaikuttaa joissakin tilanteissa myös siihen, miten selaimet näyttävät HTML-dokumentin. Tämä niin sanottu doctype sniffing merkitsee absurdia piirrettä selaimissa, eikä siitä normaalisti tarvitse tietää mitään, ellei ole kirjoittanut HTML:ää tavalla, joka luottaa joidenkin selainten ominaisuuksiin. Aiheesta löytyy kuvauksia Matthias Gutfeldtin sivun Doctype switching and standards compliance: An overview kautta.

"Titteli" on tärkeä

Itse HTML-dokumentin alkuun kuuluu title-elementti. Vaikka se kuuluu "pakollisiin kuvioihin", sitä ei pidä kirjoittaa huolimattomasti saati ajattelemattomasti. Sen sisällön miettimiseen kannattaa uhrata jonkin verran aikaa, koska sillä on yllättävän paljon vaikutusta. Sen muoto on 

<title>Dokumentin "ulkoinen" otsake</title>

Sen sisältöä käyttävät hyvin monet ohjelmat erilaisiin tarkoituksiin. Se voi näkyä esim. selaimen ikkunan yläpalkissa (ei siis osana itse dokumenttia vaan sen yläpuolella), selaimen ns. hotlistassa, hakupalvelimien antamissa osumalistoissa jne.

Kirjoita title-elementtiin sellainen lyhyt ja mutta tietopitoinen otsake, joka missä tahansa asiayhteydessä kuvastaa dokumentin olennaista sisältöä.

Esimerkiksi "Johdanto" on erittäin huono otsake. Johdanto mihin? Otsakkeen pitää olla ymmärrettävä, vaikka lukija ei lainkaan tiedä, mihin asiayhteyteen dokumentti liittyy, eikä edes näe dokumenttia itseään. Otsake on usein ratkaiseva sen kannalta, ottaako lukija itse dokumenttia lainkaan luettavakseen! (Siis esim. valitseeko sen hän jostakin dokumenttien listasta, jossa kutakin juttua edustaa vain sen otsake.)

"Ulkoinen" otsake on eri asia kuin ne otsikot, joita voit sisällyttää dokumenttiin otsikkoelementeillä (h1 ym.) ja jotka näkyvät osana itse dokumenttia.

Mikään ei toki estä kirjoittamasta dokumentin ylimpään otsikkoon samaa tekstiä kuin title-elementtiin, jos sama teksti toimii hyvin sekä "ulkoisena" otsakkeena että itse dokumentin osana. Tavallisesti kuitenkin title-elementillä ilmoitettava otsake on lyhyempi ja tiiviimpi; mitään erityistä ylärajaa sen pituudelle ei ole, mutta ohjelmat eivät yleensä käytä ainakaan enempää kuin 72 ensimmäistä merkkiä.

Jambalaya-reseptimme alkuun voisimme kirjoittaa esimerkiksi seuraavan: 

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<title>Jambalaya-resepti suomal. makuun (J. Korpela)</title>
<h2>Jambalaya suomalaiseen makuun à la Yucca</h2>

Huomaa, että tässä title-elementti antaa "objektiivisemman" otsakkeen, josta mm. ilmenee, että kyseessä resepti. Sen sijaan h2-elementin sisältämä teksti on vapaampaa, koska se luetaan itse dokumenttia luettaessa, jolloin reseptiluonne ilmenee itse jutusta.

Kokeile!

Voit nyt kokeilla siipiäsi ja tehdä pienen Web-sivun ihan kokeeksi. Jos mahdollista, niin valitse jokin aihe, josta aiot myöhemmin tehdä "oikean" sivun. Esimerkiksi jos aiot tehdä jonkin yhdistyksen "kotisivut", tee lyhyt kuvaus yhdistyksen tarkoituksesta taikka jostakin muusta sisällöllisesti sinulle helposta (?) aiheesta.

Anna tiedostolle yksinkertainen nimi, joka loppuu merkkeihin (tyyppimerkintään) .html, esimerkiksi esittely.html.

Sitä, mitä teet kirjoitettuasi dokumentin tiedostoon, käsiteltiin edellä kohdassa Teksti Webiin. Nyt vain tiedoston nimi loppuu .html eikä .txt.

Vaihtoehtoisesti voit (jos luet tätä kuvaruudulta ja sinulla on Internet-yhteys) käyttää tätä pikku lomaketta. Alla olevaan alueeseen on valmiiksi täytetty pienen dokumentin runko. Täydennä sitä kirjoittamalla tekstiä väliin ja käytä Katso!-painiketta tai vastaavaa. Dokumenttisi aukeaa silloin joko nykyiseen tai uuteen ikkunaan sellaisena kuin selaimesi sen näyttää. Halutessasi voit sitten selaimen Save As -toiminnolla tallentaa tekstisi tiedostoon omaan koneeseesi.

Otsikko-osa ja runko (head ja body)

Dokumentin rakennetta voidaan korostaa lisäämällä edellä esitettyyn perusrakenteeseen merkkausta, joka on käytännössä ja vanhojen HTML-määrittelyjen mukaan vapaaehtoinen mutta etenkin tulevaisuutta ajatellen suositeltava. Tämä tarkoittaa seuraavaa:

Seuraavassa on tällaisen käytännön mukainen dokumentti, jonka rungossa on vain otsikkoelementti ja kappale-elementti:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <title>Demo html-, body- ja head-tägien käytöstä</title>
  </head>
  <body>
    <h1>Demo html-, body- ja head-tägien käytöstä</h1>
    <p>Tämä on pelkkä demo. Dokumentin merkitys tai ulkoasu
    ei muuttuisi, vaikka html-, body- ja head-tägit poistettaisiin.</p>
  </body>
</html>

Huomaa, että sisennyksiä voi halutessaan käyttää rakenteen selventämiseen HTML-merkkausta lukevalle ihmiselle. Dokumentin ulkoasuun tällaisilla sisennyksillä ei ole vaikutusta.

Vaikka dokumentissa ei olisikaan html-, head- ja body-tägejä, siinä kuitenkin aina on vastaavat elementit. Silloin selaimen oletetaan tunnistavan rakenteen "implisiittisesti". Jos kyseiset tägit jätettäisiin pois, niin esimerkkitapauksessa selain tunnistaisi h1-tägistä, että nyt siirryttiin runko-osaan, koska h1-elementti ei ole sallittu otsikko-osassa.

Otsikoilla ojennukseen

Sisällys

Otsikoinnin tarkoitus

Otsikointi mahdollistaa sen, että lukija silmäilee jutun nopeasti saadakseen yleiskuvan sen sisällöstä. Jos hän päättää lukea koko jutun, otsikot näkyvät muistutuksena siitä, missä nyt ollaan menossa, ja ne jäsentävät jutun osiin. Jos juttu muodostuu niin tärkeäksi lukijalle, että hän palaa siihen, niin otsikot auttavat löytämään sen kohdan, josta hän kulloinkin on kiinnostunut. Otsikkoa voidaan myös käyttää viitattaessa juttuun, sen yksilöimiseksi, mihin erityiseen kohtaan viitata. Viittaamisen helpottamiseksi Web-sivuilla on hyvä tehdä juttuun a name -elementtejä, mutta nekin toimivat parhaiten, kun ne ovat otsikoiden sisällä; ks. kohtaa Ole linkitettävissä!.

Otsikoilla on erittäin suuri merkitys jutun luettavuuden kannalta. Esimerkiksi lehtiuutisessa otsikot ovat tärkeämpiä kuin mikään muu, mahdollista kuvitusta ehkä lukuun ottamatta. Hyvä otsikointi edellyttää pohjakseen selkeän jäsennyksen. Sitä käsittelee oppaani Kirjoita asiaa luku Kirjoituksen rakentaminen.

Otsikoiden luonne vaihtelee suuresti. Varsinkin lehtijuttutyyppisessä tekstissä otsikot ovat lyhyitä ja iskeviä, lukemaan houkuttelevia. Raportissa tai tutkielmassa otsikot taas usein vain kuvaavat loogista jäsennystä: ne yksilöivät, mitä asiaa käsitellään, eivät niinkään tiivistä sitä, mitä asiasta sanotaan.

Otsikkoelementit HTML:ssä

HTML:ssä otsikot esitetään h1-, h2-, h3- ja h4-elementeillä. Mitä pienempi numero, sitä ylemmän tason otsikosta on kyse:

> HTML-kielessä on periaatteessa käytettävissä kuusi eritasoista otsikkoelementtiä h1:stä h6:een. Niistä kuitenkaan kahta viimeistä ei pidä juuri koskaan käyttää. Jos dokumentti vaatisi viidennen tai kuudennen tason otsikoita, se on yleensä joko väärin jäsennetty taikka niin laaja, että se on syytä jakaa useaksi Web-sivuksi. Lisäksi suositut selaimet näyttävät h5- ja h6-elementit usein ihan päin mäntyä: pienempänä kuin normaaliteksti. Tämä ongelma on kyllä pääosin hoidettavissa tyyliohjeen avulla.

Aiemmin valittiin usein sivun pääotsikon otsikkotaso sen mukaan, miten isokokoisena sen haluttiin näkyvän. (Tällaista ehdotettiin tämän oppaankin vanhoissa versioissa.) Esimerkiksi pienelle sivulle, jolla on vain vähän asiaa eikä lainkaan alaotsikoita, saatettiin pääotsikko merkata h3-elementiksi. Ajateltiin, että kun pääotsikon ei tarvitse olla isommalla kuin alaotsikot, sen fonttikoko voi olla aika pienikin. Vaikka tällaista ajattelua edelleen harrastetaan, se on varsin vanhentunutta. Otsikoiden kokoon voi vaikutta tyyliohjeilla (tyylisäännöstöillä, CSS:llä) esimerkiksi seuraavasti:

<style type="text/css">
h1 { font-size: 170%; }
h2 { font-size: 145%; }
h3 { font-size: 125%; }
</style>

Edellä olevassa CSS-esimerkissä asetetaan otsikoiden fonttikokoja suhteellisesti, suhteessa sivun perusfonttikokoon eli leipätekstin kokoon.

HTML:ssä ei varsinaisesti ole elementtejä sivun jakamiseksi osiin. Haluttaessa voidaan kuitenkin osiin jakautuminen erikseen merkata div-elementeillä seuraavaan tapaan:

<style type="text/css"><h1>Pääotsikko</h1>
<div class="osa">
<h2>Alaotsikko A</h2>
<p>Kappale.</p>
<p>Kappale.</p>
</div>
<div class="osa">
<h2>Alaotsikko B</h2>
<p>Kappale.</p>
<p>Kappale.</p>
</div>...<style>

Tällainen osiin jakaminen ei sinänsä vaikuta mitään sivun ulkoasuun, ei myöskään hakukoneisiin tms. Se voidaan ymmärtää selityksen (kommentin) luonteiseksi. Sitä voidaan kuitenkin myös hyödyntää sivun ulkoasun muotoilussa, sillä se mahdollistaa osiin viittaamisen tyyliohjeissa.

Otsikoiden tekeminen jäsentelyvaiheessa

Kun olet miettinyt jutullesi hyvän jäsennyksen, voit sen pohjalta jo kirjoittaa alustavan rungon: joukon otsikkoelementtejä, jotka vastaavat jäsennystä. Vaikkapa näin: 

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<title>Jäsennysesimerkki</title>
<h2>Kertomus matkastani Brutopiaan</h2>
<h3>Tiivistelmä</h3>
<h3>Johdanto: miksi lähdin matkalle</h3>
<h3>Havaintoja Brutopian talouselämästä</h3>
<h4>Maatalous</h4>
<h4>Teollisuus</h4>
<h4>Palveluelinkeinot</h4>
<h4>Salakuljetus</h4>
<h3>Brutopian luonnosta</h3>
<h3>Liitteet</h3>
<h4>Matkan järjestelyt</h4>
<h4>Hyödyllisiä osoitteita</h4>
<h4>Tietoisku Brutopiasta (mm. kartta)</h4>

Dokumentin, joka sisältää vain tämän rungon voit vaikkapa tulostaa itsellesi paperille, jotta voit paremmin pitää mielessäsi kokonaissuunnitelmasi. Siitä voit myöhemmin tehdä myös hypertekstisisällysluettelon.

Tiivistelmän tekeminen

Tiivistelmän tekeminen ei teknisesti liity otsikoihin mutta palvelee samanlaisia tarkoituksia. Se käsitellään tässä yhteydessä myös siksi, ettei syntyisi väärinkäsitystä, että otsikoiden kirjoittaminen ja tiivistelmän tekeminen olisivat vaihtoehtoja. Yleensä molemmat tarvitaan. Otsikot kokonaisuutena toimivat kyllä eräänlaisena tiivistelmänä, etenkin jos niiden tekstit on koottu hypertekstisisällysluetteloksi sivun alkupuolelle. Mutta se on luetelma jutun aiheista, ei normaalia tekstiä, joka on kudottu normaaleiksi, yhteen liittyviksi virkkeiksi. Hyvä nyrkkisääntö on, että varsinaisen tiivistelmän pitää olla olla sujuvasti luettavissa ääneen niin, että se kuulostaa normaalilta puheelta.

Jutun alkuun, heti pääotsikon jälkeen, on useimmiten syytä kirjoittaa kappaleen tai parin mittainen tiivistelmä. Tähän on useitakin syitä:

Tiivistelmä voidaan jättää ilman omaa otsikkoa tai sille voidaan antaa jokin havainnollisempi otsikko kuin "Tiivistelmä". Tiivistelmän otsikko saattaa toimia jutun pääotsikon alaotsikkonakin. Tyylisäännöstöillä voit ehdottaa, että selain esittää tiivistelmän jollakin normaalitekstistä poikkeavalla tavalla sen korostamiseksi, esimerkiksi isommalla tai muuten poikkeavalla kirjasinlajilla tai "laatikkona". (Tällaiseen tarkoitukseen, kappaleen tai muun laajemman kokonaisuuden korostamiseen, ei HTML:ssä valitettavasti ole rakenteellisempia keinoja.)

Otsikoinnin tekniikkaa
kuten vähän aliotsikoista

Otsikoissa ei kannata HUUTAA. Isojen kirjainten (oikeastaan: suuraakkosten) käyttö otsikoissa on perua vanhojen kirjoituskoneiden ja alkeellisten tietokonenäyttöjen ajoilta, jolloin ei juuri mitään muuta korostuskeinoa ollut. Käytä siis isoja ja pieniä kirjaimia ihan normaalisti. Luota siihen, että kukin selain esittää esimerkiksi h2-elementin tavalla, joka sopii otsikolle. Jokin selain ei ehkä pysty - käytettävän laitteen rajoitusten takia - erottamaan otsikkoa muusta tekstistä millään kehittyneemmällä tavalla kuin isokirjaimisuudella. Olkoon silloin sen asia muuntaa kirjoittamasi otsikkoteksti isokirjaimeksi. Useimmat selaimet pystyvät käyttämään esim. isompaa kirjasinlajia tai värejä, ja silloin ISOKIRJAIMISUUS on vain haitaksi. Joissakin tapauksissa voi seurata suoranaisia väärinkäsityksiä, koska isoja kirjaimia käytetään muissakin tarkoituksessa kuin korostamiseen. Kokonaan isokirjaimisessa tekstissä ei voida tehdä normaaliin tapaan eroa yleisnimen (esim. karhu) ja erisnimen (esim. Karhu tuotemerkkinä tai ihmisen nimenä) välillä.

Usein olisi kiva kirjoittaa alaotsikko, joka täydentää varsinaista otsikkoa, siten, että alaotsikko on vähemmän korostettu kuin varsinainen otsikko. Yksi tapa on kirjoittaa esimerkiksi h1-otsikon perään h2-otsikko, mutta tämä on hiukan epäloogista, koska muut h2-otsikot toimivat otsikkoina jutun osille, eivät alaotsikkona koko jutulle. Lisäksi kahden otsikkoelementin väliin jää selaimien yleensä käyttämässä esitystavassa aika lailla tyhjää tilaa. Niinpä parasta onkin ehkä kirjoittaa sekä pää- että alaotsikko yhden elementin sisään mutta erottaa ne toisistaan rivinvaihdolla (<br>) sekä siten, että alaotsikko on small-elementin sisällä, tähän tapaan: 

<h2><a name="ots-tekn">Otsikoinnin tekniikkaa</a><br>
<small>kuten vähän aliotsikoista</small></h2>

Linkkejä peliin

Sisällys

Miksi linkkejä?

Ajatellaanpa, että olet kertomassa tuttaville tai sukulaisille jostakin hauskasta tapauksesta. Ja aloitat "Kun me oltiin viime kesänä Albufeirassa, - -". Mutta entäs jos kuulijoilla ei ole harmainta aavistusta siitä, mikä Albufeira on? Voit tietysti lisätä muutaman selittävän sanan, ehkä useitakin. Mutta jos tarinasi ei ole hauska, ellei kuulija tiedä, millainen paikka se on, tarvittaisiin aika pitkä selitys. Ja se kyllästyttäisi niitä, jotka itse ovat käyneet Albufeirassa viisi kertaa. Tämä on yksi viestinnän perusongelmista: et tiedä, mitä kuulijat jo tietävät, ja ryhmälle viestittäessä tietojen ja valmiuksien erilaisuus käytännössä takaa sen, että viestintä epäonnistuu ainakin suurimmaksi osaksi.

Kirjallisessa viestinnässä tilanne on osittain toinen. Kullakin lukijalla on ainakin periaatteessa mahdollisuus tarkistaa ja tutkia asioita. Hän ei ole sidottu sinun tekstisi tasatahtiseen lukemiseen sillä tavoin, kuin kuulija on sidottu sinun kuuntelemiseesi. Häntä ei häiritse se, että jotkut muut lukijat lukevat toiseen tahtiin ja katsovat lähdeteoksista eri asioita kuin hän.

Mutta moniko käyttää lähdeteoksia, edes lukiessaan asiatekstiä? Vaikka hyllyssä olisi tietosanakirja, se on ehkä vuodelta 1960 eikä tunne Albufeiraa. Jospa voisitkin tarjota lukijalle mahdollisuuden lukea asiasta sellaisesta lähteestä, jonka itse olet lukenut ja hyödylliseksi havainnut! Ja jos kyse olisi asiasta, jota yleiset tietoteokset eivät lainkaan käsittele, vaikkapa TCP/IP-protokollan perusominaisuuksista, lukija on aika hukassa, jos juttusi alkaa tarinoimaan jostakin hänelle uppo-oudosta. Ehkäpä hänen pitäisikin lukea jotain muuta. Mutta jospa juttusi muuten kiinnostaisi häntä, ja entäpä jos alkuun pääsemiseksi riittäisi lukea hyvä sivun mittainen yleiskuvaus siitä aiheesta, jonka nimen juttusi heti alussa heittää silmille? Muutenkin voi olla erinomainen ajatus tarjota lukijalle jokin suositus siitä, mistä hän voi hankkia tarvittavia esitietoja tai palauttaa ne mieleensä.

Jokainen juttu lähtee jostakin ja päättyy johonkin. Sinun juttusi ei voi käsitellä kaikkea, mitä asiasta kannattaa sanoa - älä yritäkään, perfektionisti! Mutta voit paitsi auttaa hankkimaan pohjatietoja myös viitata eteenpäin: antaa viitteitä lähteisiin, joista voi hankkia syventäviä tai erikoistuneempia lisätietoja.

Mikä linkki on?

Linkki on Webissä tekninen tapa toteuttaa viittaus siten, että parhaassa tapauksessa lukijan ei tarvitse tehdä muuta kuin näpäyttää näppäintä, klikata hiiren nappia tai sanoa "tuonne!" päästäkseen käsiksi siihen, mihin viitataan. Tämän hintana on se, että Web-sivun tekijän on nähtävä vaivaa. Lisäksi tekijän on ymmärrettävä ajatella asiaa lukijan kannalta: mikä on lukijalle mahdollisesti avuksi? Palataksemme TCP/IP:hen: jos viittaisit laajaan tekniseen dokumenttiin, joka sisältää TCP/IP:n täydellisen teknisen määrittelyn, tekisit todennäköisesti karhunpalveluksen useimmille lukijoillesi. Sen sijaan viittaaminen lyhyeen yleisesitykseen TCP/IP:stä tai vaikka vain juttuun joka parilla sanalla sanoo, miten TCP/IP liittyy Internetiin, voisi olla suureksi hyödyksi. Ja siinä sitten voi olla linkkejä vaikka miten teknisiin juttuihin.

Linkit ovat Webin keskeisimpiä asioita, jotka erottavat sen esimerkiksi kirjallisesta julkaisemisesta. Linkeillä rakennetaan hypertekstiä, jossa tekstit viittaavat toisiinsa. Katso myös Freesoftin Internet-ensyklopedian artikkelia Hypertext.

Englannin sana web tarkoittaa mm. hämähäkinseittiä, ja nimi "(World Wide) Web" johtuu tästä. Taustalla on ajatus, että dokumentit liittyvät toisiinsa näkymättömillä langoilla, linkeillä, kuten seitin solmut toisiinsa.

Kyllähän kirjassakin voidaan viitata toiseen kirjaan, mutta viittauksen seuraaminen voi olla melkoinen työ, ellei sitä toista kirjaa satu olemaan omassa kirjahyllyssä. Myös kirjan sisäiset viittaukset kuten "Tämä selitetään tarkemmin sivulla 42" ovat kömpelömpiä kuin Webin hypertekstiviittaukset, joita lukija voi heti seurata esimerkiksi klikkaamalla sanaa, jonka selain ilmaisee linkiksi. Mutta tämän toivottavasti suurin piirtein tiedät. Katsotaan, miten linkkejä tehdään; sitä ennen kuitenkin varoituksen sana.

Linkkien keskeisyyden takia on syytä välttää kaikkea, mikä estää linkkejä näkymästä ja toimimasta linkkeinä. Itsestäänselvää? No, joka tapauksessa on hyvin yleistä sotkea asioita siten, että selvien linkkien tilalla käytetään jos jonkinlaista nappulaa ja vimpstaakia, linkkien värejä sotketaan, alleviivaukset estetään jne. Aiheesta lisää jutussani Links Want To Be Links. Sen vaihtoehtoiseen versioon pääsee myös seuraavalla "buttonilla"; tämä on tarkoitettu vitsiksi:

Jos tuo painike olisi ainoa viittaus kyseiseen juttuun tällä sivulla, et näkisi linkin väristä, oletko hiljattain käynyt kyseisellä sivulla. Et myöskään voisi avata sivua kätevästi uuteen ikkunaan etkä tehdä monia muitakaan asioita, joita linkeillä voi tehdä.

Perusesimerkki linkin tekemisestä

Olettakaamme vaikkapa, että olet valmistumassa Helsingin ammattikorkeakoulusta ja teet itsestäsi Web-sivua, joka sisältää perustietoja opinnoistasi ja muusta toiminnasta (ns. curriculum vitae, CV). Ajatuksenasi on, että voit mm. työpaikkahakemuksiisi liittää sellaisen sivun osoitteen. Jos sivu on hyvin tehty, se tietysti kertoo varsinaisen sisältönsä lisäksi myös siitä, että osaat tehdä ainakin yksinkertaisen Web-sivun hyvin.

Sellaisella sivulla epäilemättä kertoisit muun muassa, että opiskelet Helsingin ammattikorkeakoulussa (ja myöhemmin toivottavasti muistaisit päivittää tämän tiedon niin, että se kertoo valmistumisestasi!). Olisi erittäin luontevaa ja tarpeellista silloin tehdä linkki oppilaitoksen pääsivulle, jolta lukija voi esimerkiksi tarkistaa, millaisesta opinahjosta on kyse - millaista ja miten suunnattua opetusta se antaa jne. Tämän voit tehdä niin, että teet sanoista "Helsingin ammattikorkeakoulussa" tai osasta tätä ilmaisua, jättäen päätteen "-ssa" ulkopuolelle, linkin kyseiseen osoitteeseen, joka on "http://www.hit.fi/".

Linkkielementin perusrakenne koostuu seuraavista osista:

Elementin nimi a johtuu englannin sanasta anchor 'ankkuri'. Taustalla on hämärä kielikuva (metafora), jossa linkitystä verrataan laivan ankkuroimiseen. Linkki on kuin näkymätön köysi, jonka yksi pää on kiinni yhdessä dokumentissa ja toinen toisessa. Kielikuva on aika epäonnistunut, muun muassa siksi, että ankkuri estää laivaa liikkumasta, kun taas linkki mahdollistaa Webissä "navigoimisen".

Täten kirjoittaisimme esimerkiksi 

Opiskelen <a href="http://www.hit.fi/">Helsingin ammattikorkeakoulu</a>ssa.
ja se näyttäisi esimerkiksi seuraavanlaiselta:
Opiskelen Helsingin ammattikorkeakoulussa.
tai ehkä seuraavanlaiselta:
[Teksti, jossa "Helsingin ammattikorkeakoulu" on punaisella ja kursiivilla ja eräänlaisessa kehyksessä.]

Elementtien määritteet (attribuutit)

Edellä olevassa esimerkissä osa href="http://www.hit.fi/" on määrite eli attribuutti, joka tarkentaa elementin merkitystä. Yleisesti määrite on elementin alkutägiin liitettävä tarkenne, joka on muotoa nimi=arvo tai joskus pelkkä nimi.

Usein määritteitä käytetään elementin ulkoasuun liittyvien ehdotuksien tekemiseen. Esimerkiksi <h1 align="center"> ehdottaa kyseisen otsikon esittämistä vaakasuunnassa keskitettynä. Nykyisin tyylisäännöstöt sopivat useimpiin sellaisiin asioihin paremmin.

Mutta eräillä määritteillä on olennainen merkitystehtävä. Tästä tyyppiesimerkki on juuri href, jonka arvo ilmaisee, mihin dokumenttiin a-elementillä rakennettu linkki viittaa.

Kullakin HTML-kielen elementillä on joukko mahdollisia (joskus pakollisiakin) määritteitä, joita siihen voi liittää. Ne luetellaan elementin kuvauksessa kielen määrittelyssä. Samannimisellä määritteellä voi jopa olla eri merkitys eri elementeissä!

Se, millaisia arvoja jollekin attribuutille voi antaa, kerrotaan attribuutin kuvauksessa HTML-kielen määrittelyssä. Esimerkiksi href-attribuutin arvon tulee olla Web-osoite eli URL, kun taas jollekin muulle attribuutille voi antaa vain numeerisia arvoja, jollekin mielivaltaisen merkkijonon jne. HTML 4 -spesifikaatio sisältää erillisen liitteen, jossa on lueteltu kaikki attribuutit ja annettu linkit niiden määritelmiin.

Määritteen arvo on varminta kirjoittaa aina lainausmerkkien sisään, kuten edellä on tehty. Kaikissa tilanteissa tämä ei ole pakollista, mutta se on aina sallittua ja turvallista.

Suhteelliset URLit

Linkkiä rakennettaessa (ja useissa muissa yhteyksissä, esim. kuviin viitattaessa) HTML:ssä voi käyttää ns. absoluuttisten URLien asemesta myös suhteellisia. Jos esimerkiksi sivulla, jonka oma osoite on
http://jkorpela.fi/webjulk/1.5.html
haluttaisiin viitata linkillä dokumenttiin
http://jkorpela.fi/webjulk/1.1.html
niin href-määritteeseen voitaisiin tuon täydellisen, absoluuttisen URLin asemesta kirjoittaa lyhyesti
1.1.html

Tämä perustuu siihen, että kohdatessaan tuontapaisen URLin selain tulkitsee sen suhteellisena suhteessa kantaosoitteeseen, joka on viittaavan dokumentin oma URL (tai mahdollisella base-elementillä asetettu kantaosoite). Selain poistaa kantaosoitteesta loppuosan viimeiseen vinoviivaan asti ja lisää suhteellisen osoitteen sen perään ja sitten käyttää näin muodostamaansa osoitetta.

Käytännössä tämä merkitsee tavallisesti sitä, että samassa hakemistossa olevat dokumentit voivat viitata toisiinsa pelkillä tiedostonnimillä. Lisäksi ne voivat viitata kyseisen hakemiston alihakemistoissa oleviin tiedostoihin; suhteellinen URL tällöin aloitetaan alihakemiston nimellä, jota seuraa vinoviiva ja tiedoston nimi. Esimerkkitapauksessamme suhteellinen URL yhk/kal.html tarkoittaisi samaa kuin http://jkorpela.fi/webjulk/yhk/kal.html

Suhteellinen URL voi alkaa myös osalla ../, joka aiheuttaa sen, että selain poistaa kantaosoitteesta paitsi viimeistä vinoviivaa seuraavan osan myös siitä taaksepäin edelliseen vinoviivaan asti. Osia ../ voi olla myös useita peräkkäin, mikä käytännössä yleensä vastaa siirtymistä hakemistopuussa useita tasoja ylöspäin; tässä menee sivuntekijä kyllä helposti sekaisin. Esimerkkitapauksessamme (jossa siis kantaosoitteena on http://jkorpela.fi/webjulk/1.5.html) tarkoittaisi suhteellinen URL ../iso8601.html samaa kuin http://jkorpela.fi/iso8601.html

Suhteellisilla URLeilla saavutettavat edut eivät rajoitu lyhyyteen. Jos kokonainen Web-sivusto halutaan siirtää esimerkiksi toiseen palvelimeen taikka siitä halutaan tehdä "imuroitava" (downloadable) versio, on edullista, että viittaukset ovat suhteellisia mikäli mahdollista. Tällöinhän viittauksia ei tarvitse erikseen muuttaa viittaamaan uuteen sijaintipaikkaan.

Huomaa, että URLien osien erottimina käytetään vinoviivaa / siitä riippumatta, millainen tiedostojärjestelmä selaimessa tai palvelimessa on. Erityisesti on huomattava, että DOSin ja Windowsin kenoviiva \ ei kuulu tähän yhteyteen, vaikka jotkin selaimet senkin hyväksyvät.

Anna vinkki linkin kohteesta

Edellä olevassa esimerkissä on varsin ilmeistä, millaiselle sivulle linkki johtaa ja missä tarkoituksessa linkki on sivulle pantu. Usein tilanne on toinen. Linkkiteksti voi olla esimerkiksi lyhenne, joka ei välttämättä ole lukijalle tuttu:

Olen ollut töissä TKK:ssa.
Tietenkin lukija voi linkkiä seuraamalla nähdä, mitä "TKK" tarkoittaa (tässä yhteydessä) - ainakin jos linkin seuraaminen onnistuu eli käytännössä jos yhteydet pelaavat.

Voit auttaa osaa lukijoista näkemään tämän linkkiä seuraamattakin, kun liität a-elementtiin title-määritteen seuraavaan tapaan: 

Olen ollut töissä <a title="Teknillinen korkeakoulu"
href="http://www.hut.fi">TKK</a>:ssa.

Eräät selaimet näyttävät title-määritteen arvon käyttäjällä joissakin tilanteissa. Edellisessä esimerkissä on käytetty title-määritettä, joten voit testata, tukeeko käyttämäsi selain sitä. Tyypillisesti tämä merkitsee, että kun siirrät hiirellä kursorin linkin kohdalle, tulee näkyviin pieni ikkuna, jossa title-määritteen arvo näkyy. Katso esimerkkejä Jakob Nielsenin kirjoituksessa Using Link Titles to Help Users Predict Where They Are Going.

Yleensä title-määritteen arvon on hyvä olla lyhyehkö, enintään muutaman kymmenen merkin mittainen, eikä siihen kannata sisällyttää rivinvaihtoja.

Tämäntapaisten vinkkien antaminen on erityisen hyödyllistä silloin, kun linkki on tekstin seassa eikä ole linkkitekstin perusteella mitenkään ilmeistä, mihin linkki johtaa. Esimerkki:

Lehdessä kerrotaan, että elokuussa on standardista SFS 4175 hyväksytty uusittu versio.

Tällaisesta voi olla vaikea arvata, mihin ihmeeseen linkki viittaa. Tässä tapauksessa on linkkiin liitetty title-määritteellä lyhyt selitys "Yleistietoa standardoinnista". Tämä toivottavasti auttaa lukijaa ratkaisemaan, kiinnostaako häntä juttu, johon linkki viittaa. Jos hänen selaimensa ei tue title-määritettä, niin sitten hänen ei ehkä auta muu kuin seurata linkkiä nähdäkseen, mitä sen takana oikein on.

Muillakin keinoin kuin title-määritteellä voit auttaa lukijaa näkemään, mitä merkitys jollakin linkillä on, ja siten arvioimaan, kannattaako hänen seurata sitä. Ks. kohtaa Expressing the nature of a link oppaassani Learning HTML 3.2 by Examples.

On mahdollista liittää title-määrite moniin muihinkin elementteihin kuin a-elementtiin. Ajatuksena on, että lukija saisi halutessaan luettavakseen samanlaisia "vinkkejä" (tooltips) kuin linkkien yhteydessä viemällä kursorin elementin esityksen päälle tai jollakin vastaavalla tavalla. Uusimmissa selainversioissa on melko hyvä tuki tälle. title-määritteen kuvausta HTML 4 -spesifikaatiossa ja IE:n dokumentaation selostusta title-määritteestä. Huomaa, että jostain käsittämättömästä syystä IE ei tue tätä määritettä sille elementille, jossa se olisi ehkä kaikkein hyödyllisin: abbr-elementille! Sen sijaan Netscape 6 tukee sitä ja vieläpä näyttää lyhenteen alla katkoviivan merkiksi siitä, että lyhenteelle on tarjolla selitys.

Hypertekstiallekirjoitus

Juttu kannattaa allekirjoittaa jo pelkästään tyylikkyyssyistä: nimettömään kirjoitukseen suhtaudutaan toisin kuin sellaiseen, josta näkee, kenen se on. Mukaan voi liittää meiliosoitteen ("sähköpostiosoitteen") etenkin jos toivoo lukijoiden lähettävän kommenttejaan. Lisäksi voi mainita ammatti- tai tutkintonimikkeen (selväkielisenä, ei mitään hämäriä lyhenteitä kuten "LuK") tai muun vastaavan taustatiedon.

Yleisesti tekijän osoitetiedot ja vastaavat voi kirjoittaa address-elementtiin. Tällainen elementti vastaa kappale-elementtiä (P-elementtiä), mutta sen tarkoitus on antaa tietoja dokumentin (tai sen osan) tekijästä. Selain saattaa näyttää (ja yleensä näyttääkin) address-elementin normaalikappaleesta poikkeavasti, esim. sisennettynä tai eri kirjasinlajilla.

Mainitunlaiset tiedot voi sijoittaa esimerkiksi heti pääotsikon alle taikka aivan jutun loppuun.

Jos kirjoitat osoitetietosi dokumentin loppuun, niin niiden edelle voi kirjoittaa seuraavanlaisen:

<hr title="Tietoja tästä dokumentista">

Tässä käytetään hr-elementtiä, jonka looginen merkitys on aihepiirin vaihtuminen (change of topic), esimerkiksi siirtyminen itse dokumentista sitä koskeviin tietoihin. Tyypillinen tämän elementin esitysmuoto on jonkinlainen vaakasuora viiva, mistä sen nimikin alun perin johtuu (engl. horizontal rule). Halutessaan sitä voi käyttää dokumentin jäsentämiseen otsikoiden ohella siten, että jokaisen ison otsikon edellä on hr-elementti. Tässä esimerkissä hr-elementtiä käytetään otsikon asemesta: osoitetiedot eivät oikein ansaitse omaa otsikkoa, mutta ne on hyvä jotenkin erottaa dokumentin varsinaisesta sisällöstä.

Edellä olevassa esimerkissä osa title="Tietoja tästä dokumentista" on määrite, joka sisältää kommentinluonteisen selityksen elementin käyttötarkoituksesta. Mutta selain voi näyttää määritteen arvon käyttäjälle esimerkiksi siten, että kun kursori on elementin päällä, title-määritteen arvo tulee näkyviin erilliseen pikku ikkunaan lisätiedoksi. Toistaiseksi vain IE 4+ tukee tätä ajatusta.

Samaan yhteyteen voi liittää päiväyksen tai kaksikin päiväystä, jotka kertovat, koska alun perin kirjoitit jutun ja koska olet viimeksi muuttanut sitä. Voi olla hyödyksi kirjoittaa kolmekin päiväystä: alkuperäisen kirjoittamisen ajankohta, viimeisimmän tarkistuksen ajankohta ja viimeisimmän muutoksen ajankohta. "Tarkistus" voisi tarkoittaa tällöin sitä, että sivu on käyty järjestelmällisesti läpi, pyrkien korjaamaan kaikki virheet ja vanhentuneisuudet tai ainakin enin osa niistä, kun taas "muutos" voisi olla mikä tahansa yksittäinen korjaus tai lisäys. Päiväyksen on syytä olla yksiselitteinen eikä esimerkiksi 01/02/03, joka voidaan tulkita ainakin kolmella eri tavalla. Mielestäni paras tapa saavuttaa yksiselitteisyys on käyttää ISO 8601 -standardin mukaista merkintää kuten 1999-04-01, joka tarkoittaa 1. huhtikuuta 1999. Nämä voivat olla tärkeitä asioita lukijalle, joka joskus vuosien kuluttua löytää juttusi.

Webissä voit myös tehdä allekirjoituksestasi linkin kotisivullesi tähän tapaan: 

<address><a href="../henkkoht.html">Jukka K. Korpela</a>,
<a href="mailto:jkorpela@cs.tut.fi"><code>jkorpela@cs.tut.fi</code></a>
</address>

Koska meiliosoite on koodinluonteinen, se on kirjoitettu code-elementin sisään. Edellä esitetty voisi näkyä esimerkiksi seuraavaan tapaan:

Jukka K. Korpela, jkorpela@cs.tut.fi

Tässä sekä nimi että meiliosoite ovat linkkejä. Ensin mainittu johtaa sivulle http://jkorpela.fi/henkkoht.html eli tekijän kotisivulle. Tässä kotisivu tarkoittaa sivua, jolla on tietoja jostakusta ihmisestä.

Sanaa "kotisivu" tarkoitetaan hyvin yleisesti väljemmässä merkityksessä tarkoittamaan jonkun ihmisen henkilökohtaisesti tekemää ja ylläpitämää sivua - tai vielä yleisemmin tarkoittamassa mitä tahansa Web-sivua! Lisäksi se voi tarkoittaa selaimen aloitussivuksi (start page) asetettua sivua taikka jonkin sivuston pääsivua (main page). Tämän epämääräisyyden takia sanaa "kotisivu" on paras kokonaan välttää, paitsi yhteyksissä, joissa sen tarkoitettu merkitys on ilmeinen tai voidaan selittää.

Esimerkin meiliosoite taas on niinsanottu mailto-linkki. Se tarkoittaa, että useissa selaimissa käyttäjä voi klikkaamalla linkkiä käynnistää meiliohjelman siten, että vastaanottaja-kentässä on valmiiksi kyseinen osoite. Meiliosoitteen voisi jättää kokonaan pois tästä yhteydestä silloin, kun nimi on linkki kotisivulle, jolta meiliosoite löytyy. Mutta meiliosoite on sen verran keskeinen yhteystieto, että se ehkä on hyvä mainita nimen yhteydessä.

Millainen kotisivu

Kotisivun (sanan suppeassa merkityksessä) ei tarvitse olla laaja. Sen olisi parempi olla olematta kovin laaja! Sen tarkoitus on olla eräänlainen käyntikortin vastine, joka vastaa lyhyesti kysymykseen, kuka tämä ihminen on, mitä hän on tehnyt ja tekee, miten hänet tavoittaa jne. Taiteelliset tai tieteelliset tuotokset kannattaa panna muille sivuille; kotisivulla on toki hyvä olla linkit niihin (tai niiden luetteloihin, jos niitä on paljon).

Jos kotisivullasi on

niin kotisivusi on hyödyllisempi ja sisältää enemmän tietoa kuin 99 kotisivua 100:sta. (Ihan totta. Paljon on esimerkiksi "kotisivuja", joilla ei edes kerrota tekijän oikeaa nimeä.) Työ- tai opiskelupaikan nimestä voi tehdä linkin kyseisen organisaation Web-sivulle. Tietojen on hyvä olla oikein ja vielä oikeassa, suositellussa muodossa; ks. ohjetta Puhelinnumeroiden ja muiden yhteystietojen esittämisestä.

Millaisia linkkejä? Mistä hyviä kohteita?

Linkkilista?

Millaisia linkkejä sitten kannattaa sivuilleen panna? Kovin usein ihmiset kokoavat sivulleen oman "suosikkilistansa" - ehkä sen tärkeimmäksi tai ainoaksi sisällöksi. Jos tunnet houkutusta sellaiseen, suosittelen lukemaan kirjoitukseni So you want to create a home page?, jossa totean mm. seuraavan:

Useimmilla sellaisilla aloilla, joista ihmisten voi kuvitella olevan kiinnostuneita, linkkilistoja on ylenpalttisesti. (Ks. Zangelding - The Official Homepage.)  - - Lisäksi linkkilistoilla on taipumus vanhentua varsin nopeasti; lista, joka nyt sisältää parhaat linkit voi olla hyödytöntä pahempi puolen vuoden kuluttua. (Se voisi helposti saada ihmiset lukemaan vanhentunutta aineisto sen sijaan, että he käyttäisivät hakujärjestelmiä etsiäkseen, mitä todella on tarjolla).

Linkkilistan voi toki tehdä itselleen, sivuksi, jonka kautta voi suunnistaa; etuna selainkohtaisiin bookmarks- tai favorites-listoihin on se, että Web-sivuksi tekemääsi linkkilistaa voit käyttää kaikilla selaimilla ja kaikilla koneilla, ja toki se saattaa olla muillekin hyödyksi.

Toki julkiseksi tarkoitettukin linkkilista voi olla hyödyllinen. Mutta ei pidä vain kasata isoa joukkoa linkkejä. Sellaisen ylläpito käy aika mahdottomaksi, ellet sitten todella ota hoitaaksesi jonkin alan linkkilistaa.

Lisätietoa-linkit

Sivulle kannattaa panna sellaisia linkkejä, jotka havainnollistavat tai muuten täydentävät sivun varsinaista sisältöä. Jos esimerkiksi olet kirjoittanut sivun, joka kertoo kotikaupunkisi historiasta, on luonnollista liittää sivulle linkki kaupungin omiin Web-sivuihin. Jos löydät Webistä sivuja, joilla kerrotaan mainitsemistasi henkilöistä, paikoista, tapahtumista jne. tarkemmin, niin niihinkin on hyvä viitata. Toisen esimerkin ottaakseni: Jos olet kirjoittanut lyhyen johdatuksen suahilin kieleen, on luonnollista liittää siihen ainakin yksi linkki sivuun, jolla kerrotaan suahilista enemmän.

Erityisesti linkki voi viitata väitteiden perusteluihin. Kyseessä voi olla laaja dokumentti, jossa joku (mahdollisesti kirjoittaja itse) tarkemmin perustelee ja selittää jotain väitettä, tai esimerkiksi vain juttu, jossa joku muu esittää saman kannan kuin kirjoittaja. Jälkimmäinen voi toimia hyvin perusteluna, jos se vetoaa alallaan tunnetun ja tunnustetun asiantuntijan käsitykseen.

Taustatietoa-linkit

Erityisen tärkeitä linkit ovat silloin, kun juttusi edellyttää joitakin erityisiä taustatietoja taikka käytät käsitteitä ja termejä, joita ei voi pitää kovin yleisesti tunnettuina. Sinun ei tarvitse kertoa kaikkea; voit viitata sivuihin, joilla on taustatietoja, määritelmiä jne.

Parasta on, jos sivulla, johon viittaat, on sekä yleistajuinen esitys että muutamia linkkejä tarkempiin ja teknisempiin esityksiin. Vaihtoehtoisesti sivun sisältö voi olla linkkilista, jossa viitataan erityyppisiin ja -tasoisiin esityksiin aiheesta.

Miten löydän linkitettävää?

Hyvien sivujen löytäminen on Webin käyttäjän tärkeä taito, johon tässä ei voida kovin syvällisesti paneutua. Yleisesti korostan seuraavia:

Montako linkkiä per asia?

Tärkeimpien sellaisten asioiden osalta, joihin haluat liittää linkkejä, kannattaa harkita viittaamista pariin kolmeen vaihtoehtoiseen sivuun. Ensinnäkin voi olla, että lukijasi mielestä ensimmäinen linkkisi johtaa hänelle hyödyttömään tietoon, mutta toinen vaihtoehto voisi kelvata. Toiseksi sattuu aika usein, että olennainen linkki ei toimi jostain syystä (esim. kansainvälinen datayhteys poikki). Ja kolmanneksi linkit valitettavan usein lakkaavat toimimasta. Viimeksi mainittuun ongelmaan auttaa osittain se, että liität linkin yhteyteen tiedon siitä, minkä organisaation sivusta on kyse ynnä linkin organisaation pääsivulle. Sen kautta lukijasi ehkä löytää tiedon senkin jälkeen, kun organisaatiossa on taas kerran sotkettu sivujen hierarkia uuteen uskoon.

Hyvässä jutussa on yleensä linkkejä eteenpäin, ja eri jutuissa on hiukan erilaisia, toisiaan täydentäviä linkkilistoja. Eli se, jolle annat pari hyvää linkkiä, todennäköisesti niiden kautta löytää ihan tarpeeksi muita sivuja. Jos annat enemmän linkkejä, sinun on syytä liittää niihin omia kommenttejasi ja luokitella linkkejä jotenkin. Miten lukija, joka oletettavasti tietää asiasta paljon vähemmän kuin sinä, voisi arvata, mitkä linkeistä ovat hänelle tärkeitä?

Esimerkkejä linkittämisestä

Seuraavassa on muutamia esimerkkejä linkittämisen mahdollisuuksista:

Linkkien tekeminen voi olla sinulle itsellesi sekä hauskaa että opettavaista ja myös lukijoillesi suureksi hyödyksi. Mutta älä innostu liikaa, ainakaan liian aikaisin. Tärkeintä on kuitenkin yleensä itse tuottamasi sisältö ynnä esityksesi rakenne, joka nivoo sisällön ja linkit järkeväksi kokonaisuudeksi.

Sivulle, jolla on jambalaya-resepti, voisimme lisätä vaikkapa linkit seuraaville sivuille (jotka ovat löytyneet edellä hahmotelluilla tavoilla):

Voisi tietysti ajatella lisäävänsä myös esim. linkin, joka etsii AltaVistalla tietoja avainsanalla "jambalaya" Mutta kannattaneeko se? Lukija, joka ei osaa käyttää hakupalvelimia, luultavasti hämmentyy suuresti; lukija, joka osaa, osannee tehdä sen ilman sinun linkkiäsikin.

Mitä linkitys oikein on? Pitääkö kysyä lupaa?

Linkittäminen on pelkkää viittaamista. Siihen sisältyy vain ajatus siitä, että lukijaa ehkä kiinnostaisi katsoa sitä dokumenttia, johon linkki viittaa. Ellet erikseen toisin sano, tämä ei sisällä sitä, että esim. hyväksyisit siinä esitetyt mielipiteet!

Vastoin melko tavallista käsitystä normaaliin linkittämiseen ei tarvita lupaa. Luvan kysymiseen voi joskus olla erityinen aihe, esimerkiksi jos hyvin suositulle sivulle aiotaan panna linkki sivulle, joka on pienessä palvelimessa hitaan yhteyden takana; silloin voi olla tarkoituksenmukaista kopioida haluttu sivu omaan palvelimeen, ja siihen tarvitaan lupa.

Sisäiset linkit

Edellä olevissa esimerkeissä linkki on ollut viittaus dokumentin jostakin kohdasta toiseen dokumenttiin. On myös mahdollista ja usein erittäin hyödyllistä rakentaa dokumentinsisäisiä linkkejä sekä linkkejä, jotka viittaavat muiden dokumenttien määrättyihin kohtiin. Näitä vastaavat painetuissa kirjoissa sellaiset viittaukset kuin "ks. s. 42", "ks. liitettä A" ja "ks. Tuntematon sotilas, s. 42".

Kohteen määritteleminen

Sisäistä linkkiä varten tarvitaan kohteeseen HTML-elementti, joka on muotoa

<a name="nimi">tekstiä</a>

Tämä tekee dokumenttiin kohteen, johon voi viitata linkeillä, joissa href-määritteen arvo on
"#nimi" (dokumentinsisäisissä linkeissä)
tai
"osoite#nimi" (muissa dokumenteissa olevissa linkeissä).

Edellä kuvattua menettelyä käytettäessä on huolehdittava siitä, että a-elementin sisällä on vain tekstiä ja tekstitason merkkausta (ei kuitenkaan a-elementtejä). Tällaista rajoitusta ei ole, jos käytetään vaihtoehtoista tapaa linkin kohteen määrittelemiseen: id-määritettä, joka voidaan liittää useimpiin elementteihin:

id="nimi"

Vertaa seuraavia:

<h2><a name="tulokset">Tutkimuksen tulokset</a></h2>
<h2 id="tulokset">Tutkimuksen tulokset</h2>

Kummassakin tapauksessa voidaan kyseiseen otsikkoon viitata linkeillä samalla tavoin, esim. href="#tulokset". Eräät vanhat selaimet eivät kuitenkaan tunnista id-määritettä, joten vanhempi tapa on hiukan luotettavampi.

Esimerkki sisäisestä linkistä

Voimme esimerkiksi kirjoittaa sivun loppuun luvun, jossa on otsikkona Huomautuksia:
<h2><a name="huom">Huomautuksia</a></h2>
ja eri kohdissa sivua viitata siihen seuraavanlaisella rakenteella:
Tästä on lisätietoja luvussa <cite><a href="#huom">Huomautuksia</a></cite>.

Muotosääntöjä

Määritteessä id="nimi" on tiukat rajoitukset nimen muodolle: nimi alkaa englannin kielen kirjaimella (A - Z tai a - z), ja se saa sisältää vain seuraavia merkkejä: englannin kielen kirjaimia, numeroita (0 - 9), yhdysmerkkejä (-), alaviivoja (_), kaksoispisteitä (:) ja pisteitä (.). Yleensä kannattaa käyttää vain kirjaimia, numeroita ja yhdysmerkkejä. Määritteessä name="nimi" on periaatteessa paljon väljemmät säännöt: nimi voi sisältää mitä tahansa merkkejä. Käytännössä muut kuin edellä mainitut merkit aiheuttavat usein ongelmia.

Nimiavaruus

Määritteessä id="nimi" tai a-elementin name="nimi" -määritteessä ilmoitetun nimen tulee olla yksikäsitteinen dokumentin sisällä. Tämä tarkoittaa, että yhdessä dokumentissa ei sama merkkijono saa esiintyä kahdessa eri kohdassa kyseisissä yhteyksissä. Tämähän on luonnollista: mistä muuten tiedettäisiin, mihin href="#nimi" viittaa?

Linkki sivun alkuun on turha

Usein näkee käytäntöä, jossa sivu sisältää esimerkiksi jokaisen pääkohdan jälkeen linkin, jonka tekstinä on vaikkapa "Takaisin alkuun". Sen lisäksi, että sellainen teksti on jossain määrin epäselvä (minkä alkuun se viittaa?), koko linkki on tarpeeton.

Kaikissa selaimissa on jokin yksinkertainen tapa päästä sivun alkuun. Varsin usein voidaan käyttää näppäimistön Home-näppäintä. Joka tapauksessa alkuun pääsee helposti, joten on turhaa tehdä sivukohtainen korvike sille. Sitä paitsi "Takaisin alkuun" -linkit näyttävät hassuilta paperitulosteissa!

Ole linkitettävissä!

Edellä sanotusta seuraa, että voit viitata määrättyyn kohtaan jonkun muun tekemässä dokumentissa vain, jos se joku muu on kirjoittanut edellä mainitun kaltaisen elementin siihen kohtaan. Vastaavasti tietysti pätee, että muut eivät voit viitata sinun juttusi eri kohtiin, ellei sinä ole sitä mahdollistanut.

Jotta muut voisivat kätevästi viitata dokumenttisi osiin, jotka ovat heidän aiheidensa kannalta tärkeitä, kannattaa sinun kirjoittaa joko a name -elementit tai id-määritteet ainakin kaikkiin otsikoihin.

Eikä olisi liioittelua kirjoittaa a name -elementtiä myös jokaisen kappaleen alkuun tai liittää kuhunkin p-elementtiin oma id-määrite. (Tosin otsikon jälkeiseen ensimmäiseen kappaleeseen sellaista ei tarvita, jos edellä annettua perussuositusta on noudatettu.) Onhan ainakin hyvä kirjallinen esitys jaettu kappaleisiin nimenomaan sisältönsä rakenteen mukaan, joten kappale on luonteva viittaamisen kohde.

Sinua ehkä huolestuttaa se, että linkin kautta lukija "hyppää keskelle" sinun juttuasi eikä lue sen osaa asiayhteydessään. "Keskelle hyppäävät" linkit ovat kuitenkin keskeinen osa hypertekstin voimaa. Käytä sitä hyväksesi, älä taistele sitä vastaan. Fiksu lukija osaa kyllä kelata juttua taaksepäin, jos se on asian ymmärtämiseksi tarpeen tai häntä kiinnostava yksityiskohta on saanut hänet kiinnostumaan jutustasi muutenkin. Mutta jos silti pidät asiaa ongelmana, voit dokumentinsisäisillä linkeillä yrittää auttaa lukijaa nopeasti löytämään sen, mitä hän "keskelle hypättyään" todennäköisesti tarvitsee. Voit toimia aina a name -elementin jälkeen kuten dokumentin alussa siinä mielessä, että teet esim. teknisen termin ensiesiintymästä linkin sen määritelmään.

Linkitettävyyteen kuuluu myös se, että kun lukija päätyy jonkin linkin kautta sinun dokumenttiasi katsomaan, hän voi helposti päästä selville, mihin kokonaisuuteen dokumentti kuuluu. Tätä aihetta käsittelemme myöhemmin kohdassa Irti irrallisista sivuista.

Käytännön neuvoja a name -elementtien kirjoittamisesta

Kirjoita a name -elementit seuraavasti:

Edellä olevat säännöt ovat siinä mielessä vahvasti yksinkertaistetut, että ne eivät ole kielestä itsestään johtuvia rajoituksia. Tässä on kuitenkin otettu huomioon käytännön seikat kuten selainten bugit ja pyritty menettelyyn, joka varmasti toimii. Syynä suositukseen tekstitason merkkauksen ja linkkimerkkauksen suhteesta on se, että tekstitason merkkaus voi aiheuttaa tekstin värin muuttumisen. Linkkien värien olennaisuuden takia on tällöin parempi, että linkkivärit "voittavat" sellaisen vaikutuksen, ja CSS:n säännöistä seuraa, että sisempi elementti voittaa.

Hypertekstisisällysluettelo

Ellei dokumentti ole lyhyt, sen alkuun kannattaa yleensä kirjoittaa sisällysluettelo, jonka kohdat ovat linkkejä eri osien otsikoihin. Sopiva paikka sille on johdantokappaleen jälkeen. Sisällysluettelon tekeminen voi tuottaa tekijällekin ahaa-elämyksen, kun hän huomaa, että dokumentin jäsennystä voisi parantaa esim. paremmalla otsikoinnilla, osien järjestystä muuttamalla tai osia jakamalla tai yhdistämällä.

Yksinkertainen sisällysluettelo on luontevaa kirjoittaa listaksi (ul-elementiksi), jossa kukin alkio (li-elementti) sisältää vain yhden linkkielementin (a href). Monimutkaisemmassa tapauksessa, kun jutussa on eritasoisia otsikoita, tarvitaan hiukan mutkikkaampi rakenne. Tätä havainnollistaa seuraava esimerkki, joka sopisi Jambalaya-sivumme sisällysluetteloksi. 

<h2>Sisällys</h2>
<ul>
<li><a href="#ainekset">Ainekset</a></li>
<li><a href="#astiat">Astiat</a></li>
<li>
  <a href="#valmistus">Valmistus</a>
  <ul>
    <li><a href="#perus">Perusosan valmistus</a></li>
    <li><a href="#lisa">Lisäosan valmistus</a></li>
  </ul>
  </li>
<li><a href="#tarjoilu">Tarjoilu</a></li>
</ul>

Sisällysluettelolla varustettu versio sivusta on rakenteeltaan selkeä, mutta luettelo vie monen mielestä liikaa tilaa. Vaihtoehtona on - etenkin jos luettelon kohtien tekstit ovat lyhyitä - käyttää rakennetta, jossa listan asemesta on linkit vain peräkkäin sopivalla erotinmerkillä kuten pystyviivalla erotettuina, taikka kirjoittaa sisällysluettelo yksiriviseksi taulukoksi.

Kyseinen sivu on rajatapaus sen suhteen, kannattaako siihen kirjoittaa sisällysluettelo. Mutta tämä yksinkertainen esimerkki sopinee havainnollistamaan kaksitasoisen sisällysluettelon tekemistä

Laajalle dokumentille, jossa on eritasoisia otsikoita, voi kirjoittaa myös vain yksitasoisen sisällysluettelon. Silloin voi kunkin luvun alkuun - jonne siis pääsee linkillä sisällysluettelosta - kirjoittaa luvun oman tarkemman sisällysluettelon.

Näkyminen netissä, eli miten muut löytävät sivusi

Yksi tavallisimmista sivuntekijöiden ongelmista on saada sivunsa tunnetuiksi. Usein tämä muotoillaan tekniseksi kysymykseksi "miten saan sivuni näkyviin hakukoneissa?", jopa "miten pääsen listan kärkeen hakukoneissa?". Usein kysymys on aivan ennenaikainen. Jos sivulla ei ole mitään varsinaista sisältöä, on parempi, että kukaan ei vielä löydä sitä.

Sisällys

Miten sivu saattaa löytyä?

Miten ylipäänsä kukaan voi löytää mitään miljoonien Web-sivujen joukosta? Tapoja on monia:

  1. Vinkit. Joku mainitsee Web-sivun osoitteen esimerkiksi sanomalehdessä, kahvipöytäkeskustelussa tai nyyseissä sellaisessa asiayhteydessä, että joku muu kiinnostuu ja käy katsomassa. Joskus homma jopa toimii, jos osoite on ilmoitettu oikein (tai vain sillä tavoin väärin, että käytetty selain selviytyy siitä).
  2. Linkit. Joku kirjoittaa omalle sivulleen linkin sinun sivullesi. Tämä tietysti edellyttää, että se joku on ensin löytänyt sinun sivusi (ja että hänen sivunsa on sitten jonkun muun löydettävissä).
  3. Hakemistot. Sivusi saattaa tavalla toisella - myös tietämättäsi - päätyä erilaisiin hakemistoihin. Yksinkertaisimmillaan hakemisto on pelkkä lista linkkejä jotakin aihetta käsitteleviin sivuihin. Hakemisto voi myös olla hierarkkisesti jäsennetty, siinä voi olla kommentteja sivuista, joihin se viittaa, siihen voi liittyä hakutoimintoja jne. Yleisesti tämä tapa on erikoistapaus edellä mainitusta, linkeistä, mutta tärkeä erikoistapaus.
  4. Hakupalvelimet (search engines). Niitä on suuri määrä erilaisia, mutta muutaman hyvän hakupalvelimen käytön osaaminen kuuluu webinkäyttäjän perustaitoihin.

Vertaa aiemmin esitettyyn kuvaukseen hyvien sivujen etsimisestä. Tässä tarkastelemme asiaa toiselta kannalta: sivun tekijänä, joka haluaa sivujensa löytyvän. Asenteeksi on kuitenkin syytä ottaa löydettävyyden lisääminen, ei tuputus.

Sivujen löydettävyyden parantaminen

Perusmenetelmiksi voimme ottaa edellä kuvattuja löytämistapoja vastaavat tavat:

  1. Voit antaa vinkkejä tuntemillesi ihmisille, joiden tiedät olevan kiinnostuneita sivujesi aihepiiristä. Voit lehtijutussa tai nyysiartikkelissa mainita sivusi silloin, kun se liittyy asiaan.
  2. Voit ehdottaa muille, että he lisäävät sivuilleen linkkejä sinun sivuillesi. Sopiva tilanne on esimerkiksi sellainen, jossa jonkun muun sivu käsittelee samaa aihepiiriä kuin sinun sivusi ja ne täydentävät toisiaan (esim. yleiskuvaus ja tärkeän yksityiskohdan kuvaus taikka yleistajuinen ja tekninen kuvaus).
  3. Voit ehdottaa sivuasi hakemistoihin. Usein esimerkiksi pidetään tärkeänä saada omat sivut Yahoo-hakemistoon, koska se on niin suosittu. Saahan sitä ehdotella (ja esim. Yahoolla on ohjeet menettelytavoista), mutta ensinnäkin ehdotusten käsittely on aika hidasta ja toiseksi Yahoo on sittenkin aika sekava ja tasoltaan kirjava. Kiinnostavampi vaihtoehto on dmoz eli Open Directory Project, jossa on myös laaja suomenkielisten sivujen alue ja jonka tietoja käytetään monien muiden hakemistojen (mm. Google-hakemiston ylläpidossa). Suomalaisia sivuja, jos niillä on todella hyvää ja laajasti kiinnostavaa sisältöä, voi ehdottaa myös esim. Makupaloihin.
  4. Voit ilmoittaa sivusi hakupalvelimille. Tätä ei kannata tehdä joka sivulle erikseen, sillä kun linkität sivusi toisiinsa, hakupalvelimet kyllä löytävät ne aikanaan, kunhan ne "pääsevät käsiksi" yhteenkin niistä. Mutta alkuun pääsemiseksi voi olla tarpeen ilmoittaa yhdestä sivusta muutamille yleisesti käytetyille hakupalvelimille.

    Seuraavassa listassa palvelimien nimet ovat linkkejä niiden sellaisille sivuille, joilta voit ilmoittaa oman sivusi (liitettäväksi palvelimen tietokantaan).

    Yleisesti hakupalvelimen pääsivulta varsin usein löytyy jostain lopusta ainakin pienellä tekstillä "Add URL" tms. linkki, jota kautta pääset mainitunlaiselle sivulle.

    Ota huomioon, että ilmoittaminen ei yleensä vaikuta aivan välittömästi, eikä välttämättä ollenkaan. Mutta esimerkiksi viikon kuluttua voit hakupalvelimella etsiä, löytyykö sivujasi, esim. käyttämällä hakulauseketta, jossa on useita juuri sille ominaisia sanoja.

Miten hakupalvelut ("hakukoneet") toimivat

Yleisesti käytetty ilmaisu "hakukone" on virheellinen käännös englannin ilmaisusta "search engine"; englannin sana "engine" tarkoittaa monia muitakin asioita kuin niitä, joita suomen "kone" tarkoittaa, kuten yleisesti välinettä. Tässä se viittaa kokonaiseen järjestelmään, jossa on useita suhteellisen erityyppisiä osia.

Hakupalvelu koostuu tyypillisesti seuraavista osista:

Hakupalvelut ovat yksi keskeisimpiä syitä tehdä sivut niin, että ne ovat muun ohessa "tekstiystävällisiä", toisin sanoen sellaisia, että jos lukee vain tekstuaalisen sisällön, saa sivusta irti sen, mitä sillä tavoin on ylipäänsä saatavissa. Jos sivulla on esimerkiksi vain kuvagalleria ilman mitään selityksiä, niin se on hakupalvelun mielestä sisällötön sivu. Mutta jos sivulla on otsikko ja lyhyt selitys, millaisista kuvista on kyse, ynnä kuvatekstit, niin siinä on jo indeksoitavaa. Ja tämän perusteella sitten se, joka etsii jotakin aihepiiriä käsitteleviä kuvia, voi löytää sen gallerian.

Kuvauksen esittäminen meta-elementissä

Voit lisäksi kirjoittaa dokumenttiisi sellaisen meta-elementin, joka sisältää lyhyen kuvauksen sivun sisällöstä. Sen muoto on 

<meta name="description" content=
"Lyhyt kuvaus, pelkkää tekstiä.">
Sen voi kirjoittaa heti title-elementin perään. Sen merkitys on siinä, että jotkin hakupalvelimet esittävät sellaisen kuvauksen "osumalistoissa". Muita hakupalvelimia varten ja muistakin syistä saattaa kannattaa lisäksi kirjoittaa dokumentin varsinaisen tekstin alkuun tiivistelmä, kuten edellä kuvattiin. Esimerkiksi jambalaya-sivumme alkuun voisimme lisätä meta-elementin tähän tapaan: 
<title>Jambalaya-resepti suomal. makuun (J. Korpela)</title>
<meta name="description" content=
"Miedohko, suomalaiseen makuun sopiva muunnelma jambalayasta.
Valmistetaan kahdessa astiassa - ruuan perusosa on lastenkin mieleen,
ja toinen osa sisältää voimakkaammasta mausta pitäville lisän,
joka voidaan yhdistää perusosaan lautasella.">
<h2>Jambalaya suomalaiseen makuun à la Yucca</h2>
<p>
Tämä on miedohko, suomalaiseen makuun sopiva muunnelma jambalayasta.
Tässä se valmistetaan kahdessa eri astiassa siten, että ruuan
perusosa on lastenkin mieleen ja toinen osa sisältää voimakkaammasta
mausta pitäville lisän, joka voidaan yhdistää perusosaan lautasella.
</p>

Näin muokattu sivu näkyy selaimella aivan samanlaisena kuin aiempi versio, mutta hakupalvelimet saattavat kuvata sen eri tavalla. Seuraava eräällä hakupalvelimella eräässä tilanteessa saatu tulos havainnollistaa asiaa:

1. Jambalaya-resepti suomal. makuun (J. Korpela)
Jambalaya suomalaiseen makuun à la Yucca. Tämä on miedohko, suomalaiseen makuun sopiva muunnelma jambalayasta. Tässä se valmistetaan kahdessa eri astiassa.
URL: www.hut.fi/u/jkorpela/webjulk/jambalaya.html
Viimeksi muutettu: 28.5.1999 - sivun koko: 2764 tavua - kieli: suomi.
2. Jambalaya-resepti suomal. makuun (J. Korpela)
Miedohko, suomalaiseen makuun sopiva muunnelma jambalayasta. Valmistetaan kahdessa astiassa - ruuan perusosa on lastenkin mieleen, ja toinen osa sisältää
URL: www.hut.fi/u/jkorpela/webjulk/jambameta.html
Viimeksi muutettu: 28.5.1999 - sivun koko: 3038 tavua - kieli: suomi.

Esimerkkitapauksessa on lähinnä makuasia, kumpi esitys on informatiivisempi. Tilanne voi olla toinen silloin, kun sivun varsinaisessa sisällössä ei ole tiivistelmäksikin sopivaa tekstiä ihan alussa. Toisaalta silloin useat hakupalvelimet joka tapauksessa näyttävät sivun hassusti - kaikki niistä kun eivät välitä mitään meta-elementeistä.

Muut meta-elementit ja muita lisätietoja

On olemassa muunkinlaisia meta-elementtejä kuin edellä kuvattu. Niiden hyödyllisyys on kuitenkin sangen kyseenalainen.

Monet sivuntekijät (tai heille palveluja tarjoavat ihmiset ja yritykset) sanovat meta name="keywords" -elementtejä hyvin tärkeiksi, koska niiden oletetaan parantavan sivun löytyvyyttä sille ilmoitettujen avainsanojen kautta. Totta on, että esimerkiksi AltaVistan ohjeissa on tällaisia elementtejä koskeva kohta, mutta sen sävy on muuttunut aiemmasta aktiivisesta suosittelemisesta varoitteluun. Esimerkiksi AltaVistan meta-ohjeiden eräs versio sanoi erityisesti (suom. JK):

Se, mikä on tärkeää useimmille AltaVistan käyttäjille, on todellinen sisältö, joka näkyy Web-sivuilla, eivät markkinointiin suuntautuneet huomautukset, jotka on lisätty meta-tägeillä. Ja teksti, joka esiintyy title-elementissä ja muutamalla ensimmäisellä rivillä, todennäköisesti liittyy läheisesti sivun tärkeimpään sanomaan.

Eräs meta-tägien alalaji on kuitenkin syytä mainita, koska sitä voidaan tarvita indeksoitumisen estämiseen:
<meta name="robots" content="noindex,nofollow">
Tämä on indeksointiroboteille esitetty pyyntö olla käsittelemättä mitenkään sitä sivua, jolla tämä elementti on. Tästä voi olla hyötyä, jos kyse on esimerkiksi pelkästä testisivusta, johon kuitenkin on testauksen vuoksi linkkejä normaaleilta sivuilta. Varmempi tapa vaikuttaa indeksointiin olisi ns. robots.txt-tiedosto, mutta sen pitäisi sijaita palvelimen "juuressa" ja sen tekeminen ja muuttaminen on muutoinkin palvelimen ylläpidon asia. Aiheesta kertoo lisää Jouni Heikniemen kirjoitus Kuinka estää hakukonetta löytämästä minua? ja englanniksi robotstxt.org-sivusto.

Lisätietoja:

Kuvia putkeen

Sisällys

Yksi kuva sanoo enemmän kuin tuhat sanaa, sanotaan (miten se muuten sanotaan kuvalla?). Tosin ehkä ihan eri asian kuin oli tarkoitus. Joka tapauksessa yksi kuva helposti vie enemmän datansiirtokapasiteettia kuin tuhat sanaa. Mutta kuvilla on käyttönsä. Esimerkiksi eläinlajin esittely ilman kuvaa eläimestä olisi aika puutteellinen.

Miten kuvia saa sivulle

Kun haluat kuvittaa dokumenttiasi, tarvitset ensin kuvia digitaalisessa, tietokoneella luettavassa muodossa, jossakin yleisesti tuetussa kuvaformaatissa. Tavallisimmat kuvaformaatit ovat Gif ja Jpeg, joista jälkimmäistä käytetään nimenomaan valokuville. Uudemmalla PNG:llä on useita etuja, mutta selainten PNG-tuki on vielä puutteellinen. Tietoja kuvaformaateista löytyy seuraavien sivujen kautta; Grafiikkaformaatit ja niiden käsittely ja W3C material on graphics formats.

Kuvaformaateista sinänsä sinun ei tarvitse tietää paljoakaan, kunhan osaat käyttää jotain ohjelmaa, jolla saadaan kuvia johonkin kuvaformaattiin. Tavallisimpia vaihtoehtoja kuvien tuottamiseen:

Toisen tekemää kuvaa ei saa ilman lupaa käyttää omalla Web-sivulla, kuten ei toisen kirjoittamaa tekstiäkään. Ks. tarkemmin selostusta Miks mä muka en sais skännätä tätä veppisivulleni eli mitä jokaisen tietokoneen käyttäjän pitäisi tietää tekijänoikeudesta.

Vaihtoehdot: linkitys ja upotus

Kuvaan voi viitata linkillä, esim.
<a href="baby.jpg">kuva minusta pienenä</a>
jolloin viittaavalla sivulla näkyy normaali tekstilinkki kuten kuva minusta pienenä ja sitä seurattaessa kuva tulee näkyviin. Tämä tarjoaa monipuolisia vaihtoehtoja, koska käyttäjä voi esimerkiksi avata kuvan samaan tai uuteen selainikkunaan, tulostaa sen erikseen, tallentaa sen omaan koneeseensa myöhemmin katseltavaksi jne. Myös selaimella, joka ei tue kuvia, on mahdollista seurata tällaista linkkiä ja ottaa kuva talteen tiedostoon (esim. siirrettäväksi toiseen ohjelmaan tai koneeseen, jossa sitä voi katsoa).

Toinen vaihtoehto on "upottaa" kuva dokumenttiin seuraavassa kohdassa kuvattavalla img-elementillä, jolloin se näkyy kiinteänä osana sivua, kun sivua katsotaan graafisella selaimella, joka on konfiguroitu lataamaan ja näyttämään kuvat automaattisesti (tai kyseinen kuva on erikseen ladattu).

Kumpaa tapaa sitten kannattaa käyttää? Yleisesti: mitä isompi kuva, sitä vakavammin kannattaa harkita linkittämistä upotuksen asemesta. Sama koskee tilannetta, jossa kuva on suhteellisen erillinen "oheiskuva". Olennaista on antaa käyttäjälle mahdollisuus valita, mitä hän katsoo ja mihin hän aikaansa käyttää; kuvien latautumiseen kuluva aika on usein hyvin konkreettisesti rahaa esim. yhteyden aikaveloituksen takia.

On myös mahdollista yhdistää mainitut tavat. Ensinnäkin voit upottaa sivulle pienikokoisen version kuvasta, joka on linkki kuvan isompaan versioon. Jäljempänä selostetaan tarkemmin, että kuvakin voi olla linkki (toiseen kuvaan, HTML-dokumenttiin tai johonkin muuhun). Toisaalta jos haluat, että kuvan voi ladata ja sitä voi katsella erillisenä mutta niin, että siihen liittyy lyhyt kuvateksti, voit tehdä linkin, joka viittaa HTML-dokumenttiin, joka sisältää upotetun kuvan ja siihen liittyvän tekstin. Linkki voi siis viitata joko kuvaan sellaisenaan tai HTML-dokumenttiin, jonka osana on kuva.

Kuva sivun osana HTML:n kannalta: img-elementti

HTML-dokumenttiin liitetään kuva seuraavanlaisella img-elementillä:

<img alt="tekstivaihtoehto" src="osoite">

missä

Esimerkki, jossa käytetään pakollisten määritteiden lisäksi align-määritettä, jolla ulkoasu saadaan paremmaksi: 

<p><strong>Tehtävä 42</strong>. Laske
<img src="integral.gif" align="middle" alt=
"lausekkeen exp(x**2) integraali, kun x menee
0:sta äärettömään."></p>

Tässä alt-määrite huolehtii siitä, että annettu tehtävä on täysin ymmärrettävissä kuvattomassakin esityksessä. Sinun käyttämälläsi selaimella rakenne näkyy nyt näin:

Tehtävä 42. Laske lausekkeen exp(x**2) integraali, kun x menee 0:sta äärettömään.

Jossakin toisessa tilanteessa esitysmuoto voisi olla seuraavanlainen:
Tehtävä 42. Laske lausekkeen exp(x**2) integraali, kun x menee 0:sta äärettömään.

Yleisesti alt-määrite on erittäin olennainen sen kannalta, että sivu toimii myös tilanteessa, jossa selain ei esitä kuvia tai käyttäjä muusta syystä ei niitä näe. Tämän määritteen arvo ilmoittaa ikään kuin "sijaisen" kuvalle, siis tekstin, joka tuuraa kuvaa tämän poissa ollessa. Sen siis ei pitäisi nimetä tai kuvailla kuvaa vaan tehdä sen hommat niin hyvin, kuin teksti vain voi. Lisätietoja: Jouni Heikniemen Kunnollinen alt-teksti kuville ja Jukka K. Korpelan Guidelines on alt texts in img elements.

On ehkä hyvä ajatella, että img-elementti on kahtalainen, duaalinen. Se on "olio", jolla on kaksi mahdollista ilmenemismuotoa: tekstimuotoinen ja kuvamuotoinen. Tekstimuotoisen vaihtoehdon ilmoittaa alt-määrite, kuvamuotoiseen taas viittaa src-määrite.

Huomautuksia:

img-elementtiin voidaan ja on yleensä suotavaa kirjoittaa myös width- ja height-määrite, jotka ilmoittavat kuvan leveyden ja korkeuden kuvapisteinä eli pikseleinä (pixels). Tämän merkitys on siinä, että selain voi varata tilan kuvalle jo ennen kuin se on saanut itse kuvadatan. Tällöin käyttäjä saa sivun näkyviinsä nopeammin. Mutta jos et tiedä, miten saat kuvan ulottuvuudet pikseleinä selville, jätä nämä määritteet pois. Jos nimittäin annat väärät tiedot, selain skaalaa kuvan niiden mukaiseksi, mikä voi merkitä melkoista kuvan vääristymistä. Kyseiset määritteet kannattaa jättää pois myös silloin, kun kuva on pieni suhteessa alt-tekstiin, koska eräät suositut selaimet eivät silloin osaa näyttää kyseistä tekstiä kunnolla.

Tällaisen elementin voi sijoittaa omaksi kappaleekseen (p-elementin sisään) mutta myös tekstikappaleen yhteyteen. Kuvan ja tekstin keskinäisiin suhteisiin sijoittelussa voidaan vaikuttaa img-elementtiin liitettävällä align-määritteellä. Ks. Dianne Gormanin havainnollista dokumenttia Aligning Images and Text. Tässä vain aivan perusteita:

Kuva linkkinä

Finland Linkin yleisen rakenteen kuvauksessa mainittiin, että linkkitekstin tilalla voi olla myös kuva. Tällainen linkki ei sinänsä poikkea normaalista linkistä muutoin. Esimerkki:
<a href="finland.html" title="General information about Finland"><img src="suomi.gif" alt="Finland"></a>
Esimerkkitapauksessa linkki viittaa englanninkieliselle sivulle, jolla hiukan yleistietoa Suomesta. Kun kuva on linkkinä, on erityisen tärkeää, että alt-teksti kirjoitetaan niin, että se hoitaa mahdollisimman hyvin sen tehtävän, jonka kuva hoitaisi, jos näkyisi. Tässä tapauksessa sana "Finland", joka näkyy linkkinä, kertonee suunnilleen, mistä on kyse. Jos olisi kirjoitettu selostus kuvasta, millä kielellä hyvänsä, esim. "Finnish flag", se johtaisi pahasti harhaan.

Useimmat selaimet näyttävät linkkinä olevan kuvan ympärillä reunuksen. Tämä hyödyllinen piirre auttaa katsojaa näkemään, mitkä kuvat ovat linkkejä ja mitkä eivät, ja lisäksi reunuksen väri kertoo (linkkitekstien värien tapaan), onko linkin kohde sellainen, jossa käyttäjä on (hiljattain) käynyt. Joskus, kuten esimerkkitapauksessa, voi reunus tuntua epäesteettiseltä, asiaankuulumattomalta. Teknisesti reunuksen voi estää lisäämällä img-elementtiin määritteen border="0" (joskin kehittynyt selain saattaa silti näyttää reunuksen). Reunuksen estäminen on mielekästä lähinnä silloin, kun muilla keinoin tehdään käyttäjälle selväksi, mitkä kuvat ovat linkkejä.

Yleensä on syytä välttää kuvien käyttöä linkkeinä. Yksi syy tähän on edellä kuvattu dilemma: reunus tarvittaisiin, mutta se voi näyttää sopimattomalta. Linkkejä voidaan kyllä kuvittaa, mutta sen voi tehdä niin, että jutussa on normaali tekstilinkki ja sen yhteydessä kuvituksena kuva. Kuvan ei tällöin tarvitse olla linkki, tai siitä voidaan tehdä linkki, joka ei näytä linkiltä (border="0"), siltä varalta, että sivulla kävijä on oppinut napsauttelemaan kaikkia kuvia! Ks. esimerkkiä kohdassa Suunnitelma - miksi? Siinä reunus olisi aika häiritsevä, koska itse kuva ei ole suorakaiteen muotoinen. Tai teknisesti on, mutta ns. läpinäkyvyystekniikalla (transparency) se saadaan näyttämään muunmuotoiselta.

Kohdassa Karttalinkit (imagemaps) kerrotaan, miten kuvasta voi tehdä eräässä mielessä sellaisen linkin, että kuvan eri kohtien napsauttamisella on erilainen vaikutus. (Normaalissa kuvalinkissä on toki samantekevää, mihin kohtaan kuvaa käyttäjä napsauttaa.)

Valokuvan laittaminen Web-sivulle

Tarvitset skannerin siihen liittyvine ohjelmineen ja käyttöohjeineen. Skanneri (engl. scanner) on laite, joka siirtää kuvan digitaaliseen, tietokoneella käsiteltävissä olevaan muotoon, skannaa kuvan.

Helpoimmin onnistuu paperikuvan skannaaminen. Diakuvan tai negatiivin skannaus vaatii lisälaitteita ja lisäohjeita.

Valokuvan laittaminen Web-sivulle paperikuvasta lähtien käy näin (tyypillisellä skannerilla):

  1. Tarkista, että skanneriin on kytketty virta (yleensä siinä palaa esim. pieni vihreä valo tämän merkiksi).
  2. Nosta skannerin kansi ja pane kuva valotuslasille kuvapuoli alaspäin.
  3. Aloita kuvan skannaus käynnistämällä sopiva ohjelma tietokoneessa, johon skanneri on kytketty. Kunkin skannerin mukana tulee yleensä oma ohjelmansa.
  4. Noudata skannausohjelman käyttöohjeita ja vastaa sen mahdollisesti esittämiin kysymyksiin. Se saattaa esimerkiksi odottaa, että valitset sen skannaamasta alueesta (kuva taustoineen) sen osan, jonka todella haluat (yleensä vain itse kuvan).
  5. Tallenna, edelleen ohjelman käyttöohjeita tarvittaessa lukien, kuva tiedostoon. Yleensä ohjelma tarjoaa useita erilaisia vaihtoehtoja tallennusmuodoksi eli formaatiksi. Valokuville sopivin on yleensä JPEG-muoto. Tiedosto saa tällöin tavallisesti tyyppimerkinnän .jpg, joka liittyy tiedostolle antamasi nimen perään. (Jos skannausohjelma ei tue JPEG-muotoa, tallenna kuva jossain muussa formaatissa ja muunna muoto myöhemmin, ks. seuraavasta kohdasta.) Näin saatu kuva on yleensä liian hyvä. Tämä tarkoittaa sitä, että siinä on enemmän esitystarkkuutta ja kokoa kuin nykyisin ja lähitulevaisuudessa kannattaa käyttää Webissä. Niinpä...
  6. Käynnistä sopiva kuvankäsittelyohjelma eli ohjelma, jolla voi muokata digitaalisessa muodossa olevia kuvia. Voit nyt eri tavoin muokata kuvaa tavoilla, mutta ensisijaisesti tarvitset keinon pienentää kuvaa siten, että alkuperäiset mittasuhteet säilyvät. Selvitä ohjelman käyttöohjeista, miten tämä tapahtuu.
  7. Pienennä kuva kohtuullisen kokoiseksi ja tallenna se valintasi mukaan joko eri nimellä tai samalla nimellä kuin alkuperäinen kuvatiedosto sen mukaan, haluatko säilyttää (ja ehkä panna Webiinkin) myös alkuperäisen, isomman ja tarkemman kuvan. Kohtuullinen koko riippuu tilanteesta. Voit kokeilla erilaisia kokoja ja katsoa, miltä ne näyttävät ruudulla. Nyrkkisäännöksi voisi antaa, että 400 pikselin leveyden ylittäminen vaatii hyvin painavat perusteet. (Ohjelman käyttöohjeista ilmenee, miten saat selville kuvan koon pikseleinä eli kuvapisteinä ja miten saat kuvan muunnettua haluttuun pikseleinä ilmaistuun kokoon.)
  8. Siirrä tai kopioi kuvatiedosto(t) samaan hakemistoon, missä HTML-dokumenttisi ovat. Jos käytät tähän FTP-ohjelmaa, on syytä antaa FTP-ohjelman sisällä ennen itse siirtoa käsky binary. (Muutoin se voi yrittää siirtää kuvan tekstin tapaan, jolloin kuvatiedoston rakenne särkyy.)
  9. Kirjoita HTML-dokumenttiisi edellä kuvatun lainen img-elementti siihen kohtaan, mihin haluat kuvan. Esimerkki: 
    <p><img alt=
"Olen vaaleatukkainen, rillipäinen nuori mies."
src="foto.jpg" width="200" height="350"></p>

Lisää kuvista

Jos sinulla on paljon kuvia ja haluat tehdä niistä oikein kuvagallerian, niin yleensä ei kannata panna suurta määrää kuvia yhteen dokumenttiin, koska sivun latautuminen olisi kovin hidasta etenkin modemilinjalla.

Yksi yleisesti käytetty menettely on ns. thumbnail-tekniikka: Sopivaa kuvankäsittelyohjelmaa käyttäen tehdään kustakin kuvasta pienennetty versio, tavallisesti keskenään samankokoisiksi. Sitten kirjoitetaan hakemistosivu, jolla on ne pienennetyt versiot, "thumbnailit", jotka ovat linkkejä täyskokoisiin kuviin. Tällöin hakemistosivulta näkee havainnollisesti, millaisia kuvia on tarjolla. Hyvä esimerkki on EKLYn Lintukuvia-sivu.

Yksinkertaisempi vaihtoehto on tehdä tekstimuotoinen hakemistosivu, jolla on vain kuvien nimet, jotka ovat linkkejä kuviin. Ks. esim. hakemistoa Koirien värejä - Canine colors, jossa linkit viittaavat sivuihin, joilla on kullakin yksi kuva ja sen selitysteksti.

Muutenkin kannattaa muistaa, että kuviin voi viitata myös linkeillä, niitä ei ole pakko "upottaa" osaksi sivua. Jos sinulla on paljon juttuusi sopivaa kuvitusta, sijoita vain kaikkein olennaisin ja paras osaksi itse juttua. Muihin kuviin voit viitata linkeillä niin paljon kuin haluat. Näin ne, jotka haluavat nähdä nopeasti olennaisimman, eivät joudu turhaan odottelemaan kuvien latautumista.

Kuvien käytön erilaisia tarkoituksia ja niihin liittyviä näkökohtia käsittelee kirjoitukseni Kuvien käytöstä viestinnässä yleensä ja Webissä erityisesti.

Kuvien käsittelyn tekniikkaa (erityisesti Photoshop 5 -ohjelmassa käytettynä) käsittelee laajasti Internetixin kurssi Skannaus ja kuvankäsittely.

Tampereen TKK:n Hypermedian perusteet -kurssin aineistoon sisältyy laajahkona osuutena Kuva ja eri kuvaformaatit.

Kysymykseen "mistä löydän yleistietoja ja tarkkoja kuvauksia eri grafiikkaformaateista (GIF, PNG, PostScript ym.) sekä ohjelmista, joilla niitä voi lukea, esittää, tuottaa ja muuntaa toisikseen?" yrittää vastata juttu Grafiikkaformaatit ja niiden käsittely.

Kuvia kuten muitakin teoksia koskee se periaate, että tekijä on ilmoitettava. Jos siis esimerkiksi käytät toisen ottamaa valokuvaa Web-sivullasi, sinun on paitsi saatava hänen lupansa myös ilmoitettava hänet kuvan ottajaksi.

Esimerkki kuvituksesta: ruusukuoriainen

Jambalayaa käsittelevään esimerkkidokumenttiimme voitaisiin toki liittää kuvitusta. Valokuva valmiista ruuasta tai vaikka ruuan valmistamisestakin havainnollistaisi asioita. Seuraavassa on kuitenkin toisenlainen esimerkki, jossa kuvalla on vielä olennaisempi merkitys.

Olemme tehneet pienen Web-dokumentin, joka kuvaa erästä koppakuoriaislajia, ruusukuoriaista. On luonnollista liittää sellaiseen kuva eläimestä, etenkin, kun kyse on melko tuntemattomasta lajista. Kuva on tehty Paint-ohjelmalla ja muunnettu sitten Photoshop-ohjelmalla Bitmap-muodosta Gif-muotoon. Kuvan esitys Windows Bitmap -muodossa vie dataa ja siten levytilaa ja siirtoaikaan erittäin paljon enemmän kuin esim. Gif-muoto.

Kuva on liitetty dokumenttiin seuraavanlaisella HTML-rakenteella: 

<p><img align="right" src="kopp.gif"
width="237" height="286" title="Ruusukuoriaisen kuva"
alt=
"Ruusukuoriainen muistuttaa ..."
>
Ruusukuoriaisia (engl. <i lang="en">Rose beetle</i>)
...

Tämä merkitsee, että selain sijoittaa kuvan selaimen ikkunan oikeaan laitaan, ja sen vasemmalle puolelle tulee tekstiä sen verran, kun ikkunan leveys sallii.

Dokumentin lopussa ilmoitetaan kuvan tekijä seuraavasti, viitaten hänen Web-sivuunsa, kun sellainen sattuu olemaan olemassa: 

<p>Kuva: <a href="http://www.hut.fi/u/lsarakon/">
Liisa Sarakontu</a>.</p>

Tietoa taulukoihin

Sisällys

Katso myös lukua Vaativampia taulukoita.

Taulukoiden käyttö Web-dokumenteissa ei suinkaan aina ole tarpeellista. Luonnollista se on silloin, kun jokin aineisto on loogiselta rakenteeltaan kaksiulotteista.

Perusesimerkki taulukosta

Seuraavassa on yksinkertainen esimerkki taulukosta, joka esittää Suomen kuuden suurimman kaupungin asukasluvut vuoden 1998 lopussa: 

<table border="1">
<tr><th>Helsinki</th> <td>546 317</td></tr>
<tr><th>Espoo</th> <td>204 962</td></tr>
<tr><th>Tampere</th> <td>191 254</td></tr>
<tr><th>Vantaa</th> <td>173 860</td></tr>
<tr><th>Turku</th> <td>170 931</td></tr>
<tr><th>Oulu</th> <td>115 493</td></tr>
</table>

Tietolähde: Kuntaliiton tilasto Kunnat suuruusjärjestyksessä asukasluvun mukaan 31.12.1998.

HTML-merkkauksessa rakenne koostuu table-elementistä, jonka sisällä on muutamia tr-elementtejä, joista kukin muodostaa taulukon yhden rivin (table row). Rivi puolestaan koostuu alkioista eli soluista, jotka voivat olla otsikkosoluja (th, table header cell) tai datasoluja (td, table data cell). Määrite border="1" aiheuttaa reunukset ("laatikot"), jotka yleensä tekevät taulukon rakenteen helpommin havaittavaksi.

Taulukko näyttää selaimellasi seuraavalta:

Helsinki 546 317
Espoo 204 962
Tampere 191 254
Vantaa 173 860
Turku 170 931
Oulu 115 493

Tässä esimerkissä kaksiulotteisuus on vain sitä, että lukujen listan (yksiulotteinen rakenne) lisäksi meillä on sen kanssa rinnakkainen kaupunkien nimien lista. Laajempaa kaksiulotteisuutta saataisiin, jos ilmoitettaisiin lisäksi asukasluvut muina vuosina.

Yleisesti sanottuna taulukko on jono rivejä, joista kukin on puolestaan jono soluja (taulukon alkioita) siten, että riveillä on keskenään sama sisäinen rakenne. Tämä merkitsee, että rivien ensimmäiset solut jossakin mielessä vastaavat toisiaan, muodostaen taulukon ensimmäisen sarakkeen (column), toiset solut muodostavat toisen sarakkeen jne. Tavanomainen tapa esittää taulukko näkyvässä muodossa on vain tämän loogisen rakenteen esitystapa.

Määritteitä taulukoille

HTML:n taulukkokäsite on suhteellisen alkeellinen. Niinpä ei voida rakenteisella tavalla kertoa esimerkiksi sitä, että jokin sarake sisältää desimaalilukuja (jolloin tekstit pitäisi tasata desimaalipilkun tai -pisteen kohdalta) tai että solun sisältö on tekstiä (jolloin on hyvä jättää ainakin noin puolen kirjaimen levyiset reunukset joka suuntaan).

Niinpä taulukoille usein onkin aiheellista kirjoittaa ulkoasuun vaikuttavia määritteitä, vaikka niitä muutoin tulee välttää HTML:ssä. Näitä ovat seuraavat:

määrite missä elementissä merkitys
border=n table kunkin solun sekä koko taulukon ympärille tulevan reunaviivan leveys kuvapisteinä eli pikseleinä (pixels)
cellpadding=n table kunkin solun sisällön ja solun reunaviivan väliin tulevan tyhjän tilan (padding) leveys pikseleinä; oletusarvo yleensä pienehkö luku, tekstiä sisältäville taulukoille voi esim. cellpadding="6" olla sopivampi
cellspacing=n table eri solujen väliin tulevan tyhjän tilan (spacing) leveys pikseleinä; oletusarvo yleensä pienehkö luku; cellspacing="0" saa vierekkäisten solujen reunaviivat yhtymään
align=tasaustapa tr, th tai td solun sisällön tasaus, "alignointi"; tasaustapa voi olla center (keskitys solun sisällä; tämä on oletusarvo otsikkosoluille, th), left (tasaus solun vasempaan reunaan; tämä on oletusarvo normaaleille soluille, td) tai right (tasaus solun oikeaan reunaan).

Edellä esitetty yksinkertainen esimerkkitaulukko näyttäisi seuraavalta, jos lisäämme table-tägiin määritteen cellpadding="6" sekä kuhunkin th-alkioon määritteen align="left":

Helsinki 546 317
Espoo 204 962
Tampere 191 254
Vantaa 173 860
Turku 170 931
Oulu 115 493

Esimerkistä ilmenee, että cellpadding-määrite vaikuttaa joka suunnassa eli solun sisällön ylä- ja alapuolelle, vasemmalle ja oikealle. Joustavampia ulkoasuun vaikuttamisen keinoja tarjoavat tyylisäännöstöt.

Jos numeerista tietoa sisältävän sarakkeen luvut sisältävät eri määrän numeroita, saataisiin esitysmuoto paremmaksi käyttämällä kyseisille soluille määritettä align="right". Lisäksi saattaa auttaa, jos luvuille käytetään tasalevyistä fonttia, joka saadaan aikaan kirjoittamalla ne tt-elementtien sisään. Tämä on kuitenkin sen verran työlästä ja tylsää, että tyylisäännöstöjen käyttö on yleensä parempi ratkaisu, ellei sitten tuoteta tarvittavaa HTML-merkkausta jollain työkaluohjelmalla. Tästä ja muusta taulukoihin liittyvästä lisää kohdassa Vaativampia taulukoita.

Taulukoita kuvakokoelmille ja kuville

Taulukoita voidaan käyttää myös kuvakokoelmien esittämiseen. Etenkin silloin, kun kuvat ovat pienehköjä ja niihin halutaan liittää kuvatekstit, voidaan menetellä seuraavasti: kirjoitetaan taulukko, jossa

Edellä mainittu Lintukuvia-sivu muodostaa esimerkin tästäkin.

Yksinkertaisempi tapaus on sellainen, jossa halutaan allekkain yksi kuva ja sen kuvateksti. Tätä varten ei ole sopivaa elementtiä, mutta käytännössä kohtuulliseen tulokseen päästään käyttämällä yksinkertaista taulukkoa seuraavaan tapaan: 

<table border="0" align="center">
<tr><td>
  <a href="barbi.gif" title="Leväbarbin kuva isommassa koossa">
    <img alt="[Leväbarbin kuva]" src="barbi0.gif"
    width="300" height="151">
  </a>
</td></tr>
<tr><th>
  Leväbarbi <i lang="la">(Crossocheilus siamensis)</i>
</th></tr>
<tr><td align="center">
  <small>Piirros: <a href=
  "http://www.hut.fi/u/lsarakon/">Liisa Sarakontu</a>.
  </small>
</td></tr>
</table>

Kokonaisuus on hiukan mutkikkaan näköinen, mutta taulukkorakenne sinänsä on yksinkertainen: kolme riviä, kullakin yksi alkio, nimittäin kuva, kuvateksti ja pienellä oleva tieto kuvan tekijästä. Tämä voi näyttää esimerkiksi seuraavalta:

[Leväbarbin kuva]
Leväbarbi (Crossocheilus siamensis)
Piirros: Liisa Sarakontu.

Kuvan ympärillä todennäköisesti näkyy reunus (kehikko), koska tämä on tyypillisten selainten tapa osoittaa, että kuva on linkki. Jos kuvagalleriasivulla selvästi sanotaan, että kaikki kuvat ovat linkkejä, voi harkita näiden reunusten poistoa (img-elementtiin border="0").

Valitettavasti ei ole mahdollista kirjoittaa rakennetta, jossa olisi kuvia ja niihin liittyviä kuvatekstejä siten, että selain näyttää niitä rinnakkain aina sen verran kuin selaimen ikkunaan vaakasuunnassa mahtuu. Edellä kuvattu menettely on siis lähinnä pakon sanelemaa "taittoa", joka aiheuttaa omat ongelmansa (esim. leveässä ikkunassa tilaa tuhlaantuu). Lähes aina "taitto" HTML:ssä aiheuttaa enemmän ongelmia kuin ratkaisee, mutta joitakin poikkeuksia siis on.

Jos kyse olisi pelkästään kuvista, voisimme menetellä niin, että kirjoitamme vain img-elementtejä peräkkäin. Silloin selain näyttäisi niitä rinnakkain sen verran kun mahtuu. Vastaava koskee sanoja (tai muita lyhyitä ilmaisuja) esimerkiksi valikoissa: jos kirjoitat sanoja peräkkäin välilyönneillä erotettuina, selain jakaa ilmaisun eri riveille. Jäljempänä tarkastellaan vielä yhtä temppua, "näennäistaulukkoa".

"Taulukoilla taittaminen"

Taulukoita voi käyttää monenlaisiin asioihin; asiaan palataan kohdassa Vaativampia taulukoita. Tässä esityksessä korostetaan kuitenkin sitä, että taulukoita ei pidä käyttää vain ulkoasun tyylittelyyn eikä matkien erilaisia tavallisia ratkaisuja.

Edes W3C:n pääsivu ei kelpaa esimerkiksi tässä suhteessa! Kokeilepa katsoa sitä esim. 400 pikselin levyisessä ikkunassa. On ahdettu liikaa asiaa yhdelle sivulle ja sitten yritetty vielä ahtaa se liian tiiviisti. Quis custodiet ipsos custodes?

Esimerkiksi sivusta http://www.uiah.fi/ ei saa käytännössä mitään selvää, jos selaimen leveys on reilut 300 pikseliä. Sivun pääotsikostakaan ei näy kuin "Taide") Varsin yleisesti taulukoita käytetään "taittamiseen" eli sommitteluun (layout), esimerkiksi sanomalehden ladontaa muistuttavalla tavalla: erilaisia aineksia asemoidaan sivun määrättyihin kohtiin ilman, että tällä on mitään tekemistä aineiston loogisen rakenteen kanssa. Tämä yleisesti epäonnistuu rajoittaen sivujen toimivuutta ja osoittaa, ettei ymmärretä painojulkaisujen ja Webin eroja eikä yleisemmin Web-julkaisemisen luonnetta.

Käytännön tasolla "taittamisen" haitallisuuden näkee yleensä yksinkertaisesti katsomalla sivua erilevyisissä ikkunoissa. Tyypillisessä graafisessa selaimessa voit muuttaa ikkunan leveyttä hyvin helposti: vie hiirellä kursori ikkunan oikean reunaviivan päälle, jolloin kursori muuttuu erinäköiseksi; paina hiiren vasen nappi alas ja sitä alhaalla pitäen liikuta hiirtä vaakasuunnassa; kun päästät napin ylös, sivun leveys asettuu kursorin paikan mukaiseksi.

Esim. 300 pikseliä ei ole mitenkään äärimmäisyys mutta tyypillisesti romahduttaa "taitetun" sivun täysin. Tässä käytetyssä esimerkissä (kuva oikealla) sentään pelastaa jotain se, että vasemmalla on tekstilinkkejä, vaikka ne onkin onnistuttu tekemään lähes lukukelvottomiksi (yrittämällä asettaa fonttikoko niin pieneksi kuin mahdollista). Lukija saa kuitenkin ehkä niistä linkeistä edes jotain tuntumaa siihen, millaisella sivulla ollaan. Pahempaa jälkeä tulee esim. MTV3:n sivuilla, koska vasen osa on täytetty mainoksilla!

Silloin, kun halutaan tuottaa todella taitettua aineistoa, on parasta käyttää siihen soveltuvia kieliä ja välineitä kuten TeX, Adobe Acrobat, PageMaker ja PostScript. Jopa tavanomaiset tekstinkäsittelyohjelmat kuten MS Word ja WordPerfect sopivat paremmin taittamiseen kuin HTML. Tietenkin HTML-muotoinen aineisto on laajemmin ja laiteriippumattomammin luettavissa kuin edellä mainituilla välineillä tehty; ja tämä on osa sitä asiaa, että HTML-dokumentit eivät ole valmiiksi "taitettuja".

Lisää perusteluja sille, miksi "taulukoilla taittaminen" on huono ajatus, löytyy seuraavista jutuista:


Tekstiä monenlaista - tekstitason korostus- ja muut elementit

Kaikki teksti ei ole samanlaista. Hyvin kirjoitetussa jutussa korostetaan tärkeitä asioita. Tämä on Webissä vielä tärkeämpää kuin esimerkiksi kirjoissa. Kuvaruudulta luetaan silmäillen, etsien tärkeitä kohtia, jotka houkuttelisivat lukemaan leipätekstiäkin.

Eräs menettely onkin, että liki joka kappaleessa vahvasti korostaa muutamia avainsanoja. Kappale on silloin ikäänkuin pienoisluku, jolle ei käytännön syistä ole kirjoitettu erillistä otsikkoa, vaan avainsanojen korostus on ikäänkuin otsikoinnin tilalla. Menettelyn haittana on, että tekstistä tulee helposti levottoman näköistä, ja on vaikea kirjoittaa niin, että avainsanat sekä sopivat lauseyhteyteensä että antavat erilleen otettuina kuvaa tekstin sisällöstä. Niinpä parempi vaihtoehto voikin olla käyttää runsaasti väliotsikoita.

Lisäksi tekstissä voi esiintyä normaalikielestä poikkeavia ilmaisuja, esimerkiksi ohjelmointikielen lauseita kuten a[i++] = 0 tai tieteellisiä lajinimiä kuten Homo sapiens taikka fysiikan kaavoja kuten F = ma. On eduksi, jos tällaisissa asioissa käytetään näkyvän ulkoasun vaihtelua eli typografisia keinoja - mutta liika on aina liikaa: kovin monien eri kirjasinlajien käyttö tekee tekstistä sotkuisemman, ei selkeämpää. Charles Kelly mainitsee eräässä dokumentissaan, että monet Web-sivut palauttavat mieleen sen ajan, kun Mac-tietokoneet olivat tulleet käyttöön ja hän sai ihmisiltä kirjeitä, joissa oli käytetty noin 25:tä eri fonttia.

Web-dokumentin tekijä ei kuitenkaan voi tietää, mitä typografisia keinoja kussakin katselutilanteessa on käytettävissä. Hän ei voi tietää edes sitä, onko hänen juttunsa käsittely jotain ihan muuta kuin näkyvässä muodossa näyttämistä. Juttua voi käsitellä esimerkiksi puhesyntetisaattori tai hakupalvelimen indeksointirobotti.

Ratkaisuna on loogisten elementtien käyttö. Esimerkiksi strong-elementti merkitsee, että sen sisältämä teksti on voimakkaasti korostettua. Korostuksen toteutus riippuu selaimesta. Toteutus voi perustua esimerkiksi tekstin lihavointiin, alleviivaukseen, tekstin värin muuttamiseen tai äänen volyymin nostamiseen.

Tekstitason korostus- yms. elementit
elementti merkitys huomautuksia
Korostukset
em korostus (emphasis) sopii "paikalliseen" korostukseen; tyypillinen esitysmuoto: kursivointi
strong voimakas korostus sopii tekstin "nostamiseen esiin" dokumentista; tyypillinen esitysmuoto: lihavointi
dfn määrittelyesiintymä sopii käytettäväksi, kun sana tai muu ilmaisu esiintyy yhteydessä, jossa sille annetaan määritelmä; tyypillinen esitysmuoto: normaaliteksti (!) tai kursivointi
Muut ns. fraasielementit
abbr lyhenne tarkempi merkitys ja suhde acronym-elementtiin epäselvä; selaimet eivät juuri tue nykyisin
acronym lyhenne tarkempi merkitys ja suhde abbr-elementtiin epäselvä
cite kirjan tai artikkelin nimi tms. ei tarkoita sitaattia (vrt. q-elementtiin) vaan pikemminkin viittausta lähteisiin; tyypillinen esitysmuoto: kursivointi
code (tietokone)koodi esim. ohjelmakoodi, käyttöjärjestelmäkomento; tyypillinen esitysmuoto: tasalevyinen fontti
kbd näppäimistöltä (keyboard) kirjoitettava teksti soveltuu tietokoneoohjelmien käyttöohjeisiin yms.; tyypillinen esitysmuoto: tasalevyinen fontti
q lainaus (quotation) ei kannata käyttää, koska selaintuki on liian suppea; käytä lainausmerkkejä tai kursivointia (i-elementtiä) taikka isoille lainauksille lohkotason elementtiä blockquote
samp esimerkkituloste (sample output) soveltuu tietokoneohjelmien käyttöohjeisiin yms.; tyypillinen esitysmuoto: tasalevyinen fontti
var muuttuja (variable) soveltuu sellaisiin yhteyksiin kuin "tiedosto hävitetään komennolla rm tiedostonnimi", ilmaisemaan että jotain osaa (kuten tiedostonnimi) ei pidä kirjoittaa sellaisenaan vaan se on vain osoittamassa, minkätyyppinen ilmaisu kohtaan pitää kirjoittaa; tyypillinen esitysmuoto: tavallinen teksti (!) tai kursiivi tai tasalevyinen fontti (!); ei sopine fysiikan tai matematiikan muuttujille, joille sopii paremmin i-merkkaus
Muutosten merkintä
ins lisätty (inserted) teksti Selainten tuki näille elementeille on suppeahko. Jotkin selaimet voivat näyttää del-elementin tekstin yliviivattuna - mutta muissa selaimissa "poistettu" teksti näkyy normaalina tekstinä!
del poistettu (deleted) teksti
"Merkityksetön" yleiselementti
span (ei merkitystä) käytetään erottamaan osa tekstistä kokonaisuudeksi, johon voidaan liittää esim. tyyliehdotus
Fonttitason elementit (vältä!)
b lihavointi (bolding) esim. fysiikassa vektorien merkitsemiseen; voimakkaaseen korostamiseen kannattaa käyttää tämän asemesta strong-elementtiä
big iso fontti käytä mieluummin esim. otsikkoelementtiä, jos kyse on otsikosta
font fontin koko, väri, muoto lähes aina haitallinen elementti, jolle on erittäin vähän jos ollenkaan järkevää käyttöä
i kursivointi (italics) esim. tieteellisissä nimissä ja sitaattilainoissa sekä muissa ilmaisuissa, jotka vakiintuneen tavan mukaan pyritään esittämään kursiivilla, esim. suureiden symbolit kuten T 'lämpötila' fysiikassa; korostamiseen kannattaa käyttää tämän asemesta em-elementtiä
small pieni fontti yleensä tekstin merkitsemiseen vähemmän tärkeäksi
strike yliviivaus yleensä poiston merkitsemiseen, vrt. del-elementtiin
sub tason pudotus (subscript) ei kaikissa esitystilanteissa mahdollinen; sub sopii esim. alaindeksien esittämiseen (x1, H2O) silloin, kun esitys normaalitekstinäkin (x1, H2O) on hyväksyttävä
sup tason korotus (superscript) ei kaikissa esitystilanteissa mahdollinen, eikä sup siksi yleensä sovi ; sen sijaan esim. ilmaisuihin 1st (=first), Mlle (mademoiselle)
tt tasalevyinen (monospace) fontti nimi johtuu sanasta teletype, joka tarkoittaa vanhanaikaista laitetta, jolla merkistö on aina tasalevyinen, t.s. kaikki kirjaimet ja muut merkit ovat keskenään samanlevyisiä (esim. i vie yhtä ison tilan vaakasuunnassa kuin m)
u alleviivaus (underline) vältettävä, koska sekaantuu linkkien tavalliseen esitysmuotoon

Edellä kuvatut elementit ovat tekstitason elementtejä, englanniksi text level element tai inline element. Tämä sisältää sen, että niiden sisällä saa olla tekstiä ja muita tekstitason elementtejä, mutta ei esimerkiksi kappaleita.

Kokonaisten kappaleiden korostamiseen ei HTML:ssä ole hyvää keinoa keinoa. Koko kappaleen tekstin kirjoittaminen esim. em-elementin sisään (<p><em>Tekstikappale</em></p>) on mahdollista, mutta tulos ei ole kovin mukavan näköinen. Rakenne <p><big>teksti</big></p> myös yksi vaihtoehto, mutta teksti voi silloin tuntua lukijasta aivan liian isolta. Tyylisäännöstöillä voidaan asia tehdä paljon tyylikkäämmin, mutta tämä merkitsee, että kappale näkyy aivan normaalin näköisenä silloin, kun selain ei sovella kyseistä tyylisäännöstöä.

Valitettavasti tekstitason elementtien valikoima ei ole kovinkaan huolellisesti suunniteltu, eikä sitä myöskään ole kovin hyvin toteutettu selaimissa. Monet selaimet esimerkiksi käyttävät kursiivia kovin moniin tarkoituksiin (esim. em-, cite- ja var-elementtien sekä tietysti myös i-elementtien esittämiseen), joten HTML-dokumentissa huolella tehdyt erot eivät näykään lukijalle.

Looginen elementtien käyttö on silti järkevää. On parempi tehdä sivuja niin, että ne toimivat jotenkuten nykyisillä selaimilla ja hyvin tulevilla kuin välittää vain siitä, miltä asiat nyt näyttävät (tai olla välittämättä siitäkään). Ja jo nykyisin voidaan aika paljon saada aikaan käyttämällä tyylisäännöstöjä yhdessä elementtien loogisen käytön kanssa. Vaikka esimerkiksi code-, samp- ja kbd-elementit kaikki näkyvät samanlaisella fontilla, kun tyypillistä selainta käytetään oletusasetuksin, niin tyylisäännöstöillä voidaan kullekin ehdottaa omaa esitystapaa. Tästä on hyviä esimerkkejä mm. WDG:n CSS Quick Tutorial -aineistossa, jonka oma ulkoasu pyrkii hyödyntämään CSS:ää.

Tekstitason korostus- yms. elementtien käytössä voi soveltaa Jambalaya-periaatetta: lisukkeita voi panna mukaan maun ja inspiraation mukaan ja miten tilanteeseen sopii. "Perusmausteita" em ja strong voi käyttää olennaisten sanojen korostamiseen, jos väliotsikot eivät tunnu paremmalta vaihtoehdolta. Muutoin kyse on paljolti siitä, miten paljon haluat nähdä vaivaa tulevaisuutta varten.

Reseptit: Miten luon Web-sivujen kokonaisuuden, ja muuta vaativampaa

Suunnittele kokonaisuus

Sisällys

Suunnitelma - miksi?

Pitäisikö tehdä suunnitelma pomolle, jotta tämä voisi mapittaa sen ja haukkua sinut vuoden kuluttua siitä, että et ole toteuttanut sitä? Tai komitealle, joka muuttaisi sen kompromissiksi? (Kompromissi: ratkaisu, jolla on kaikkien ehdotettujen vaihtoehtojen huonot puolet ja joka on kustannuksiltaan niiden summa.) Toivottavasti et joudu sellaiseen. Jos joudut, suosittelen Dilbertin lukemista mielenterveyden säilyttämiseksi. Mutta toivottavasti voit tehdä suunnitelmia itsellesi eli miettiä etukäteen, mitä teet, taikka olla mukana porukassa, joka tekee suunnitelmia itselleen eli mukana olijoille.

Hyvin suunniteltu ei ole puoliksi tehty. Sen sijaan hyvä suunnittelu voi säästää 90 % tekemiseen tarvittavasta työstä etenkin siksi, että se estää tekemästä turhaa tai suorastaan haitallista työtä. Suunnitelman ei tarvitse olla paperilla eikä tietokoneessa, vaikka useimmiten kannattaisi olla. Tärkeää on se, että sivuston tekijällä tai tekijöillä on mielessään riittävän selvä ajatus siitä, mitä tehdään.

Tee ainakin aluksi suunnitelma, joka on yksinkertainen ja kohtuullisen nopeasti toteutettavissa. Lyö lukkoon perustavoitetaso, jonka saavuttamisen jälkeen sivuston voi julkistaa, ja toteuta se ensin. Hyvät ideat ovat vaarallisia, koska ne aivan liian helposti johtavat toteuttamaan hienouksia, jotka ovat sinänsä ihan hyviä mutta vievät aikaa yksinkertaisemmilta perusasioilta. Suunnittelussa ja alkuvaiheen tekemisessä kirjoita rönsyilevät ideat muistiin. Silloin ne eivät haihdu mielestä eivätkä toisaalta jää rasittamaan mieltä, jonka pitäisi askarrella muissa asioissa. Aikanaan sitten voit valita toteutettaviksi ne ideat, jotka vielä myöhemminkin vaikuttavat hyviltä ja tekemisen arvoisilta.

Sivuston tekemiseen tarvittava työmäärä aliarvioidaan aina, usein hyvinkin rajusti. Mutta tämä on pientä verrattuna ylläpitotyön aliarviointiin.

Under construction -symbolit symboloivat suunniteltua epäonnistumista. Kovin paljon on sivuja, joiden teossa on lähdetty soitellen sotahan. Rakentaminen on jäänyt kesken, tai rakennus on lahonnut kunnossapidon puutteeseen niin, että löytyy vuosia sitten vanhentuneita tietoja eikä nyt tärkeitä asioita ole ollenkaan esillä. Muista, että vuoden kuluttua sivusto tuntuu sinusta (tai organisaatiostasi) erittäin todennäköisesti paljon vähemmän tärkeältä kuin nyt. Mieti ennalta, paljonko jaksat ja viitsit ja voit todella ylläpitää.

Luvussa Miksi ja mitä julkaisen Webissä? käsitellään perustuvanlaatuisempia kysymyksiä. Sen lukeminen ensin on suositeltavaa, mutta jos sinulle on kiire "päästä töihin käsiksi", niin jatka suoraan seuraavasta. (Mutta tuskin mikään on aiheuttanut enempää ajan tuhlausta kuin kiire; jos teet ihan vääriä asioita, on sitä pahempi, mitä nopeammin ja tehokkaammin niitä teet.)

Oikea tavoitetaso

Koska ratkaisevaa on, paljonko tulet todella tekemään työtä sivuston ylläpitämiseksi, niin ensimmäiseksi kannattaa päättää sivuston päivitystiheys. Sivusto voi olla

Jos kyseessä on esimerkiksi Web-muotoon siirretty väitöskirja, sen tulee ilman muuta olla "pysyvä". Ei sen sisältöä saa korjata, vaan jos mahdolliset muutokset tietoihin esitetään erikseen; enintään voi väitöskirjan Web-versioon liittää linkit myöhempiin tietoihin. Muutokset itse väitöskirjasivustoon tulee rajoittaa mahdollisiin teknisiin korjauksiin sen johdosta, että siirrossa Webiin on sattunut virheitä, esim. jokin kuva skannattu huonolaatuisesti. Tyypillisesti "pysyvän" sivuston tulisikin olla dokumentti siitä, mitä joku tai jokin on tehnyt tai ajatellut määrätyssä tilanteessa, kuin historiankirjoihin viety dokumentti.

Useimmat sivustot kuuluvat tai ainakin niiden pitäisi kuulua ryhmään "aika ajoin päivitettävät". Sivuston tekijän pitäisi olla siinä määrin kiinnostunut sen aihepiiristä, että hän seuraa sitä, työssään tai vapaa-aikanaan, ja aika ajoin hoksaa, että on tapahtunut jotain, joka antaa aiheen muuttaa sivustoa. Jos kiinnostus loppuu tai sivuston perusylläpito muuten lopahtaa, olisi kohtuullista joko kirjoittaa tästä maininta sivuille (esim. "sivuston ylläpito lopetettu 1999-12-31") tai mieluummin yrittää saada sivusto siirretyksi jonkun muun, siitä kiinnostuneen hoidettavaksi.

Todellisen ylläpidon ohella on tietysti olemassa nimellistä ylläpitoa. Organisaatioilla on pyrkimys ratkaista olettamiaan ongelmia "nimeämällä vastuuhenkilöitä". Näille saatetaan esimerkiksi antaa määräys "päivittää sivut" määrätyin väliajoin.

Säännöllinen sivuston läpikäynti mahdollisten korjaustarpeiden selvittämiseksi on toki hyväksi myös todellisessa ylläpidossa. Niinpä kannattaakin kysyä itseltään jo sivustoa suunnitellessaan: kuinka usein tulen käymään tämän sivuston läpi? Kerran vuodessa? Kerran kuussa? Kerran päivässä? Ratkaisevaa ei ole, mitä vastaat, vaan miten hyvin vastaus tulee vastaamaan todellisuutta. Kun etukäteen hahmotat päivitystiheyden oikein, osaat myös ottaa sen huomioon sivustoa tehdessäsi.

Päivittäistietoa antavalla sivustolla pitää olla päivittäjä, joka voi todella käyttää päivittäin tarvittavan osan ajastaan sen hoitamiseen. Tämä merkitsee, että hänellä pitää olla varamies, mielellään myös varamiehen varamies; on varmaa, että päivittäjä ei ole joka päivä (edes joka työpäivä) töissä. Päivittäjällä ja varamiehillä pitää myös olla toimivat työkalut eli ohjelmat, joilla päivitykset tehdään. Sivuston alkuperäisen tekijän täytyy huolehtia tästä ja työkalujen käytön opastamisesta.

Reaaliaikaisiin ja vuorovaikutteisiin sivustoihin ei tässä puututa enempää kuin sanomalla, että niitä ei kannata edes ajatella, ennenkuin edellä kuvatun kaltaisten sivustojen teko on hallussa.

Oikea sisällön laajuus

Edellä kuvattujen tarkastelujen jälkeen voit toivottavasti hahmotella, mitä asiaa sivuille tarvitaan. Voit samalla suunnitella, mikä asia tarvitaan heti aluksi ja mitä voidaan lisäillä myöhemmin, kun sivusto on jo käytössä. Ja koska samalla kannattaa miettiä myös sivuston looginen rakenne, suunnitelman voi tehdä vaikkapa luetelmalla tähän tapaan (esimerkkinä kuvitteellisen tutkimuslaitoksen kuvitteellinen osasto):

Isomman tutkimusyksikön Web-sivujen tekemiseen löytää ideoita katselemalla VTT:n laajaa mutta yhtenäiseen tyyliin tehdyä sivustoa.

Sivuston kieli riippuu tietenkin sen tarkoituksesta. Ei kannata itsetarkoituksellisesti tehdä englanninkielisiä sivuja, jos sivusto on kuitenkin tarkoitettu suomalaisille. Toisaalta esimerkiksi tutkimuslaitoksen toiminnassa kansainväliset yhteydet ovat sen verran tärkeitä, että englannin kieli voi olla syytä asettaa etusijalle. Valtion viraston taas tulisi tehdä sekä suomen- että ruotsinkieliset sivut ja mahdollisesti muunkinkielisiä sivuja. Periaatteessa olisi mahdollista (ns. language negotiation -menettelyllä) järjestää asiat niin, että kullakin sivulla on yksi osoite (URL), joka johtaa erikielisiin versioihin eri tilanteissa, käyttäjän selaimeensa asettamiensa kielipreferenssien mukaan. Tähän ei kuitenkaan voi ollenkaan luottaa, joten joka tapauksessa erikieliset sivut on syytä linkittää toisiinsa. Minimivaatimus on, että kunkinkielisellä pääsivulla on linkit muunkielisiin versioihin. Tässä ei ole syytä käyttää maiden lippuja! Yksinkertainen menettely kaksikielisen sivuston tapauksessa on se, että otsikon alla on (mielellään keskitettynä) toisenkielinen nimi, joka on linkki senkieliseen versioon seuraavaan tapaan:

Hypermystiikan tutkimuskeskus
Research Center for Hypermystics

Vinkki: Jos englanninkielisellä sivustolla haluaa tehdä myönteisen vaikutuksen, kannattaa kirjoittaa englantia oikein ja tyylikkäästi. Tähän tarvitaan todennäköisesti apuvälineitä kuten sanakirjoja, kielioppeja ja tarkistusohjelmia. Katso esim. pientä koostettani Resources on the English language.

Yrityksen pääsivun tekemisestä

Esimerkiksi kaupallisen yrityksen kannattaisi asettaa Web-sivustonsa tavoitetasoksi jokin seuraavista:

  1. "olemme läsnä" Webissä; minimivaatimuksena on tällöin, että sivuilla kerrotaan firman toimiala ja annetaan oikeat yhteystiedot
  2. kerromme tuotteistamme ja itsestämme yleisesti; tämä voi olla hyvää mainontaa ("tuoteinformaatiota"), jos se tehdään kunnolla ja tiedot pidetään tuotevalikoimaa vastaavina
  3. jaamme yksityiskohtaista tuotetietoa ja hintatietoja; tämä on ensimmäinen askel kohti liiketoimintaa netissä, etenkin jos tuotteista on sellaisia tietoja, joiden pohjalta voi jo tehdä ainakin alustavan ostopäätöksen; tämä edellyttää käytännössä (lähes) päivittäistä ylläpitoa sekä jonkinlaista vuorovaikutteisuutta ainakin niin, että käyttäjällä on helppo tapa lähettää pyyntö saada lisätietoja ja että hän saa vastauksen (ainakin alustavan) viimeistään seuraavana työpäivänä
  4. otamme vastaan tilauksia (ja maksuja); tilauslomakkeen tekeminen ei vielä hirveästi vaadi, mutta se on syytä tehdä kunnolla; maksujärjestelmiin liittyminen vaatiikin sitten jo sitä alaa tuntevan ammattilaisen, yhteyksiä pankkeihin yms.

Mikään, edes ensimmäinen, näistä tavoitetasoista ei merkitse "pysyvää" sivustoa, vaan kaikkiin sisältyy jonkinasteinen ylläpitotarve. Jos ajatellaan, että kyllä joku hoitaa ylläpidon, olisi parempi jättää sivusto tekemättä. Joku ei todellakaan tee mitään (toisin kuin Joku Muu, joka sotkee sivuston jonain päivänä).

Kaupallisten yritysten sivustot tuntuvat kilpailevan keskenään käsittämättömyydessä. On poikkeus, jos pääsivulla edes kunnolla sanotaan, minkä alan firma on kyseessä. Itse asiassa selailin aika monia kaupallisten sivustojen pääsivuja, ennenkuin löysin sellaisen, jossa on vakavaa yritystä tähän suuntaan: Pejan Oy. (Kuinka ollakaan, kyseinen sivusto on nyttemmin uusittu - monin tavoin huonompaan suuntaan, joskin myös parannuksia tehden.)

Pejanin pääsivun Logossa on teksti PEJAN OY - LIGHTNING. Sen alla: Valaisimien ja valaistustarvikkeiden maahantuonti ja konsultointi. Sitten valikko: Yritys; Päämiehet; Esitteet; NäyttelyM Dico Plis - Langaton palo ja varkaushälytin Pejan Oy:n sivulla sanotaan heti logon alla selvällä suomen kielellä toimiala. Sivulla on myös yhteystiedot sekä muutama kohtuullisen hyvin nimetty linkki, jotka antavat käsityksen siitä, mitä sivustossa on, ja myös johtavat siihen.

Sivulle olisi vielä mahtunut aineistoa jonkin verran, esimerkiksi kohtuullisen kokoinen valokuva, joka havainnollistaisi valikoimaa. Kuvitus loisi odotuksia siitä, että sivustossa on kuvallista aineistoa, mikä tässä tapauksessa pitäisi paikkansa: sivustossa on visuaalisesti varsin korkeatasoinen esitteistö. (Tai siis oli. Edellä oleva linkki on rikottu, t.s. sivuston uusijat eivät ole noudattaneet periaatetta URLien pysyvyydestä.)

Sivujen mainitseminen esimerkkeinä on tietysti aina riskialtista. Sivustothan muuttuvat. Usein rakennetta muutetaan rajustikin, mikä on yleensä merkki siitä, että alkuperäinen sivusto oli huonosti suunniteltu ja uusi suuremmalla työmäärällä mutta huonommin. Tässä tai muissa esimerkeissä ei ole tarkoitus ottaa kantaa sivustoon tai luonnehtia sitä muuten kuin esitettävän asian kannalta. Esimerkiksi edellä mainitulla pääsivulla yksinkertaisen ja idealtaan aika toimivan linkkilistan toteutus ei ollut kovinkaan hyvä.

Esimerkkisivulla oli kuitenkin hyvin vältetty yksi kaikkein tavallisimmista virheistä: väärinymmärretty mainoshenkisyys. Tyypilliset isojen yritysten pääsivut pyrkivät visuaaliseen näyttävyyteen, usein tolkuttomasti tilaa törsäillen. Tavoitteena kai on vangita katsojan huomio ymmärtämättä, että ei Webiä katsella kuin televisiota tai lehteä tai kadunvarsimainoksia. Sivulle "menijä" on jo valinnut, on jo päättänyt hetkeksi kohdistaa huomionsa siihen asiaan, jota sivulla on. Pääsivun pitäisi vastata tähän kertomalla sitä asiaa ja tarjoamalla selkeä tapa mennä sivuston siihen osaan, joka käyttäjää nyt kiinnostaa.

Esimerkki: yhdistyksen pääsivun rakenne

Hahmotellaanpa yksinkertainen malli yhdistyksen pääsivulle. Yhdistyshän tarkoittaa periaatteessa yhteenliittymää, jolla on jokin jossain mielessä aatteellinen tavoite. Yhdistyksen Web-sivunkin tietysti pitäisi palvella yhdistyksen tarkoitusta, suoraan tai epäsuorasti: kertoa tavoitteesta, kertoa toiminnasta sen edistämiseksi ja kutsua mukaan toimintaan. Muu onkin sitten rönsyilyä.

Esimerkkinä käytämme kuvitteellista yhdistystä Mahdollisimman paljon yhteistä hyvää kaikille ry. (Siltä varalta, että sellainen yhdistys sattuisi tässä yhdistysten luvatussa maassa jo olemaan, pahoittelen yhteensattumaa.) Pääsivun rakenteeksi hahmottelemme seuraavan:

Peruslinkeissä on kohta Tapahtumakalenteri korostettu, koska sivuilla usein vieraileville juuri sellainen tieto on oletettavasti tärkeää. Ja toisaalta ulkopuolisetkin saavat todenmukaisimman kuvan yhdistyksestä katsomalla, mitä se todella tekee tai ainakin on tekevinään. Seuraavat peruslinkit johtavat yhdistyksen viimeaikaisiin kannanottoihin sekä yhdistyksen tavoitetta palvelevaan käsikirjatyyppiseen aineistoon, joka on tarkoitettu opastamaan, miten yhdistyksen jäsenet voivat jokapäiväisessä elämässään edistää sitä aatetta, jota varten yhdistys on olemassa. Vasta näiden jälkeen tulevat tiedot itse yhdistyksestä - siihen liittymisestä, yhteystiedoista ja toimihenkilöistä. Vielä myöhemmin, "toissijaisissa" linkeissä eri otsikon alla, tulevat sellaiset asiat, joilla on merkitystä lähinnä vain yhdistyksen sisällä jo toimiville, heistäkin ehkä vain ydinjoukolle. Mitä enemmän asiaa pääsivulla muutoin on, sitä enemmän kannattaa harkita toissijaisen linkkilistan kirjoittamista eri sivulle, jolloin pääsivulla on vain yksi linkki (esim. "Arkisto").

Näistä aineksista on koottu Mahdollisimman paljon yhteistä hyvää kaikille ry:n pääsivu. Tosin siinä on lisäksi tyylisäännöstöjen avulla ehdotettu eräitä ulkoasuseikkoja kuten yhdistyksen henkeen sopivaa taustaväriä ja -kuviota. Ja koska taustakuvana on käytetty erästä vapaan grafiikan kokoelmaa, on mukaan liitetty (kuvallinen) linkki siihen.

Todellisena esimerkkinä tämäntapaisesta perusrakenteesta oli aikoinaan Suomen Internet-yhdistyksen pääsivu, jossa oli nostettu keskeisiä ajankohtaisia asioita suoraan pääsivulle otsikoina, jotka toimivat suorina linkkeinä. Tämä on usein hyvä ratkaisu, ja voisipa siihen liittää hiukan laajempaakin uutistekstiä, jopa kuvitusta, jos on asiaan liittyvä kuva. Sivulla oli myös linkki hakemistoon; isossa sivustossa sen tilalla tai rinnalla olisi hyvä olla hakutoiminto, jolla voi hakea sivustosta tietoja avainsanoilla. - Mainittakoon, että huomasin kyseisen sivun vasta laadittuani naivistisen esimerkkini. Jos olisin huomannut aiemmin, olisin tehnyt esimerkkini paremmin. Ja tätä kirjoitettaessa (2000-11-03) onkin yhdistyksen sivusto pantu uusiksi eli sekaisin, ja siellä kerrotaan kuukausia vanhoista asioista tulevina tapahtumina. (Syvä huokaus.)

Kuten sivuista ilmenee, perusrakenteen toteutus ja soveltaminen voi vaihdella suurestikin. Loppujen lopuksihan ei ole kyse muusta kuin terveen järjen mukaisesta keskittymisestä olennaiseen. Eivätkä kaupallinen yritys ja aatteellinen yhdistys eivät eroa toisistaan ollenkaan niin paljon kuin voisi luulla. Ja paljon niillä on yhteistä myös julkisen palvelulaitoksen tai vaikkapa tutkimuslaitoksen kanssa. Jokaisen on syytä Web-sivuillaan vastata niihin kysymyksiin, joita sivuilla kävijöillä oikeasti on ja jotka voidaan tiivistää organisaation itsensä kannalta esimerkiksi näin:

Sivuilla kävijän kysymys on tietysti aina erilainen. Siksi keskeistä on ensinnäkin selkeä sivuston rakenne, joka on tehty käyttäjän tarpeisiin (ulkopuolista varten) eikä esimerkiksi oman organisaatiomallin mukaan. Tämän lisäksi on toki hieno asia, jos on myös hakemisto tai hakutoiminto.

Etenkin jos kyse on julkisia palvelua tarjoavasta organisaatiosta, kannattaa tutustua julkisen hallinnon suositukseen Julkisten palvelujen kuluttajalähtöinen palveluhakemisto (JHS 145). Se ehdottaa seuraavaa ylimmän tason jäsennystä ja siihen useantasoisia alajäsennyksiä.

Tämä sopii hyvin etenkin kunnan sivuston perusjäsennykseksi. Toimialaltaan erikoistuneemmat organisaatiot voisivat soveltaa asianomaista alajäsennystä kyseisessä suosituksessa.

Muut tasot: keskeiset alasivut, ja niiltä eteenpäin

Sivuston rakenne on yleensä puumainen eli monitasoinen eli hierarkkinen siten, että pääsivulta pääsee joillekin seuraavan jäsennystason sivuille, joilla taas voi olla linkkejä "alaspäin" jne. Mitään pakkoa tähän ei ole, eikä rakenteen tarvitse eikä yleensä kannatakaan olla puhtaasti puumainen, vaan sivut voivat "viitata ristiin" muille sivuille. Joka tapauksessa "toisen tason" sivuilla on yleensä keskeinen merkitys. Pääsivu antaa hyvin yleistä tietoa ja lupaa, että sivustosta löytyy asiaa, joka vastaa pääsivun keskeisiä linkkejä eli toisen tason sivujen otsikoita. Jos pääsivulla on linkki "Tapahtumakalenteri", se lupaa, että sitä seuraamalla saa tiedon siitä, mitä yritys, yhdistys, laitos tms. lähiaikoina tekee tai mitä sen alalla tapahtuu.

Tästä seuraa, että pääsivua ei yleensä kannata julkistaa, ennenkuin ainakin toisen tason sivut on tehty ja niillä on jotakin sisältöä. Muutoinkin vaikka suunnittelu on hyvä tehdä "ylhäältä alas", yleisestä yksityiskohtiin edeten, niin sivuston toteutus on syytä tehdä niin, että ylemmän tason sivulla on linkki alaspäin vasta kun se johtaa johonkin. (Jos se johtaa tapahtumakalenteriin, joka on tyhjä, niin tämä on tietysti omalla tavallaan informatiivista.)

Alasivujen suunnittelu voi noudattaa samoja periaatteita kuin pääsivun, kuitenkin niin, että mitä alemmas tullaan, sitä enemmän varsinaisen sisällön pitäisi korostua. Jos sivun sisältönä on esimerkiksi yhdistyksen toimintakalenteri, niin se voi koostua esimerkiksi vain aikajärjestyksessä olevasta tapahtumien listasta, jossa on kustakin tapahtumasta joko kuvaus tai linkki tarkempiin tietoihin tai molemmat. Erityisempiä esittelyjä tällainen ei vaadi; päinvastoin esittely, joka puhuisi yleisesti toiminnasta, olisi toimintakalenterisivulla lähinnä lässytystä. Toki sivulla pitää olla otsikko ja linkkejä, jotka liittävät sen asiayhteyteensä. Kalenterisivulla myös kuvitus olisi lähinnä häiritsevää, ellei kyse ole hyvin hillityistä (pienistä mutta merkityksellisistä) kuvista.

Parasta olisi, jos alasivu sisältäisi niin paljon tietoa, että suurin osa sille tulijoista saa siltä sen mitä sieltä etsii ja muut saavat sen sitten linkkejä seuraamalla. Jos esimerkiksi tutkimuslaitoksen pääsivulla on linkki sivulle, joka käsittelee hypermystiikan tutkimusaluetta, niin tällä sivulla olisi hyvä alussa kertoa, millaista tutkimusta laitos sillä alalla tekee. Vasta sen jälkeen on syytä luetella tutkijoita, tutkimushankkeita ym. linkkeineen. On sangen turhauttavaa käydä läpi satakohtainen linkkilista vain huomatakseen, että laitoksessa tutkitaan yksinomaan epäorgaanista hypermystiikkaa, jos tarkoitus oli löytää tietoja orgaanisesta hypermystiikasta.

Mitä keskeisemmästä sivusta on kyse, sitä tärkeämpää on pitää sen rakenne mahdollisimman samana. Tämä on olennaista niille, jotka käyvät sivuilla usein. Mutta myös alasivujen yhtenäisyydellä voi olla merkitystä silloin, kun se on luontevasti toteutettavissa. Jos sivuilla on esimerkiksi yrityksen tuotteiden esittelyjä, on hyvä, jos mahdollinen asiakas löytää samat perustiedot aina samoista paikoista. Muuan yksinkertainen tapa toteuttaa yhtenäisyys on laatia sivurungot, joiden tekeminen on samalla sivuston suunnittelua.

Muista muuttuvaisuus

Kaikki virtaa.
Herakleitos

Kaikki, mikä voi muuttua, muuttuu joskus. Se, mikä ei voi muuttua, muuttuu myös, kun sikseen tulee. Kun 1990-luvullakin valtioita hajosi ja vakaita suuryrityksiä fuusioitiin varsin yllättäen, voitko luottaa siihen, että firmasi organisaatio säilyy?

Jo sivuja alun perin suunniteltaessa kannattaa miettiä myös pääpiirteittäinen kunnossapitosuunnitelma. Jos nimittäin kunnossapidon vaatimukset otetaan alun alkaen huomioon, niin päivittäminen sujuu sutjakammin eikä jää päivittelyksi. Karkea suunnitelma voisi olla esimerkiksi seuraava:

Olennaista on, että ihmiset oikeasti ryhtyvät hoitamaan tällaisia asioita muun toimintansa ohessa tai pikemminkin osana. Sen sijaan sivuston rakennetta ei pidä suunnitella "vastuujaon" mukaan; joskus sellainen saattaa toimia, yleisesti ei. Olennaista on kannettu vastuu tietojen ajantasaisena pitämisestä, sattuivat ne tiedot olemaan missä tahansa. Tosin tätä helpottaa, jos samaa asiaa ei ole kovin monella sivulla.

Muutoksiin varautumisen yksi keino on se, että muuttuvat tiedot pidetään yhdessä paikassa, josta ne on helppo muuttaa. Esimerkiksi laitoksen tarjoamien palveluiden hintoja ei ole syytä ripotella eri sivuille eri yhteyksiin, joissa palveluihin viitataan. Hinnat on syytä koota yhdelle sivulle, johon muilta sivuilta tarvittaessa viitataan. Kyse ei ole vain konkreettisista rahasummista - jotka väistämättä muuttuvat siirryttäessä markoista kokonaan euroihin - vaan myös yleisluonteisemmista tiedoista Jos aiemmin maksuton palvelu muutetaan maksulliseksi, on melkoinen urakka, jos pitää käydä läpi tuhat eri sivua sen selvittämiseksi, missä sanotaan joillakin sanakäänteillä, että jotain tehdään maksutta.

Kaikkea ei tietenkään voi keskittää. Emme voi lähteä siitä, että yrityksen nimi mainitaan vain yhdellä sivulla. Nimenmuutos on joka tapauksessa asia, jonka yhteydessä on syytä käydä kaikki sivut tarkoin läpi, eikä tätä voi automatisoida kuin osoittain.

Erityisesti henkilötiedot ovat muuttuvaisia. Suoria viittauksia nimettyihin ihmisiin pitäisi välttää silloin, kun kyse on ihmisten työnään tai luottamustehtävänään hoitamista asioista. Jos sivulla sanotaan, että sillä käsitellystä aiheesta antaa lisätietoja Matti Meikäläinen, puh. 555 5555, niin on erittäin noloa, jos numerosta 555 5555 vastaa joku, joka ei ole kuullutkaan Matista tai ei ainakaan tiedä, kuka häneltä jääneitä hommia nykyisin hoitaa, tai jos kukaan ei vastaa, koska numero on poistettu käytöstä. Jos sivuille ripotellaan tällaisia viittauksia, niiden tulisi ainakin olla todella ylläpidettyjä, mikä yleensä onnistuu vain, jos ylläpitoa hoitaa ihminen, joka muutenkin ylläpitää henkilöstöluetteloa. (Lisäksi hänellä pitää olla ylläpitoon työkalut, joilla homma hoituu niin, että hän tekee muutoksen henkilöstöluettelon tietoihin ja niinsanotusti vain painaa nappia.) Yleisesti on parempi, että käyttäjä joutuu kulkemaan organisaation pääsivun kautta löytääkseen jotakin asiaa hoitavan henkilön. On tärkeämpää löytää kerralla oikeat yhteystiedot kuin löytää nopeasti jotakin.

Web-sivun tekijän yhteystiedot ovat eri asemassa, koska ne ovat sidoksissa itse sivuun ja koska niiden ylläpito on osa itse sivun ylläpitoa. Niissäkin on syytä pitäytyä tietoihin, jotka ovat suhteellisen muuttumattomat: nimi, mahdollisesti meiliosoite ja kotisivun osoite, joista viimeksimainittu on "piilotetusti" mukana, koska nimi on linkki kotisivulle. Muuttuvammat tiedot löytyvät sitten kotisivulta. Samat periaatteet soveltuvat niihin poikkeustapauksiin, joissa sivuille "sirotellaan" viittauksia ihmisiin.

Lisää suunnittelusta

CSUNin kirjasto on laatinut paikallisen ohjeiston, jossa on kiinnitetty huomiota moniin keskeisiin kysymyksiin selkeällä tavalla. Se viittaa useisiin laajempiin "tyylimanuaaleihin" (style manuals).

Monia aiheita, myös kokonaisuuksien suunnittelua, käsittelee tunnettu käytettävyystutkija Jakob Nielsen kahden viikon välein ilmestyvissä alertboxeissa. Niistä mainittakoon Ten Good Deeds in Web Design. Mutta jokaisen Web-sivustoa suunnittelevan pitäisi lukea myös varoituksen sanat. Edelleenkin voidaan liioittelematta sanoa, että pelkästään välttämällä Nielsenin klassikossa Top Ten Mistakes in Web Design kuvatut virheet pääsee Web-sivujen pieneen kärkijoukkoon.

Suomessa on voimassa julkisen hallinnon suositus, joka kannattaa lukea muidenkin kuin julkisella sektorilla toimivien, koska sen periaatteet ovat enimmäkseen varsin hyviä: Julkishallinnon WWW-sivuston suunnittelun ohjeet (JHS 129). Puutteena siinä on lähinnä se, että se on ilmeisesti koottu monesta hyvästä ja muutamasta huonosta pohjapaperista sakset-leikkaa-liimaa-menetelmällä ja jäsennykseltään hiukan sekava.

Koska JHS 129:n useimmat suositukset ovat erinomaisia, seuraavassa kommentoidaan vain sen virheitä tai kyseenalaisia tai huonosti muotoiltuja kohtia:

Sivut järjestykseen: hakemistoja

Sisällys

Pieni on kaunista

Yleensä Web-dokumentin on hyvä olla lyhyt tai lyhyehkö. Jos juttu olisi paperille tulostettuna pitempi kuin kolme neljä sivua, harva viitsii sitä lukea kuvaruudulta. Tietenkin kiinnostunut lukija voi todellakin tulostaa sen paperille. Mutta olisi suotavaa, että tarjoaisit myös kuvaruudulta mukavasti luettavan vaihtoehdon.

Jos on paljon asiaa, jaa se useaksi dokumentiksi. Tähän on useita syitä, muun muassa se, että iso dokumentti kestää latautua. Esimerkiksi ajankohtaisten tapahtumien lista kannattaa ehdottomasti kirjoittaa omaksi dokumentikseen, jotta sitä tarvitseva voi nopeasti hakea juuri sen.

Jos teet vaikkapa jonkin yhdistyksen esittelyä Webiin, ei kannata kirjoittaa yhdistyksen yleisesittelyä, yhdistyksen hallituksen kokoonpanoa, toimintakalenteria, toimintasuunnitelmaa jne. kaikkea yhteen dokumenttiin. Tee kustakin asiakokonaisuudesta oma sivunsa ja linkitä ne yhteen ainakin indeksisivun (pääsivun) kautta.

Kirjatyyppinen aineisto, olipa sitten kyseessä "oppikirja" tai "romaani", on yleensä luonnollista jakaa kerralla luettavaksi sopiviin jaksoihin, esimerkiksi lukuihin. Tällöin on kunkin jakson loppuun syytä panna linkki seuraavaan. Lisäksi ainakin oppikirjan tapauksessa on tarpeen tehdä sisällysluettelo. Esimerkki: Internetixin "kurssi" Elämme fysiikan maailmassa.

Jäljempänä selostetaan, miksi myös iso on kaunista eli miksi aineisto olisi hyvä tarjota sekä paloihin jaettuna että yhtenä kokonaisuutena.

Hakemistotekniikkaa

Käytännön syistä on järkevää jakaa Web-sivut hakemistoihin (directories) tai kansioihin (folders). Näiden eri järjestelmissä käytettyjen nimitysten ero heijastaa osittain teknisiä eroja, mutta keskeisesti on kyse samasta asiasta: tiedostot järjestetään paremman hallittavuuden takia ryhmiin. Jos esimerkiksi kirjoitat laajan johdatuksen hypermystiikkaan, kannattaa kaikki siihen liittyvät tiedostot panna omaan hakemistoonsa tai kansioonsa. Niin ne eivät sekaannu muihin tiedostoihisi. Lisäksi ryhmitys voi olla monitasoinen eli hierarkkinen: hakemistossa voi olla alihakemistoja ja niissä taas voi olla alihakemistoja jne.

Hakemistojen tai kansioiden perustaminen ja käsittely tapahtuu käyttöjärjestelmästä riippuvilla tavoilla. Tässä vain viitataan pariin juttuun aiheesta: Unix-oppaan luku Tiedostot ja hakemistot sekä Marko Nybyn Windowsin peruskäyttö -ohje ja siihen liittyvä ohje Joitakin yleisimpiä toimintoja. Mutta muista, että "Unix" ja "Windows" ovat laajoja käyttöjärjestelmäperheitä, joiden sisälläkin on suurta vaihtelua. Yksityiskohdat kannattaa selvitellä järjestelmäkohtaisista ohjekirjoista tms.

Yleensä on parasta uutta Web-sivujen kokonaisuutta aloittaessaan perustaa sille oma hakemisto - sen hakemiston alihakemistoksi, missä Web-sivusi ovat. Hyvin usein tämä tarkoittaa, että perustat hakemiston toisaalta siihen koneeseen, jolla sivuja valmistelet (esim. oma PC:si), että siihen palvelimeen, johon sivusi siirrät julkaistaksesi ne. Huomaa, että näissä koneissa saattaa olla erilaiset käyttöjärjestelmät. Käytännössä hakemistojen perustaminen ja käsittely palvelimen osalta onnistuu usein FTP-ohjelman käskyillä.

Hakemiston nimi kannattaa valita huolella ja sellainen, jota ei tarvitse muuttaa. Käytännössä se tulee esiintymään URLeissa, joten sen on hyvä olla lyhyehkö, ja esim. skandinaavisia kirjaimia åäö ei kannata käyttää, ei myöskään välilyöntejä.

Hakemistoista ja niihin liittyvistä asioista on Dan kirjoittanut artikkelin Directories and Default Index Files. Kunpa olisin lukenut sen ajoissa! Kerran rämettymään päässyttä hakemistorakenetta on erittäin vaikea korjata.

Irti irrallisista sivuista

Jos teet useita Web-sivuja, kannattaa järjestää ne jonkinlaiseksi kokonaisuudeksi ja liittää ne toisiinsa linkeillä. Kun olet tehnyt edellä mainitun Pieni on kaunista -periaatteen mukaisen useiksi dokumenteiksi jaetun aineiston, on syytä jokaiseen dokumenttiin kirjoittaa ainakin linkki sisällysluetteloon. Tämä on ratkaisevan tärkeää, koska Webille kaikkein ominaisimpia ilmiöitä on se, että ihmiset päätyvät sivuillesi mitä erilaisimpia reittejä, esimerkiksi hakupalvelimien kautta ja linkkejä seuraamalla.

Usein linkki sivuston sisällysluetteloon voidaan yhdistää osaksi kontekstitietoa, jollainen pitäisi olla jokaisen sivun alussa, ehkä osana pääotsikkoa, ehkä muutoin. Jos sivu alkaa vain esimerkiksi otsikolla "Hinnasto", jonka jälkeen tulee iso taulukko, niin siltä puuttuu tieto kontekstista, asiayhteydestä. Esimerkiksi "Oy Firma Ab:n hilavitkutintuotteiden hinnasto" olisi paljon parempi, ja firman nimen voi sitten tehdä linkiksi firman pääsivulle (ja sanan "hilavitkutintuotteiden" linkiksi sivulle, joka esittelee kyseisten tuotteiden ominaisuuksia). Toteutus voi toki vaihdella; ellei sivun otsikosta haluta noin pitkää, voi ennen otsikkoa kirjoittaa esim. "Oy Firma Ab: Hilavitkutintuotteet" ikäänkuin logoksi (ehkä yhdessä logokuvan kanssa).

Entä yksityishenkilön sivut? Lukija, joka löytää jonkin sivusi, saattaa olla kiinnostunut siitä, mitä kaikkea muuta olet tehnyt. Hänelle voi olla myös tärkeää löytää taustatietoja sinusta, esim. asiantuntemuksesi alalla, jota jutussasi käsittelet. Kätevä tapa on käyttää hypertekstiallekirjoitusta eli tehdä nimestäsi linkki pääsivullesi, jolla on tai jonka kautta löytyy sivujesi luettelo.

Jokaisella Web-sivulla tulisi olla jokin olennainen kontekstitieto, jonka kautta lukija tiedon siitä, kuka sivun on tehnyt ja mitä muita Web-sivuja hänellä on.

Ks. Jakob Nielsenin alertboxin Top Ten New Mistakes in Web Design kohtaa Lack of Biographies.

Kyse ei suinkaan ole siitä, että jokaisella sivullasi pitäisi olla linkki jokaiseen muuhun sivuusi! Mutta olisi hyvä, että jokaiselta sivultasi voi epäsuorasti päätyä kaikille muille sivuillesi. Eräs käytännöllinen tapa on tehdä tämä on hypertekstiallekirjoitus, joka viittaa tekijän kotisivuun sanan ahtaassa merkityksessä. Sillä kotisivulle sitten voi olla tässä luvussa esiteltävän kaltainen sivujen indeksi taikka linkki sellaiseen.

Oletustiedostot (index.html tms.)

Yleensä Web-palvelin toimii siten, että kun selain lähettää pyynnön, jossa URL loppuu vinoviivaan, niin palvelin vastaa lähettämällä asianomaisen hakemiston tiedoston, jolla on palvelinkohtainen oletusnimi, esimerkiksi index.html tai default.htm (tarkista käyttämäsi palvelimen dokumentaatiosta!).

Lisäksi jos sennimistä tiedostoa ei ole, niin useat palvelimet itse tuottavat sellaisen rakentamalla hakemiston sisältämistä tiedostoista listan, indeksin. Listan muoto ja sisältö riippuu täysin palvelimesta. Seuraavassa on muuan esimerkki (jonka kaikki linkit eivät toimi):

      Name                   Last modified       Size  Description


[TXT] huo.txt                10-Feb-1999 13:50    15k
[TXT] huolto.html            20-May-1999 08:52    15k
[TXT] huolto.txt             10-Feb-1999 14:13    15k
[TXT] kiitos.html            20-May-1999 13:50     1k
[TXT] kompos.html            27-May-1999 12:37    31k
[TXT] yhdyssanat.html        21-May-1999 12:58     8k

Tähän perustuu se, että hyvin usein ilmoitetaan sentapaisia URLeja kuin
http://jkorpela.fi/suomi/
Usein niistä jätetään vinoviiva pois lopusta, mutta niin ei pidä tehdä. Vinoviiva kuuluu loppuun, jos URLin viimeinen osa on hakemiston nimi.

Mainitunlaista URLia voi käyttää tiedottaessaan sivuistaan ja myös linkeissä. Tästä riippumatta käyttäjät saattavat päätyä kirjoittamaan niitä, jos he huomaavat, että jokin URL ei toimi. Aika monet nimittäin tietävät, että silloin kannattaa kokeilla poistaa URLin lopusta tekstiä viimeiseen vinoviivaan asti, sitten siitä ehkä vielä taaksepäin edelliseen vinoviivaan jne. Näin päästään hierarkiassa ylöspäin, ehkä sivuille, joiden kautta voi yrittää löytää sen, mitä etsitään. (Ehkäpä URLin loppuosassa oli vain kirjoitusvirhe.)

Oman indeksidokumentin tekeminen

Edellä kuvatun kaltainen, palvelimen automaattisesti tuottama indeksi ei yleensä sano paljoakaan. Eihän siitä tavallisesti edes ilmene, mitä eri dokumentit käsittelevät. Mukaan eksyy yleensä myös sivuja, joiden ei ole varsinaisesti tarkoitus näkyä ulospäin ainakaan tällaisissa listoissa.

Yksinkertaisimmillaan indeksidokumentti on hyvin samanlainen kuin edellä käsitelty hypertekstisisällysluettelo, erona vain se, että linkit eivät ole dokumentinsisäisiä vaan viittaavat eri dokumentteihin. Esimerkki: 

<p><a href="../henkkoht.html">Jukka Korpela</a>n
kirjoituksia suomen kielestä:</p>
<ul>
<li><a href="huolto.html"><cite>Onko kielenhuolto hölynpölyä?
 </cite></a></li>
<li><a href="kompos.html"><cite>Suomen kielen yhdyssanamuodot
 (kompositiivit)</cite></a></li>
<li><a href="yhdyssanat.html"><cite>Yhdyssanat yhteen</cite></a>
 (käytännön neuvoja)</li>
</ul>

Tämä näyttää esim. seuraavanlaiselta

Jukka Korpelan kirjoituksia suomen kielestä:

Indeksidokumenttiin voidaan tietysti lisäillä erilaisia aineksia, kuvallisiakin, mutta kovin isoksi sitä ei kannata paisuttaa - parhaimmillaan se on, kun se on pieni ja tehokas.

Jos tiedostoja on paljon ja uusia lisäillään usein, kannattaa ehkä etsiä sopiva työkaluohjelma indeksitiedoston tuottamista varten.

Jotain hienompaa?

Jostakin syystä monet sivuntekijät pitävät suorastaan välttämättömänä

Nämä kaikki merkitsevät eriasteisia huononnuksia yksinkertaiseen ja toimivaan rakenteeseen. Jostain syystä tässä yhteydessä puhutaan "navigoinnista". Ehkäpä siihen sisältyy uusi tulkinta lauseesta Navigare necesse est: navigointipalkkien virittely on välttämätöntä, sisältö ei.

Toisenlaisen tavan hämärtää indeksien rakennetta ja tehdä niistä hankalampia käyttää ovat ns. alasvetovalikot. Seuraavassa on esimerkki siitä, millainen tämän dokumentin 1. osan lukuihin vievä indeksi olisi alasvetovalikkona:

Jos mielesi tekee käyttää moisia, tutustu kirjoitukseeni Navigational pulldown menus in HTML (joka kyllä kertoo myös, miten niitä tehdään, jopa niin että ne toimivat, mutta selostaa tusinan verran syitä, miksi koko ajatus on lähes aina huono).

Työkaluja

Sisällys

Miksi työkaluja?

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 ja muut tarkistukset

Validointi tarkistaa muotoseikkoja

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.

Muitakin tarkistuksia tarvittaisiin

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.

Kieliasu kuntoon

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.

Miten valitsen työkalut?

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:

Muutamia vaihtoehtoja

Seuraavassa esitetään esimerkkien avulla muutamia työkaluja, joita voi käyttää Web-sivujen tekemisessä.

Runkotiedosto

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
Esiprosessointi ja SSI

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.

Sivujen generointi ohjelmalla

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ä.

Iso ja pieni ovat molemmat kauniita, ja muita vaihtoehtoja

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.

Vuorovaikutusta: lomakkeet (forms)

Sisällys

Tarvitaanko vuorovaikutusta?

Web kokonaisuudessaan on vuorovaikutteinen väline. Web-sivuilla vierailija valitsee itse, poistuuko hän sivulta saman tien, miten hän sitä lukee, katselee tai kuuntelee ja seuraako hän sivulla olevia linkkejä. Vierailija voi myös säädellä sitä, miten hän sivun näkee, esimerkiksi muuttamalla selaimen asetuksia ja ikkunan kokoa.

Mutta vuorovaikutteisuus eli interaktiivisuus tarkoittaa Webistä puhuttaessa yleensä vielä jotain muuta, esimerkiksi sitä, että käyttäjän toimenpiteet voivat olennaisesti muuttaa sivun sisältöä taikka suorastaan vaikuttavat Webin ulkopuoliseen todellisuuteen (esim. tavaran tilaaminen, kameran ohjaaminen, tietokannan sisällön muuttaminen). Tyypillisesti tämä tehdään nykyisin JavaScriptillä tai (joskus) Javalla taikka sitten lomakkeilla. Tässä luvussa käsittelemme lomakkeita, koska ne ovat varmin tapa tarjota lisämahdollisuuksia vuorovaikutteisuuteen. Lisäksi todellisuuteen vaikuttaminen hoituu yleensä parhaiten juuri lomakkeiden kautta, kun taas esimerkiksi JavaScript on lähinnä selaimen sisällä leikkimistä.

Martti Rahkilan kirjoitus Interaktiivisuuden toteuttamistekniikat WWW:ssä luonnehtii monipuolisesti sekä palvelin- että selainpohjaisia vuorovaikutteisuuden välineitä. Tässä oppaassa käsitellään niistä vain muutamia tavallisimpia.

Vuorovaikutteisuuden ei kuitenkaan pitäisi olla itsetarkoitus. Sillä pitäisi olla jotain mielekästä merkitystä käyttäjälle, oli se sitten hupia tai hyötyä

Palautteen saaminen (antaminen)

Aloitamme sellaisesta vuorovaikutuksen muodosta, joka tuntuu usein olevan kovin tärkeä aloitteleville sivuntekijöille mutta jonka merkitys käyttäjille ei ole niinkään selvä: sivuntekijä haluaa sivuillaan kävijöiltä palautetta - kehuja, haukkuja, kommentteja, kehitysehdotuksia.

Miksi kukaan antaisi palautetta?

Jos haluat saada palautetta sivuistasi, muista ensimmäiseksi, että sivuillasi vierailevien kannalta on kyse palautteen antamisesta. Se merkitsee heille ajankäyttöä ja vaivaa, josta tuskin kukaan heille maksaa. Tuskin sinullakaan on varaa maksaa siitä heille. Lisäksi monet, jotka haluavat antaa palautetta, oppivat nopeasti, että kovin usein siihen tulee vastaukseksi jotain tylyä, jopa haistattelua. Ja vaikkei tulisikaan, on masentavaa nähdä, että jopa rakentava ja perusteltu kehitysehdotus, jonka toteuttaminen veisi vain vähän aikaa, jää vaille huomiota, tai ainakin vaille vaikutusta.

Muista siis, että olet pyytämässä, etten sanoisi kerjäämässä palautetta. Haluat jotain, jonka saaminen on sinulle paljon tärkeämpää kuin sen antaminen on niille, joilta sitä haluat. Aneleva saati ruikuttava asenne ei silti kannata.

Keskeisintä on
Annatko vaikutelman, että palaute vaikuttaa?

Jos sivusi sisältö on jonkun mielestä hyvä ja sen aihepiiri tärkeä, hän luultavasti toivoisi sivusi kehittyvän vielä paremmaksi. Erityisesti hän voisi toivoa itseään varten lisäyksiä ja muita samoista asioista kiinnostuneita varten korjauksia ja selvennyksiä. Onko hänelle syytä olettaa, että palaute johtaisi sellaiseen? Tärkeintä on, uskooko hän, että saattaisit todella päivittää sivujasi. Tämä riippuu mm. siitä, miten paljon niillä nyt on vanhentunutta asiaa tai tuoreiden asioiden puutetta.

Sekava rakenne, huolimaton kielenkäyttö ja epätarkkuudet asiatiedoissa ovat myös viestejä: jos sivua ei alun perinkään ole tehty kokosydämisesti, onko syytä olettaa, että niistä myöhemminkään kannetaan huolta?

On turha luvata, että päivität sivujasi; teot ja niiden tulokset puhuvat. Wittgensteinia hyvin vapaasti mukaillen voimme sanoa: on asioita, joita ei kannata sanoa, koska sanottuina niitä ei uskota; niiden pitää näkyä.

Vaaditko palautteen antajaa mukautumaan sinun ehtoihisi?

Mitä tulee palautteen antamisen tekniikkaan, niin olennaistahan on, miten lähettäjä haluaa (ja voi) kirjoittaa. Kun kerran Internetistä on kysymys, niin on yleensä kohtuullista olettaa, että lähettäjä voi käyttää meiliä (sähköpostia) ja usein myös haluaa käyttää sitä. Se on melkoisen vaivatonta, ainakin verrattuna siihen vaivaan, mikä itse palautteen kirjoittamisessa on.

Kirjoita sivullesi meiliosoitteesi, mieluiten hypertekstiallekirjoitukseen, mutta joka tapauksessa niin, että se on helppo löytää. Tämä on paljon olennaisempaa kuin mitkään palautelomakkeet, "vieraskirjat" sun muut.

Kuitenkin näkee paljon sivuja, joilla on vain palautelomake! Usein vielä sellainen, joka toimii silloin kun sattuu, ns. mailto:-lomake.

Käyttäjällä voi olla ihan omat syynsä käyttää omaa meiliohjelmaansa, sotkematta Web-selainta tähän asiaan. Ja tällöin käyttäjä haluaa voida ottaa suoraan sivulta osoitteen. Esimerkkejä syistä:

Meiliosoitteen on syytä olla sivulla näkyvissä, ei vain niin sanotussa mailto-linkissä niin, että näkyvä teksti on vain "lähetä palautetta" tai jotain vastaavaa. Sellainen linkki toimii vaivatta vain, jos käyttäjä haluaa käyttää selaimeensa liitettyä meiliohjelmaa. Mutta hänen selaimeensa ei ehkä ole liitetty mitään meiliohjelmaa tai selaimeen liitetty meiliohjelma on hänestä ominaisuuksiltaan ala-arvoinen.

Palveluosoitteet esille

Jos kyse on yrityksen, laitoksen, yhdistyksen tms. sivustosta, on suositeltavaa, että käytössä on ainakin joukko RFC 2142:n mukaisia palveluosoitteita, esim. support@alue tuotetukea varten. Tämän lisäksi voi toki olla suomenkielisille havainnollisempia synonyymeja, esim. tuki@alue. Huomattakoon myös, että RFC 2142:n mukaan osoitteiden www@palvelin ja webmaster@palvelin tulisi molempien toimia (synonyymisina).

Palautelomake

Usein sivuntekijät valittavat, että heidän meilitse saamistaan palautteista ei ilmene, mitä sivua palaute koskee. Tätä ongelmaa sitten yritetään ratkaista liittämällä mailto-linkkiin jokin viritelmä, joka asettaisi viestiin sopivan otsikon (teknisesti: Subject-otsakkeen), joka sitten kertoisi sivuntekijälle, mitä sivua asia koskee. Mutta ei ole mitään luotettavaa tapaa liittää mailto-linkkiin rakennetta, joka asettaisi otsikon. Sen sijaan on mahdollista kirjoittaa sivulle meiliosoitteen lisäksi erityinen palautelomake.

Seuraavassa on hyvin yksinkertainen palautelomake:

<form action="http://www.tipjar.com/cgi-bin/generic"
 method="post">
<p>
<input type="hidden" name="mailto" value="jkorpela@cs.tut.fi">
<input type="hidden" name="subject" value=
 "Kommentteja Web-julkaisemisen oppaasta">
Tällä lomakkeella voit lähettää Jukka Korpelalle
(<code>jkorpela@cs.tut.fi</code>) yleisiä kommentteja
<i>Web-julkaisemisen oppaasta</i>:<br>
<textarea name="mail" rows="3" cols="50">
Kommentteja Web-julkaisemisen oppaasta:
</textarea>
<br>
Lähettäjän meiliosoite (toivottava):
<input type="text" name="mailfrom" size="30">
<br>
<input type="submit" value="Lähetä">
</p>
</form>

Tämä näkyy selaimessasi seuraavanlaisena. Huomioi, että esitysasuun vaikuttaa mm. se, millainen tyylisäännöstö liittyy tähän dokumenttiin. Lomake ei toimi, koska näin tehty lomake on liian altis ns. lomakespämmäykselle. (Voit täyttää ja lähettää lomakkeen, mutta tällöin saat vain selaimeen näkyviin, millaisessa muodossa tiedot lähtisivät palvelinskriptille, joka voisi toimittaa ne eteenpäin.)

Tällä lomakkeella voit lähettää Jukka Korpelalle (jkorpela@cs.tut.fi) yleisiä kommentteja Web-julkaisemisen oppaasta:

Lähettäjän meiliosoite (toivottava):

Lomakkeessa on piilokentässä (hidden field) vastaanottajan osoite. Tämä on melko tavallinen mutta ei itsessään turvallinen järjestely. Tyypillisesti palvelinskriptit, joilla voidaan lähettää viesti sähköpostitse, on tehty sellaisiksi, että niillä voidaan lähettää vain joihinkin ennalta määrättyihin osoitteisiin.

Lomakkeen perusidea HTML:ssä yleisesti on seuraava: Lomake antaa selaimelle ohjeen muodostaa käyttöliittymä, jonka kautta käyttäjä voi kirjoittaa tekstiä tai antaa muuta dataa. Lomakkeen rakenne määrää, minkätyyppisiä kenttiä käyttöliittymä sisältää. Lomakkeeseen liittyy myös action-määrite, joka kertoo selaimelle, mihin osoitteeseen sen tulee lähettää käyttäjältä saatu data jonkinlaista käsittelyä varten. Tämä osoite (URL) viittaa palvelimessa toimivaan ohjelmaan tai skriptiin, jota voidaan kutsua palvelinskriptiksi (server-side script). Palvelinskripti voidaan ohjelmoida tekemään hyvin monenlaisia asioita; yksi vaihtoehto on, että se vain lähettää datan meilitse johonkin osoitteeseen. Palvelinskriptiä voidaan myös käyttää muutenkin kuin lomakkeiden kautta.

Palautelomakkeen tekemistä harkittaessa kannattaa ensisijaisesti selvittää, tarjoaako oma palveluntarjoajasi käyttöösi sopivan palvelinskriptin (jota usein kutsutaan erään käytetyn teknisen piirteen takia CGI-skriptiksi). Ota huomioon, että käytettävät kenttien nimet (kuten edellä olevassa esimerkissä mailto, subject, mail ja mailfrom) ovat palvelinskriptistä riippuvia joten lue käyttöohje huolella. Esimerkiksi jos palveluntarjoajasi on Jippii, löydät sen Web-sivuilta selkeän suomenkielisen ohjeen lomakkeiden tekemisestä, josta ilmenee, mitä kenttien nimiä Saunalahden palvelinskriptin yhteydessä käytetään.

Jos palveluntarjoajasi ei tarjoa sellaista peruspalvelua kuin helppokäyttöinen palvelinskripti lomakedatan toimittamiseksi annettuun meiliosoitteeseen, sinun täytyy harkita muita vaihtoehtoja. Ks. lisätietoja sivulta How to use HTML forms. (Esim. edellä olevissa esimerkkilomakkeissa käytetään TipJarin ilmaista palvelua. Ilmaisuuteen kuuluu, että palvelu voidaan lopettaa koska tahansa ja että mukana on mainoksia. Lisäksi viesti käy kääntymässä turhan kaukana, jos esim. joku Suomesta lähettää sinulle palautetta.)

Lomakkeen rakenne ja kentät

Lomakkeen yleinen rakenne on seuraavanlainen: 

<form action="palvelinskripti" method="post">
<p>
lomakkeen kenttiä, ynnä selitystekstejä ym.
</p>
</form>

Kenttien joukossa on syytä olla lähetyskenttä eli input type="submit" -kenttä, koska vain se takaa, että käyttäjä voi lähettää lomakkeen. Muita mahdollisia kenttiä ovat

Asetusnappia kutsutaan yleisemmin nimellä valintaruutu, joka onkin kuvaavampi, koska kyse on pienestä neliöstä.

Hyvä suomenkielinen esitys lomakkeista on Jyväskylän yliopiston tietotekniikan approbatur-opintojen aineiston osa WWW-lomakkeet. Tarkempia tietoja löytyy mm. erilaisista englanninkielisistä lomaketutoriaaleista.

Seuraavassa on esimerkki palautelomakkeesta, jolla pyritään "lypsämään" käyttäjältä arviointeja. Ihmiset ovat usein valmiimpia vastaamaan, kun he voivat yksinkertaisesti valita vaihtoehdoista, "antaa arvosanoja". Lomakkeen HTML-koodi on melko sotkuinen, ja se on tuotettu esiprosessorilla, kuten kannattaa tehdä sivut, joilla hyvin samantapaiset rakenteet toistuvat.

Tällä lomakkeella voit esittää oman arviosi Web-julkaisemisen oppaan ensimmäisestä osasta (Jambalaya: Miten teen Web-sivun) ja auttaa kehittämään sitä edelleen. Arvioi kukin kohta sekä ymmärrettävyyden kannalta (helppo/ei vaikea eikä helppo/vaikea) että laajuuden kannalta, siis onko asiasisältö tarpeisiisi liian suppea, sopivanlaajuinen vai liian laaja. Lisäksi voit esittää lisäystoivomuksesi eli kirjoittaa, mitä kohdan aihepiiriin kuuluvaa asiaa siinä pitäisi myös käsitellä (tai käsitellä laajemmin).

Kohtaymmärrettävyyslaajuus Lisäystoive
Teksti Webiin
Rakennetta mukaan (HTML)
Dokumentin kirjoittaminen
Otsikoilla ojennukseen
Linkkejä peliin
Näkyminen netissä
Kuvia putkeen
Tietoa taulukoihin
Tekstiä monenlaista

Vapaamuotoisia lisäkommentteja:

Halutessasi voit antaa meiliosoitteesi:

Hakulomakkeen tekeminen

Helpoin tapa tehdä sivullesi hakutoiminto, jolla voi etsiä tietoja sinun sivuiltasi (tai esimerkiksi yhdestä Web-palvelimesta) on tehdä lomake, joka käyttää hyväksi jotain yleistä hakupalvelua. Seuraava lomake käyttää AltaVistaa siten, että haku rajataan sivuihin, joiden URLit alkavat määrätyllä merkkijonolla, eli käytännössä yhteen sivustoon.

Haku Jukka K. Korpelan sivustosta. Kirjoita hakusanasi tekstinsyöttökentässä olevan merkkijonon perään, ei sen tilalle:

Jukka K. Korpelan sivuston suomenkielinen pääsivu sisältää myös vastaavan lomakkeen, joka käyttää Google-järjestelmää.

Näillä tavoilla löytyy tietenkin vain sellaisia sivuja, jotka ovat indeksoituneet hakupalvelun tietokantaan. Eräissä hakupalveluissa on kuitenkin kohtuullisen laaja ja melko usein päivittyvä suomalaisten (Suomessa, tarkemmin sanoen .fi-domainissa, sijaitsevien) sivujen tietokanta.

Vaativampaan käyttöön tarvitaan vaativampia menetelmiä. Jos halutaan palvelu, joka hakee esimerkiksi jostakin palvelimesta niin, että haku ottaa huomioon kaikki siinä olevat sivut tuoreeltaan, täytyy itse tehdä hakupalvelu, joka indeksoi ne sivut niin usein kuin halutaan. Käytännössä yleensä riittää hankkia ja asentaa jokin yleiskäyttöinen ohjelmisto tähän tarkoitukseen. Tämä on kuitenkin webmasterin eikä tavallisen sivuntekijän heiniä.

Edellä kuvattujen mahdollisuuksien välimuotona on sellaisten palvelujen kuin Atomz käyttö. Niissä ideana on, että sivuston tekijä voi pyytää palvelua indeksoimaan hänen sivunsa, ja omille sivuille voi sitten panna hakulomakkeen, joka etsii sivuja palvelun tietokannasta.

Mitä muuta lomakkeilla voisi tehdä

Voisi sanoa, että edellä kuvatut lomakkeiden käyttömahdollisuudet antavat vasta hyvin suppean kuvan asiasta. Lomakkeilla voi tehdä hyvin paljon muutakin kuin helpottaa palautteen lähettämistä ja tarjota käyttöön hakutoimintoja. Esimerkiksi ilmoittautumisen johonkin tilaisuuteen, tuotteiden tilaamisen, tietokannan ylläpidon taikka äänestämisen voisi käyttöliittymän osalta hoitaa lomakkeilla.

Mutta toisaalta kuten edellä kuvattiin, lomake ei itsessään ole muuta kuin eräänlainen käyttöliittymän kuvaus. Lomakkeen tekeminen on yleensä helpoin osa asiaa; varsinainen vaikeus on palvelinskriptin löytäminen tai tekeminen ynnä asentaminen ja testaaminen. Niinpä tarkastelemmekin tätä aihepiiriä vasta seuraavan osan luvussa Palvelinskriptit.

Tässä kohdassa oli aiemmin maininta FlashBase-palvelusta, jolla saattoi tehdä tiedonkeruulomakkeita hyvin helposti. Valitettavasti tämä(kin) ilmaispalvelu on poistumassa eikä enää ota uusia käyttäjiä. Tiedonanto asiasta suositteli kokeilemaan seuraavia vaihtoehtoja: ActiveSpace, BitLocker ja FormSite. Niistä vain viimeksi mainittu näyttäisi olevan enää toiminnassa. Yleisesti kannattaa muistaa, että se, joka tarjoaa ilmaispalveluja, voi lopettaa ne milloin tahansa.

Värikkyyttä: tyylisäännöstöt (style sheets, CSS)

Sisällys

Mitä tyylisäännöstöt (style sheets) ovat

Tyylisäännöstö (style sheet) on yleisesti sanottuna dokumentin esitysasua koskeva ehdotus, joka on kirjoitettu tarkoitukseen erityisesti kehitetyllä kielellä. Näistä kielistä Webissä tärkein, itse asiassa toistaiseksi lähes ainoa käytetty, on CSS. Alan yleistä kehitystä voi seurata Web-konsortion Web Style Sheets -sivuilta.

Tarkemmin sanoen CSS on kieliperhe, johon kuuluvat nykyisin CSS1 ja sitä paljon laajempi CSS2; lisäksi CSS3 on valmisteilla. Seuraavassa keskitytään lähes kokonaan CSS1:een, koska sille alkaa olla osittain jo melko hyvin toimiva tuki selaimissa. Lopussa on muutama viittaus CSS2:een.

Esimerkki erittäin yksinkertaisesta tyylisäännöstöstä (CSS1-kielellä) on seuraava: 

kbd { font-weight: bold; }

Kun HTML-dokumenttiin liitetään tällainen tyylisäännöstö, niin se ehdottaa, että kaikki dokumentin sisältämät kbd-elementit tulisi esittää lihavalla (engl. bold) kirjasinlajilla. Tämä ehdotus ei mitenkään puutu muihin ulkoasuseikkoihin kuten kirjasinten muotoon ja kokoon, tekstin väriin tms.

Hiukan mutkikkaampi tyylisäännöstö on seuraava, jonka vaikutuksen saatat hyvinkin nähdä lukiessasi tätä dokumenttia: 

h1, h2, h3, h4 { color : #000; background : #e0ffdd url(bg3.png);
font-family : Verdana, Arial, Helvetica, sans-serif; }

Tämä säännöstö sisältää useita ehdotuksia otsikkoelementtien esitysasusta. Lyhyesti sanottuna se ehdottaa niiden esittämistä niin, että teksti on mustalla määrätynkuvioista taustaa vasten jollakin ns. sans serif -fontilla ilmoitetussa preferenssijärjestyksessä. Se myös sisältää taustaväriehdotuksen siltä varalta, että kuvat eivät ole käytössä tai selain muusta syystä ei käytä taustakuvaa. Merkinnät #000 ja #e0ffdd ovat värikoodeja. Muihin otsikoiden esittämisen piirteisiin, kuten eritasoisten otsikoiden esittämiseen erikokoisin kirjaimin, tämä säännöstö ei puutu.

Tavallisin ja haitallisin tyylisäännöstöjä koskeva harhaluulo on, että niillä määrättäisiin dokumentin esitysasu ja voitaisiin "määritellä uudestaan" HTML-elementtien merkityksiä. Hyödyllinen naseva muistutus siitä, että CSS:llä voi ehdottaa, ei pakottaa, sisältyy listaan CSS Caveats.

Nimitys tyylisäännöstö on oma ehdotukseni, mutta mielestäni helppo ymmärtää ja luonnollinen. Tyylisäännöstö (engl. stylesheet) nimittäin koostuu säännöistä (rule). Yksi sääntö asettaa joidenkin elementtien joillekin ominaisuuksille (properties) joitakin arvoja. Ominaisuus voi olla esimerkiksi väri, koko, kirjasinlaji tai elementtiä kehystävän viivan paksuus. Säännössä ns. selektori valitsee, mitä elementtejä sääntö koskee. Seuraava kaavio havainnollistaa näiden käsitteiden suhdetta toisiinsa:

sääntö (rule)
  deklaraatio (declaration)  
selektori   ominaisuus (property)   arvo (value)    
h1 { font-family : Arial, sans-serif ; }

Miten tyylisäännöstö liitetään HTML-dokumenttiin

Periaatteessa on useita vaihtoehtoisia tapoja liittää CSS-tyylisäännöstö HTML-dokumenttiin. Käytäntö on osoittanut, että tapojen moninaisuus varsin usein aiheuttaa sekaannuksia. Niinpä tässä esitetään vain yksi selkeä ja looginen tapa:

Yleisemmin nimen (esim. siis art.css) tilalla voi olla URL, joten voit siis käyttää myös jossakin muualla olevaa tyylisäännöstöä. Esimerkki: 

<link rel="stylesheet" title="Yucca's basic style" href="http://jkorpela.fi/basic.css">

Tosin jos käytät jonkun muun tekemää tyylisäännöstöä, niin voi tulla ikäviä yllätyksiä, jos se joku muu muuttaa sitä tai poistaa sen.

Mitä kaikkea tyylisäännöstöillä voisi tehdä

Se, mitä tyylisäännöstöillä voi tehdä, riippuu kahdesta asiasta:

Karkeasti sanottuna nykyisin voi käytännössä käyttää CSS1:tä, vaikka senkin toteutus selaimissa on hyvin puutteellinen ja viallinenkin. Joitakin CSS2:n piirteitä on myös toteutettu joissakin selaimissa.

CSS1:ssä voi ehdottaa elementeille lähinnä seuraavanlaisia ominaisuuksia:

Jo tästä suppeasta luonnehdinnasta selvinnee, että CSS1:täkin voi helposti käyttää väärin. Ei ole mitään teknistä estettä ehdottaa 1. tason otsikoiden näyttämistä millimetrin korkuisilla kirjaimilla punaisina punaisella taustalla - tai niiden jättämistä kokonaan pois! Jos tämä tuntuu oudolta, et ole vielä nähnyt paljoakaan. Ks. esim. WDG:n iskevää Style Sheet Dependence -sivua tai artikkeliani Lurching Toward Babel: HTML, CSS, and XML (PDF).

Miten asiat sotketaan tyylikkäästi

Primum non nocere.
Ensimmäiseksi [muista että hoidolla] ei [saa] vahingoittaa [potilasta].

Tämä vanha lääkärinohje, ilmeisimmän sisältönsä lisäksi, viittaa siihen, että jos potilasta ei lainkaan hoideta, on mahdollista, että "luonto" parantaa. Modernimmin sanottuna ihmisen elimistön oma toiminta kuten immuunipuolustus ja haavojen arpeutuminen ehkä korjaa tilannetta, kenties koko tilanteen. Tämä ei tarkoita sitä, että lääkärin ei pitäisi koskaan tehdä mitään. Mutta se tarkoittaa, että ei pidä ruveta hoitamaan, ellei ole jotain perusteita olettaa, että hoidosta on enemmän hyötyä kuin haittaa. Se, että tekee jotain vain tehdäkseen jotain, ei ole hyvä ajatus. Se voi esimerkiksi sotkea luonnollisen immuunipuolustuksen niin, että tuloksena on tilanne, joka on paljon pahempi kuin se olisi ilman "hoitoa". Lääketieteen ja puoskaroinnin historia tuntee paljon sellaisia "hoitomuotoja".

Miten tämä voisi analogisesti koskea Web-sivuja ja tyylisäännöstöjä? Ensinnäkin siten, että jos sinä saat tyylisäännöstöillä (tai muilla keinoin) "viritettyä" sivusi näkymään mielestäsi paremmin, ei ole mitään takeita, että se parantaa tilannetta yleisesti. Se, mitä sinä näet, on se, mitä sinä näet. Entäs jos useimpien muiden katselutilanteessa ulkoasu meneekin paljon hullummaksi kuin ilman "hoitoa"? (Tai voi olla, että 80 %:ssa katselutilanteista esitysasu on hiukan kauniimpi kuin ilman tyylisäännöstöjä mutta 20 %:ssa paljon rumempi tai jopa lukukelvoton.) Tämä on mahdollista, jopa tavallista, eikä ainoa syy suinkaan ole se, että monien selainten tyylisäännöstötuessa on pahoja virheitä. (Itse asiassa tämä koskee kaikkia selaimia - mutta virheitä on eri asioissa.)

Mutta myös ajatuksella "luonnon" parantavasta vaikutuksesta on vastineensa Web-maailmassa. Oletetaanpa, että jonkin yleisesti käytetyn selaimen tapa esittää joitakin HTML-rakenteita on kertakaikkisen huono. Esimerkkejä ei tarvitse erityisesti etsiä; mainittakoon vaikkapa se, että Internet Explorer 4 näyttää select-elementillä tehdyn valikon tekstit selvästi pienemmällä kuin normaalitekstin. Kannattaako tällaista ruveta korjailemaan omien sivujensa osalta? Kysehän on selaimen piirteestä. Joskus ehkä kannattaa "hoitaa" tällaisia asioita tyylisäännöstöillä, mutta kannattaa muistaa, että se on vain oireiden hoitoa. Ja esimerkkitapauksessamme käy itse asiassa hyvin helposti hullusti: IE 4 ymmärtää select-elementtien fonttikokoon vaikuttavia tyylisääntöjä päin seiniä, niin että esimerkiksi kokomäärite small aiheuttaa koon suurentamisen. Ja jos kokeilemalla olet huomannut näin olevan ja ajattelet, että "sehän toimii", niin sitten sivusi tulee "toimimaan" päin seiniä kaikilla selaimilla, jotka toteuttavat kyseisen tyylisäännön oikein.

Mihin tyylejä sitten kannattaa käyttää?

Tyylejä voi käyttää dokumentin rakenteen korostamiseen. Esimerkiksi jos dokumentissa on paljon lainauksia, kuten esim. tieteellisessä artikkelissa taikka kirjallisuusarvostelussa usein on, voi olla hyödyllistä ehdottaa jotain blockquote-elementtien esitysasusta. Niiden tavanomainen esitysasu yleensä erottaa ne melko huonosti normaalitekstistä. Yksi keino on ehdottaa sopivaa taustaväriä. Seuraavassa on eräs mahdollisuus: 

blockquote { background : #eaeaea none; color: #000; }

Ja jos tekstissäsi on runsaanpuoleisesti lainauksia kahdesta eri lähteestä, voi olla eduksi erottaa ne toisistaan visuaalisesti käyttämällä hiukan erilaisia taustavärejä.

Toissijaisesti tyylejä voi käyttää "tyylittelyyn": ulkoasun saattamiseen jutun luonnetta vastaavaksi, sitä korostavaksi. Tyypillisesti käytetty keino on jutun aihepiiriin liittyvän taustakuvan käyttö. Tässä on kuitenkin syytä olla hyvin varovainen: yleensä taustakuva vaikeuttaa lukemista. Ainakin on syytä käyttää himmeää taustakuvaa, jossa ei ole liikaa yksityiskohtia. Kenties himmeän taustavärin käyttö riittäisi, ja joka tapauksessa siitä kannattaa aloittaa; jos nimittäin ehdottaa taustakuvaa, on syytä ehdottaa myös siihen sopivia tekstin ja linkkien värejä ja tämän takia myös taustaväriä. Taustavärihän näkyy silloin, kun selain ei syystä tai toisesta käytä taustakuvaa.

Tyylittelynä voidaan käyttää myös kappaleiden ulkoasun ehdottamista "kaunokirjallisen tyylin" mukaiseksi, jos juttu on vaikkapa novelli tai sisältää otteen sellaisesta. Kyseinen tyyli sisältää erityisesti sen, että kappaleiden välissä ei ole isompaa väliä kuin normaali rivinväli mutta kunkin kappaleen ensimmäistä riviä on hiukan sisennetty. Luvun ensimmäistä kappaletta ei kuitenkaan sisennetä, mutta sen alkukirjain on ehkä iso ja tyylitelty. Seuraavassa on eräs mahdollisuus ehdottaa tällaista esitysmuotoa, kuitenkin siten, että tässä kappaleiden välillä on hiukan ylimääräistä tilaa: 

p { text-indent : 1em;
    margin-bottom : 0.5ex;
    margin-top : 0.5ex; }

p.start { text-indent : 0; }

p.start:first-letter { font-size : 200%; font-weight : bold;
   color : #060; background : #fff none; }

Edellä käytetty ns. pseudoelementti first-letter toimii tätä kirjoitettaessa vain muutamissa selaimissa (kuten Opera ja Netscape 6). Muilta osin kyseinen tyylisäännöstö toimii myös IE 4:ssä ja Netscape 4:ssä. Seuraavissa kolmessa kappaleessa sitä on käytetty, joten näet, miten sinun selaimesi sen toteuttaa. (Laajempi esimerkki tämäntapaisesta tyylistä on juttuni Passiivin käytöstä, jonka ehdotetussa ulkoasussa on pyritty jäljittelemään jutun alkuperäistä painoasua.)

Usein halutaan vaikuttaa kirjasinlajien eli fonttien käyttöön sivuilla. Parasta on yleensä tehdä tämä epäsuorasti, käyttäen loogisia tekstielementtejä kuten strong ja cite. Yleensä on aivan tarpeetonta yrittää vaikuttaa siihen, mitä kirjasinlajia selain käyttää ns. leipätekstille, ja suorastaan haitallista yrittää asettaa leipätekstin koko; ks. Jukka Tujulan kirjoitusta Fonttikoot WWW-sivuilla. Jos kuitenkin halutaan erottaa joitakin jutun osia muista, esimerkiksi lainaukset omasta tekstistä, käyttäen kirjasinlajien muuntelua yhtenä keinona, niin silloin on toki syytä ehdottaa leipätekstin fonttikin.

Fonttien käytöstä on Todd Fahrner kirjoittanut käytännöllisen ohjeen Beyond the FONT tag: Practical HTML text styling. Kirjasinlajeihin vaikuttaminen on sen mukaan mahdollista tehdä CSS:llä kohtuullisen hyvin; sen sijaan kirjasinten koko on paljon ongelmallisempi asia nykyisissä toteutuksissa. Taustatietoja "fonttien maailmasta" tarjoaa Dmitry's Design Labin The World of Fonts.

Jos käytät mustaa taustaa ja vastaavasti valkoista, keltaista tai muuten vaaleaa tekstin väriä, ota huomioon, että valkoinen teksti mustalla taustalla on vaikeampaa lukea kuin samankokoinen musta teksti valkealla taustalla. Jos siis ehdotat mustaa taustaa, on syytä ehdottaa fonttikokoa isommaksi. Tämä on sitten ongelmallista, kuten edellä sanottiin, ja varminta lienee käyttää big-elementtiä; koska se on tekstitason elementti, täytyy tällöin kirjoittaa mm. joka kappaleen alkuun (<p>-tägin perään) <big> ja joka kappaleen loppuun (ennen </p>-tägiä) </big>. Muuten käy niinkuin Todd Fahrnerin Agitprop-sivulla, joka ei ole käytännössä kovinkaan sujuvasti luettavissa ilman selaimen asetusten säätöä, jos selaimen normaaliasetukset tekevät normaalitekstin luettavaksi!

Värikoodit

Yksinkertaisimmillaan värikoodit ovat CSS:ssä muotoa #pvs missä p, v ja s ilmoittavat punaisen, vihreän ja sinisen valon intensiteetin heksadesimaalinumerolla 0, 3, 6, 9, c tai f. Nämä tarkoittavat itse asiassa heksadesimaalilukuja 00, 33, 66, 99, cc ja ff eli desimaalilukuja 0, 51, 102, 153, 204 ja 255. Näin saadaan 216 värin paletti, jonka värejä sanotaan "turvallisiksi", browser-safe colors. Tosin turvallisuus on hiukan kyseenalaista kuvissa käytettävien värien osalta, mutta taustan ja tekstin väreinä nämä värit toimivat luotettavammin kuin muut. (Hyvä havainnollinen "värikartta" näistä väreistä on Dave Raggettin jutun Adding a touch of style kohdassa Browser safe colors.) Myös muita intensiteettejä (väliltä 0 - f) voi käyttää.

Esimerkiksi #f00 on siten puhdas punainen, #fff on puhdas valkoinen (sisältää kaikkia värejä maksimimäärän) ja #000 on musta (ei sisällä minkäänväristä valoa, siis täysi pimeys).

Värikoodi #pvs voi olla myös pidempää muotoa, missä p, v ja s ovat kaksinumeroisia heksadesimaalilukuja, siis väliltä 00 - ff. Näin voidaan esittää paljon laajempi valikoima värejä. Värien esityksen tarkkuus kuitenkin riippuu käyttäjän näyttölaitteesta ja sen asetuksista. Jos käytössä on esimerkiksi vain 256 eri väriä, mikä on aika tavallista, tulos on sama kuin jos värikoodit pyöristettäisiin kukin lähimmäksi "browser-safe" -väriksi.

Tässä värijärjestelmässä on kyse valon eri väreistä ja siten additiivisista väreistä, tarkemmin sanoen RGB-järjestelmän mukaisista (red, green, blue). Jos sekoitat vihreää ja punaista maalia tai muuta väriainetta, saan jonkinlaista ruskeaa; mutta additiivisessa järjestelmässä on kyse valojen yhdistämisestä, ja silloin vihreän ja punaisen yhdistäminen tuottaa keltaisen. Ks. Internetixin kurssin Värähdys- ja aaltoliike osaa Värit.

Kirkkaimpia värejä kuten puhdasta punaista (#f00) kannattaa käyttää hyvin varovaisesti.

Kuvaruudulla voimakkaat värit ovat vielä paljon ärsyttävämpiä kuin muualla. Muutama pieni voimakkaanvärinen läiskä tai teksti voi olla eduksi, mutta esimerkiksi punaisen käyttäminen leipätekstin (tai taustan!) värinä on hyvin ajattelematonta. Käytä mieluummin himmeitä pastellivärejä taustan värinä ja vain jonkin verran mustasta poikkeavia värejä tekstin väreinä. Tällöin mahdolliset kuvasikin pääsevät paremmin oikeuksiinsa, kun räikyvät tekstin ja taustan värit eivät häiritse.

Taustatietoja "värien maailmasta" julkaisemisen kannalta tarjoaa Dmitry's Design Labin The World of Color. Teknisempiä tietoja värien käytöstä antavat mm. WDG:n sivun Design Elements kohdassa Color Palettes and Usage ja Kevin Werbachin The WWW help pagen kohdassa Setting Background and Text Colors mainitut jutut.

Koskaan ei pidä luottaa väriin ainoana informaation välittämisen keinona. Esimerkiksi työntekijöiden lomia esittävä taulukko, jossa tyhjien alkioiden taustavärillä kerrotaan, onko asianomainen lomalla vai ei, on esimerkki tämän säännön karkeasta rikkomisesta. Värit voivat jäädä näkemättä hyvin monista eri syistä: värisokeus, mustavalko- tai harmaasävynäyttö, mustavalkotulostus paperille, selaimesta käännetty "pois" tekstin ja taustan värit (koska niin monilla Web-sivuilla käytetään värejä niin järjettömän räiskyvästi) jne. Esimerkkitapauksessa auttaisi asiaa jo se, että alkiossa on vaikkapa jokin kirjainkoodi, josta voisi edes arvata jotain. Aiheesta lisää: Web Content Accessibility Guidelines, periaate 2: Don't rely on color alone.

Yhteensovittaminen

Oletetaanpa, että haluat tehdä jotain niin vaatimatonta kuin ehdottaa sivullesi himmeänsinistä taustaväriä, vaikkapa "turvallista" väriä #cff. (Se voisi olla hyvä idea vaikkapa akvaarioaiheisella sivulla.) Luonnollista olisi yrittää ensin seuraavaa: 

body {background : #cff;}

Mutta tämä tarkoittaisi olennaisesti seuraavanlaista toivomusta: käytä vaaleansinistä taustaväriä ja ihan mitä vaan tekstin väriä. Vaikka tekstin väri todennäköisimmin on musta, siihen ei pidä luottaa. Kenties joku käyttää pitää pikimustasta taustasta ja valkoisesta tai vaikkapa vaaleansinisestä tekstistä ja on asettanut selaimensa käyttämään niitä. Jos selain sitten tältä pohjalta soveltaa tyylisäännöstöäsi tehden juuri sen, mitä se sanoo, tuloksena on erittäin vaikeasti luettava tai kokonaan lukukelvoton sivu. Jos ehdotat taustan värin, ehdota myös siihen sopiva tekstin väri, tässä tapauksessa musta. Periaatteessa on myös mahdollista, että käyttäjän selain oletusarvoisesti käyttää jotain taustakuviota. Siihenkin sinun on syytä varautua. Kun kerran ehdotat tekstin väriä, niin velvollisuutesi on tehdä kaikki voitava taustankin suhteen. Yksinkertaisimmin tämä tapahtuu ehdottamalla, ettei selain käytä taustakuvaa lainkaan; toinen vaihtoehto olisi tehdä tekstin värille sopiva taustakuvio.

Huomaa, että jos selaimesta on kuvien automaattilataus kytkettynä pois, se ei lataa eikä käytä taustakuviakaan vaan taustaväriä. Jos taas automaattilataus on toiminnassa, selain aluksi käyttää taustaväriä ja vaihtaa sen taustakuvaksi myöhemmin, kenties niin nopeasti, ettei käyttäjä ehdi huomata taustaväriä lainkaan.

Seuraava tyylisäännöstö olisi siis paljon luotettavampi: 

body {background : #cff none; color : #000;}

Linkit mutkistavat vielä asioita. Yleisimmissä selaimissa on oletusarvona näyttää linkkitekstit violetilla tai sinisellä sen mukaan, onko linkki "käyty" vai "käymätön" eli onko kyseinen käyttäjä hiljattain seurannut linkkiä vai ei. Tämä on sivujen käytettävyyttä aivan olennaisesti parantava seikka, jota ei pidä mennä pilaamaan! Toisaalta linkkien väreihin pätee sama kuin tekstin väriin: et voi tietää, mitä värejä selain käyttää. Jos siis ehdotat taustan ja tekstin väriä, on syytä ehdottaa myös linkkien värejä. Muutenhan voi käydä niin, että linkit eivät lainkaan erotu normaalitekstistä - tai ovat lukukelvottomia taustavärin takia. Yleensä on syytä tällöin käyttää selainten tyypillisiä oletusarvoja. (Kuuluisan artikkelin Top Ten Mistakes in Web Design mukaan 8. virhe on Non-Standard Link Colors.) Tämä tietysti asettaa omat rajoituksensa taustan ja tekstin värin valitsemiselle; käytännössä taustan on yleensä syytä olla vaalea ja tekstin värin lähellä mustaa.

Kun vielä otetaan huomioon eräät linkkeihin liittyvät seikat, päädytään seuraavaantapaiseen tyylisäännöstöön: 

body {background : #cff none; color : #000;}
a:link    { color : #009; background : transparent none; }
a:visited { color : #609; background : transparent none; }
a:active  { color : #f00; background : transparent none; }
a:hover   { color : #933; background : #eee none; }

Selaimet sitten saattavat soveltaa tätä kokonaan tai osittain. Esim. Netscape 4 ja Opera 3.6 eivät tue kahta viimeksi esitettyä sääntöä, joka itse asiassa kuuluu CSS2:een. Kumpikaan ei muuta linkin väriä, kun kursori viedään sen päälle, oli tyylisäännöstö käytössä tai ei. "Aktiivisen" linkin käsitettä ei tuossa vanhassa Operan versiossa ole lainkaan, ja Netscape 4 taas käyttää kiinteästi punaista väriä "aktiivisille" linkeille. Mutta dokumentin tekijän on silti syytä kirjoittaa tyylisäännöstönsä edellä kuvatun tapaisesti; muutoin hän voi sotkea asioita niin, että selain, joka normaalisti käyttäisi esim. erityistä väriä kursorin ollessa linkin kohdalla, menettää tämän ominaisuutensa.

Tyylien käytön tekniikkaa

Seuraavassa on ehdotus menettelytavoiksi, jos haluat käyttää tyylisäännöstöjä. Olen laatinut englanninkielisen, kehyksiä käyttävän sivun, joka ehkä auttaa soveltamaan näitä menettelytapoja.

Aluksi kannattaa tutustua johonkin edellä esitettyä täydentävään, CSS:n perusasioita selittävään tai niihin johdattavaan juttuun kuten seuraaviin:

Lukemisessa on ehkä pientä apua jutustani CSS-termejä suomeksi ja englanniksi, jossa on myös lyhyitä suomenkielisiä määritelmiä keskeisimmille CSS1:n käsitteille.

Kun sitten halutaan käyttää tyylisäännöstöjä johonkin nimenomaiseen tarkoitukseen, kannattaa toimia näin:

  1. Kirjoita juttu (HTML-dokumentti) hyvien rakenneperiaatteiden mukaisesti, murehtimatta vielä esitysmuotoa. Huolehdi siitä, että juttu "toimii" hyvin ilman tyylisäännöstöjä. CSS:llä voi tehdä hyvästä paremman, mutta ei huonosta hyvää.
  2. Mieti, millaisia esitysasun parannuksia haluaisit tehdä. Usein herätteen antaa jokin yksityiskohta, jossa tavallisimmat selaimet esittävät jutun vähän rumasti tai tylsästi. Tai sitten sinulla ehkä on selvä mielikuva siitä, millainen esitysasu olisi paras. Tutki sitten esim. WDG:n CSS Properties -aineistoa nähdäksesi, mikä on periaatteessa mahdollista ja miten se periaatteessa tehdään. Epäselvissä tilanteissa lue virallisia CSS1:n ja CSS2:n spesifikaatioita. Vaikka CSS2 on suurimmaksi osaksi toteuttamatta, sen spesifikaatio voi olla hyödyksi, koska se sisältää monista peruskäsitteistä tarkemman kuvauksen kuin CSS1-spesifikaatio.
  3. Tutki, mikä käytännössä toimii toteutuksissa. Tässä on erittäin suureksi avuksi Eric Meyerin Master Compatibility Chart. Huomaa, että tuen puuttuminen ("N" kyseisessä taulukossa) ei ole ollenkaan niin vakavaa kuin toteutuksen bugisuus ("B") on! Voit myös käyttää sivustoa CSS1 Test Suite testataksesi eri CSS-piirteiden toimivuutta käyttämilläsi selaimilla.
  4. Jos päädyt siihen, että CSS sopii tarkoituksiisi, kirjoita tyylisäännöstö ja liitä se juttuusi.
  5. Tarkista tyylisäännöstösi CSSCheckillä. On käytännöllisesti katsoen varmaa, että teet virheitä kirjoittaessasi tyylisäännöstön - jokainen tekee.
  6. Tarkista HTML-dokumenttisi validaattorilla. Teit sen tietysti jo 1. kohdassa, mutta tee se uudestaan, vaikka HTML-dokumenttiin tekemäsi muutokset tuntuisivatkin pieniltä.
  7. Katso, miltä se näyttää tärkeimmillä selaimilla. Lähinnä on syytä katsoa toimivuus Internet Explorer 4:llä, Netscape 4:llä ja Opera 3.60:lla. Hyvä olisi katsoa myös toimimattomuus IE 3:lla, mutta käytännössä IE 3:n huomioon ottaminen yleensä tekee CSS:n käytön mahdottomaksi tai hyödyttömäksi - niin paljon siinä on bugeja.

Kun sitten menee kuitenkin pieleen, seuraavista vinkeistä voi olla apua:

Ominaisuuksien "riippumaton periytyminen" CSS:ssä

Yksi tavallisimmista virheistä tyylisääntöjen käytössä on se, että oletetaan, että selain joko soveltaa tyylisäännöstöä sellaisenaan tai jättää sen kokonaan huomiotta. No, ehkä vielä tavallisempi erehdys on ajatella, että ainakin "tarpeeksi uusi" selain aina soveltaa dokumentin kirjoittajan tekemää tyylisäännöstöä! Mutta sellaiseenhan emme sortune?

Tarkastellaanpa seuraavaa yksinkertaista tyylisäännöstöä:

strong { color : #300; }

Tämähän on varmaankin vaaratonta? Siinähän vain ehdotetaan tavallisesta mustasta hiukan poikkeavaa väriä (hyvin tumman ruskeaa) strong-elementille.

Mutta emme voi tietää taustaväriä. Entäpä jos käyttäjä on selaimessaan asettanut tai selaimessa muuten vaan on vaikkapa musta taustaväri ja valkea teksti? Menee huonosti.

No, korjataanpa asia lisäämällä seuraava:

body { background : #fff none; color : #000; }

Nyt sitten joko käyttäjän selain käyttää omia asetuksiaan ohittaen kaikki tyyliehdotuksemme tai näyttää valkealla taustalla normaalin tekstin mustalla ja vahvasti korostetun tekstin tummanruskealla. Vai vieläkö jäi sudenkuoppa?

Toki. Ensinnäkin unohtui, että linkkien väreille on syytä tehdä jotain. Mustaa taustaa rakastava käyttäjämme toki on fiksuna henkilönä asettanut selaimen käyttämään siihen sopivia linkkien värejä, koska normaalit oletusarvot kuten tummansininen eivät kovin hyvin erotu mustaa taustaa vasten. Ja nyt kun emme ole linkeistä mitään sanoneet, selain käyttää omia asetuksiaan. Lisäksi meidän on huolehdittava taustakuvasta. Mutta näitä asioita käsiteltiin jo edellä. Tämä oli vain muistutus seuraavasta:

Jos ehdotat joitakin värejä ja taustoja, laadi kokonaisehdotus, joka kattaa niin taustavärin ja -kuvion kuin tekstin ja erilaisten linkkienkin värit.

Mutta ei tämä riitä. Katsotaanpa miten käy esimerkkitapauksessamme, vaikka olisimme täydentäneet body-elementtiin ja linkkeihin liittyviä tyylisääntöjä aiemmin esitettyyn tapaan. Kun dokumentissa on strong-elementti, niin selain toimii, tai sen ainakin pitäisi toimia CSS:n määrittelyyn sisältyvän ns. kaskadin (cascade) mukaan, seuraavasti:

  1. Selain katsoo, mitä tyylisääntöjä ylipäänsä on olemassa, jotka koskevat strong-elementtejä. Tässä tapauksessa on meidän sääntömme strong color : #300; } ja selaimen oletusarvoiset säännöt, jotka ovat meille tuntemattomat, mutta jotka saattaisivat olla seuraavat (CSS2-spesifikaation liitteessä A ehdotetun esimerkin mukaiset): 
    STRONG { font-weight: bolder }
STRONG { pitch: medium; pitch-range: 60; stress: 90; richness: 90 }

    Jälkimmäinen koskee vain äänimuodossa, esim puhesyntetisaattorilla, tapahtuvaa dokumentin esittämistä.

  2. Koska tässä tapauksessa säännöt koskevat eri ominaisuuksia, mitään valintatilannetta ei ole, vaan selain soveltaa kaikkia. Jos sen sijaan olisimme ehdottaneet font-weight-ominaisuudelle muuta arvoa kuin bolder, se olisi "voittanut" selaimen oletusarvon, samoin kuin mahdollisessa käyttäjän tyylisäännöstössä olevan asetuksen samalle ominaisuudelle, ellei siinä ole lisämääritettä !important.
  3. Ne ominaisuudet, joille ei lainkaan määräydy arvoa edellä sanotun perusteella, määräytyvät "periytymisen" (inheritance) kautta: jos elementille ei ole asetettu jonkin ominaisuuden, esim. color, arvoa, se saa tämän ominaisuuden siltä elementiltä, jonka sisällä se välittömästi on. Tämä taas on ehkä perinyt sen "ylemmältään" jne. Jos siis dokumentissa on vaikkapa
    <body><p><strong>Hei</strong></p></body>
    niin strong-elementti "perisi" p-elementiltä ominaisuuksia, jotka taas voisivat "periytyä" body-elementiltä. Täten yleensä esimerkiksi strong-elementti saa saman taustavärin kuin dokumentti kokonaisuutena, ja jos olimme kirjoittaneet asianmukaiset säännöt body-elementille, kaikki on hyvin. Yleensä.

Mutta entäpä jos käyttäjän tyylisäännöstössä on
strong {color : #ffc ; background : #000 none; }
eli keltaista mustalla. Nyt strong-elementti saakin background-ominaisuuden käyttäjän tyylisäännöstöstä. Ja koska dokumentin tekijän tyyliehdotukset normaalisti voittavat käyttäjän omat, niin color-ominaisuus tulee tekijän tyylisäännöstöstä. Ei mene hyvin, kun on tummanruskeaa mustalla.

Kenen syy? Käyttäjän tyylisäännöstö on tältä osin sisäisesti melko johdonmukainen, joten syy on dokumentin tekijässä, joka ei ollut ottanut huomioon tätä:

Myös yksittäisten elementtien eikä vain koko dokumentin osalta pätee: taustaväri, taustakuva ja tekstin väri on syytä ehdottaa aina yhdessä. Ei pidä luottaa siihen, että taustaväri on jo asetettu koko dokumentille.

Linkkien väritkin pitäisi ottaa huomioon - tekijän tyylisäännöstössä silloin kun elementin sisällä voi olla linkkejä, käyttäjän tyylisäännöstössä aina. (Käyttäjähän ei voi tietää, onko esim. strong-elementtien sisällä linkkielementtejä tai kääntäen.) Hankalaa? Kyllä. Ja toistaiseksi on melko harvinaista, että käyttäjillä on omia tyylisäännöstöjä. Mutta ei kannata tehdä "moderneilla välineillä" hienoja sivuja, jotka menevät rikki, kun niitä katsellaan oikeasti moderneilla välineillä ja tavoilla.

Puhe ominaisuuksien periytymisestä on toki kaukaa haettu ja monin tavoin harhaanjohtavakin analogia. Mutta se on joissakin suhteissa ehkä valaiseva. Etenkin niille, jotka tuntevat genetiikkaa, sillä voidaan sanoa: CSS:ssä ominaisuudet periytyvät toisistaan riippumatta hiukan niinkuin geenit yksinkertaisimmassa tapauksessa. Esimerkiksi elementin tekstin väri (color-ominaisuus) tällöin vastaa yhtä geeniä, ja väri tulee joko tekijän tai käyttäjän tyylisäännöstöstä (tai selaimen oletusarvoista), ei niiden sekoituksena. Ja ennen muuta: se "periytyy" täysin riippumatta esimerkiksi background-ominaisuuden "periytymisestä". Se, että tyylisääntöjä voidaan niputtaa tyyliin
strong {color : #ffc ; background : #000 none; }
on siis siinä mielessä harhaanjohtavaa, että aaltosuluissa olevat asetukset eivät suinkaan käyttäydy jakamattomana kokonaisuutena.

CSS2 (ja CSS3): positiointi ym.

CSS2 on CSS1:tä paljon laajempi tyylisäännöstökieli, jonka toteutus selaimissa on vielä erittäin puutteellinen. Lisäksi kokemusta ja oppaita sen käytöstä ei vielä ole kertynyt paljoakaan. Suurin osa asioista on opiskeltava suoraan CSS2-spesifikaatiosta, joka on varsin laaja ja paikoin raskaslukuinen. Ja hommat toimivat tai sitten eivät, yleensä eivät. CSS2:n osalta ei ole koottu sellaisia selaintukitiivistelmiä tai bugilistoja kuin CSS1:stä. CSS Pointers Menu toki sisältää jotain CSS2:eenkin liittyvää.

Hyvä, havainnollinen johdanto yhteen CSS2:n alueeseen, positiointiin eli elementtien sijoitteluun sivulla, on Stephanos Piperogloun CSS Positioning, Part I. Jatkolukemisiksi sopivat sitten saman tekijän CSS Positioning, Part II sekä CSS Floats, Part I ja CSS Floats, Part II.

Muita mainitsemisen arvoisia CSS2:n piirteitä ovat:

Jos käytät CSS2:ta, kannattaa ehdottomasti tarkistaa tyylisäännöstö W3C:n CSS2 Validation Servicellä.

CSS3 on luonnosasteella oleva kehitelmä, joka laajentaisi CSS:ää modulaarisesti: interaktiivisuutta, skaalautuvaa vektorigrafiikkaa, "kansainvälisyyttä", monipalstaisuutta, ...

Lisätietoja tyyleistä löytyy sivun Keskeisiä CSS-linkkejä kautta.

Loppumuistutus tyyleistä

Tyylisäännöstöjä kannattaa käyttää hillitysti ja harkitusti ja vasta kun sisältö ja rakenne on kunnossa. On parempi saada juttu ylipäänsä Webiin tällä viikolla ja esitysasu hiukan tyylikkäämmäksi ensi kuussa kuin toisinpäin. Jos jotain jää tekemättä, olkoon se tyyli, ei sisältö!

Tyyli ei saa olla sisällön välittymisen este millään tavoin: tyyliehdotuksilla pyritään vain parantamaan esitysasua. Jos sivu ei toimi silloin, kun tyyliehdotukset eivät toteudu, sivu on rikki.

Merkillisyyksiä: merkit ja niiden koodit

Sisällys

Tämä luku käsittelee erilaisten merkkien (characters) sisällyttämistä Web-sivuille. Mitä laajempaa merkkivalikoimaa tarvitset, sitä vaikeammiksi hommat käyvät.

"Turvalliset" merkit

"Turvallisia" merkkejä datan käsittelyssä ja siirrossa ovat oikeastaan vain Ascii-merkit, ja niistäkin joihinkin liittyy ongelmia eri yhteyksissä.

Seuraava taulukko esittää Ascii-merkistön kirjoittuvat merkit; HTML:n kannalta ongelmalliset merkit ovat korostettuina: 

  ! " # $ % & ' ( ) * + , - . /
0 1 2 3 4 5 6 7 8 9 : ; < = > ?
@ A B C D E F G H I J K L M N O
P Q R S T U V W X Y Z [ \ ] ^ _
` a b c d e f g h i j k l m n o
p q r s t u v w x y z { | } ~

Kyseisiin ongelmallisiin merkkeihin liittyvät seikat ovat ratkaistavissa helposti:

" Voidaan yleensä kirjoittaa sellaisenaan, mutta määritteiden arvoissa (lainausmerkkien sisällä) käytetään merkintää &quot; (esimerkki: title="Jukka &quot;Yucca&quot; Korpela"
& kirjoitetaan &amp; silloin, kun halutaan sisällyttää &-merkki itse dataan (esim. R&amp;D näkyy muodossa R&D)
< kirjoitetaan &lt; silloin, kun halutaan sisällyttää <-merkki itse dataan (esim. a&lt;b näkyy muodossa a<b)
> kirjoitetaan &gt; silloin, kun halutaan sisällyttää >-merkki itse dataan

Sääntöjen syynä on se, että kyseisiä merkkejä käytetään itse HTML-kielen rakenteiden erottamiseen tekstistä. Niinpä tarvitaan jokin keino (ns. escape-mekanismi), jolla niitä tarvittaessa voidaan sisällyttää itse tekstiin.

"Ääkköset" ja muut ISO Latin 1 -merkit

Edellä esitetty Ascii-merkistö ei tietenkään riitä esimerkiksi suomen kielen kirjoittamiseen, vaan tarvitaan lisäksi ä- ja ö-kirjaimet. Nekään eivät käytännössä yleensä tuota ongelmia Suomen oloissa nykyisin; yleensä ne löytyvät suoraan näppäimistöltä tai ovat ainakin kirjoitettavissa jollain näppäintemppuilulla.

Tarvittaessa kuitenkin ä, ö, Ä ja Ö voidaan esittää merkinnöillä &auml;, &ouml;, &Auml; ja &Ouml;. Silloin tosin HTML-dokumenttia on ikävä lukea sitä editoitaessa. Kyseisten merkintöjen käyttö ei tarjoa mitään etua paitsi erikoisissa poikkeustilanteissa, esim. kun dokumentin koodauksena on UTF-8.

Yleisemmin HTML:ssä voidaan suhteellisen turvallisesti käyttää koko ISO Latin 1 -merkistöä. Tämä merkistö on länsi- ja pohjoiseurooppalaisia kieliä varten kehitetty. Tarkemmin siitä kertoo kirjoitukseni ISO-Latin-1-merkistöstä. Seuraavassa on kaikkien ISO Latin 1 -merkkien taulukko, jossa kukin merkki toimii linkkinä merkin yksityiskohtaiseen (englanninkieliseen) kuvaukseen dokumentissa The ISO Latin 1 character repertoire - a description with usage notes:

  ! " # $ % & ' ( ) * + , - . /
0 1 2 3 4 5 6 7 8 9 : ; < = > ?
@ A B C D E F G H I J K L M N O
P Q R S T U V W X Y Z [ \ ] ^ _
` a b c d e f g h i j k l m n o
p q r s t u v w x y z { | } ~
  ¡ ¢ £ ¤ ¥ ¦ § ¨ © ª « ¬ ­ ® ¯
° ± ² ³ ´ µ · ¸ ¹ º » ¼ ½ ¾ ¿
À Á Â Ã Ä Å Æ Ç È É Ê Ë Ì Í Î Ï
Ð Ñ Ò Ó Ô Õ Ö × Ø Ù Ú Û Ü Ý Þ ß
à á â ã ä å æ ç è é ê ë ì í î ï
ð ñ ò ó ô õ ö ÷ ø ù ú û ü ý þ ÿ

Jos käytät esim. Mac-tietokonetta, niin käytössä oleva merkkikoodi on eri kuin ISO Latin 1. Tästä ei kuitenkaan yleensä aiheudu ongelmia, jos dokumentin siirto Macistä Web-palvelimeen tehdään oikein, esim. FTP:llä tekstimoodissa, jolloin tapahtuu automaattinen merkkikoodimuunnos.

Toisaalta suurelle osalle Maciä käyttävistä lukijoista aiheuttaa ongelmia se, että monet Macissä toimivat selaimet eivät vieläkään osaa näyttää kaikkia ISO Latin 1 -merkkejä. Ongelmalliset merkit ovat: ¦²³¹¼½¾Ð×ÝÞðýþ joista yläindeksit ja kertomerkki lienevät tavallisimmin käytettävät.

ISO Latin 1 -merkkien kirjoittamiseen joudutaan yleensä käyttämään erityisiä ohjelmakohtaisia menetelmiä, koska missään näppäimistössä tuskin on niitä kaikkia. Tyypillisen PC-näppäimistön osalta ks. ohjetta Erikoismerkkien kirjoittaminen suomalaisella PC-näppäimistöllä. Yleisesti aiheesta kertoo A tutorial on character code issues, kohta Typing characters, mutta tässä kerrottakoon yksi hyvin yleisesti käytetty menetelmä: Windows-järjestelmissä lähes kaikissa ohjelmissa (ei kuitenkaan Emacsissa) voi käyttää ns. Alt-0nnn-menetelmää: Paina Alt-näppäin (välilyöntinäppäimen vasemmalla puolella) alas ja, pitäen sitä alhaalla, kirjoita erilliseltä numeronäppäimistöltä (oikealla) merkki 0 (nolla) ja halutun merkin kolminumeroinen desimaalinen koodi nnn. Koodit voit katsoa esim. dokumentista Taulukko ISO-Latin-1:n merkeistä ja niiden nimistä. Vastaavat tiedot ovat monella muullakin Web-sivulla, mutta ole tarkkana: muista käyttää desimaalisia koodeja ja olla käyttämättä koodiarvoja 127 - 159, sillä ne eivät kuulu ISO Latin 1:een. Esimerkiksi espanjan kielessä käytetty ñ-merkki (n-kirjain, jonka päällä on tilde, "aaltoviiva") voidaan Windowsissa kirjoittaa näppäilemällä Alt-0241. Yksi vaihtoehto on kirjoittaa &#241;, mutta silloin sinun on itsesi vaikea lukea, mitä kirjoitat, vaikka se kyllä selaimissa toimii. Lähes yhtä vaikea on lukea "symbolisia" merkintöjä kuten &ntilde;, vaikka ne ovatkin vielä yksi (ja aina käytettävissä oleva, ohjelmasta riippumaton) vaihtoehto.

Seuraavassa tarkasteltavat aksenttinäppäin ja diereesinäppäin ovat suomalaisen PC-näppäimistön perusosan oikeassa reunassa, +-näppäimestä oikealle ja å-näppäimestä oikealle.Tyypillisellä Suomessa käytettävällä PC-näppäimistöllä onnistuu aksentillisten kirjainten kuten é kirjoittaminen usein myös näppärällä ja helposti muistettavalla tavalla: käyttäen apuna näppäimistön paria erikoisnäppäintä, joita voi sanoa aksenttinäppäimeksi ja diereesinäppäimeksi. Jos näpäytät ensin aksenttinäppäintä, johon on merkitty akuutti aksentti ´ ja sen yläpuolelle graavi aksentti `, ja sitten vaikkapa e-näppäintä, saat aikaan akuutilla aksentilla varustetun kirjaimen é. Tekemällä samoin mutta shift-näppäin alhaalla silloin, kun näpäytät aksenttinäppäintä, saat aikaan graavilla aksentilla varustetun kirjaimen è. Vastaavasti saat diereesinäppäimellä, jossa on ¨ ja ^, aikaiseksi diereesillä (kahdella pistellä, umlautilla) tai sirkumfleksilla varustettuja merkkejä kuten ü ja û sekä vielä Alt Gr -näppäintä apuna käyttäen tildellä varustettuja merkkejä kuten ñ. Isojen kirjainten aikaansaamiseksi käytetään shift-näppäintä siinä vaiheessa, kun näpäytetään kirjainnäppäintä. Mainittakoon vielä, että µ-kirjain saadaan Alt Gr:n avulla m-näppäimestä. Edellä sanottu koskee siis tyypillistä suomalaista PC-näppäimistöä eikä ole yleispätevä ohje.

Muita suomen kielen kirjoittamisen ongelmia

ISO Latin 1 ei sisällä hattu-s:ää eikä hattu-z:aa, jotka kuuluvat suomen viralliseen kirjoitusjärjestelmään. yleensä on parasta HTML-dokumenteissa toistaiseksi käyttää niiden asemesta merkkipareja sh ja zh. Jos kuitenkin pidät tärkeämpänä sitä, että useat näkevät sivusi niin, että sillä on oikea hattu-s ja hattu-z, kuin sitä, että kaikki voivat lukea sivusi, käytä seuraavia merkintöjä: &#353; (pieni hattu-s), &#352; (iso hattu-s), &#382; (pieni hattu-z) ja &#381; (iso hattu-z). Euron merkkiä ei myöskään kannata käyttää; on paljon turvallisempaa käyttää sanaa "euro" sopivassa taivutusmuodossa kuin sinänsä oikeaa esitysmuotoa &#8364;. Huomaa myös, että ajatusviiva ei kuulu ISO Latin 1:een eikä ole turvallisesti esitettävissä, vaikka se kuuluukin ns. Windows-merkistöön. (Tai oikeammin sanoen siihen kuuluu kaksi erimittaista viivaa, "em dash" ja "en dash".) Sama koskee ns. "oikeita" lainaus- ja heittomerkkejä. On parasta tyytyä toistaiseksi käyttämään yhdysmerkkiä ajatusviivan asemesta sekä "pystysuoraa" (Ascii-merkistön) lainausmerkkiä (") ja heittomerkkiä ('). Ks. kirjoitustani Mikrojen merkistöjen aiheuttamista ongelmista Webissä.

Laajempiin merkkiavaruuksiin

Valitettavasti muiden kuin ISO Latin 1 -merkkien käyttö Webissä aiheuttaa huomattavia ongelmia. Niiden vaikeusaste vaihtelee, ja aloitamme helpoimmista. Ensin kuitenkin yleisiä huomautuksia.

Miten merkeille voi käydä
Hieno esitys Kun menee pieleen
Lech Walesa, alpha Centauri ja nabla F hienosti esitettyinä Lech WaB sa, ± Centauri ja F

Harkitse, selviäisitkö kuitenkin ISO Latin 1:llä. Yhdenkin sen ulkopuolisen merkin ottaminen mukaan aiheuttaa ongelmia. Olisi kyllä hienoa ja korrektia, jos voisi kirjoittaa esimerkiksi Lech Walesan nimen tarkasti oikein, puhua alfa Centaurista kreikkalaista kirjainta käyttäen ja viitata Laplacen operaattoriin nablamerkillä. Mutta maksaako se vaivan, jos merkittävä osa lukijoista - ehkä jopa enemmistö - näkee hienot merkkisi outoina vänkyröinä, kysymysmerkkeinä, laatikoina tai oikeannäköisinä mutta väärinä merkkeinä? Seuraavassa on edellä mainittuja merkkejä sisältäviä ilmaisuja, jotta voit nähdä, miten sinun selaimesi niistä selviää (ja ohessa on kuvat kahdesta muusta esitysmuodosta): Lech Wałęsa, α Centauri, ∇F.

On tärkeää, miten laajaa merkkivalikoimaa tarvitset. Toinen tärkeä kysymys on, miten olennaiseen käyttöön niitä tarvitset. Jos esimerkiksi jutussasi puhutaan Lech Walesasta, ei ole viestinnän onnistumiselle välttämätöntä, että saat l- ja e-kirjaimeen oikeat lisukkeet. Mutta jos koko juttusi on puolankielinen, tilanne on aivan toinen: tarvitset merkkivalikoiman, jolla puolaa voi kirjoittaa normaalisti. Vastaavasti jos juttusi käyttää yksikköä ohmi, on tuskin välttämätöntä, että voi käyttää oikeaa ohmin tunnusta eli isoa oomegaa (Ω). Jos taas tekstisi vilisee kreikankielisiä sitaatteja taikka matemaattisia erikoissymboleita, joudut yleensä hyväksymään sen, että kaikki eivät voi lukea sitä kunnolla.

Käytännössä keskeistä on, selviätkö jollakin ns. kahdeksanbittisellä merkistöllä. Sellaisessa merkistössä on periaatteessa 256 merkkipaikkaa, joista käytännössä yleensä puolet on kaikissa merkistöissä samoja, nimittäin Ascii-merkit. Loppuosastakin useat positiot on varattu kontrollikoodeille, joten käytännössä vaihtoehtoja on vain noin 100 merkin osalta. Esimerkiksi

Joka tapauksessa joudut huolehtimaan merkkien koodausta koskevan informaation lähettämisestä selaimelle. Esimerkiksi ISO 8859-2 -koodatussa tekstissä mikään itse tekstissä ei kerro koodausta, siis siitä, miten mikin data-alkio pitää tulkita. Periaatteessa sama ongelma on ISO Latin 1:n kanssa, mutta käytännössä ISO Latin 1 on varsin pitkälle oletusarvo selaimissa.

Kyseinen informaatio tulisi Web-palvelimen lähettää selaimelle. Tapa, jolla asia hoidetaan, on palvelinkohtainen. Ks. yleisiä ohjeita asiasta pienoisoppaassa Laajennetun merkistön käyttö HTML:ssä.

"Keskieurooppalaiset", kyrilliset, kreikkalaiset ym. merkit

"Keskieurooppalainen" merkistö ISO 8859-2

Aloitamme ehkä helpoimmasta tapauksesta: edellä mainitusta ISO 8859-2:sta. Miten voisimme kirjoittaa esimerkiksi puolankielisen HTML-dokumentin? Unohdetaan tässä kielivaikeudet ja keskitytään merkistöongelmiin. Puolan merkistössä tarvitaan meille tuttujen kirjainten ohella eräitä merkkejä, joissa tavalliseen kirjaimeen on liitetty lisuke kuten poikkiviiva.

Käsittelemme ensin erästä tapaa, joka on ehkä enemmänkin eräitä periaatteita valaiseva kuin käytännöllinen. Voisimme menetellä niin, että kirjoitamme dokumentin muutoin aivan tavalliseen tapaan mutta käyttäen vain Ascii-merkkejä sekä ä:tä ja ö:tä, ja puolassa tarvittavat kirjaimet otamme ISO 8859-2:sta siten, että katsomme vertailutaulukosta, mitkä ovat koodinumeroiltaan vastaavat merkit ISO Latin 1:ssä. Esimerkiksi l-kirjainta, jossa on poikkiviiva, vastaa tässä mielessä yläindeksi ³ ja e-kirjainta, jossa on koukku alhaalla, vastaa e, jossa on sirkumfleksi (ê). Nyt sitten vain kirjoitamme nuo merkit jollakin edellä kuvatuista tavoista; näin kirjoitettuna esimerkiksi Walesa-nimestä tulee Wa³êsa. Tämähän ei hyvältä näytä, mutta jos palvelin pannaankin ilmoittamaan koodaukseksi ISO 8859-2 ja selain tämän ymmärtää ja sillä vielä on sopiva fontti käytössään, niin hommahan pelaa (ei aina, koska selaimissa on vielä puutteita, mutta jo useimmiten).

Tämä voi kuulostaa huijaukselta ja sekoilulta, mutta merkkikoodiasioiden perusteiden pohjalta sen ehkä voi ymmärtää ja samalla se kenties havainnollistaa koodiasioita: se, miltä tiedosto näyttää esimerkiksi editorissa, riippuu täysin siitä, minkälaisen koodauksen mukaisesti ohjelma tulkitsee tiedoston sisällön merkeiksi. Ja joka tapauksessa ISO 8859-2 sopii hyvin moniin tarkoituksiin. Luonnollisestikin on parempi, jos voi käyttää sellaista editoria, joka suoraan näyttää merkit oikein.

Hankala kysymys on, pitäisikö dokumenttiin kirjoittaa myös meta-elementti, joka ilmoittaa koodauksen, esim.
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-2">
Periaatteellisesti se on epälooginen, münchhausenmainen ratkaisu - dokumentti yrittää kertoa oman koodauksensa, ja tämän se tietysti tekee tekstillä, mutta miten tekstiä voi lainkaan tulkita tietämättä koodausta? Käytännössä se voi aiheuttaa ongelmia. Mutta tässä yhteydessä olen noita meta-elementtejä käyttänyt. Syynä on lähinnä se, että muutoin paikalliset kopiot dokumenteista eivät toimi oikein. Jos lukija on imuroinut aineiston omaan koneeseensa ja lueskelee sitä siellä, niin tietenkään mikään palvelin ei ole lähettämässä informaatiota koodauksesta!

ISO 8859-2:ta käsittelee laaja sivusto, joka nimestään Latin 2 Fonts huolimatta käsittelee monia muitakin asioita kuin fontteja (kirjasintyyppejä), mm. näppäimistö- ja ohjelmistoasioita.

Huomaa, että edellä ei ole puhuttu mitään fonteista. Eikä ole syytäkään. Toki on hyvä, jos sivun tekijällä on käytössään fontti, jonka ansiosta hän näkee merkit oikein. Mutta kuten esimerkki osoitti, se ei periaatteessa ole välttämätöntä. Lukija tarvitsee koneeseensa jonkin fontin, jossa on tarvittavat merkit. Mutta itse HTML-dokumentissa ei tarvitse eikä yleensä ole syytäkään sanoa mitään fonteista.

Kyrilliset, kreikkalaiset yms. merkit

Yleisempi ratkaisu on käyttää jotakin sopivaa ohjelmistoa, joka helpottaa kirjoittamista ja jolla voidaan kirjoittaa useita eri kieliä. Ks. Alan Woodin koostetta Unicode and Multilingual Editors and Word Processors. Tässä mainitaan vain eräs vaihtoehto Windows-koneisiin: UniPad, joka on laajaa merkkivalikoimaa tukeva tekstieditori. Apuohjelmana voi käyttää Free recodea, joka on yleisohjelma merkkikoodien välisiin muunnoksiin.

Täten voisi esimerkiksi kirjoittaa UniPadillä dokumentin, jossa on suomea ja venäjää, tallentaa sen UTF-8-muodossa kyseisestä ohjelmasta ja muuntaa Free recodella esimerkiksi koi8-r-muodoon, joka lienee venäjänkielisten sivujen tavallisin koodaus. Muunnos tapahtuisi (komentoikkunassa) seuraavaan tapaan:
cp test.utf test.koi
recode utf-8..koi8-r test.koi
Palvelimeen voidaan sitten siirtää haluttaessa molemmat versiot (test.utf ja test.koi) ja tarvittaessa nimetä ne sopivalla tavalla. Palvelinkohtaisilla järjestelyillä on sitten hoidettava, että palvelin lähettää oikean informaation koodauksesta. Seuraavat linkit viittaavat demosivuun kahtena eri versiona: UTF-8-testisivu ja KOI8-R-testisivu. Nämä sitten saattavat toimia selaimessasi tai olla toimimatta.

Tässä tapauksessa dokumentteihin on vielä "käsin" lisätty meta-tägit, jotka ilmoittavat koodauksen. Kuten edellä mainittiin, sellainen ei yleensä ole aiheellista. Tämä esimerkki havainnollistaa osaltaan, miksi näin on. Jos dokumentin koodausta muutetaan, niin myös sellaiset meta-tägit pitäisi muuttaa, mutta tätä taas merkkikoodinmuunnosohjelmat eivät suinkaan tee - niiden tehtävähän on operoida koodauksen tasolla, oli data millaista tahansa, eivätkä ne esim. tunnista HTML-merkkausta.

UniPadistä voidaan myös suoraan tallentaa esim. koi8-r-koodattuna, kunhan käytetään sen Export-valikkoa. Edellä oleva menettely oli siis turhan mutkikas yksinkertaisiin tilanteisiin mutta toisaalta havainnollistaa sitä, että ei ole kovinkaan vaikeaa tehdä sivusta versioita, joissa on eri koodaus. Sellainen vaihtoehtoisuus voi olla eduksi, koska osalle lukijoista sopii teknisten syiden takia yksi koodaus, osalle toinen.

Kreikan kirjoittamiseen voidaan käyttää nykykreikan osalta koodausta ISO 8859-7 tai windows-1253, joiden ero on suhteellisen pieni. Ns. polytoninen kreikka, jossa on useita erilaisia painomerkkejä, vaatiikin sitten jo käytännössä Unicoden käyttöä (ja lisäksi lukijoiden todennäköisesti pitää jostain löytää sopiva fontti).

Matemaattiset merkit - ja lausekkeet

Matemaattisten merkkien käyttö, matemaattisista lausekkeista puhumattakaan, on varsin ongelmallista HTML:ssä. Edellä kuvattu ISO Latin 1 sisältää vain muutaman matemaattisen merkin. Merkkivalikoiman laajentaminen on mahdollista seuraavassa kohdassa kuvattavalla tavalla, joskin silloin lisääntyy niiden lukijoiden määrä, jotka eivät näe sivua oikein. Vielä ongelmallisempaa on, että varsinaisia kaavoja ja lausekkeita varten HTML:ssä ei ole merkkausta.

Niinpä yleensä käytetään sellaista menettelyä, että kaavat tuotetaan kuvamuotoon esim. TeX-ohjelmistolla ja upotetaan HTML-dokumenttiin img-elementillä. Menettelyä käytetään mm. CSC:n opasaineistossa sekä laajassa MathWorld-tietosanakirjassa.

Jossain määrin, melko yksinkertaisissa tapauksissa, on kuitenkin mahdollista käyttää HTML:ää matemaattisten kaavojen esittämiseen. Ks. Math in HTML (and CSS). Tässä vain pikku esimerkki (joka ei välttämättä toimi selaimellasi):

√(a²+b²)

"Täydellinen" merkkivalikoima (UCS)

Periaatteessa HTML:ssä voi käyttää koko Unicode-merkistöä, tai vieläkin periaatteellisemmin sanoen vieläkin laajempaa merkistöä (Universal Character Set, UCS). Vaihtoehtoja on olennaisesti kaksi:

Näitäkin asioita on selostettu hiukan tarkemmin edellä mainitussa ohjeessa Laajennetun merkistön käyttö HTML:ssä. Suomeksi merkistöasioiden keskeisiä kysymyksiä käsittelee myös Markku Immosen esitys merkistöistä Webissä.

Vaativampia taulukoita

Luvussa Tietoa taulukoihin kuvattiin HTML-taulukoiden käytön perusteet. Tässä luvussa käsitellään eräitä vaativampia erityisaiheita kuten taulukoiden ohjelmallista tuottamista sekä ulkoasun "virittelyä".

Sisällys

Taulukot ja luettelot

Usein asian voi esittää luettelona (luetelmana) tai taulukkona. Esimerkiksi kirjallisuusluettelon voisi esittää ul- tai ol-elementtinä, jossa kukin alkio sisältää tiedot yhdestä kirjasta (tai artikkelista tms.) tai sitten taulukkona. Jälkimmäisessä tapauksessa kukin taulukon rivi (tr-elementti) sisältäisi tiedot yhdestä kirjasta, ja sarakejako voisi olla esimerkiksi sellainen, että 1. sarake sisältää viittauksen numeron tai muun koodin, 2. sarake kirjoittajan nimen, 3. sarake teoksen nimen jne. Tällainen rakenne olisi huomattavan selkeä mutta jonkin verran työläs kirjoittaa, ja ennen kaikkea se poikkeaisi perinteestä; lisäksi ulkoasun saaminen hyväksi olisi vaativaa.

Periaatteellisesti voidaan sanoa, että jos luettelon kaikilla kohdilla on sama sisäinen rakenne, se olisi loogisempaa kirjoittaa taulukoksi. Edellä oleva esimerkki osoittaa, ettei se aina ole käytännössä tarkoituksenmukaista. Mutta otetaanpa tyypillinen esimerkki kuvitteellisesta budjettiehdotuksesta, jossa on seuraavanlainen lista

Hilavitkutinjärjestelmien kehittämiseen

Tämä olisi esitysmuodoltaan ehkä napakampi ja muutenkin parempi taulukkona, josta eri kohtien yhtenäinen rakenne (ja poikkeukset siitä!) tulevat paremmin esille:

Hilavitkutinjärjestelmien kehittämiseen
laitteeet 3 000 000 euroa tammikuussa
ohjelmistot 300 000 euroa joulukuussa
käyttökoulutus 3 000 euroa heinäkuussa
käsikirjat 1 000 euroa  

Esimerkkitaulukossa on lukuja sisältävän sarakkeen tasaus oikealle hoidettu hiukan näppärämmin kuin aiemmassa esimerkissä, nimittäin kirjoittamalla table-tägin perään seuraavat elementit:

<col>
<col class="numeric">
<col>

ja liittämällä tyylisäännöstöön sääntö 

.numeric
  { font-family : Courier, monospace;
    text-align : right; }

Sääntö kehottaa selainta esittämään jokaisen sellaisen elementin, jossa on määrite class="numeric", Courier-fontilla tai jollakin muulla tasalevyisellä fontilla ja oikeaan reunaan tasattuna (siinä tilassa, jonka selain on varannut elementille, esim. taulukon alkiolle). Tällöin ei itse td-elementteihin tarvitse lisätä mitään ulkoasuun liittyviä asioita, vaan ne ovat yksinkertaisesti muotoa <td>sisältö</td>. Tämän tyylikkyyden hinta on sitten se, että toistaiseksi menetelmä toimii vain IE:ssä versiosta 4 alkaen. Esim. Netscapessa esitysasu on huonompi (mutta luettavissa).

Toisena teknisenä yksityiskohtana mainittakoon, että erinäisistä syistä tyhjä alkio on yleensä parasta esittää muodossa <td>&nbsp;</td>. Toisaalta tyhjiä alkioita kannattaa välttää. Yleensä löytyy jokin parempi tapa esittää taulukossa tiedon puuttuminen. Esimerkkitapaukseemme sopisi kysymysmerkki (?).

Taulukoiden tuottaminen

Vaikka HTML:n taulukkorakenne on melko yksinkertainen, on isohkon taulukon HTML-merkkauksen kirjoittaminen "käsin" melko työlästä. Niin varsinkin valmiiksi jossain taulukkomuodossa olevan aineiston muuntaminen HTML-muotoon kannattaa yleensä tehdä jollakin työkalulla, vaikkapa editorin makroilla tai pienellä Perl-ohjelmalla.

Esimerkiksi yksinkertainen Excel-taulukko voidaan muuntaa HTML-muotoon seuraavasti (olettaen, että meillä on taulukko aluksi erillisenä Excel-tiedostona):

  1. Avaa taulukon sisältävä tiedosto Excelissä.
  2. Tallenna se Excelin toiminnon "Save As..." kautta siten, että valitset tallennusmuodoksi (Save as type) "Text (tab delimited)(*.txt)". Tämä tarkoittaa muotoa, jossa taulukon sisältö on tekstitiedostona, kukin taulukon rivi yhtenä tekstirivinä, taulukon alkioiden välissä erottimina tabulointimerkit (tab).
  3. Käsittele tuloksena saatava tekstitiedosto ohjelmalla, joka vaihtaa rivinvaihtojen ja tabulointimerkkien tilalle sopivan HTML-taulukkomerkkauksen ja lisää alkuun ja loppuun HTML-taulukon aloituksen ja lopetuksen. Tämä voidaan tehdä vaikkapa seuraavalla Perl-ohjelmalla: 
    print "<table border=\"1\">";
while (<>) {
    s@^@<tr><td>@;
    s@$@<br></td></tr>@;
    s@\t@ </td><td>@g;
    print; }
print "</table>";
  4. Tarkista, miltä HTML-taulukko näyttää selaimella katsottuna, ja lisää tarvittaessa HTML-määritteitä tai tyylisääntöjä ulkoasun parantamiseksi.

Edellä esitettyä Perl-ohjelmaa tai sen muunnelmia jäljempänä ei ole välttämätöntä ymmärtää. Voit yksinkertaisesti ladata ohjelman omaan koneeseesi ja ajaa sen sentapaisella komennolla kuin
perl mktab.pl <nimi.txt >nimi.html
(Olettaen toki, että koneessa on Perl-tulkki. Sellaisen saa perl.comin jakelusivuilta.) Mutta jonkinasteinen Perlin hallinta tietenkin tarvitaan, jos halutaan muokata tällaisia ohjelmia omiin tarpeisiin sopiviksi.

42 52 62
142 152 162

Esimerkkinä muunnamme erään triviaalin Excel-taulukon HTML-muotoon. Kun aluksi saatava tekstimuotoinen ("tab delimited") versio on käsitelty edellä mainitulla Perl-ohjelmalla, on saatu alustava HTML-muoto. Koska taulukon alkiot ovat kokonaislukuja, esitysmuoto on parempi, jos ne näkyvät solun oikeaan reunaan tasattuina. Tämä voitaisiin tehdä joko align-määritteillä tai tyylisäännöstöillä (tässä tapauksessa pelkkä td {text-align:right;} riittäisi) kuten aiemmin on selostettu. Jos haluttaisiin käyttää varmemmin toimivaa mutta kömpelömpää align-määritettä, niin helpointa olisi muokata Perl-ohjelmaa niin, että se suoraan kirjoittaa halutut määritteet. Lisäksi on ehkä luettavuudelle hyväksi lisätä taulukolle sellaiset määritteet, joilla poistetaan solujen välinen tyhjä tila mutta lisätään tyhjää tilaa solun sisällön ja reunan väliin. Eräs mahdollisuus toteuttaa tämä on käyttää HTML-taulukkomuodon tuottamiseen edellä olevan Perl-ohjelman asemesta seuraavaa muokattua ohjelmaa (jolla saatu tulos näkyy ohessa):

print "<table border=\"1\" cellspacing=\"0\" cellpadding=\"4\">";
while (<>) {
    s@^@<tr><td align=\"right\">@;
    s@$@<br></td></tr>@;
    s@\t@ </td><td align=\"right\">@g;
    print; }
print "</table>";

Kauniin numeerisen taulukon tekeminen

Pieni ongelmataulukko
1 888 55542,5
1 111 111424,589
420,51

Edellä mainittu ohjelma tuotti numeerisen taulukon, jossa data on solun sisällä oikeaan reunaan tasattuna. Tämä riittää yksinkertaisissa tapauksissa tuottamaan ihan kohtuullisen ulkoasun. Mutta varsinkin tieteessä ja tekniikassa esiintyy taulukoita, joissa on suuria moninumeroisia lukuja ja lisäksi desimaalipilkun tai -pisteen sisältäviä lukuja. Tällöin syntyy kaksi ongelmaa, vaikka luvut olisikin tasattu solujensa oikeaan reunaan:

Numeroiden leveydet saa varmimmin samoiksi käyttämällä tt-merkkausta, esim. <tt>42,5</tt>. Tosin siitä syntyy sitten se ongelma, että myös piste tai pilkku vie vaakasuunnassa saman tilan kuin muutkin merkit, jolloin esim. 42,5 näyttää vähän hassulta. Tähän taas auttaisi se, että piste tai pilkku jätetään kyseisen merkkauksen ulkopuolelle: <tt>42</tt>,<tt>5</tt>, jolloin 42,5 näyttää jo paremmalta. Tämä on tietenkin sen verran työlästä, että jokin apuväline (sentapainen kuin edellisessä kohdassa käsitelty) olisi kovasti tarpeen. Voi olla, että numeroiden leveyksiä ei kannata pitää ongelmana.

Tasaaminen desimaalipilkun tai -pisteen kohdalta onkin käytännössä tärkeämpi ongelma, ja hiukan hankalampi. Teoriassa voisimme käyttää HTML 4.0:n mukaista määritettä align="char" yhdessä char-määritteen kanssa, mutta toistaiseksi mikään selaan ei tiettävästi tue niitä.

Yksinkertaisin menetelmä on kirjoittaa kaikkiin saman sarakkeen lukuihin sama määrä numeroita desimaalipilkun tai -pisteen oikealle puolelle, siis esim. korvaten edellä olevassa taulukossa luvut 42,5 ja 0,51 luvuilla 42,500 ja 0,510. Mutta tätä ei ehkä haluta tehdä, koska numeroiden määrällä usein karkeasti myös ilmaistaan mittauksen tai arvion tarkkuus merkitsevinä numeroina. Tällöin voidaan täytemerkkinä käyttää 0:n asemesta no-break space -merkkiä. Numeerisen taulukon muokkaaminen tämän mukaiseksi on tylsää tehdä käsin, joten työkalua kaivataan.

Yksinkertaisuuden vuoksi oletamme, että meillä on taulukko ns. tab separated -muodossa kuten edellä, ja muokkaamme Perl-ohjelman seuraavanlaiseksi: 

while (<>) {
    chomp;
    @tmp = split(/\t/);
    $sarakenro = 0;
    for $sarake (@tmp) {
	if($sarake =~ /[,.](\d+)/ &&
           length($1) > $des[$sarakenro]) {
           $des[$sarakenro] = length($1); } 
        $sarakenro++; }
    push @data, [ @tmp ]; }
print "<table border=\"1\" cellspacing=\"0\"",
      " cellpadding=\"4\">\n";
for $rivi ( @data ) {
    print "<tr>";
    $sarakenro = 0;
    for $alkio (@$rivi) {
	if($alkio =~ /[,.](\d+)/) {
           for($i=length($1);$i<=$des[$sarakenro];$i++) {
	       $alkio = $alkio . "&nbsp;"; }}
	$alkio =~ s? ?</tt>&nbsp;<tt>?g;
	$alkio =~ s?\.?</tt>.<tt>?;
	$alkio =~ s?,?</tt>,<tt>?;
        $sarakenro++;
	print "<td align=\"right\"><tt>$alkio</tt></td>"; }
    print "</tr>\n"; }
print "</table>\n";
1 888 55542,5   
1 111 111424,589 
420,51  

Ohjelma laskee, mikä on kussakin sarakkeessa desimaalien (siis desimaalipilkusta tai -pisteestä oikealle olevien numeroiden) enimmäismäärä, ja tulostaessaan lisää no-break space -merkkejä lukujen perään tasausmerkeiksi. Lisäksi se huolehtii siitä, että desimaalipilkku ja -piste sekä datassa alun perin olleet välilyönnit ovat tt-elementtien ulkopuolella eli normaalilla fontilla. Saatava tulos (ohessa) on HTML-merkkaukseltaan aika sotkuinen mutta ulkoasu on kohtuullisen hyvä. Yksi kehittämismahdollisuus olisi se, että desimaalipilkun tai -pisteen jälkeiset numerot olisivat pienikokoisempia, minkä saisi aikaan small-merkkauksella. Tämä vaatisi vain pienehköjä muutoksia; tosin tulos ehkä ei sikäli olisi hyvä, että lukijoiden mielestä pienennetty tasalevyinen fontti voisi olla liian pieni.


Muuan temppu: selainikkunan leveyteen mukautuva "näennäistaulukko"

HTML:ssä on periaatteessa menu-elementti, joka oli tarkoitettu sellaisten listojen esittämiseen, jossa on suuri määrä suhteellisen pieniä alkioita, esim. sanoja (jotka tyypillisesti ovat linkkejä jonnekin). Koska selaimet eivät käytännössä missään vaiheessa ruvenneet tukemaan sitä, joudumme miettimään muita keinoja kuten taulukoiden käyttöä "valikoiden" esittämiseen.

On myös mahdollista tehdä "näennäistaulukko", joka koostuu sanoista, jotka näyttävät muodostavan taulukon seuraavaan tapaan:

A           ABBR        ACRONYM     ADDRESS     APPLET      AREA        B           BASE        BASEFONT    BDO         BIG         BLOCKQUOTE  BODY        BR          BUTTON      CAPTION     CENTER      CITE        CODE        COL         COLGROUP    DD          DEL         DFN         DIR         DIV         DL          DT          EM          FIELDSET    FONT        FORM        FRAME       FRAMESET    H1          H2          H3          H4          H5          H6          HEAD        HR          HTML        I           IFRAME      IMG         INPUT       INS         ISINDEX     KBD         LABEL       LEGEND      LI          LINK        MAP         MENU        META        NOFRAMES    NOSCRIPT    OBJECT      OL          OPTGROUP    OPTION      P           PARAM       PRE         Q           S           SAMP        SCRIPT      SELECT      SMALL       SPAN        STRIKE      STRONG      STYLE       SUB         SUP         TABLE       TBODY       TD          TEXTAREA    TFOOT       TH          THEAD       TITLE       TR          TT          U           UL          VAR        

Edellä oleva rakenne mukautuu selaimen leveyteen: kun leveyttä muutetaan, "taulukon" jakautuminen riveihin muuttuu vastaavasti. Jippona on se, että kyseessä onkin kappale (p-elementti), jonka sisällä sanat ovat toisistaan välilyönneillä erotettuina. Taulukkomainen ulkoasu johtuu siitä, että sanat on tasattu samanpituisiksi käyttämällä lopussa täytemerkkinä no-break space -merkkiä (&nbsp;) ja sisällyttämällä ne tt-elementtiin, joka käytännössä aiheuttaa tasalevyisen fontin käytön (kaikki kirjaimet samanlevyisiä). Vaikka periaatteessa ei ole mitään takeita siitä, että selaimet kohtelevat no-break space -merkkiä tavalla, jota tässä ajetaan takaa, temppu toimii useimmissa selaimissa eikä tiettävästi aiheuta ongelmia silloin, kun ei toimi (ulkoasu ei vain ole niin siisti kuin halutaan). Antti Näyhä on huomauttanut, että siirtämällä no-break space -merkit a href -elementin ulkopuolelle saadaan aikaan tyylikkäämpi muunnelma aiheesta.

Edellä olevan "taulukon" kohdat ovat muuten linkkejä virallisen HTML 4.0 -spesifikaation kohtiin, joissa eri elementit on määritelty.

Lisätietoja ja -esimerkkejä taulukoista

Näitäkin voit tarvita

Sisällys

Lainaus (sitaatti) erillisenä lohkona: blockquote

Edellä kohdassa Tekstiä monenlaista mainittiin, että tekstin sisällä esiintyvät lainaukset kannattaa esittää ihan vaan lainausmerkeillä, esim. "Veni vidi vici", tai ehkä kursiivilla, i-elementtiä käyttäen. Jälkimmäinen sopii etenkin tilanteisiin, joissa puhutaan kielen sanoista ja fraaseista, esim. sanan kissa taivutusmuodosta kissoista. Eräänlaisena lainauksena voidaan pitää myös kirjan tai muun teoksen nimeä kuten Nuorena nukkunut, jolle sopiva merkkaus on cite-elementti.

Laajahko lainaus eli sitaatti esitetään omana "lohkonaan" blockquote-elementillä. Tällöin lainausmerkkejä ei käytetä. Ainakin jos lainaus on kappaleen mittainen tai pitempi, on syytä esittää se tällä tavoin. Tyypillinen esitysmuoto on kyllä melko tylsä (yleensä sisennys vasemmalla, mahdollisesti myös oikealla, joskus teksti kursivoituna), mutta tyylisäännöstöillä voi ehdottaa jotain parempaa.

Toisaalta vaikka blockquote-elementtiä onkin syytä käyttää pitkille lainauksille, ei pidä luottaa siihen, että se yksinään kertoo tarpeeksi selvästi, että kyseessä on lainaus. Tyypillinen esitysmuoto, sisennys, ei mitenkään yksiselitteisesti kerro sitä. Lisäksi se ei toimi ääniesityksessä. Niinpä onkin hyvä ennen lainausta kertoa sanallisesti jotenkin, että tulossa on sitaatti. Lainauksen loppumisen taas yleensä kertoo tarpeeksi selvästi lähdeviittaus sen perässä.

Eräs ongelma tällaisissa lainauksissa onkin, miten esitetään lainatun tekstin kirjoittaja ja lähde, jotka on yleensä jo lain vaatimuksestakin mainittava. Valitettavasti siihen ei ole mitään erityistä rakenteista tapaa. Yksi vaihtoehto on sisällyttää maininta lähteestä siihen tekstikappaleeseen, joka edeltää sitaattia ja johdattaa siihen. Mutta etenkin jos sitaatteja on paljon, jokin tyylikkäämpi ja yhtenäisempi tapa olisi suotava. Seuraavassa on muuan yksinkertainen vaihtoehto: 

<blockquote>
<div>Alussa olivat suo, kuokka - ja Jussi.</div>
<div class="credit">Väinö Linna: <cite>Täällä Pohjantähden alla</cite>, s. 1</div>
</blockquote>

Tässä on käytetty div-elementtiä, joka yleisesti vain tekee dokumentin osasta (division) erillisen lohkon. Jälkimmäiseen div-elementtiin liittyy class-määrite, jonka avulla voimme liittää siihen esitysasua koskevan ehdotuksen. Tyylisäännöstö voisi tällöin olla vaikkapa seuraava:
.credit { font-size : 85%; text-align : right; } jolloin kyseinen teksti näkyy (mahdollisesti) hiukan pienempänä ja oikeaan reunaan tasattuna. Esimerkiksi seuraavaan tapaan (huomaa, että esitysasuun voivat vaikuttaa muutkin tyylisäännöstöt):

Alussa olivat suo, kuokka - ja Jussi.
Väinö Linna: Täällä Pohjantähden alla, s. 1

Lähteen ilmaisemisen tarkkuus riippuu asiayhteydestä, lainauksen tarkoituksesta, teoksen tunnettuudesta jne. Esimerkiksi tieteellisissä teksteissä on omat sääntönsä, tarkemmin sanoen muutamia vaihtoehtoisia, tarkoin määriteltyjä järjestelmiä. Ks. esim. Helsingin ammattikorkeakoulun opinnäytetyöohjeen kohtaa Lähdeviitteet.

Luonnollisestikin jos lainaus on Webissä olevasta lähteestä (tai teoksesta, joka on myös Webissä) on suotavaa liittää siihen linkki. Tällöin lukija voi suoraan tutustua lähteeseen ja nähdä lainatun tekstin alkuperäisessä yhteydessään. Toissijaisesti voi viitata sivuun, joka sisältää tietoja (esim. bibliografisia tietoja tai referaatin tai arvostelun) siteeratusta teoksesta.

"Pelkkää tekstiä sellaisenaan": pre

Edellä on kuvattu, miten selain normaalisti muotoilee tekstin uudestaan, kiinnittämättä huomiota siihen, miten HTML-dokumentissa on rivinvaihtoja. Lisäksi selain ei kiinnitä huomiota siihen, montako välilyöntiä kahden sanan välissä on. Erityisesti mitkään sisennykset eivät säily. Tämä on siis normaalia ja yleensä tarkoituksenmukaista.

Joskus tästä halutaan poiketa: halutaan esittää teksti "sellaisenaan". Tyypillinen esimerkki on jollakin ohjelmointikielellä kirjoitettu ohjelma, jossa on mm. sisennyksiä, joiden halutaan säilyvän. Esimerkki:

$line = 1;
while (<FOO>) {
  print $line, " ", $_;
  $line = $line + 1; }

Tarkoitukseen käytetään pre-elementtiä: juuri ennen kyseistä tekstiä kirjoitetaan <pre>-tägi ja heti sen jälkeen </pre>-tägi. Nimi johtuu sanasta preformatted 'valmiiksi muotoiltu'. Käytännössä selain tällöin normaalisti käyttää tasalevyistä fonttia, koska muutenhan ei voitaisi sanoa kaiken säilyvän "sellaisenaan". Tämä merkitsee, että pre-elementtiä voidaan käyttää myös eräänlaiseen alkeelliseen taulukointiin varsinaisten taulukoiden asemesta. Esimerkiksi kohdassa "Turvalliset" merkit esitetty merkkien "taulukko" on itse asiassa tehty pre-elementillä.

Vaikka pre-elementti tavallaan merkitseekin alkeellisen "pelkän tekstin" liittämistä irrallisena lisukkeena HTML-dokumenttiin, sen sisällä voidaan kuitenkin käyttää HTML-merkkausta kuten korostuksia ja linkkejäkin. Sellaista merkkausta koskevat syntaktiset rajoitukset (ks. pre-elementin tarkkaa kuvausta) tähtäävät siihen, että elementin sisällä ei saa olla sellaisia rakenteita, jotka sotkisivat sen perusidean. Esimerkiksi otsikot eivät tule kyseeseen, koska ne tyypillisesti aiheuttavat fonttikoon muuttumisen.

Vaikka ehkä tyypillisin pre-elementin käyttötarkoitus on ohjelmakoodin tai vastaavan esittäminen, ei tämä elementti itsessään sano mitään sisältönsä merkityksestä. Itse asiassa sitä joskus käytetään muun muassa esitettäessä modernia runoutta, jossa tyhjien välienkin halutaan olevan osa itse runoa. Jos sisältö on koodia, on asianmukaista esittää se code-elementtiä käyttäen. Lisäksi on huomattava, että pre-merkkaus ei muuta normaaleja HTML:n sääntöjä. Jos esimerkiksi koodissa esiintyy <-merkki, se on syytä esittää muodossa &lt;. Täten edellä olevan esimerkin merkkaukseksi sopisi seuraava:


<pre><code>$line = 1;
while (&lt;FOO&gt;) {
  print $line, " ", $_;
  $line = $line + 1; }</code></pre>

Vältä pitkiä rivejä pre-elementin sisällä. Jos niitä välttämättä tarvitaan, on hyvä ehdottaa tyylisäännöstöllä fontin pienentämistä pre-elementin sisällä, jotta teksti todennäköisemmin mahtuisi selaimen ikkunaan vaakasuunnassa.

Varsinkin, jos pre-elementissä on paljon sisältöä, on usein hyödyllistä, että ennen sitä on linkki sen jälkeen tulevaan sisältöön. Esimerkiksi puhesynteesissä kyseinen sisältö toimii usein huonosti, ja muutenkin sisältö voi olla käyttäjän vaikeasti hahmotettavissa. Tämä koskee etenkin niin sanottua Ascii-grafiikkaa, jossa merkkien sijoittelulla luodaan eräänlainen kuvallisen esityksen korvike.

Pakotetut rivinvaihdot: br ja div

Pelkästään rivinvaihtojen pakottamiseen ei kannata käyttää pre-elementtiä, muun muassa siitä syystä, että sivuvaikutuksena on tasalevyinen fontti. Esimerkiksi runo- tai laulutekstin halutaan yleensä esittää niin, että yhdellä rivillä on yksi säe, ja tämä onnistuu br-elementillä, joka kirjoitetaan kunkin säkeen perään. Se on poikkeuksellisesti elementti, jolla ei ole sisältöä eikä lopputägiä vaan se on pelkkä <br>. Se voidaan siis ymmärtää eräänlaiseksi rivinvaihtokäskyksi, ei varsinaisesti rakenteelliseksi elementiksi.

Hiukan rakenteisempi vaihtoehto on div-merkkaus. Tosin sekään ei sano mitään tekstisisällön merkityksestä ja loogisesta rakenteesta, mutta sen avulla voidaan teksti jakaa elementeiksi eikä vain "rivinvaihtokäskyjen" erottelemaksi tekstivirraksi. Esimerkki:

<div>Mieleni minun tekevi</div>
<div>aivoni ajattelevi</div>
<div>lähteäni laulamahan</div>
<div>saa'ani sanelemahan.</div>

Pakotetuilla rivinvaihdoilla voidaan myös tehdä eräänlaisia minikappaleita kappaleiden sisään. Joskus esimerkiksi kappaleen tekstissä mainitaan jotain, jonka olisi hyvä näkyä kappaleesta "esiin nousevana" mutta silti siihen sisältyvänä. Esimerkiksi pitkähkö URL kuten
http://dmoz.org/Science/Biology/Genetics/Eukaryotic/Animal/Dog/
voisi olla sellainen. Sellaisesta osasta voidaan tehdä erillinen rivi. Tämä merkitsee, että ennen sitä ja sen jälkeen kirjoitetaan <br>-tägi. Toisaalta sellainen osa usein halutaan lisäksi keskittää center-elementillä, jolloin <br>-tägit ovat tarpeettomia (koska center käytännössä aiheuttaa rivinvaihdot).

Sisennykset ovat sitten eri juttu. Jos esimerkiksi runo vaatii sisennyksiä, voidaan kirjoittaa rivin alkuun haluttu määrä ns. no-break space merkkejä (&nbsp;). Kyseisellä merkillä on nimittäin varsinaisen merkityksensä lisäksi sellainen vaikutus, että useimmat selaimet näyttävät sellaisten merkkien jonon tyhjänä välinä, jonka leveys riippuu merkkien määrästä. Tämä on toki kömpelö ratkaisu. Tyylikkäämpi (mutta melko työläs) ratkaisu olisi tehdä kustakin rivistä erillinen div-elementti ja liittää sellaisiin elementteihin tyylisäännöstöillä tehtyjä ehdotuksia esitysmuodosta.

Keskitys vaakasuunnassa: center

Tekstin tai kuvan voi keskittää vaakasuunnassa kirjoittamalla sen center-elementin csisään. Tekstikappaleisiin sovellettuna se antaa levottoman vaikutelman, koska selain käytännössä jakaa tekstin eri riveille kuten normaalistikin ja sitten keskittää kunkin rivin.

Niinpä tekstikappaleen varsinaisen keskittämisen asemesta kannattaakin ehdottaa sille vasenta ja oikeaa reunusta tyylisäännöstöillä (esim. margin-left:2em; margin-right:2em).

Entä taulukon keskitys? Siihen on usein käytetty menettelyä, jossa on juuri ennen taulukkoa tägi <center> ja heti taulukon perään tägi </center>. Nykyisen tulkinnan mukaan kuitenkin tämä itse asiassa merkitsee pyyntöä keskittää kunkin alkion sisältö. Eräät selaimet vieläpä soveltavat joko vanhaa tai uutta tulkintaa sen mukaan, millainen dokumenttityypin määrittely on annettu! Taulukon keskitystä ei yleensä kannata toistaiseksi yrittää, mutta taulukolle voi halutessaan ehdottaa sopivaa vasenta marginaalia, esimerkiksi
<table style="margin-left:3em">

Seuraavassa esimerkissä on keskitettynä lyhyt teksti, joka on itse asiassa HTML-merkkaus, jolla kuva keskitetään, ja sitten keskitetty kuva,

<center><p><img alt="_________" src="anchor.gif"</p></center>

_________

Usein huomautetaan, että center-elementti ei ole rakenteellinen vaan esitysasuun puuttuva. Tämä on aivan totta. Useissa tapauksissa keskittämisen ehdottaminen tyylisäännöstöillä johtaisi kuitenkin vielä ongelmiin selainten virheiden takia. Niinpä tässä on esitelty "perinteisempi" tapa, joka toimii lähes kaikissa selaimissa. Tällöin kuitenkin on "pakollisiin kuvioihin" kuuluvassa DOCTYPE-määrittelyssä ilmoitettava, että on käytetty ns. Transitional-versiota kielestä.

Oikea reuna suoraksi: align="justify"

Lehdissä ja kirjoissa tekstipalstat on usein tasattu oikealta eli rivit ovat tasamittaisia; tällöin yleensä sanojen välissä on vaihteleva määrä tyhjää tilaa, tai joskus kirjainten välistyskin vaihtelee.

Sellainen tasaus on yleensä huono idea Web-sivuilla. Ensinnäkin se tekee tekstin jonkin verran vähemmän luettavaksi kuvaruudulla. Mutta ennen muuta selainten taito tasata tekstiä on erittäin huono. Nykyiset selaimet eivät lainkaan jaa sanaa eri riveille, paitsi IE rajallisessa määrin, tavalla, josta on usein enemmän haittaa kuin hyötyä. Ja suomen kaltaisessa kielessä, joka synteettisyytensä ja sananjohtamismahdollisuuksien runsauden takia on varsin pitkäsanaista, tämä aiheuttaa pahoja ongelmia. Etenkin jos palsta on suhteellisen kapea, ja sehän voi olla.

Sanomalehdissä tasaus kuuluu median luonteeseen ja sitä pidetään aika välttämättömänä. Mutta vaikka se tehdään suhteellisen kehittyneillä ladontaohjelmilla, jotka osaavat (suurimmaksi osaksi) tavuttaa ja vaikka prosessi on periaatteessa ihmisten kontrolloitavissa, niin niissä erittäin usein esiintyy hyvinkin rumia tasauksia. Toki tämä johtuu suurimmaksi osaksi siitä, että automatisointi on viety liian pitkälle tekniikan kehittyneisyyteen nähden, eli ulkoasua ei tarkisteta ennen painokoneisiin menoa, koska se "maksaisi liikaa". Mutta Webissä tilanne on se, että sivuntekijä ei edes voisi tarkistaa, miten mikin selain milloinkin on tasaamassa tekstiä.

Erikoistapauksissa tasausta voi harkita. Se voisi olla tehokeino, muun muassa juuri siksi, että sitä ei yleensä käytetä Webissä. Esimerkiksi jos sivulle otetaan lyhyt lainaus sanomalehtiuutisesta, voisi sille ehdottaa ulkoasua, joka joissakin suhteissa matkii alkuperäistä. Vaikkapa tähän tyyliin: 

<style type="text/css"><!--
blockquote.newspaper {
  text-align: justify;
  width: 20em;
  border: none;
  font-family: "Times New Roman", serif; }
--></style>

Tosin esimerkiksi Netscape 4.0 näyttää jättävän säännön text-align:justify huomiotta, joten ehkä kannattaisi varmuuden vuoksi kirjoittaa myös HTML-määrite align="justify" kuhunkin kappale-elementtiin.

Lainaus sitten aloitettaisiin seuraavasti:
<blockquote class="newspaper"><p class="literary" align="justify">
(missä määrite class="literary" viittaa eräänlaiseen "kirjalliseen tyyliin" kappaleiden esityksessä) ja tulos voisi näyttää seuraavanlaiselta:

Ohjelmistopatenttien sallimista Euroopassa ajaa Yhdysvallat, joka saisi näin täälläkin patenttisuojan esimerkiksi uusille verkkoliiketoimintamalleille ja -sovelluksille. Amerikkalaiset ovat verkkokaupassa useita vuosia eurooppalaisten edellä.

-- Tietoviikko 1999-08-13

Kannattaa katsoa, miltä tulos näyttää. Tässä tapauksessa IE:n jotkin versiot innokkaasti tasaavat jättämällä tyhjää myös sananalkuisen yhdysmerkin jälkeen. Netscape 4 taas saattaa jättää yhden riveistä vajaaksi, kun sitä seuraa pitkä sana. Mutta ehkäpä sinulla on parempi tuuri eli teksti, jossa ei ole kovin pitkiä sanoja eikä sellaisia omituisuuksia kuin yhdysmerkki sanan alussa!

Hiukan lisätietoja: How do I justify text on both sides on Web pages?

Lisukkeet: Mitä kaikkea voisikaan lisäksi tehdä

Palvelinskriptit (server-side scripting)

Sisällys

"Kaikki on mahdollista"

Tämän oppaan toisessa luvussa kuvattiin lomakkeiden käytön alkeita, ja siinä yhteydessä mainittiin myös, että lomakkeita käytettäessä varsinaisen työn tekee palvelinskripti.

Palvelinskriptiksi voidaan asentaa periaatteessa mikä hyvänsä ohjelma tai skripti. Sanoilla "ohjelma" ja "skripti" ei ole selvää eroa. Usein skripti tarkoittaa suhteellisen yksinkertaista ohjelmaa, joka on tavallisesti kirjoitettu tarkoitukseen sopivalla ohjelmointikielellä, skriptikielellä.

Teknisellä tasolla palvelinskripti voi esimerkiksi lukea ja kirjoittaa palvelimessa olevia tiedostoja ja tietokantoja, lähettää meilejä tai fakseja ja ylipäänsä tehdä kaikkea, mitä voidaan tehdä palvelinjärjestelmän laitteilla tai niiden kautta. Turvallisuus- ja muista syistä toimintamahdollisuuksia on usein rajoitettu, joten mainittu periaatteellinen mahdollisuus koskee ensisijaisesti Web-palvelimen ylläpitohenkilöstöä.

Jonkinlaisen kuvan siitä, millaisiin erilaisiin tarkoituksiin on käytännössä tehty palvelinskriptejä, antaa CGI Resource Indexin kohta Programs and Scripts. Lisäksi on tietenkin olemassa täysin sovelluskohtaisia skriptejä.

Jotta voisit käytännössä tehdä jonkin asian palvelinskriptillä (ja siihen liittyvällä lomakekäyttöliittymällä), tarvitset jommmankumman seuraavista:

Tekniikkaa: PHP, CGI, ASP...

Teknisesti skripti voi olla toteutettu monella eri tavalla. PHP-ohjelmointikielellä toteutettu sivu (jollaisen toisinaan tunnistaa siitä, että osoite loppuu .php eikä .html) on nykyään yleisin pienten sivustojen käytössä. Jäljempänä on lyhyitä PHP-esimerkkejä; muista tekniikoista on vain linkkejä tietolähteisiin.

Vanhin tekniikka on CGI-rajapinta. Se ei ole ohjelmointikieli vaan liityntä, jota voi käyttää mikä tahansa ohjelmointikieli; yleisin käytetyistä kielistä on Perl. Valmiita CGI-skriptejä on moniin tarkoituksiin vapaasti saatavilla, mutta nykyään myös PHP-kielisiä versioita löytyy lähes yhtä paljon.

Käytännössä palveluntarjoajasi ratkaisut määräävät, voitko lainkaan asentaa palvelinskriptejä. Lisäksi palveluntarjoajasi määrää, mitä liityntätekniikkaa käytetään ja millä ohjelmointikielellä tai -kielillä voit kirjoittaa skriptejä. Palveluntarjoajien tavallisimmat vaihtoehdot ovat (1) "eioo", (2) PHP ja (3) CGI, jossa kielenä Perl on tai C (tai molemmat vaihtoehdot).

Muita vaihtoehtoja ovat mm. ASP (ks. myös ASP FAQ) ja Java servlet -tekniikka. Nämä ovat käytettävissä selvästi harvemmin kuin PHP ja CGI.

Äänestetään!

On monia asioita, joita usein halutaan tehdä Webissä ja joita ei voi tehdä, ei ainakaan läheskään niin helposti kuin luullaan ja luulotellaan. Tyypillinen esimerkki tästä on kunnollisen äänestyksen tai mielipidetutkimuksen järjestäminen.

Äänestyksiä, mielipidetutkimuksia yms. on ruvettu yleisesti järjestämään Webissä. Monestakin syystä ne ovat useimmiten ihan huuhaata, ainakin jos niiden väitetään antavan yleistettävissä olevia tuloksia tyyliin "42 % suomalaisista - -" tai edes "42 % suomalaisista Internetin käyttäjistä - -". Useinkaan ei ole estetty edes moninkertaista äänestämistä, saati että äänestäjien joukko olisi otos jostakin tunnetusta perusjoukosta. Mutta monta hyvää lehtijuttua on pilattu faktojen tarkistamisella ja monta hyvää "Internet-kyselyä" tilastotieteen alkeiden tuntemisella. Niin ei ole erehdytty tekemään esim. Valittujen Palojen "kyselytutkimuksissa", joista tehdyt jutut aloitetaan komeasti tyyliin "85 prosenttia suomalaisista - -".

Varsin usein vielä lisäksi kutsutaan äänestystä tms. "gallupiksi". "Gallup" on todellisuudessa rekusteröity tavaramerkki. Nimitystä ei pidä käyttää edes oikeista mielipidetutkimuksista elleivät ne ole tavaramerkin haltijan tekemiä.

Luotettava äänestäminen, otantatutkimus tms. Webissä on mahdollista lähinnä silloin, kun osallistujien joukko on selvästi määritelty, esim. jonkin yhdistyksen jäsenet, ja on (mieluiten laillisesti) saatavissa rekisteri heidän osoitetiedoistaan. Silloin kullekin äänioikeutetulle tai otokseen valikoituneelle voidaan toimittaa esimerkiksi käyttäjätunnuksen ja salasanan yhdistelmä, jolla voi äänestää yhden kerran. Tällöin virhelähteitä ja väärinkäytön mahdollisuuksia on suurin piirtein vain sen verran kuin äänestyksissä ja otantatutkimuksissa yleensäkin.

On tehty paljonkin sellaisia "äänestyksiä" tai "tutkimuksia", joissa vain pannaan Web-sivulle lomake, jonka kuka hyvänsä voi täyttää ja lähettää ja niin saada äänensä tai vastauksensa huomioon otetuiksi. Sen voi tehdä hyvinkin helposti, ja tulokset ovat silloin yleensä roskaa pahemmat. Joissakin tilanteissa, mahdollisesti erinäisiä melko vaativia tekniikoita käyttäen, voidaan ehkä kehittää systeemi, joka tuottaa jotain mielekästä. Lisäksi jos äänestyksen kohde ei herätä suuria intohimoja vaan on luokkaa ”kumpi näistä naamakuvistani miellyttää enemmän”, tulokset yleensä antavat jotain suuntaa. Kukaan tuskin viitsii häiriköidä sellaista äänestystä.

Ulkopuolisen skriptin käyttö (esimerkkinä vieraskirja)

Ensimmäisessä osassa esitettiin jo lyhyesti hakulomake, joka käyttää muualla olevaa valmista skriptiä. Sellaisen tekeminen edellyttää paitsi HTML:n lomakerakenteiden osaamista myös sitä, että tiedetään tai päätellään, miten skripti toimii ulkonaisesti katsottuna: mitä sille pitää "syöttää", jotta se saataisiin tekemään haluttu asia. Hakuskriptien tapauksessa tämä voi vaatia arvailua, joten katsotaanpa selvempää tilannetta.

Aika usein aloitteleva Web-sivujen tekijä haluaa sivuilleen vieraskirjan (guestbook). Tämä tarkoittaa järjestelmää, jonne kuka hyvänsä voi kirjoittaa viestin ja josta kuka hyvänsä voi lukea muiden kirjoittamia viestejä. Usein vieraskirja tehdään sivulle ennen omaa sisältöä, jolloin vaikutelma on lähinnä säälittävä.

Vieraskirjat täyttyvät helposti roskasta, koska osa kävijöistä on häiriköitä ja töhertelijöitä. Suurempi ongelma ovat hakukonespammerit, jotka yrittävät huijata esimerkiksi Googlea luulemaan omaa sivuaan suosituksi. Google nostaa hakutuloksissa ylemmäs sivun, johon osoittaa paljon linkkiä. Jotkut ovat tehneet ohjelmia, jotka automaattisesti täyttävät vieraskirjoja pelkillä linkeillä.

Voisimme valita CGI Resource Indexin asianomaisesta osasta, Programs and Scripts: Remotely Hosted: Guestbooks, jonkin vaihtoehdon, tutustua sen käyttöohjeisiin ja rakentaa vieraskirjan. Itse asiassa tässä oppaassa oli aiemmin esimerkkinä eräs sellainen. Nyttemmin kyseinen palvelu on poistunut. Ilmaispalvelujen varaan ei todellakaan kannata rakentaa paljoakaan. TANSTAAFL!

Muuan erityisesti suomalaisille tarkoitettu ilmainen vieraskirjapalvelu on Freebok. Se kertoo: "Palvelun avulla vieraskirjan käyttöönotto on helppoa eikä vaadi kokemusta ohjelmoinnista: rekisteröinnin jälkeen lisäät vain sivuillesi linkin uuteen vieraskirjaasi!" Ja tämä näyttäisi pitävän paikkansa. Rekisteröinnin jälkeen tulee tieto, millaiset linkit sivulle tarvitaan vieraskirjaa varten. Seuraavassa on tämän oppaan vieraskirjaa varten tekemäni linkit:

Kyseiseen vieraskirjaan, kuten moneen muuhun, on kirjoitettu lähinnä eri sivustojen mainoksia. Vakavasti otettavan vieraskirjan ylläpitäminen vaatisi käytännössä valvontaa ja roskaviestien poistamista.

Ulkopuoliset, ilmaiseksi tarjolla olevat skriptit voivat kadota ilman ennakkovaroitusta. Sivuntekijän kannalta turvallisempi on oman palveluntarjoajan valmiiksi asentama skripti. Käyttö ei eroa ulkopuolisen skriptin käytöstä. Moni palveluntarjoaja antaa asiakkaidensa käyttöön valmiin skriptin palautelomakkeen tekoa varten, harvempi muihin tarkoituksiin.

PHP, alkeiden perusteet

PHP on yksinkertaisin tapa omien palvelinskriptien tekemiseen. Aloita tekemällä normaali HTML-sivu (huomioiden pakolliset kuviot), mutta nimeä se .php-loppuiseksi ja kirjoita runko-osaan seuraava rivi: 

<P>Tänään on <?php $aika=getdate(); print $aika['weekday']; ?>.

Jos kaikki meni hyvin, olet nyt tehnyt sivun jossa lukee esimerkiksi "Tänään on perjantai." tai "Tänään on monday.", riippuen viikonpäivästä ja palvelimen asetuksista. Jos homma ei toiminut, ei palveluntarjoajasi ehkä tue PHP:ta. Voi myös olla, että PHP on otettava erikseen käyttöön, tai siitä peritään lisämaksu, tai sivu pitääkin nimetä .phtml, tai jotain muuta. Lue palveluntarjoajan ohjeet!

PHP-osa alkoi koodilla <?php ja loppui ?>. Kaikki sen ulkopuolella tulkittiin normaalina HTML:nä. Selaimelle siis annettiin ensin <P>Tänään on , sitten PHP:n tuloste, ja lopuksi piste. PHP-ohjelma koostui kahdesta lauseesta. Ensimmäinen sijoitti senhetkisen ajan muuttujaan $aika, toinen tulosti tämän muuttujan kentän (komponentin) 'weekday'.

Yleiskatsauksellisuuden vuoksi lomakkeessa on käytetty yksinkertaistettua merkkausta. Todellisessa lomakkeessa olisi hyvä mm. määritellä kenttien ja niiden selitysten vastaavuudet LABEL-elementin avulla.

Toisena esimerkkinä tehdään yksinkertainen palautelomake. Aloita tekemällä HTML-tiedosto, johon tulee seuraava lomake: 

<FORM ACTION="laheta.php" METHOD="post">

<P>Nimesi: <INPUT TYPE="text" NAME="nimi">

<P>Sukupuolesi:<BR>
<INPUT TYPE="radio" NAME="sukupuoli" VALUE="1">Mies<BR>
<INPUT TYPE="radio" NAME="sukupuoli" VALUE="2">Nainen

<P>Kommentit tekstistä "Sukupuolen vaikutus PHP-ohjelmointiin":

<TEXTAREA NAME="palaute" ROWS=10 COLS=60>
</TEXTAREA>

<P><INPUT TYPE="submit" VALUE="Lähetä">
</FORM>

Tämän jälkeen tehdään laheta.php, joka tekee varsinaisen työn. Pakollisten kuvioiden jälkeen lisää seuraava: 

<?php

if (strlen($HTTP_POST_VARS['nimi']) == 0) {
    print "<P>Nimi puuttuu! Palaa takaisin!";
} else {
    print "<P>Lähetän viestin.";
    mail('oma.osoitteesi@domain.example', 'Palaute WWW-lomakkeelta',
     "Nimi: ".$HTTP_POST_VARS['nimi']."\n".
     "Sukupuoli: ".$HTTP_POST_VARS['sukupuoli']."\n\n".
     "Viesti: ".$HTTP_POST_VARS['palaute']);
}

?>

Esimerkissä on hyvin alkeellinen tarkistus: nimeksi pitää syöttää jotain. Sitä, että herrat Aku Ankka ja Mikki Hiiri lähettävät palautetta, ei kuitenkaan voi estää.

Liityntä HTML:n ja palvelinskriptin välillä on hyvin yksinkertainen: kun HTML-lomakkeessa on lomakkeen elementillä name-attribuutin arvo xyz, se näkyy PHP-skriptille muuttujana $HTTP_POST_VARS['xyz'] tai $HTTP_GET_VARS['xyz'], riippuen siitä onko form-elementin method-attribuuttina post vai get.

PHP-kielen virallinen sivusto on php.net, jossa on myös manuaali. Suomeksikin on olemassa monenlaisia ohjeita, esimerkiksi Jarkko Leponiemen kurssimateriaali Verkkopalvelut ja PHP tai Pauli Kujalan LuK-tutkielma Dynaamisten WWW-sivujen tuottaminen PHP-kielen avulla.

CGI-skriptin asentaminen

CGI-skriptin asennus vaatii ennen muuta sitä, että olet selvittänyt, miten skriptejä ylipäänsä asennetaan Web-palvelimeen, jota käytät. Tästä, kuten muistakin vastaavista asioista, saat tietoja omalta palveluntarjoajaltasi tai Web-palvelimen ylläpidolta. Suurin osa ongelmista skriptien asentamisessa johtuu siitä, että asiaa koskevia palvelinkohtaisia ohjeita ei ole saatu tai ei ole luettu tai ei ole ymmärretty. Ohjeiden taso vaihtelee. Usein ne on kirjoitettu olettaen, että lukija tuntee asiaan liittyviä tekniikoita aika paljon.

Yleistä taustatietoa antaa Lars Marius Garsholin kirjoittama How the web works: HTTP and CGI explained.

Erityisesti jos skripti on kirjoitettu Perl-kielellä, kuten suurin osa palvelinskripteistä on, tarvitset yleensä tiedon siitä, minne (millä polkunimellä) Perl-tulkki on asennettu. Jos Perl-skriptien asennuksessa Unix-järjestelmään tulee ongelmia, niin mainio tarkistuslista löytyy dokumentista The Idiot's Guide to Solving Perl CGI Problems, joka on nimeään paljon ystävällisempi (mutta edellyttää Unixin käytön perusasioiden tuntemista).

Lisäksi jonkun muun tekemän skriptin asennus vaatii skriptikohtaisesti ennen muuta seuraavan:

  1. Lue asennusohjeet. Jos skriptille ei ole asennusohjetta, älä asenna sitä.
  2. Lue asennusohjeet uudestaan. Jos et ymmärrä jotain, hanki taustatietoja.
  3. Tarkista, oletko ymmärtänyt asennusohjeet oikein. Jos et, palaa kohtaan 1. Jos mielestäsi olet, lue ne kuitenkin vielä kerran uudestaan.
  4. Kun jotain menee pieleen, mene kohtaan 1.

Siinäpä se suunnilleen onkin. Käytetyn ohjelmointikielen (Perl, C, joskus jokin muu) tuntemus ei periaatteessa ole välttämätöntä, jos haluat asentaa skriptin sellaisenaan ja sen asennusohjeet ovat hyvät.

Kun yrität ymmärtää toisaalta palvelinkohtaisia, toisaalta skriptikohtaisia ohjeita, niin CGI Resource Indexin osasta CGI Tutorials voi olla apua.

CGI-skriptien tekeminen

Omien CGI-skriptien teko on yleensä hiukan PHP-sivun tekemistä vaativampaa. Kannattaa aloittaa jostakin helposta, esimerkiksi skriptistä, joka vain tulostaa Hello world. Sitten voi asteittain siirtyä vaativampiin toimintoihin. Käytäntö on osoittanut, että ohjelmoinnin aloituskynnys on korkea: kun olet saanut ajetuksi ensimmäisen ohjelmasi, teki se sitten miten triviaalin asian tahansa, olet jo ratkaissut monta ongelmaa.

Edellä mainittu CGI Tutorials sisältää monia erityyppisiä johdatuksia CGI-ohjelmointiin. Seuraavat minun kirjoittamani johdatukset aihepiiriin on tarkoitettu lähinnä havainnollistamaan, millaisista asioista on kyse:

JavaScript (ja vastaavat)

Sisällys

Miksi JavaScript?

JavaScriptillä voidaan saada aikaan Web-sivuja, jotka "vastaavat" käyttäjän toimenpiteisiin kuten hiiren klikkauksiin, syöttötietojen kirjoittamiseen ja sivulla liikkumiseen. Yleisemmin JavaScriptillä voidaan ohjelmoida erilaisia toimintoja, jotka selain suorittaa - mahdollisesti.

Tämä kappale on esimerkki siitä, miten HTML-dokumenttiin saattaa tulla mukaan selaimen lisäämää sisältöä. Tässä tapauksessa JavaScript-koodi lisää päiväyksen:

Voi tietysti kysyä, mitä iloa moisesta on. Oletetaanko käyttäjä typerykseksi, joka ei osaa itse katsoa (esim. tietokoneestaan), mikä päivä on? Yleensä tällaiset päivämääräntulostukset ovatkin pelkkää peeloilua. Mutta jos teet esimerkiksi lomakkeen, josta käyttäjä voi valita päivämäärän, haluat ehkä asettaa "nykyisen" (siis lomakkeen täyttämishetken) päivän oletusarvoksi; siinä voisi olla järkeä. Se vaatiikin sitten jo vähän enemmän.

Suuri osa JavaScriptiä sisältävistä Web-sivuista käyttää sitä erilaisiin ärsyttäviin efekteihin kuten uusien ikkunoiden pulautteluun käyttäjän ruudulle ja käyttäjän sivulla liikkumisen rajoittamiseen. Lisäksi JavaScript-toteutuksista löytyy aina uusia turvallisuusaukkoja. Näistä ja muista syistä onkin syytä varautua siihen, että monet fiksut käyttäjät ovat disabloineet JavaScriptin eli käskeneet selaintaan olemaan suorittamatta JavaScript-koodia tai että JavaScript muutoin jää suorittamatta.

Toisaalta JavaScriptillä on monenlaista hyvinkin hyödyllistä käyttöä. Ks. kirjoitusta JavaScript: mukavuutta, mutta myös riskejä. Sivulle voidaan kirjoittaa noscript-elementti, jonka sisällössä kuvataan, mitä hyötyjä voisi saavuttaa käyttämällä selainta, jossa JavaScriptin suoritus on sallittu.

Mitä JavaScript on

JavaScript on ohjelmointikieli, jota yleensä käytetään selainskriptien tekemiseen (client-side scripting): jos HTML-dokumenttiin on sopivalla tavalla liitetty JavaScript-ohjelma, niin Web-selain mahdollisesti suorittaa tämän ohjelman, kun sitä on käsketty näyttämään kyseinen HTML-dokumentti. Ohjelma voi olla hyvin yksinkertainen, esimerkiksi alert('heippa'), joka luo ruudulle ikkunan ja siihen tekstin heippa ja odottaa, että käyttäjä "kuittaa" tämän klikkaamalla ikkunassa olevaa OK-painiketta. Toisella tapaa (ja paljon harvemmin) JavaScriptiä käytetään palvelinskriptien tekemiseen.

JavaScript on sinänsä vain yksi monista selainskriptien tekemiseen käytetyistä kielistä. Se on kuitenkin ehdottomasti laajimmin selainten tukema ja sen takia yleisimmin käytetty. (Toiseksi yleisin lienee VBScript, jota IE tukee.) Selainskriptien liittämistä HTML-dokumentteihin käsittelee yleisesti, siis ohjelmointikielestä riippumattomalta osin, HTML-spesifikaation luku Scripts.

Koska kielen toteutus perustuu tulkintaan (interpretation) eikä kääntämiseen (compilation) ja koska JavaScript-ohjelmat ovat tyypillisesti aika pieniä, puhutaan JavaScriptin yhteydessä usein skripteistä (scripts) eikä ohjelmista (programs). Kyse on kuitenkin vain sananvalinnasta.

JavaScript on suhteellisen monipuolinen ohjelmointikieli. Muita ohjelmointikieliä tuntevalle sanonee jotain se, että JavaScriptissä on melko tavanomainen funktiokäsite, rakenteiset ohjauslauseet (esim. while toiston toteuttamiseen), taulukkorakenne, joustava merkkijonojen käsittely ja suuri joukko valmiita funktioita, jotka liittyvät etenkin selaimen toimintojen ohjaamiseen. Toisaalta hyvinkin yksinkertaisilla JavaScript-ohjelmilla - joita siis kaikki eivät edes ohjelmiksi kutsu - voi tehdä monenlaisia asioita.

JavaScriptin liittäminen HTML-dokumenttiin voidaan tehdä useilla tavoilla:

Esimerkkejä JavaScriptin käytöstä

Seuraavassa on pari yksinkertaista esimerkkiä. Runsaasti muita esimerkkejä löytyy esimerkiksi Website Abstractionin Free JavaScripts! -sivuilta. Kannattaa kuitenkin muistaa, että useimmiten JavaScriptillä pilataan sivuja eikä paranneta niitä. Ajattelu ja harkinta kannattaa, samoin esimerkkien katselu ideoiden saamiseksi. Sensijaan kopioimalla koodia ymmärtämättä, mitä se tekee ja miten ja milloin, onnistuu yleensä vain sotkemaan asioita.

Kuvan vaihto

Olettakaamme, että haluaisimme, että Web-sivulla oleva kuva vaihtuu toiseksi, kun kursori viedään sen päälle. Luonnollinen tapa tehdä tämä JavaScriptillä olisi seuraava: 

<img alt="" src="1.gif" name="kuva1"
 width="148" height="109"
 onmouseover="if(document.images) document.kuva1.src='2.gif'">

Tässä onmouseover on tapahtumamäärite, ja sitä vastaava tapahtuma (kursorin vieminen kuvan alueelle hiiren tai vastaavan laitteen avulla) aiheuttaa määritteen arvona olevan JavaScript-ohjelman suorittamisen. Jos selain tukee JavaScriptiä ja tuki on enabloituna; muuten ei tapahdu mitään. Kyseessä on toki erittäin yksinkertainen ohjelma, joka muuttaa dokumenttia - sellaisena kuin se on selaimen muistissa - siten, että kyseisen img-elementin src-määritteen arvoksi tulee 2.gif. Hyvään JavaScript-ohjelmointityyliin kuuluu tarkistaa, tukeeko käytössä oleva kielen toteutus tarvittavia "olioita" ennenkuin niitä "olioita" yritetään käsitellä, tässäkin on ehto if(document.images). (Tämän nimenomaisen varmistuksen käytännöllinen merkitys on suhteellisen pieni, koska lähes kaikki JavaScript-toteutukset tukevat kuvaolioita. Yleisesti tällaiset tarkistukset ovat hyvinkin tarpeellisia.)

Edellä kuvattu luonnollinen rakenne kuitenkin toistaiseksi toimii vain joissakin selaimissa, lähinnä IE 4:ssä ja uudemmissa. Huomattavasti laajemmin tuettu on rakenne, jossa onmouseover on liitetty linkkiin eli a href -elementtiin eikä img-elementtiin. Tässähän ei sinänsä ole ongelmaa, jos haluammekin kuvan olevan linkki. Mutta jos emme, niin sitten pitää temppuilla, jotta rakenne joka (teknisesti) on linkki ei näyttäisi linkiltä ja jotta mitään ei tapahtuisi, jos sitä kuitenkin yritetään seurata: 

<a href="#" onmouseover=
"if(document.images) document.kuva2.src='2.gif'"><img
 alt="" src="1.gif" name="kuva2" border="0"
 width="148" height="109"></a>

Tässä on kirjoitettu href-määritteen arvoksi "#", mikä on periaatteessa väärin (virheellinen URL-viittaus) mutta ei tässä yhteydessä aiheuta ongelmia. Linkkiä ei ole tarkoituskaan seurata, eikä yritys seurata sitä johda mihinkään.

Jos halutaan, että kursorin poistuessa kuvan päältä kuva palautuu ennalleen, kirjoitetaan onmouseover-määritteen lisäksi onmouseout-määrite samaan tapaan.

Kahden kuvan vaihto

Kun JavaScriptillä muutetaan dokumentin sisältöä, niin muutettavan kohdan ei tarvitse olla sen elementin sisällä, johon tapahtumamäärite liittyy. Voimme esimerkiksi tehdä tekstilinkin, jota ei ole tarkoitettukaan seurattavaksi vaan toimimaan vain seuraavasti: kun kursori viedään linkkitekstin päälle, kaksi jossain muualla olevaa kuvaa vaihtuvat, ja kun kursori viedään pois, kuvat palautuvat ennalleen.

Tässä tapauksessa JavaScript-ohjelmalla on jo sen verran pituutta, että se kannattaa kirjoittaa funktioksi. Silloin tapahtumamääritteiden arvoiksi kirjoitetaan vain funktioiden kutsut: 

<a href="#" onmouseover="vaihda2()"
 onmouseout="vaihda2tak()">teksti</a>
Funktioiden määrittelyt voidaan kirjoittaa erilliseen tiedostoon, sanokaamme vaihda.js, ja dokumenttiin kirjoitetaan viittaus siihen aiemmin kuvatulla tavalla. Koodi voisi olla seuraava: 
function vaihda2() {
  if(document.images) {
    document.kuva1.src = '2.gif';
    document.kuva2.src = '3.gif'; } }
function vaihda2tak() {
  if(document.images) {
    document.kuva1.src = '1.gif';
    document.kuva2.src = '1.gif'; } }

JavaScriptissä aaltosulut { ja } toimivat ryhmittelymerkkeinä. Koko funktion runko kirjoitetaan niiden väliin. Lisäksi niitä käytetään tarvittaessa ryhmittelyyn funktion sisällä. Esimerkiksi tässä tapauksessa if-lauseen sisällä pitää olla olla sijoitusta, joten ne "kootaan yhteen" aaltosuluilla.

Sekä JavaScriptissä että HTML:ssä tarvitaan lainausmerkkejä erilaisten merkkijonojen rajoittimina. Tilannetta hankaloittaa mm. se, että HTML:n määritteen arvo kirjoitetaan lainausmerkkeihin ja toisaalta usein sisältää JavaScript-merkkijonovakion. Asioita helpottaa, kun omaksuu sen käytännön, että HTML:ssä käytetään varsinaisia lainausmerkkejä (kaksoislainausmerkkejä, ") ja JavaScriptissä puolestaan lainausmerkkien heittomerkkejä (yksinkertaisia lainausmerkkejä, ').

Huomaat varmaan, että funktiot ovat hyvin samanlaisia. Voisimmekin tehdä asian tyylikkäämmin käyttämällä funktion argumentteja, jolloin selviämme yhdellä funktiolla. (Isommissa hommissa argumenttien käyttö yksinkertaista ja helpottaa ohjelmointia vielä paljon enemmän.) Funktio olisi tällöin esim. seuraava: 

function vaihdane(eka,toka) {
  if(document.images) {
    document.kuva1.src = eka;
    document.kuva2.src = toka; } }
ja dokumentissa olisi: 
<a href="#" onmouseover="vaihdane('2.gif','3.gif')"
 onmouseout="vaihdane('1.gif','1.gif')">teksti</a>

Jos suurin piirtein ymmärsit, mistä edellä esitetyssä on kyse, tiedät JavaScript-ohjelmoinnin perusteista luultavasti enemmän kuin useimmat, jotka yrittävät sitä räpeltää.

Fokusointi lomakkeen kenttään

Jotta lomakkeen kenttään voisi kirjoittaa, täytyy yleensä selain saada "fokusoimaan" siihen eli tekemään kyseinen kenttä aktiiviseksi. Tämä tapahtuu tavallisesti viemällä kursori kentän alueelle ja klikkaamalla hiiren nappia. Tämä ei ole kovin suuri vaiva, mutta JavaScriptillä voimme ehkä auttaa käyttäjää välttämään sen.

Eräs tapa ilmenee seuraavasta esimerkistä (jota voi kokeilla erikseen). Lomakkeelle name-määritteellä annettava nimi on vapaasti valittavissa.

<form action="http://www.google.com/search"
 name="lomake">
<div><a href="http://www.google.com/">Google</a>:
<input type=text name=q size=40>
<input type=submit value=Search>
</div></form>
<script type="text/javascript" language="JavaScript"><!--
document.lomake.q.focus();
//--></script>
Tarkistukset

Lomakkeelta syötetty data pitää aina tarkistaa palvelinskriptissä, ennen kuin se rupeaa sitä muutoin käsittelemään - ellei sitten koko lomaketta ole tarkoitettukin vain selaimessa toimivaksi, kaikin siitä johtuvin rajoituksin.

Mutta etukäteistarkistus voi olla käyttäjälle mukava. On parempi saada mahdollisimman nopeasti "valitus" siitä, että jokin kirjoitettu data oli väärässä muodossa. Tällöin tietojen korjaaminen käy yleensä helpommin.

Ennakkotarkistus voidaan tehdä siten, että form-tägiin liitetään onsubmit-määrite, jonka arvona on JavaScript-funktion kutsu. Kyseinen funktio kirjoitetaan siten, että se palauttaa arvon true (tosi), jos datat ovat hyväksyttäviä, ja arvon false (epätosi) muutoin. Jos lomake täytetään siten, että JavaScript on toiminnassa, niin arvo false aiheuttaa sen, että lomakkeen lähetystä ei tapahdukaan, vaan lomakkeen sisältävä sivu jää näkyviin. Jotta käyttäisi ymmärtäisi, mitä häneltä edellytetään, niin funktion on syytä antaa virheilmoitus tai -ilmoituksia esim. alert()-funktiolla.

Seuraava esimerkki käyttää erästä laajahkoa lomakkeentarkistuskirjastoa. Tarvittavat tarkistusrutiinit eivät olisi kovin vaikeita itse koodata, mutta ainakin harjoittelussa ja kokeiluissa on mukava käyttää valmiita rakennuspalikoita. (Vakavammissa jutuissa on syytä ainakin lukea niiden palikoiden koodi ja katsoa, että se tekee sen mitä todella halutaan, kaikissa tapauksissa!).

<script type="text/javascript"
 language="JavaScript"
 src="FormChek.js">
</script>
<script type="text/javascript"
 language="JavaScript"><!--
function valid(obj) {
  var status = true;
  if(!isAlphabetic(obj.nimi.value))
    { alert('virhe nimessä'); status = false; }
  if(!isInteger(obj.luku.value))
    { alert('virhe luvussa'); status = false; }
  return status; }
//--></script>
<form action=
"http://jkorpela.fi/cgi-bin/echo.cgi"
onsubmit="return valid(this)">
<p>Kirjoita nimi (vain kirjaimia A-Z, a-z):<br>
<input type="text" name="nimi"></p>
<p>Kirjoita kokonaisluku (vain numeroita 0-9):<br>
<input type="text" name="luku"></p>
<p><input type="submit" value="Lähetä"></p>
</form>

Kirjoita nimi (vain kirjaimia A-Z, a-z):

Kirjoita kokonaisluku (vain numeroita 0-9):

"Juoksevan summan" laskeminen

Oletetaanpa, että meillä on tilauslomake, jolta käyttäjä voi asetusnapeilla (checkboxes) valita erilaisista osista koostuvan tuotteen. Haluamme näyttää käyttäjälle "juoksevan summan" eli paljonko siihen mennessä valitut osat yhteensä maksavat. Tämän tulee toimia niin, että jos käyttäjä poistaa valinnan, summa vastaavasti laskee.

Tehty lomake on toteutettu seuraavasti:

Olisi myös mahdollista kirjoittaa sivu niin, että summan näyttävää tekstikenttää ei lainkaan näy silloin, kun JavaScript on disabloituna. Tämä hoituisi sillä, että kyseinen HTML-elementti (input type="text" -elementti) ei ole sivun kiinteä osa vaan JavaScript-koodi kirjoittaa sen (document.write-funktiolla).

Esimerkki on toki kovin alkeellinen, mutta havainnollistanee erästä ideaa. Sen sujuvaksi soveltamiseksi isompiin lomakkeisiin kannattaa tutustua mm. JavaScript-fakin kohtaan How do I display the value of each text field using a for loop?.

JavaScriptin sudenkuoppia

JavaScript muistuttaa joissakin omituisissa yksityiskohdissa Perl-kieltä ja Java-kieltä sekä eräitä muita kieliä. Taustalla on yhteinen pohja, nimittäin C-kieli, joka suunniteltiin alkujaan ammattilaisten työkaluksi mutta joka pääsi karkuun laboratoriosta.

Näitä omituisuuksia, joihin lähes jokainen kieltä opiskeleva kompastelee ja jotka vaivaavat kokeneempiakin, ovat mm. seuraavat:

Lisäksi JavaScriptissä on sille ominaisia sudenkuoppia. Niistä mainittakoon, että 2+2=22, mikä johtuu siitä, että JavaScriptissä "+" on ensisijaisesti merkkijono-operaattori. (Muuttujien a ja b summa saadaan esim. lausekkeella (a-0)+(b-0).)

Lisätietoja JavaScriptistä

Suomenkielistä JavaScript-aineistoa:

Erityisen suositeltava jokaiselle JavaScriptiä kirjoittavalle on kokeneen asiantuntijan Martin Webbin ohje JavaScript Guidelines and Best Practice. Martin ylläpitää myös laajaa fakkia: JavaScript FAQ Knowledge Base. Se on mm. laajuutensa takia osittain sekava: vaikka se on jaettu aihepiireittäisiin osiin, yhdessä osassa voi olla kymmenien kysymysten lista, eivätkä kaikki vastaukset ole tasoltaan yhtä hyviä. Aloittelijalle onkin avuksi erityisesti lista vastauksia kaikkein useimmin esitettyihin kysymyksiin: JavaScript Very Frequently Asked Questions. Lisäksi sivuilla on käytännöllinen hakulomake (joka itse asiassa hakee koko irt.orgista).

Tässä on kyseisen lomakkeen kopio hiukan muokattuna. Jos annat useita avainsanoja, haku antaa sivut, jotka sisältävät kaikki antamasi sanat.
Avainsana(t):

Fakit eivät suinkaan ole erehtymättömiä eikä niitä pidä lukea kritiikittömästi. Esim. edellä mainittu VFAQ sisältää salasanasuojausta koskevaan kysymykseen vastauksen, joka on varsin harhaanjohtava. Ks. sfnet.viestinta.www VUKK:n vastausta salasanakysymykseen.

Kirjoitukseni JavaScript and HTML: possibilities and caveats esittää eräitä esimerkkejä (mm. uuden ikkunan avaaminen, josta myös Jouni Heikniemi on kirjoittanut jutun: Uudet ikkunat web-sivuilla - puolesta ja vastaan) ja yleisiä periaatteita JavaScriptin käytöstä etenkin lomakkeiden yhteydessä.

Netscapen JavaScript-dokumentaatio sisältää oppikirjatyyppisen JavaScript Guiden sekä käsikirjan JavaScript Reference (jossa on erittäin käyttökelpoinen hakemisto). Niistä on myös versiot, jotka voit ladata omaan koneeseesi. Ne soveltuvat JavaScriptin järjestelmälliseen opiskeluun, kunhan muistat edellä mainituissa muissa dokumenteissa olevat varoitukset. Internet Explorer tukee JScriptiä, joka on Microsoftin versio JavaScriptistä; siitä on laaja dokumentaatio Microsoftin sivuilla, mutta lisäksi tarvitaan Web Workshop -aineisto, jossa kuvataan eri objektit ja menetelmät, joita JScriptillä voi käsitellä. Etenkin etsittäessä vastineita Netscapen JavaScriptin rakenteille on kyseisen aineiston hakemisto erittäin hyödyllinen. ECMA on standardoinut osan JavaScriptistä (kielen eräät perusrakenteet) nimellä ECMAScript.

HTTP, välimuistit (cachet), evästeet (cookies)

Sisällys

HTTP

HTTP on Webin keskeinen protokolla, joka määrittelee, miten Web-selain ja Web-palvelin viestivät keskenään. Ilman sellaista sopimusta tai määrittelyä ei Webiä voisi olla.

Yleensä tavallisen sivuntekijän, sivujen lukijoista puhumattakaan, ei tarvitse tietää HTTP:stä. Eräät perusasiat on kuitenkin hyvä tuntea, jotta voi esimerkiksi hahmottaa, mitä tarkoittaa vastaus "se on tehtävä HTTP:n tasolla, ei HTML:ssä". HTTP:n tasolla tekeminen tarkoittaa käytännössä usein vain sitä, että palvelimessa muutetaan jotakin, esimerkiksi lisätään palvelimeen sopiva tiedosto, joka ohjaa sitä, miten palvelin toimii lähettäessään sivuja. Tässä mielessä HTTP:n tasolla tehtäviä asioita ovat mm.

Vaikka HTTP johtuu sanoista HyperText Transfer Protocol, niin se ei suinkaan rajoitu hypertekstidokumenttien (HTML-dokumenttien) kuljettamiseen. Päinvastoin se on yleinen protokolla kaikenlaisen datan kuljettamiseen, ja dataa lähettäessään palvelin erikseen kertoo, mitä tyyppiä data on (esim. Content-Type:text/html kertoo, että kyseessä on HTML-dokumentti, Content-Type:image/gif puolestaan että kyseessä on GIF-muotoinen kuvadata).

Otetaanpa mielivaltainen esimerkki: Käyttäjä haluaa nähdä sivun, jonka osoite (URL) on
http://www.useit.com/alertbox/20000123.html
No, hänpä kirjoittaa tuon osoitteen selaimensa Address- tai Location-kenttään tai muulla tavoin antaa osoitteen suoraan selaimelle. Selain ensinnäkin tunnistaa alkuosasta http://, että kyse on jostakin, joka pitää hakea nimenomaan HTTP-protokollalla. Sitten selain erottaa URLista palvelinosan, tässä tapauksessa www.useit.com. Tälle palvelimelle - joka on Internetissä oleva tietokone, johon voidaan viitata tuollaisella nimellä - selain sitten lähettää määrätyllä tavalla pyynnön (HTTP request), joka olennaisesti sanoo "annapa /alertbox/20000123.html". Tähän pyyntöön siis tulee URLin loppuosa. Palvelin sitten jollakin tapaa käsittelee pyynnön, tavallisesti muuntamalla URLin loppuosan tiedostonnimeksi omassa tiedostojärjestelmässään, joidenkin palvelinkohtaisten sääntöjen mukaan, ja sitten lähettää tiedoston sisällön. Sitä ennen se kuitenkin lähettää HTTP-otsakkeita, jotka kertovat, mitä on tulossa, ja vielä niitäkin ennen koodin, joka kertoo, että pyyntöön on suostuttu.

Monimutkaisemmissa tapauksissa, esim. kun URL sisältää ns. kyselyosan, joka alkaa ?:llä, tilanne on hiukan mutkikkaampi.

Web-palvelimen selaimelle lähettämien vastausten muoto on yleisen Internet-viestien muodon (RFC 822) sovellus. Alussa on otsakkeita (headers), sitten tulee varsinainen viesti. Otsakkeet antavat tietoa dokumentista, palvelimesta, lähetysajankohdasta yms. Esimerkki palvelimen vastauksesta siten, että itse datasta, tässä tapauksessa HTML-dokumentista, on vain aivan alkuosa otettu tähän mukaan:

HTTP/1.0 200 OK
Date: Wed, 29 Mar 2000 10:06:29 GMT
Server: BESTWWWD/2.4
MIME-version: 1.0
Content-Type: text/html
Content-Length: 7871
Last-modified: Mon, 07 Feb 2000 05:06:01 GMT
Accept-Ranges: bytes

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
"http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
<TITLE>Saying No: How to Handle Missing Features (Alertbox Jan. 2000)</TITLE>

Tätä sitten selain rupeaa käsittelemään. Erityisesti Content-Type-kenttä kertoo, mitä tyyppiä data on Koska on HTML-dokumentista kyse (mediatyyppi text/html, selain todennäköisesti näyttää sen sisällön ruudulle muotoiltuna. Jos dokumentissa on esimerkiksi img-elementti ja jos selain on konfiguroitu lataamaan kuvat automaattisesti (oletustilanne useimmissa graafisissa selaimissa), se käsittelee src-määritteen arvona olevan URLin siihen tapaan, kuin yllä on kuvattu. Se siis lähettää uuden HTTP-pyynnön ja saa vastaukseksi kuvadataa, ja sitten esittää kuvan ruudulla, osana dokumenttia.

Jos haluat katsoa, mitä otsakkeita palvelin lähettää jonkin sivun (esim. sinun sivusi) osalta, voit käyttää Rex Swainin HTTP Header Viewer -palvelua (tai Delorien HTTP header viewer -palvelua).

Laajempia johdantoja:

Lisätietoja on laajasti W3C:n HTTP-sivustossa. Siellä on mm. HTTP-protokollan nykyversion HTTP 1.1:n määrittely hypertekstinä.

Välimuistit (cachet)

Edellä kuvattua selaimen ja palvelimen välistä viestintää mutkistaa - ja Webin toimintaa tehostaa - datan välivarastointi. Jos esimerkiksi joku vierailee sivullasi, jolla on muutamia kuvia, ja sitten siirtyy toiselle sivullesi, jolla on osittain samoja kuvia, niin selain ei yleensä lähetä uutta HTTP-pyyntöä niistä kuvista, jotka se on jo saanut. Selain pitää kirjaa osoitteista (URLeista), joita vastaava data sillä on "tarpeeksi tuoreena", ja kohdatessaan uuden osoitteen katsoo ensimmäiseksi, onko se listassa (tai oikeammin tietokannassa). Selain voi pitää sivujen osoitteita ja sisältöjä koneen keskusmuistissa tai levyllä; jälkimmäisessä tapauksessa ne säilyvät, vaikka kone sammutetaan. Kummassakin tapauksessa voidaan puhua välimuistista (cache, lausutaan "käsh").

Lisäksi selain on saatettu konfiguroida käyttämään jotakin välipalvelinta (välityspalvelin, proxy). Tällöin selain uuden URLin kohdatessaan katsoo ensin, onko sillä itsellään vastaavaa dataa tallessa, ja jos ei ole, niin se lähettää pyynnön sivusta (koko URLin ilmoittaen) välipalvelimelle. Tämä puolestaan joko ottaa itsellään tallessa olevan datan, johon annettu osoite viittaa, taikka käy hakemassa sen palvelimelta, johon URL viittaa. Ideana on, että yksi palvelin voi toimia laajaa käyttäjäjoukkoa palvelevana resurssina. Jos esimerkiksi jossakin suomalaisessa yliopistossa monet viittaavat usein samalle sivulle, joka sijaitsee Yhdysvalloissa, niin asioita tehostaa huomattavasti se, että sivu tallentuu yliopiston välipalvelimeen, joka jakaa sitä halukkaille. Käyttäjä ei normaalisti huomaa mitään - paitsi että asiat voivat sujua huomattavasti lennokkaammin kuin ne sujuisivat, jos joka ikinen sivuun kohdistuva pyyntö aiheuttaisi dataliikennettä Atlantin yli.

Tähän toki liittyy ongelmia. Sivu, joka tulee selaimen tai välipalvelimen välimuistista, voi olla vanhentunut. On olemassa suhteellisen monimutkaisia järjestelyjä, joilla tämä pyritään estämään. Joissakin erityistilanteissa voi olla tarpeen, että sivuntekijä tekee toimenpiteitä, joilla vaikutetaan dokumentin vanhenemisaikaan tai jopa yritetään estää koko välimuistiin tallentuminen (caching). Perustiedot aiheesta kertoo Caching Tutorial for Web Authors and Webmasters. Sen arvioimisessa, miten sivu käyttäytyy välimuistien kannalta, auttaa sivulla Cacheability Engine Query oleva palvelu.

Mainittakoon kuitenkin se aika monen sivuntekijän kokema ongelma, että hänen muuttamansa sivu ei näykään hänen selaimessaan muuttuneena. Tällöin on lähes aina kyse selaimen toiminnasta, ja korjauksena on yleensä selaimen välimuistien tyhjentäminen, jos selaimen Reload- tai Refresh-nappi ei auta. Joskus kyllä selain saattaa hyvinkin sitkeästi näyttää vanhan version, jopa niin, että selainohjelma pitää sammuttaa ja käynnistää uudestaan, jotta tilanne korjaantuu.

Evästeet (cookies)

Cookie tarkoittaa dataa, jonka palvelin lähettää selaimelle pyytäen tätä tallentamaan sen (levylle) ja jota palvelin voi pyytää myöhemmin takaisin. Yleensä kyse on pienestä datamäärästä, esim. lyhyestä tekstirivistä. Cookie-sana tässä yhteydessä ei ole onnistunut eikä sille ole hyvää eikä vakiintunutta suomennosta; usein puhutaan pipareista tai kekseistä, mutta asiallisempi nimitys on eväste tai kuitti.

Ajatuksena on helpottaa käyttöä esimerkiksi tilanteessa, jossa käyttäjä on antanut informaatiota kiinnostuksensa kohteista ja sitten myöhemmin palaa samoille sivuille. Evästeen avulla palvelin voi automaattisesti, käyttäjää vaivaamatta, saada selaimelta informaation, jonka käyttäjä oli aiemmin antanut.

EU:n sähköisen viestinnän tietosuojadirektiivi (2002/58/EY) vaatii, että evästeitä käyttävässä sivustossa on ilmoitettu evästeiden käytöstä ja kerrottu, mihin niitä käytetään.

Evästeet mainitaan tässä, koska nekin välittyvät HTTP-protokollan kautta. Asiaan ei enempää paneuduta tässä oppaassa, mutta lisätietoja löytyy mm. seuraavista lähteistä:

Java-sovelmat ja Flash-tekniikka

Java

Java on monipuolinen ohjelmointikieli, jolla voidaan muun muassa toteuttaa Web-sivuihin liitettäviä ohjelmia, joita sanotaan sovelmiksi (applet). Niillä voidaan periaatteessa tehdä hyvin hienoja ja havainnollisia, "eläviä" ja vuorovaikutteisia esityksiä.

Java on aivan eri kieli kuin JavaScript, joskin joitakin samanlaisia piirteitä niissä on. Nimien samankaltaisuus on ilmeisesti tarkoituksellisen hämäävää.

Sovelma kirjoitetaan Java-kielellä tekstitiedostoon. Se käännetään sopivalla ohjelmalla, Java-kääntäjällä, jolloin saadaan ns. luokkatiedosto. Sovelma liitetään Web-sivuun kirjoittamalla HTML-dokumenttiin applet-elementti, joka viittaa sovelmaa vastaavaan luokkatiedostoon ja voi sisältää myös sovelmalle annettavia syöttötietoja, parametreja.

Selain voi toteuttaa applet-elementin varaamalla selaimen ikkunasta osan sovelman "suoritusalustaksi" ja suorittamalla sovelman. Täten siis selain toteuttaa, jos toteuttaa, Java-sovelman, ilman, että sillä on vuorovaikutusta palvelimen kanssa sen jälkeen, kun selain on saanut sovelman koodin palvelimelta. Koneeseen ladattua sovelmaa voidaan tämän takia käyttää myös ilman Internet-yhteyttä ("offline").

Kaikki selaimet eivät tue Javaa. Lisäksi niistä, jotka tukevat, voidaan tuki disabloida. Kummassakin tapauksessa selain esittää, tai sen ainakin tulisi esittää, applet-elementin sisältö, jollaiseksi sivuntekijä siis voi kirjoittaa esimerkiksi staattisen kuvallisen tai sanallisen selityksen siitä aiheesta, jonka sovelma pyrkii esittämään havainnollisemmin.

Arto Wikla on kirjoittanut laajahkon esityksen Ohjelmoinnin perusteita Java-kielellä, joka sisältää myös useita esimerkkejä, yksinkertaisimmista kokeiluista alkaen. Ks. myös Lasse Lehtimäen esitystä Yleiskatsaus Java-kieleen osa Lappeenrannan TKK:n kurssilla Internet-ohjelmointi esitettyä aineistoa. Pitemmälle ehtineille voi sopia TY:n Ohjelmointi II (Java-kielellä) kurssin aineisto.

Pankaj Kamthan on koonnut laajahkon kokoelman opetuskäyttöön vakavassa mielessä tehtyjä sovelmia: Java Applets in Education.

Flash

Yhtenä vaihtoehtona Javan käytölle on Macromedian Flash-tekniikka. Perusidea on sama siinä mielessä, että HTML-dokumenttiin "upotetaan" toiminnallisesti erillinen osa. Flashin yhteydessä käytetään kuitenkin object-elementtiä (jota voisi kyllä periaatteessa käyttää myös Java-sovelman upottamiseen) tai (HTML-spesifikaatioihin kuulumatonta) embed-elementtiä. Flashin yhteydessä käytettävä dataformaatti on Shockwave Flash (SWF).

Käytettävyystutkija Jakob Nielsen on arvioinut, että Flash-tekniikka huonontaa sivujen käytettävyyttä, ja esittää kolme perustelua: se houkuttelee suunnittelemaan sivut käytettävyyden kannalta väärin; se rikkoo tavan, jolla vuorovaikutuksen on tarkoitus toimia Webissä; ja sen tekeminen vaatii paljon voimavaroja, joille olisi parempaakin käyttöä (Flash: 99% Bad).

Vaikka suurin osa selaimista jo tukeekin Flashiä, on järkevää tarjota sille toimiva vaihtoehto. Sovellettaessa terveitä suunnitteluperiaatteita tehdään ensin yksinkertainen versio, joka "toimii kuin junan vessa", ja sitten ruvetaan harkitsemaan laajennuksia. Esimerkiksi jos jonkin tekstikappaleen tai kuvan sanoma halutaan esittää Flashillä elävämmin, niin tehdään sitten Flash-vaihtoehto ja kirjoitetaan kappaleen, kuvan tms. ympärille kirjoitetaan sopiva object-elementti. Näin tehden sivu saadaan nopeasti toimivaksi ja se toimii sen yksinkertaisemman vaihtoehdon varassa silloinkin, kun selain ei tue Flashiä tai tuki on siitä disabloitu esim. tehokkuussyistä.

Hyvä johdatus Flashin käyttöön on Kate Levyn Working With Flash.

Suomeksi Flashistä ei ole vielä kirjoitettu paljoakaan. Seuraavassa muutamia suomenkielisiä Web-sivuja aiheesta:

Kirjallisuudesta mainittakoon Docendon julkaisema suomenkielinen Flash MX Toolkit.

Äänet, videot, ...

Tämä opas käsittelee ääniä, videoita ja muuta "hienoa" asiaa lähinnä vain kahdelta kannalta: Esitän yleisiä varoituksia siitä, miksi niitä ei pidä upottaa sivulle vaan tarjota valittavissa olevina vaihtoehtoina linkkien kautta. Ja sitten esitän eräitä linkkejä aineistoihin, joissa näitä asioita käsitellään teknisesti ja muutoinkin.

Yleisenä varoituksena on syytä mainita, että äänitteet, videot ym. ovat tekijänoikeuden alaisia. On laitonta esimerkiksi muuntaa äänite tietokoneella luettavaan muotoon ja panna se omalle Web-sivulleen, ellei ole saatu äänitteen tuottajan lupaa ja muiden mahdollisten oikeudenomistajien lupaa. Ks. tekijänoikeusfakin kohtaa Mitens midit?

Linkitä, älä upota!

Kuvia käsittelevässä osuudessa selostettiin, miten kuvan voi upottaa (engl. embed) sivulle tai siihen voi viitata linkillä. Sama koskee ääniä ja videoita, mutta niiden osalta linkittäminen on lähes aina parempi vaihtoehto kuin upottaminen, koska

Paul Rundle, Pankaj Kamthan ja Martin Webb ovat kirjoittaneet erinomaisen esityksen Web Design Hints and Tips, joka käsittelee erilaisten multimediapiirteiden ja muiden hienouksien fiksua lisäämistä sivuille. Sen kohdassa Sound he kuvaavat havainnollisesti, miten vaarallista äänen upottaminen on:

Many computers have a CD-ROM built-in. People do use these to play music whilst they surf the Web. It can be most distracting when you are listening to Claude Debussy's Claire de Lune to suddenly have it overlaid with a poor Midi rendition of Meatloaf. Without any means to turn off Meatloaf, the easiest option is to press the back button, never to return.

Linkittämisen voi tehdä esimerkiksi niinkuin Warren Steel ehdottaa mainiossa ohjeessaan Hints for Web Authors:

You don't need to say "Click here for information on our graduate programs;" just insert the link into what you were saying: "Our excellent graduate programs ..." Links to large files or unusual formats should be so marked, perhaps in a parenthetical note: "Our stirring fight song (400k .au) ..."

Huomaa, että edellä olevassa lainauksessa viimeinen linkki, joka viittaa äänidataan, on tehty merkkauksen tasolla aivan samalla tavoin kuin muut linkit, jotka viittaavat HTML-dokumentteihin. Ero on paitsi itse datan formaatissa myös siinä, millaisen tiedon dataformaatista Web-palvelin lähettää. Ks. kirjoitustani Mediatyypit Internetissä, erityisesti Webissä.

Ääneen ja videoihin liittyviä linkkejä

WDG:n Web Authoring FAQ:n luku Other Media sisältää teknisiä perustietoja myös äänen ja videon liittämisestä Web-sivuihin.

Tampereen yliopiston Hypermedian perusteet -kurssin aineistoon sisältyy laajahko esitys sekä äänestä että videosta.

Internetixissä on laajahko kurssi äänenkäsittelystä, myös äänen lisäämisestä Web-sivulle.

Virtuaalitodellisuus: VRML

VRML (Virtual Reality Modeling Language) mahdollistaa kolmiulotteisten "virtuaalisten ympäristöjen" tekemisen niin, että käyttäjä voi selaimellaan "liikkua" ympäristössä, esimerkiksi katsellen rakennusta eri kulmilta. Käyttäjä tarvitsee erityisen VRML-selaimen tai tavalliseen Web-selaimeen liitettävän erillisen osan (plug-in). Tekniikka on monella tapaa raskas. Internetixissä on kurssi VRML-perusteet: VRML 1.0.

"Dynaaminen HTML"

Kreikan sana dýnamis (δύναμις) tarkoittaa voimaa, ja monissa yhteyksissä sen johdokset todella tarkoittavat fysikaalista voimaa tai siihen liittyviä suureita kuten tehoa. Niinpä tästä johtuvien mielleyhtymien takia dynaamisuus on tai sen oletetaan olevan myyvää. Erityisesti sitä usein käytetään ilmaisemaan muutosta tai muutettavuutta, kiinteän eli staattisen vastakohtana.

Mitä "DHTML" on olevinaan

Ilmaisua DHTML eli dHTML eli dynamic HTML kuvataan Web-konsortion DOM-sivulla näin (suomennos minun):

"Dynaaminen HTML" on termi, jota jotkin ohjelmistovalmistajat käyttävät kuvaamaan HTML:n, tyylisäännöstöjen ja skriptien yhdistelmää, joka mahdollistaa dokumenttien elävöittämisen.

Tässä olen suomentanut epämääräisen sanan animate yhtä (?) epämääräiseksi elävöittämiseksi. Se tarkoittaa muun muassa sitä, että dokumentin ulkoasu voi muuttua; esimerkiksi tekstin väri voi muuttua, kun kursori viedään sen päälle taikka painikkeen klikkaaminen voi vaihtaa koko sivun taustavärin.

"Dynaaminen HTML" = HTML + tyylisäännöstöt + JavaScript (tai muu selainskriptikieli) + sekalaisia tapoja yhdistellä niitä. Kyse ei siis ole mistään HTML-kielen laajennuksesta vaan eri tekniikoiden yhdistelmästä.

Laajahkon johdannon "dynaamiseen HTML:ään" tarjoaa Davud Gardnerin Beginner's Guide to DHTML. Sitä ja muuta vastaavaa aineistoa lukiessa kannattaa muistaa, että kilpailevista lähestymistavoista Netscapen ns. tasot (layers) hävisivät Microsoftin lähestymistavalle, jota edellä mainittu Web-konsortion määrittelemä DOM (dokumenttioliomalli, Document Object Model) lähinnä vastaa. Täten kyseinen Netscapen tekniikka kannattaa käytännössä unohtaa. (Jos kuitenkin haluat siihen vielä perehtyä, niin hyvän johdatuksen tarjoaa Ryan Detertin Man-Handling Events #1.) Samalla on hyvä muistaa, että DOM-pohjaista toimintaa eivät vielä tue juuri muut selaimet kuin IE versiosta 4 alkaen. Itse DOM-määrittely on huomattavan teoreettinen ja yleisluonteinen, joten käytännössä on syytä käyttää tietolähteenä lähinnä IE:n dokumentaatiota ja toivoa, että se edes suunnilleen vastaa sitä, mitä tulevat selaimet tukevat DOMin puitteissa.

Sikäli kuin "dynaaminen HTML" sisältää mitään uutta osiinsa verrattuna, se on juuri edellä mainittu dokumenttioliomalli, joka määrittelee uusia liityntöjä osien välille. Erityisesti siinä on kyse siitä, miten JavaScriptissä (tms.) voidaan viitata toisaalta HTML-dokumentin eri osiin, toisaalta niihin liitettyihin tyylisäännöstöihin.

Esimerkki: pienennetyn tekstin "dynaaminen" suurentaminen

Tämä esimerkki toimii vain IE 4:ssä ja uudemmissa versioissa. Toisaalta tämä on suunniteltu niin, että toimimattomuus ei haittaa muissa selaimissa: sivu näkyy samalla tavalla kuin se näkyisi ilman tätä pikku lisäpiirrettä.

Usein juttuun halutaan liittää osuuksia, jotka ovat vähemmän tärkeitä kuin normaaliteksti. Painoteksteissä käytetään yleisesti hiukan pienempää kirjasinkokoa (ja pienempää rivinväliä). HTML:ssä voi menetellä samoin, eli käyttää small-elementtiä, koska rakenteisempaakaan menetelmää ei ole tarjolla. Mutta Web-sivuilla voimme joissakin tilanteissa saavuttaa jotain, mikä on paperilla mahdotonta: klikkaamalla pienennettyä tekstiä käyttäjä saa suurennettua sen normaalikokoiseksi. Pienennyksen tarkoitushan on toisaalta osoittaa teksti vähemmän tärkeäksi, toisaalta säästää hiukan tilaa; ja siksi pienuus muuttuu vain haitaksi siinä vaiheessa, kun käyttäjä päättää lukea sen!

Koon muuttaminen voidaan tehdä "dynaamisesti" siten, että kyseiseen small-elementtiin liitetään tapahtumamäärite (event attribute) seuraavasti: 

<small onclick="this.style.fontSize='1em'">

Tämä on "dynaamista HTML:ää" MicroSoftin malliin yksinkertaisimmillaan. Tavalliseen HTML-tägiin liitetään määrite, jonka arvona on JavaScript-koodi, joka muuttaa elementtiin liittyviä tyyliominaisuuksia. Käytännössä tämä merkitsee, että kun käyttäjä klikkaa hiirellä jonnekin kyseisen elementin alueelle (pienellä näkyvää tekstiä), se merkitsee onclick-tapahtumaa, jolloin selain suorittaa JavaScript-koodin this.style.fontSize='1em', joka puolestaan vastaa sitä, että tyylisäännöstössä asetettaisiin kyseiselle elementille font-size:1em.

Emme tässä puutu enempää "dynaamisen HTML:n" yksityiskohtiin, etenkään, kun ala on vakiintumaton ja sekava. Aihepiiriä voi opiskella mm. irt.orgin Dynamic HTML -sivuilta, aloittaen vaikkapa Martin Webbin jutusta What is So Dynamic About Dynamic HTML?. Aika näyttää, muodostuuko jonkinlainen yleisesti tuettu normi, jota edes Microsoftin ja Netscapen uudet selaimet tukisivat kohtuullisesti. Seuraavassa tarkastelemme sen sijaan eräitä yleisiä periaatteita kiinnittäen erityisesti huomiota siihen, että "dynaamisella HTML:llä" ei sotkettaisi toimivuutta tilanteissa, joissa "dynaamisuus" syystä tai toisesta puuttuu.

Esimerkkitapauksessamme mahdollisuus "suurentaa klikkaamalla" on aika hyödytön, ellei käyttäjä tiedä siitä! Luonnollinen ajatus on lisätä sivun alkuun tästä yleinen huomautus. Mutta tästä taas seuraa ongelma: huomautus näkyy niillekin, joille se on hyödytön, jopa vahingollinen, koska he turhautuvat ihmetellessään, miksei klikkaaminen vaikutakaan mitään. Ratkaisuna on kirjoittaa huomautusteksti "dynaamisesti" seuraavaan tapaan:

<script type="text/javascript"><!--
if(document.styleSheets)
  document.write('<p class="huom">Tällä sivulla on kappaleita, joiden teksti '+
  'on pienemmällä kirjasinlajilla kuin normaaliteksti. '+
  'Voit muuttaa ne normaalikokoon klikkaamalla tekstiä. '+
  'Klikkaamalla uudestaan saat sitten kirjasinkoon taas pieneksi.<\/p>');
//--></script>

Tällöin jos selain tukee JavaScriptiä ja tyylisäännöstöjä Microsoftin määrittelemällä tavalla ja jos kumpaakaan näistä ei ole disabloitu, niin selain suorittaa document.write-koodin, joka lisää dokumenttiin kyseessä olevan ohjeen kyseiseen kohtaan. Huom.: Sana styleSheets on kirjoitettava juuri noin! Aiheesta lisää: Michael Bednarekin Dynamic StyleSheets.

Oletetaanpa sitten, että haluaisimme tehdä klikkauksesta ns. togglen niin, että uusi klikkaus taas pienentää tekstin. Tämä voidaan tehdä ehkä yksinkertaisimmin siten, että JavaScript-koodi ensin testaa, onko kirjasinkoko normaali ja jos on, niin sitten pienentää sen. Tällöin on syytä myös "staattisessa" tyylisäännöstössä ensin asettaa small-elementin kirjasinkoko halutuksi, esim. small {font-size : 0.7em;}. Ja "toggleaminen" sujuisi näin: 

onclick="if(this.style.fontSize=='1em') this.style.fontSize='0.7em'
else this.style.fontSize='1em';"

Tässä määritteen arvo on jaettu kahdelle riville, mikä on periaatteessa sallittua mutta aiheuttaa ongelmia useille selaimille. Tästä ja muista syistä on parempi kirjoittaa JavaScript-funktio, joka hoitaa "toggleamisen". Silloin HTML-elementin määritteeseen riittää kirjoittaa funktion kutsu. Funktio voitaisiin kirjoittaa näin (huomaa tarkistus, joka huolehtii siitä, että selain ei turhaan yritä suorittaa koodia silloin, kun siitä ei olisi mitään hyötyä): 

<script type="text/javascript"><!--
function togglesize(elem) {
  if(document.styleSheets) {
    if(elem.style.fontSize=='1em') {
      elem.style.fontSize='0.7em'; }
    else {
      elem.style.fontSize='1em'; }}}
//--></script>

Tämän jälkeen voimme mihin tahansa small-elementtiin liittää kyseisen toiminnon näin:

<small onclick="togglesize(this)">

Ongelmaksi kylläkin jää se, että tulostettaessa sivu paperille kyseinen ohje voi tulla mukaan, jolloin seurauksena on hiukan naurettava vaikutelma. Tämä on IE 4+:ssa mahdollista estää käyttämällä tyylitiedostoa seuraavaan tapaan:

  1. muutetaan tekstin kirjoittavaa JavaScript-koodia niin, että p-elementti tulee sellaisen div-elementin sisään, jolla on määrite class=noprint
  2. kirjoitetaan CSS-tiedosto, nimeltään vaikkapa print.css, jonka sisältö koostuu rivistä .noprint { display : none; }
  3. lisätään dokumentin head-osaan <link rel="stylesheet" media="print" href="print.css">

Luokan nimi noprint on tietysti vapaasti valittavissa. Kohdassa 1 käytetty tekniikka on periaatteessa turhan mutkikas, sillä div-elementin käytön asemesta voitaisiin p-elementti voidaan määrätä kuulumaan useaan luokkaan kirjoittamalla class-määritteen arvoksi listan välilyönnillä toisistaan erotettuja luokannimiä (class="huom noprint"). Mutta selaimet eivät tue tätä vaan tyypillisesti jättävät koko class-määritteen huomiotta. Muutenkin tyylisäännöstöjä käytettäessä joudutaan selainten virheiden takia usein lisäilemään div-elementtejä epäloogisella tavalla.

Ks. erillistä pikku dokumenttia, jossa tätä tekniikkaa on sovellettu. Ja tekniikka siis toimii IE 4:ssä mutta ei näin toteutettuna aiheuta ongelmia silloin, kun se ei toimi.

Karttalinkit (imagemaps)

Sisällys

Mikä karttalinkki on ja mihin se sopii?

Kuvien yhteydessä mainittiin, että kuvakin voi olla linkki ja että normaalissa kuvalinkissä on samantekevää, mihin kohtaan käyttäjä napsauttaa. Tässä käsiteltävät karttalinkit ovat monipuolisempia: kuvasta voidaan tehdä sellainen, että sen eri kohtien napsauttamisella on erilaisia vaikutuksia.

Nimitys "karttalinkki" ei ole vakiintunut, vaan useimmiten käytetään suomessakin englannin sanaa "imagemap" (tai "image map"). Muualla käytettyjä suomennoksia ovat "sensitiivinen kartta", "kuvakartta", "aktiivinen kuva", "aktiivinen kartta" ym.. Nimitys "karttalinkki" yrittää, englannin sanan tavoin, tuoda esiin, että kyse on jostakin karttamaisesta, usein nimenomaan kartasta.

Se, mitä tapahtuu, kun karttalinkin kohtaa napsautetaan, riippuu siitä, miten karttalinkki on tehty. Yksinkertaisimmassa tapauksessa kuvan eri alueet ovat linkkejä eri sivuille. Virtual Finlandin Active Map of Finland on esimerkki tällaisesta: kartassa näkyviä paikkakuntia napsauttamalla pääsee niitä käsitteleville sivuille.

Mutta voidaan myös rakentaa esimerkiksi kartta, jonka mielivaltaisen kohdan napsauttaminen tuottaa uuden kartan, jossa kyseinen kohta on keskipisteenä ja joka on suuremmassa mittakaavassa kuin alkuperäinen kartta. Tämä on jo huomattavasti vaativampaa toteuttaa.

Karttojen käytössä on syytä ottaa huomioon, että kartat ovat yleensä tekijänoikeuden alaisia eli niiden käyttöön tarvitaan lupa kartan valmistajalta.

Vaihtoehto: erilliset kuvat linkkeinä

Karttalinkin kuvan ei tarvitse olla kartta, mutta hyötyä karttalinkeistä tavallisiin linkkeihin verrattuna saadaan yleensä vain silloin, kun kuva esittää jotain olennaisesti kaksiulotteista samassa mielessä kuin kartta on kaksiulotteinen. Kovin usein näkee kuitenkin karttalinkkejä, joissa vain on tekstiä kuvina.

Vaikka kyseessä olisi olennaisesti kuvallinen aineisto, jonka osien halutaan olevan linkkejä, ei siitä välttämättä kannata tehdä karttalinkkiä. Helpompi ja käytettävyydeltään parempi ratkaisu on yleensä tehdä kustakin kuvasta erillinen linkki seuraavaan tapaan:


Omena
Kiivi
Päärynä

Tässäkään tapauksessa ei aineisto ole sillä tavoin olennaisesti kaksiulotteinen, että karttalinkistä olisi erityistä etua erillisiin kuvalinkkeihin verrattuna. Vaikka kukin kuva on kaksiulotteinen, ne voidaan järjestää siististi riviin ja tämä on luultavasti parempikin kuin asetelmatyyppinen kuva. Tällöinhän saadaan kuvien alle siististi kuvatekstit.

Tässä tapauksessa kukin linkeistä on toteutettu tähän tapaan:
<a href="..."><img alt="" src="..."><br>Omena</a> Tällöin kuva ja teksti yhdessä muodostavat linkin, mistä on etua muun muassa silloin, kun käyttäjä siirtyy linkistä seuraavaan tab-näppäimellä. (Jos kuva ja teksti olisivat erillisiä linkkejä, olisi mukana turhia linkkejä, jotka vaativat lisänäppäilyä, kun mennään linkkikokoelman lävitse.) Tällöin on asianmukaista ilmoittaa kuvan tekstivaihtoehto tyhjäksi, alt="". Jos kuvatekstit halutaan jättää pois, on alt-teksteiksi kirjoitettava kuvan merkitystä vastaava teksti, esim. tässä alt="omena" jne.

Tyypit: selainpohjainen ja palvelinpohjainen

Selainpohjainen karttalinkki, client-side image map, on sellainen, että HTML-dokumentissa itsessään on tieto kuvan jakautumisesta eri alueisiin sekä siitä, mihin osoitteeseen kukin alue viittaa. Kun käyttäjä napsauttaa kuvan kohtaa, selain määrittää, mihin alueeseen osuttiin, ja sen jälkeen siirtyy vastaavaan osoitteeseen. Selain saattaa tässä yhteydessä näyttää kyseisen alueen ääriviivat ohuena katkoviivana.

Palvelinpohjainen karttalinkki, server-side image map, on sellainen, että HTML-dokumentissa on vain viittaus palvelimessa olevaan koodiin, palvelinskriptiin, joka käsittelee napsautuksen. Kun käyttäjä napsauttaa kuvan kohtaa, selain lähettää palvelinskriptille kyseisen kohdan tarkat x- ja y-koordinaatit. On sitten skriptin asia, miten se niitä käyttää ja mitä se muutoin tekee.

Selaimet tyypillisesti näyttävät tila- eli statusrivillään tietoa tilanteesta, kun käyttäjä liikuttaa kursoria karttalinkin alueella. Tilarivi on tavallisesti selaimen ikkunan alalaidassa, itse sivun alapuolella. Jos kyseessä on selainpohjainen karttalinkki, tilarivillä näkyy se osoite, johon se alue viittaa, missä kursori on. Jos taas kyseessä on palvelinpohjainen karttalinkki, tilarivillä näkyy palvelinskriptin osoite, kysymysmerkki ja sen pisteen koordinaatit, jossa kursori on, esim.
http://jkorpela.fi/cgi-bin/koord.cgi?42,10

Yleensä selainpohjainen karttalinkki on paljon parempi kuin palvelinpohjainen, jos valinnanvaraa on. Palvelinpohjaista kannattaa käyttää vain silloin, kun kyse on monimutkaisemmasta asiasta kuin siitä, että kuvan eri alueita vastaavat eri kohdeosoitteet.

Periaatteessa on mahdollista tehdä yhdistetty palvelin- ja selainpohjainen karttalinkki. Sellaisia suositeltiin Webin alkuaikoina, jolloin jotkin selaimet tukivat vain palvelinpohjaisia karttalinkkejä, jotka eivät vaadi selaimelta juuri mitään. Nykyisin tämä on tarpeetonta.

Selainpohjaisen karttalinkin tekeminen

Yleensä erityisohjelmilla

Selainpohjaisen karttalinkin tekemisessä kannattaa yleensä käyttää jotakin erityistä ohjelmaa, esimerkiksi ( Windows-ympäristössä) MapThis (maksuton) tai MapEdit (hinta 10 dollaria). Sellaista käytettäessä voidaan hankalin työ eli kuvan alueiden määrittely tehdä vuorovaikutteisesti, graafisesti, kuten piirto-ohjelmassa. Petrus Kaartinen on kirjoittanut suomenkielisen ohjeen MapThis-ohjelman käytöstä; ohje on osittain vanhentunut, mutta hyödyllinen.

Karttalinkkien HTML-merkkauksen idea on hyvä tuntea

Yksinkertaisessa tapauksessa, lähinnä kun alueet ovat vain suorakulmioita tai ympyröitä, voidaan tarvittava HTML-koodi kirjoittaa melko helposti "käsin". Tosin käytännössä tarvitaan yleensä jokin piirto-ohjelma, kuten Paint, jolla voi määrittää haluttujen kohtien x- ja y-koordinaatit.

Joka tapauksessa on hyvä tietää karttalinkkien HTML-merkkauksen perusteet, muun muassa siksi, että mainittuja työkaluohjelmia pitää hiukan auttaa tekemään asiat oikein. Niiden tuottamaan koodiin on usein syytä lisätä muutamia asioita.

Kuvaelementti (img) ja karttaelementti (map)

Selainpohjaisessa karttalinkissä käytettävä kuva liitetään HTML-dokumenttiin normaalilla img-elementillä, johon lisätään yksi määrite: usemap="#kartta". Tässä kartta on haluttu nimi, jonka avulla kuva liitetään määrättyyn map-elementtiin, nimittäin sellaiseen, jossa on määrite name="kartta".

Itse kuvan siis ilmoittaa img-elementti, kun taas kuvan alueet määrittelee map-elementti puhtaasti geometrisesti: suorakulmioina, ympyröinä ja monikulmioina koordinaattien avulla. Kukin alue ilmaistaan area-elementillä, ja niitä voi olla map-elementin sisällä miten monta tahansa. Alueiden ei tarvitse vastata mitään erityisiä kuvioita kuvan sisällä, mutta käytännössä ne tietysti yleensä vastaavat.

Voimme sijoittaa map-elementin melko vapaasti dokumenttiin, koska sillä ei ole välitöntä vaikutusta dokumentin näkyvään asuun. Loogisin paikka lienee juuri ennen img-elementtiä tai heti sen jälkeen.

Esimerkki

W3C W3C:n Suomen-toimisto Demo: Geometrinen arvoitus Tässä on alkeellinen esimerkki, jossa kuvakartta sisältää vain yhden neliön ja yhden ympyrän: 

<map name="geom">
<area shape="circle" coords="24,19,12" href="http://www.w3.org"
 alt="W3C" title="W3C">
<area shape="rect" coords="56,18,83,46" href="http://www.w3c.tut.fi"
 alt="W3C:n Suomen-toimisto" title="W3C/Suomi">
</map>
<img alt="Demo: Geometrinen arvoitus" src="geom.gif"
width="100" height="50" align="right" usemap="#geom">

Selaimet yleensä piirtävät tällöin koko kuvalle sinisen reunuksen samaan tapaan kuin kuvalle, joka on tavallinen linkki. Tämän voi estää img-elementin määritteellä border="0", mutta on hyvä huomata, että sininen reunus toimii vihjeenä siitä, että kyseessä on jotain linkintapaista.

Erilaisia alueita

Alueen kuvaamiseen käytettävän area-elementin perusrakenne on seuraava:

<area alt="vaihtoehto" href="osoite" shape="muoto" coords="koordinaatit">

Tässä määritteiden merkitykset ovat seuraavat:

Jos alueet menevät osittainkaan päällekkäin, niin ensimmäisenä määritelty alue on määräävä. Saattaa siis olla merkitsevää, missä järjestyksessä area-elementit ovat. Jos halutaan vaikkapa määritellä suorakulmio, jonka sisällä on ympyrä, niin että ympyrää vastaa jokin osoite ja sen ulkopuolella mutta suorakulmion sisällä olevaa osaa jokin toinen osoite, niin on kirjoitettava ensimmäiseksi ympyrää vastaava area-elementti.

Lisäksi voi olla mm. title-määrite, jonka arvon useat selaimet näyttävät eräänlaisena avustustekstinä, kun kursori viedään elementtiä vastaavalle alueelle.

Palvelinpohjaisen karttalinkin tekeminen

Kuten edellä mainittiin, palvelinpohjainen karttalinkki edellyttää palvelimessa toimivaa skriptiä, esimerkiksi CGI-skriptiä, joka ottaa vastaan koordinaatit ja tekee jotain mielekästä. Kyseinen skripti voi olla hyvinkin monimutkainen. HTML-dokumenttiin tarvittava rakenne sen sijaan on yksinkertainen:

Esimerkki:
<a href="http://jkorpela.fi/cgi-bin/koord.cgi"><img ismap src="circle.png" alt="[Ympyräkuvio testausta varten.]" title="" width="200" height="200" border="0"></a>

Toisin sanoen kirjoitetaan kuva, joka on linkki, ja lisukkeena vain on ismap-määrite. Tämä määrite aiheuttaa käytännössä sen, että linkkiä seurattaessa selain lisää href-määritteen arvon perään ns. kyselyosan, joka koostuu kysymysmerkistä ja valitun pisteen koordinaateista. Koordinaatit ovat suhteellisia, suhteessa kuvan vasempaan yläkulmaan siten, että x-koordinaatit kasvavat (nollasta lähtien) oikealle mentäessä ja y-koordinaatit alaspäin mentäessä.

[Ympyräkuvio testausta varten.] Kuten edellä mainittiin, karttalinkkiin liittyvän palvelinskriptin tekeminen on usein vaativaa ja työlästä. Mutta seuraavassa on alkeellinen esimerkki Perlillä kirjoitetusta CGI-skriptistä, joka vain ilmoittaa valitun pisteen etäisyyden annetusta pisteestä. Tätä voi käyttää vaikkapa sen testaamiseen, miten hyvin käyttäjä osuu ympyrän keskipisteeseen, kun keskipistettä ei ole merkitty. (Jos tällaista haluttaisiin oikeasti testata, pitäisi estää se edellä mainittu selaimen piirre, että koordinaatit näkyvät selaimen tilarivillä.) Skripti on seuraava:

#!/usr/local/gnu/bin/perl
use CGI qw(:standard);
$title = 'Koordinaattitesti';
$origox = 100;
$origoy = 100;
$data =  $ENV{'QUERY_STRING'};
$data =~ m/(\d+),(\d+)/;
$xpoikk = abs($1 - $origox);
$ypoikk = abs($2 - $origoy);
print header, start_html(-title=>$title), h1($title),
  p("Osuit vaakasuunnassa $xpoikk pikselin päähän ja ",
    "pystysuunnassa $ypoikk pikselin päähän keskipisteestä."),
  end_html;

Lisätietoja karttalinkeistä

Kehykset (frames)

Sisällys

Mitä kehykset ovat

Kehykset ("freimit", engl. frames) ovat selainikkunan osia, jotka toimivat joissakin suhteissa itsenäisinä ali-ikkunoina. Kehyksen sisällä näkyy yleensä HTML-dokumentti, mutta siellä voi olla myös kuva, pelkkä tekstitiedosto tms. Kehyksen sisällys voi olla vieritettävissä (skrollattavissa) ylös ja alas, kenties myös vaakasuunnassa, kuten normaali dokumentti normaalissa selainikkunassa on. Kehykset ovat suorakulmaisia: ikkuna voidaan jakaa kahteen tai useampaan suorakulmaiseen osaan vaakasuunnassa tai pystysuunnassa. Näin saatuja osia voi vielä jakaa edelleen. Periaatteessa muunkinmuotoiset kehykset olisivat ajateltavissa, mutta ne eivät ole mahdollisia HTML:ssä. Yritykset jäljitellä niitä rakentamalla suorakulmaisista paloista monimutkainen kehikko johtavat juuri siihen mihin voi olettaakin niiden johtavan.

Sana "kehys", samoin kuin sana "frame", on aika epäonnistunut tässä yhteydessä. Parempi sana olisi ehkä "kehikko". Huomattakoon, että englannin sana "frame" tarkoittaa monenlaisia asioita ja esiintyy HTML:n yhteydessäkin myös aivan muussa merkityksessä kuin siinä, mistä on kyse. Taulukoiden yhteydessä voidaan käyttää frame-määritettä, joka (joissakin selaimissa) vaikuttaa reunaviivoihin taulukon ympärillä.

Kehysidea lienee peräisin siitä, että useissa ohjelmissa on mahdollista katsella isohkoa dokumenttia siten, että vasemmalla on kapeassa ali-ikkunassa sisällysluettelo ja oikealla isommassa ali-ikkunassa kulloinkin katsottavan osan sisältö. Seuraavassa on tästä esimerkkikuva, jossa Acrobat Readerillä luetaan sen omaa käyttöohjetta:

[Vasemmalla on ohjeen hakemisto, oikealla osa dokumentista. Ylhäällä on valikko ja painikkeita, ja alhaalla on tietoja suurennussuhteesta, sivunumerosta ym.]

Tällaisella esitystavalla on useita etuja. Käyttäjä voi siirtyä vasemmassa kehyksessä, "navigointikehyksessä" haluamaansa kohtaan ja valita klikkaamalla haluamansa kohdan. Jos hän huomaa, ettei se sisältänytkään sitä mitä hän etsi, hän voi saman tien valita toisen kohdan. Erityisesti hakuteostyyppisissä dokumenteissa tämä voi olla näppärää. Esimerkiksi Eesti keele käsiraamat on kehyksiä käyttävä HTML-muotoinen dokumentti, joka havainnollistaa tätä.

Ilmeisistä ongelmista mainittakoon, että jos navigointikehys on kapeahko, otsikot täytyy kirjoittaa hyvin lyhyiksi tai niistä näkyy vain vähän alkua. Tämä helposti pilaa koko idean. Tosin jos käyttäjä voi säätää koko ikkunan kokoa ja ali-ikkunoiden suhdetta, ongelma pienenee. Sen sijaan yritys helpottaa ongelmaa pienentämällä tekstin kokoa navigointikehyksessä helposti vain aiheuttaa lisäongelmia, etenkin jos pienentämisessä ei olla hyvin kohtuullisia. Mutta kehyksellisyys joka tapauksessa asettaa suurempia vähimmäisvaatimuksia selainikkunan leveydelle. Ja kuvaruututila vaakasuunnassa on resurssi, josta järkevässä käytössä on muutenkin pulaa, koska ruudulla on useita ikkunoita. Lisäksi navigointikehys on koko ajan läsnä, silloinkin kun ei kaivata. Miksiköhän TV-ruudussa ei näytetä ruudun vasemmassa reunassa koko ajan illan TV-ohjelmaa tai saman yhtiön muiden kanavien tarjontaa? Tai miksi kirjan joka sivulla ei ole sisällysluetteloa?

Alkeisesimerkki kehysten käytöstä

Edellä oli esimerkki yhdistyksen pääsivun rakenteesta. Oletetaanpa, että haluaisimme muodikkaasti tehdä sen kehyksillä. Jos on ensin suunniteltu ja toteutettu ja hiottu kehyksetön versio, kehyksellisen version tekeminen on suhteellisen helppoa, mutta vaatii oman työnsä. Tyypillisesti tällaisessa tapauksessa tehdään ns. navigointikehys ja sisältökehys sekä kehikko, jossa nämä ovat vasemmalla ja oikealla. Tätä varten tarvitaan kolme erillistä HTML-dokumenttia.

Kehikko (frameset) voisi olla seuraavanlainen: 

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN">
<html>
<head>
<title>Mahdollisimman paljon yhteistä hyvää kaikille ry.</title>
<link rel="stylesheet" href="util.css">
</head>
<frameset cols="30%,70%">
 <frame name="valikko" src="valikko.html" title="päävalikko">
 <frame name="sisalto" src="etusivu.html" title="sisältökehys">
<noframes>
<body>
<h1>Mahdollisimman paljon yhteistä hyvää kaikille ry.</h1>

<p><a href="etusivu.html">Yleisesittely</a></p>

<h2>Toimintaa</h2>
<ul>
<li> <strong><a href="kal.html">Tapahtumia</a></strong> </li>
<li> <a href="kannat.html">Kannanottoja</a> </li>
<li> <cite><a href="kasik/">Käsikirja</a></cite> </li>
<li> <a href="liitt.html">Liittyminen</a> </li>
<li> <a href="yht.html">Yhteystiedot</a> </li>
</ul>

<h2>Taustaa</h2>
<ul>
<li> <a href="saannot.html">Säännöt</a> </li>
<li> <a href="suunn.html">Toimintasuunnitelma</a> </li>
<li> <a href="kert/">Toimintakertomukset</a> </li>
<li> <a href="ptk/">Pöytäkirjat</a> </li>
<li> <a href="ark.html">Arkisto</a> </li>
</ul>

</body>
</noframes>
</frameset>
</html>

Tässä noframes-osa sisältää kehyksettömän vaihtoehdon eli sen, minkä selain näyttää, jos se ei tue kehyksiä tai se on asetettu näyttämään kehyksetön vaihtoehto. Sitä edeltää kehysvaihtoehto, joka koostuu yhdestä frameset-elementistä. Kyseisessä elementissä

Huomaa, että "pakollisiin kuvioihin" kuuluva dokumenttityypin määrittelyn (DOCTYPE) on erilainen kuin normaaleissa dokumenteissa. Tämä koskee kehyksiä käytettäessä vain kehikkoa, ei niitä dokumentteja, jotka halutaan näyttää eri kehyksissä (paitsi siinä tapauksessa, että ne itsessään ovat kehikoita). Kysehän on siitä, että Frameset-määrittely sallii ja vaatii, että dokumentissa on frameset-elementti, joka muutoin ei ole sallittu.

Valikkokehys sisältäisi olennaisesti saman kuin kehikon noframes-osa. Tämä johtuu siitä, että tämäntapaisessa tyypillisessä kehysten käytössä kehyksettömäksi vaihtoehdoksi sopii hypertekstisisällysluettelona toimiva linkkilista. Pieni mutta tärkeä ero on kuitenkin se, että valikkokehyksessä näytettävässä dokumentissa on alussa
<base target="sisalto">
Tämä aiheuttaa sen, että kun seurataan dokumentissa olevaa linkkiä, niin dokumentti johon se viittaa ei avaudu normaalilla tavalla koko selainikkunaan vaan siihen osaikkunaan, kehykseen, jolla on nimi sisalto. Linkin "kohde" tässä mielessä voidaan asettaa myös linkkikohtaisesti target-määritteellä, mutta base-elementti on usein kätevä silloin, kun halutaan muuttaa oletusarvoa.

Sisältökehyksen sisällön on tarkoitus muuttua, kun käyttäjä "liikkuu" sivuston sisällä. Kehikkosivu määrää vain sisältökehyksen alkusisällön ilmoittamalla sen sivun, joka aluksi latautuu sisältökehykseen. Tässä tapauksessa kyseinen sivu sisältää olennaisesti saman yleisesittelyn kuin sivuston alkuperäisen version pääsivu (mutta ilman linkkilistaa), jonka on tarkoitus näkyä toisessa kehyksessä.

Näin saatavan kokonaisuuden, yhdistyksen sivuston kehyksiä käyttävän version osoite (URL) on sen kehikkosivun osoite. Tästä aiheutuvia ongelmia tarkastellaan jäljempänä. Seuraavassa on esimerkki siitä, miltä kehikko näyttää alkutilassa eräässä katselutilanteessa:

[kuva]

Tämä on hyvin yksinkertainen rakennelma, jossa monet kehysten haitat eivät tule esiin, eivät myöskään mahdolliset hyödyt. Erityisesti mainittakoon, että tässä ei yritetään navigointikehyksessä korostaa (esim. eri värillä) sitä linkkiä, jota vastaava sivu näkyy sisältökehyksessä. Tämä vaatisi oman tekniikkansa, tavallisimmin JavaScriptiin perustuvan. Se, että kohtaa "Tapahtumia" on korostettu - koska sen oletetaan erityisesti kiinnostavan niitä, jotka vierailevat sivuilla usein - saattaa hämätä niitä, jotka ovat tottuneet siihen, että korostus tarkoittaa "olet nyt tässä"!

Näin tehty kehyksiä käyttävä versio toimii parhaimmillaan lähes yhtä hyvin kuin kehyksetön, jonkun mielestä ehkä joskus paremminkin. Valitettavasti kehyksiä käytetään yleensä ihan toisin, jopa niin, että ensin tehdään kehysversio - ja ehkä sen noframes-osassa luvataan tehdä kehyksetön versio. (Tai jopa jätetään noframes-osa tyhjäksi tai kirjoitetaan sinne jotain päätöntä kuten väite siitä, että käyttäjän selain ei tue kehyksiä ja että hänen pitäisi hankkia IE 3. Sitä on surkuhupaisaa lukea selaimella, joka tukee kehyksiä ja jonka käyttäjä on asettanut näyttämään kehyksettömän vaihtoehdon.) Saatetaan jopa vedota siihen, että "pienelle joukolle käyttäjiä" ei ehditä tai viitsitä tehdä kehyksetöntä versiota. Tämä on aivan nurinkurista.

Kehyksiä käytettäessä kannattaa tehdä ensin kehyksetön versio. Ensinnäkin näin sivustosta saadaan nopeammin toimiva versio. Toiseksi se on jatkossakin jatkuvasti käytettävissä vaihtoehtona. Kolmanneksi kehyksetön versio on luonnollinen lähtökohta kehysversion tekemiselle. Neljänneksi saatetaan käytännössä havaita, että kehyksetön versio on ihan hyvä eikä kehyksellisen tekemisestä olisi mitään hyötyä.

Periaate kehyksettömän vaihtoehdon tekemisestä ensin on erikoistapaus lisäilevästä lähestymistavasta: tehdään ensin yksinkertainen rakenne, joka toimii, ja sitten sille vaihtoehdoksi jotain mutkikkaampaa ja ehkä hienompaa. Ks. kirjoitustani Augmentative authoring.

Miksi kehykset sopivat Webiin huonosti

Kehyksiin siis liittyy itse ideasta johtuviakin ongelmia. Mutta niiden aiheuttamat sotkut Web-sivuilla johtuvat kuitenkin pääosin seuraavista kahdesta syystä:

Kehysten käytöstä on muodostunut monille sivuntekijöille paradigma. Sana paradigma johtuu kreikan sanasta, joka tarkoittaa esimerkkiä, ja paradigman noudattaminen on esimerkin apinoimista. Ilmiö on sinänsä yleinen ja oppimiselle välttämätön, mutta ongelmia syntyy, kun kehysideaa ruvetaan soveltamaan ollenkaan ajattelematta, milloin sen käytössä on edes vähän järkeä ja milloin ei. Valitettavan tyypillistä on, että sivustossa on muutama hassu sisältösivu ja "kokonaisuudesta" tehdään kehyksiä käyttävä rakenne. Ja kovin usein vielä aloitetaan siitä rakenteesta ja sen hienovirittelystä ja efekteistä, esim. navigointikehyksen linkki muuttaa väriä tai vinkaisee, kun sitä ollaan valitsemassa. Innostusta ei sitten enää oikein riitä sisällön aikaansaamiseen.

Ylinavigointi (navigoinnin ylikorostus) ei ilmeisestikään vastaa käyttäjien tottumuksia. Jakob Nielsen kirjoittaa:

Lähes seitsemän vuoden ajan tutkimukseni ovat osoittaneet saman käyttäjien käyttäytymistavan: käyttäjät katsovat suoraan sisältöä ja jättävät navigointialueet huomiotta silmäillessään uutta sivua. - -

Ei ole mitään syytä mainita sivuston kaikkia piirteitä kaikilla sivuilla. Valitse sen sijaan hyvin pieni määrä erittäin hyödyllisiä piirteitä ja rajoita kaikilla sivuilla olevat linkit ehkä viiteen tai kuuteen asiaan kuten hakutoimintoon: käyttäjät siirtyvät hakuihin, kun he ovat eksyksissä, etkä voi ennustaa, milloin niin saattaa tapahtua. Vähemmän on enemmän: jos jokaisella sivulla on pieni määrä vakiolinkkejä, on todennäköisempää, että käyttäjät tarvitessaan huomaavat ne. - -

Is Navigation Useful?, suom. JK

Lisäksi kehyksiä käytettäessä tehdään teknisiä virheitä, jotka vahvistavat edellä kuvattujen perusongelmien vaikutusta. Esimerkiksi jos navigointikehyksen kapeuden aiheuttamaa ongelmaa ei yritetä "ratkaista" käyttämällä paljain silmin näkymätöntä kirjasinkokoa niin sitten ehkä valitaan linkkien nimet niin lyhyiksi ja arvoituksellisiksi, ettei siinä ole tolkkua. (Tämän toki voi tehdä ilman kehyksiäkin, ks. esim. Peilaajan teilaaja, mutta kehykset vahvasti viettelevät siihen.) Ja kun alkuperäinen idea vahvasti perustuu siihen, että käyttäjä mieltää kehykset erillisiksi, niin tyypillisessä kehyshömpötyksessä nimenomaan pyritään estämään kehyksiä erottumasta toisistaan. (Yksi tavallisimpia kehysten tekoon liittyviä kysymyksiä on, miten saan pois rajaviivat kehysten väliltä, ei suinkaan fiksumpi kysymys, miten ne saisi paremmin erottuviksi.)

Kehyksetön vaihtoehto, ja miksi se on tärkeä

Kaikki selaimet eivät tue kehyksiä. Mutta tämä ei ole suinkaan keskeisin syy siihen, miksi kehyksiä käyttävälle sivustolle tulisi aina tarjoa myös kehyksetön vaihtoehto!

Mainittakoon, että tekstipäätteilläkin toimiva Lynx-selain tukee kehyksiä, joskin varsin eri tavalla kuin esim. IE ja Netscape. Kehikkosivun Lynx käsittelee näyttämällä kehysten nimet (sellaisina kuin ne on frame-elementtien name-määritteissä asetettu) linkkeinä, jotka viittaavat kehysten alkusisältöihin (jotka on src-määritteissä asetettu) ja lisäksi näyttämällä noframes-elementin sisällön. Tästä seuraa, että kehyssivustoa voi käyttää Lynxilläkin, kunhan sivuntekijä on kirjoittanut järkevän noframes-vaihtoehdon tai edes antanut kehyksille järkevät nimet, jotka kuvaavat niiden sisältöä ja tarkoitusta (eikä esim. vasen ja oikea taikka frame1 ja frame2).

Hakupalveluilla on erittäin suuri merkitys Webissä. Yksi osa niiden teknistä perustaa ovat ns. indeksointirobotit eli järjestelmät, jotka käyvät automaattisesti läpi Webiä seuraamalla sivuilla olevia linkkejä. Jos sellainen löytää kehikkosivun, jolla ei ole noframes-osaa, se ei ehkä löydä mitään seurattavaa. Tosin osa indeksointiroboteista katsoo myös frame-elementeissä olevia src-määritteitä, jotka jossain mielessä vastaavat linkkejä. Mutta läheskään kaikki eivät. Niinpä kehyssivustosta ei käytännössä ehkä indeksoidu mitään eli sillä olevaa aineistoa ei löydy hakupalvelimilla. Tätä voidaan yrittää ratkoa eri tavoin, esimerkiksi yrittämällä rekisteröidä kaikki alasivut erikseen hakujärjestelmiin, mutta tämä ei suinkaan aina toimi vaan voi johtaa jopa kielteisiin seurauksiin. Luonnollinen tapa on kirjoittaa noframes-osa, jossa on linkkejä, joiden kautta alasivut löytyvät.

Sen lisäksi, että kehikkodokumentissa on noframes-osa, voi olla järkevää tarjota linkki "kokonaan kehyksettömään" vaihtoehtoon. Syynä on se, että esimerkiksi Operan tai Lynxin käyttäjä voi kyllä valita noframes-vaihtoehdon mutta IE:n tai Netscapen käyttäjä ei. Esimerkissämme tämä vaihtoehto on tarjottu valikkokehyksen viimeisenä linkkinä seuraavasti:

<p><small>Tästä sivustosta on myös
<a href="index.html" target="_top"
>kehyksetön vaihtoehto</a>.</small></p>

Tässä "_top" on erityinen ennaltamääritelty (ise HTML-kielessä määritelty) arvo, joka tarkoittaa, että linkkiä seurattaessa dokumentti avautuu koko selainikkunan kokoisena, siis "murtautuu ulos kehyksistä".

Linkit kehyksissä

Tässä kohdassa käsittelemme, miten kehyksiä käyttävässä sivustossa viitataan linkeillä siitä ulospäin. Toisensuuntaista linkitystä käsitellään seuraavissa kohdissa (kahdelta kannalta: viittaaminen kehyksissä näytettäviksi tarkoitettuihin sivuihin ulkopuolelta ja viittaaminen koko kehikkoon).

Edellä mainittu target="_top" on yleisesti tarpeellinen, kun kehyksessä olevassa sivussa on linkki, joka viittaa sivustosta muualle. Muutoin käy niin, että seurattaessa vaikkapa Lafka Oy:n sivustossa olevaa linkkiä Höpsötysviraston sivulle sivu aukeaa kehyksessä ja ruudulla näkyy Lafka Oy:n navigointikehys yms. Jos Höpsötysviraston sivukin käyttää kehyksiä, tulos on erinomaisen sekava. Joka tapauksessa luvaton toisen sivuston sivujen "omiminen" omaan kehikkoon on asia, joka on kiistanalaisimpia kysymyksiä keskusteltaessa siitä, milloin linkittäminen on oikeudellisesti sallittua.

Kirjoittamisvaivaa voi säästää base-elementillä. Kun dokumentin otsikko-osaan (head-osaan) kirjoitetaan
<base target="_top">
niin se vastaa sitä, että jokaisessa linkissä olisi target="_top". Tästä seuraa, että jos linkin halutaankin avautuvan nimenomaan siihen kehykseen, jossa dokumentti on, on tällöin käytettävä linkissä määritettä
target="_self"

Miten kehys toimii "otettuna irti kehyksistään"?

Kehyksettömän vaihtoehdon tarjoaminenkaan ei poista sitä ongelmaa, että jos sivut on suunniteltu katsottaviksi nimenomaan kehyksissä, niistä on erittäin usein jätetty pois niiden asiayhteyttä koskevat tiedot. Toisin sanoen niistä on tehty irrallisia sivuja.

Otetaanpa esimerkki. Eräällä haulla löysin joukon sivuja, joista ensimmäinen alkaa näin:

KOPIRAITTI - TEKIJÄNOIKEUTTA SARJAKUVANA

Mitä yhteistä on tappajasammakoilla, taiteilijaurasta unelmoivilla flegmaattisilla teineillä ja identtisillä poliisikaksosilla? Vastaus: kaikki esittäytyvät Kopiraitti-tekijänoikeussarjakuvassa.

Mielenkiintoista, mutta mihin tämä liittyy? Itse tekstissä ei ole ensimmäistäkään linkkiä. Lukemalla jutun voi ehkä päätellä jotain asiayhteydestä. Mutta miksi sitä ei kerrota suoraan, normaaleilla tavoilla? Koska sivu on suunniteltu katsottavaksi kehyksissä, jolloin muut kehykset antavat kontekstitietoa siitä, missä mennään ja mitä aiheeseen liittyviä muita sivuja on. Mutta hakupalvelun antama linkki viittaa suoraan itse dokumenttiin.

Käytännössä kokenut käyttäjä saattaa osata hakea kontekstitietoa siten, että kokeilee, mille sivulle ehkä päästään poistamalla URLin lopusta merkkejä viimeiseen vinoviivaan asti ja ehkä vielä jatkamalla tällaista "peräytymistä". Mutta ei pidä luottaa siihen, että käyttäjä osaa tehdä niin. Ja tässä tapauksessa kun URLia http://www.kopiosto.fi/hallinto/Opettaja.html lyhennetään saadaan http://www.kopiosto.fi/hallinto/ joka kyllä ilmeisesti liittyy asiayhteyteen, mutta epäselväksi jää miten.

Aivan vastaava ongelma syntyy, jos joku tekee suoran linkin kyseiseen sivuun. Joku ehkä on sitä mieltä, ettei niin saa tehdä tai ei ole järkevää tehdä. Mutta sellainen on vastoin hypertekstin ja Webin perusideoita.

Esimerkkitapaus ei ole ihan niin mahdoton kuin edellä sanotun perusteella voisi luulla. Lopussa on sentään linkki Kopiosto ry:n pääsivulle. Eri asia sitten on, miten helposti sieltä löytää puheena olevan sivun ja siten sen tarkemman kontekstin. Mainittakoon vielä, että lopussa on myös näennäislinkki, jossa on teksti "takaisin". Kyseessä on järjetön viritys, joka tekee (jos tekee mitään) JavaScriptillä sen, minkä jokainen käyttäjä voi tehdä oman selaimensa tutulla Back- tai Takaisin-toiminnolla ja lisäksi se perusteellisesti harhauttaa sivulle eksyneen. Esimerkkitapauksessa se tietenkin vie takaisin sille sivulle, jolta oltiin tultu, eli hakupalvelun antamaan listaan, ei suinkaan Kopioston jollekin sivulle, jonka "alainen" tämä sivu on jossakin hierarkiassa!

Vaikka sivu onkin tarkoitettu katsottavaksi vain kehyksissä, sille on syytä kirjoittaa normaalit linkkeinä esitetyt tiedot asiayhteydestä, koska tosiasiassa sivu usein nähdään "kehyksistä irrotettuna".

Se, että kontekstitiedot näkyvät kahdesti - toisaalta navigointikehyksessä, toisaalta kehyksen sisällä näkyvällä sivulla esim. alussa tai lopussa - on paljon pienempi paha kuin kontekstittomuus. Sikäli kuin se on paha asia ollenkaan. Edellä tarkastellussa alkeisesimerkissä tehty kehyksiä käyttävä sivusto on sellainen, että kunkin alasivun alussa on yhdistyksen nimi, joka on linkki kehikkosivuun. Linkkiä seuraamalla voi siis kehyksiä käytettäessä päästä aloitustilaan, jossa näkyy yleisesittelysivu, ja kehyksettömässä tilassa kehikkosivun noframes-vaihtoehtoon. Tämä on helppoa tehdä:

<center><a href="kehikko.html"
title="Yhdistyksen esittelysivu">Mahdollisimman
paljon yhteistä hyvää kaikille ry.</a></center>

Kyseisen tekstin tilalla voisi myös olla logo (mieluiten tekstin kera, ellei logo ole hyvin yleisesti tunnettu ja siten ilman muuta tunnistettavissa). Otsikkoa siitä sen sijaan ei kannata tehdä, koska se ei loogisesti ole sivun otsikko vaan verrattavissa esim. kirjeen yläreunassa näkyvään lähettäjätietoon. - Pienen ongelman aiheuttaa se, että sisältökehyksen alkusivulle tällaista ei ole luonnollista tehdä, koska sillä yhdistyksen nimi on jo otsikkona. Sen tekeminen linkiksi olisi luultavasti hämäävää. Niinpä kyseiseen dokumenttiin olen kirjoittanut, uusnaivismin hengessä, pienellä präntätyn toteamuksen siitä, että käyttäjä on nyt sivuston alkusivulla. Jos hän olikin päätynyt lukemaan sivua "kehyksistä irrotettuna", tekstiin liittyvä linkki toivottavasti auttaa oikeille jäljille.

Kehysjoukon osoitteettomuus

Kun käyttäjä liikkuu kehyksiä käyttävässä sivustossa, niin selaimen näyttämä sivun osoite pysyy samana eli alkuperäisenä. Tämä johtuu kehysten yhdestä perusominaisuudesta: määrätyllä kehysten yhdistelmällä ei ole omaa osoitetta, jolla siis voisi viitata kehyskokonaisuuteen sellaisena, kuin se määrätilanteessa näkyy. Ei siis ole mahdollista kirjoittaa URLia, joka viittaisi kehikkoon (frameset-dokumenttiin) siten, että kussakin kehyksessä on määrätty sisältö. Joskus tämä esitetään ratkaisuna ongelmaan "miten estän käyttäjää näkemästä, millä sivulla hän on?"; en tiedä miten usein ratkaisu esitetään ironisessa mielessä. Joka tapauksessa ongelmia syntyy, kun käyttäjä ottaa sivun "kirjanmerkkeihinsä" tai ottaa URLin talteen tehdäkseen linkin siihen, kertoakseen siitä kavereille tms. - ja vasta myöhemmin huomaa, että URL toki viittaa kehikkoon sen alkutilassa, siis aivan eri asiaan kuin on tarkoitus.

Lyhyesti asia on esitetty WDG:n Web Authoring FAQ:ssa kohdassa 8.7 (suom. JK):

Miten ilmoitan erityisen kehysten yhdistelmän oletusdokumentin asemesta?

Tämä ei valitettavasti ole mahdollista. Kun kuljet sivustossa käyttäen kehyksiä, URL ei muutu, kun dokumentit eri kehyksissä vaihtuvat. Tämä merkitsee, ettei ole mitään tapaa osoittaa osoittaa sitä dokumenttien yhdistelmää, joka muodostaa kehikon nykyisen tilan.

Sivuntekijä voi tehdä useita kehikkodokumentteja, yhden kutakin kehyssisältöjen yhdistelmää varten, ja viitata niihin linkeillä. Näitä kehikkodokumentteja voi luoda automaattisesti, ehkä jopa "lennosta" CGI-ohjelmalla.

Havainnollinen esitys tämän tekniikan soveltamisesta on Slartin sivustossa Good and bad Frames!, luonnollisestikin osassa Create GOOD frames.

Ajatuksia kehysten mahdollisuuksista

Eräs mahdollinen hyötysovellus kehyksille olisi lainselitys, jossa yksi kehys näyttää lakitekstin, toinen kommentaarin ja kolmas oikeustapauksia. Tai ehkä neljäskin kehys voisi olla; siinä voisi näyttää lainkohdan virallisia perusteluja hallituksen esityksessä, jonka pohjalta laki on säädetty. Ideana tämä on kiehtova. Mutta siinä olisi melkoisesti työtä. Ja miten tähän voisi viitata? Jos tavoitteena olisi, että yhdellä osoitteella viitataan sellaiseen kehysten yhdistelmään, jossa on yhdessä kehyksessä lakipykälä, toisessa sen selitys jne., jouduttaisiin tekemisiin edellä kuvatun osoitteettomuusongelman kanssa. Kuten edellä selitettiin, ongelma on eräässä mielessä ratkaistavissa, mutta aika työläästi.

Hiukan sensuuntaista, jota edellä on hahmoteltua, on pienessä mittakaavassa tehty kokeilussani, joka on tekijänoikeusfakin kehyksellinen versio. Siinä tilanne on se, että varsinaisessa fakissa olevan pykäläviittauksen seuraaminen muuttaa lakitekstikehyksen sisältöä niin, että siinä näkyy kyseinen kohta laista. Sen sijaan sen kehyksen sisältö, jossa näkyy lain rakenne (sisällysluettelona), ei muutu. Tässä tapauksessa kysymykseen "miten muutan kahta kehystä samanaikaisesti" voisi mielekkäästi vastata myös JavaScript-ratkaisulla, koska toinen kehysten päivittämisestä (se, joka hoidettaisiin JavaScriptillä) olisi vain mukava lisäpiirre, ei olennainen osa sivuston toimivuutta. Ratkaisu olisi sellainen, että kukin pykäläviittaus, joka nyt on muotoa 

<a target=laki href="tekl.html#n">n §</a>)
muutettaisiin seuraavanlaiseksi: 
<a target=laki href="tekl.html#n" onclick=
"if(self!=top && parent.sis)parent.sis.location='tekl-sis.html#n'"
>n §</a>

Ehto self!=top && parent.sis huolehtii siitä, että jos sivua katsotaan muutoin kuin tarkoitetussa kehikossa, ei synny ongelmia siitä, että selain yrittäisi päivittää olematonta kehystä.

Kehyksiä voisi ajatella käytettäväksi myös alaviitteiden esittämiseen. Silloin ikkuna jakautuisi ylempään kehykseen, jossa on varsinainen juttu, ja pienempään kehykseen sen alla, jossa näkyvät alaviitteet. Ja ylemmässä kehyksessä oleva alaviitemerkintä olisi linkki, jonka seuraaminen muuttaisi alempaa kehystä niin, että siinä näkyy kyseisen alaviitteen teksti. Tämäntapainen kokeilu on kehysversio sivusta Passiivin käytöstä. Kyseisessä kokeilussa alaviitteillä ei ole kovin suurta merkitystä, mutta laajemmassa ja tieteellistyyppisessä jutussa idea ehkä olisi toteuttamisen arvoinen. Käytännössä toteutus vaatisi sopivia työkaluja, joilla tarvittava merkkaus tuotetaan, koska "käsin" sitä tuskin kukaan jaksaisi kirjoitella.

Edellä mainittu esimerkki havainnollistaa sitä, miten tärkeää on, että sivuntekijä ei estä käyttäjää muuttamasta kehysten mittasuhteita. Yleensä alaviitteet ovat vähemmän tärkeitä kuin varsinainen teksti, ja siksi niille voidaan aluksi varata pienempi tila. Mutta sellainen lukija, joka haluaa rauhassa lukea pitkähkön alaviitteen, voi siirtää kehysten rajaa ylöspäin, jolloin alaviitekehys saa suuremman osan ikkunasta. Tämä on tilanne, jos sivuntekijä ei erikseen estä sitä noresize-määritteellä taikka poistamalla kehysten välisen rajan.

Joissakin tilanteissa voidaan varsinaisten kehysten asemesta käyttää ns. upotettuja kehyksiä. Upotettu kehys (inline frame) on on ikäänkuin dokumentin sisällä oleva ikkuna, josta näkyy toinen dokumentti tai vieritettävissä oleva osa siitä. Inline-kehys itse kokonaisuutena "rullaa" sen dokumentin mukana, jossa se on. Ks. Using inline frames (iframe elements) to embed documents into HTML documents.

Lisätietoja kehysten käytöstä

Liitteet

Miksi ja mitä julkaisen Webissä?

Sisällys

1. Not Knowing Why

This is the number one problem, all right. I am amazed how many websites are built simply because some executive told somebody to do it without telling them what the site should achieve. And no, it is not an acceptable reason that "everybody else is doing it."
Jakob Nielsen: Top Ten Mistakes of Web Management

Luvussa Suunnittele kokonaisuus kuvattiin, miten Web-sivuille pantava aineisto valikoidaan ja jäsennetään. Siinä oli lausumattomana oletuksena, että sivujen tekijällä on käsitys siitä, mihin Web-julkaisemisella pyritään ja millainen aineisto voisi palvella niitä tarkoituksia. Tässä lähdetään perustavammista kysymyksistä: miksi julkaista mitään Webissä, ja mitä kannattaa julkaista?

Miksi?

Itseilmaisua vai viestintää?

On aiheellisesti sanottu, että yksityisten ihmisten tekemät Web-sivut ovat suureksi osaksi seiniin tehtyjen töherrysten ("graffitien") vastineita. Mitään varsinaista viestintätarkoitusta ei ole, vaan tekijä haluaa vain tehdä jotakin näkyvää. Ennen muinoin lapset piirtelivät paperiin, joskus seinille; nykyisin moni "piirtelee" Web-sivuilleen. Kauniisti sanottuna hän haluaa "ilmaista itseään"; mutta kun lähtökohtana ja päätepisteenä on minä, minä ja minä, niin ei oikein voi puhua edes viestinnän yrittämisestä. Todellinen viestintä olisikin paljon vaativampaa, ja sehän viestintähän yleensä epäonnistuu, paitsi sattumalta. Näistä aiheista olen kirjoittanut laajahkosti jutussani So you want to create a home page?. Nasevammin asian on esittänyt Iiris Konttinen kolumnissaan Mitä järkeä on omassa kotisivussa?

Eräänlaisena viestinnällisenä tarkoituksena töherryksissä voidaan nähdä, etenkin niiden alalajissa tägeissä (tags), alueen merkitseminen vähän samaan tapaan kuin koirat merkitsevät alueensa kuseskelemalla. Webissä tämä toimii aika huonosti, ellei sitten harrasteta sellaista, että murtaudutaan toisten palvelimiin ja kirjoitellaan omia tägitöherryksiä muiden sivuille. (Selvyyden vuoksi mainittakoon, että sellainen toiminta on paitsi typerää myös rikollista; ks. rikoslain 38. lukua.)

Aiheiden keksiminen

Yleisenä neuvona niille, jotka miettivät, mistä keksisin aiheen sivuilleni, sanoisin: älä tee sivuja, ennen kuin mieleesi luonnostaan nousee paitsi aihe myös ajatus siitä, mitä uutta esitettävää muille sinulla on siitä. Jos vaikkapa jokin bändi tai TV-sarja tai hevonen on sinulle henki ja elämä, niin todellisuudessa sinun kiinnostuksesi ei juurikaan kiinnosta muita, ei edes niitä, jotka sattuvat olemaan kiinnostuneita samasta bändistä tai sarjasta tai hevosesta. Ja ennen kuin alat kirjoittaa linkkilistaa aiheesta, vilkaisepa muutamia niistä sadoista olemassa olevista listoista, jotka löydät pienellä haulla. Onko sinulla valmiuksia tehdä jotain olennaisesti parempaa? Ja myös pitää sitä yllä?

Muutoinkin kannattaa tehdä hakuja jo siinä vaiheessa, kun vasta harkitsee sivujen tekemistä jostakin aiheesta. On ihan mahdollista, että löydät sivun, joka on sellainen, kuin sinä aioit tehdä. Tai ehkä huomaat, että sinun kannattaakin tehdä juttu vain jostakin osa-alueesta. Hyvin usein löydät sivuja, joista on hyötyä omia sivujasi tehdessäsi ja joihin voit viitata linkeillä. Jos vaikkapa aiot tehdä suomenkielisen sivun, jossa on ohjeita ImageMagick-ohjelman käytöstä, kannattaa ainakin katsoa vaikkapa AltaVistalla, mitä jo on olemassa (esim. haku lausekkeella imagemagi*, rajoitettuna suomenkielisiin sivuihin).

Eri juttu on, jos sinulla on jotain todella omaa, itse tekemääsi. Runo, maalaus tai essee voi olla hyvä Web-sivun sisältö. Se tuskin kiinnostaa miljoonia ihmisiä, mutta ehkä joitakuita; jotakuta runosi ehkä puhuttelee, maalauksesi miellyttää tai esseesi innostaa miettimään asiaa. Varaudu kuitenkin siihen, että nekin, joita sisältö ei miellytä, kertovat sinulle tai ehkä julkisesti mielipiteensä siitä. Jos menee julkisuuteen, on syytä varautua julkiseen arvosteluun.

Jos olet niin onnettomassa tilanteessa, että sinun pitää tehdä Web-sivu esimerkiksi osana jotakin koulutusta - mikä on varsin absurdi tilanne - niin ehkä seuraavasta vinkistä on apua: Yritä löytää jokin sellainen erikoinen aihe, josta tekemäsi juttu saattaisi kiinnostaa joitakuita, ehkä hyvinkin pientä porukkaa, ja jonka tekemiseen sinulla on jonkinlaiset edellytykset. Jopa pelkästään hakemalla englanninkielisiä sivuja jostakin aiheesta ja kirjoittamalla niiden pohjalta suomenkielisen tiivistelmän voi saada jotain fiksua aikaan. Mutta silloin ei kannata valita mitään laajaa yleisaihetta kuten "hevoset" tai "maanjäristykset" vaan jotain rajattua, esimerkiksi sardinian kieli tai sardiinisäilykkeiden valmistus.

Firman sivu - tekijänsä itseilmaisua vai pakollinen kuvio?

Entä yritysten, laitosten ja yhteisöjen sivut? Ensinnäkin niitä tehdään usein ihan samalta pohjalta kuin henkilökohtaisia sivuja. Tilanne on astetta pahempi, koska jos organisaation virallinen sivu on tekijänsä "itseilmaisua", häpeä tulee koko organisaation eikä vain tekijän päälle.

Mutta vaikka sivuntekijän asenne olisi asiallisempi, voi puuttua ajatus siitä, mitä oikein tavoitellaan. Aivan liian usein sivut tehdään, koska "kuuluu olla" Web-sivut - pitää "näkyä" Webissä. Siinäpä sitten näytään vielä parin vuoden päästä niillä samoilla sivuilla, joiden sisältö kertoo edelleen "syksyn erikoistarjouksista" vielä keväällä.

Ympäristön ymmärtäminen

World Wide Web välineenä on tajuton. Ihan tajuttoman iso. Maailma on paljon isompi kuin osaat kuvitella, ja vaikka toistaiseksi vain pieni osa maailman ihmisistä käyttää Webiä, et oikeasti osaa kuvitella Webin todellista laajuutta. Et osaa edes kuvitella, millaisista eri syistä ja eri tilanteissa ja eri tarkoituksissa ihmiset saattavat vierailla sivuillasi.

Web-julkaiseminen on lähtökohtaisesti avointa. Se on kuin naulaisit teesisi kirkon ulko-oveen ja jäisit ihmettelemään, käykö kukaan niitä lukemassa. Paitsi että Webissä "lukemassa käyminen" onnistuu sujuvasti ilman, että lukija liikkuu paikaltaan. Mutta toisaalta Web-julkaiseminen ei ole verrattavissa esimerkiksi sanomalehden julkaisemiseen tai televisio-ohjelman lähettämiseen, joissa on kyse juttujen aktiivisesta työntämisestä saataville, lehtikioskeihin, kirjakauppoihin, eetteriin, kaapeliin tms. (Webissä on kyllä kokeiltu "työntämistekniikkaa", push technology - ja havaittu se huonosti toimivaksi.)

Web-julkaiseminen on tarjolle panemista ja tarjolla pitämistä. Toki sivuja voi eri tavoin "mainostaa", mutta keskeistä on kuitenkin se, että Webin kautta tapahtuva viestintä on käyttäjälähtöistä ihan todellisella tavalla, ei siis fraasien "käyttäjälähtöisyyttä". Erityisesti käyttäjä lähtee muualle hyvin herkästi. Ja käyttäjä lähtee etsimään tietoja, tapahtui se sitten hakupalvelimia käyttäen, hakemistoista lähtien tai vaikkapa jostakin kuultuja tai luettuja vinkkejä seuraten. Joku saattaa kyllä lukea helsinkiläisen bussin kyljestä tekstin www.ytv.fi ja arvella, sinänsä aivan oikein, että osoitteen http://www.ytv.fi kautta löytyy Helsingin julkiseen liikenteeseen liittyvää tietoa. Mutta hän menee sivuille todennäköisesti etsimään sellaista tietoa, ei tietoa YTV:n organisaatiosta taikka sen johtajan ulkonäöstä tai tänäisistä mielipiteistä. Selvyyden vuoksi sanottakoon, että voihan sivuille panna organisaatiokaavion, historiikin, kuvakirjan jne. mutta niiden ei pidä olla pääasioita, jotka hyökkäävät silmille pääsivulta.

Keille?

Jotta Web-julkaisemisessa olisi jotain mieltä, täytyy olla jokin ajatus siitä, keille sivuilla voisi olla jotakin annettavaa ja miten. Pelkkä "yrityksen esittely" tuskin kiinnostaa ketään, jos se on ympäripyöreä mainoshenkinen yleisesittely. Sen sijaan yrityksen potentiaalinen asiakas tai yhteistyökumppani voi olla hyvinkin kiinnostunut samaan todellisia tietoja yrityksestä. Mutta silloin tietojen onkin oltava sellaisia, että ne vanhenevat melko nopeasti; todellisilla, merkittävillä tiedoilla nimittäin on sellainen ominaisuus. Tämä merkitsee, että tietoja täytyy pitää yllä jatkuvasti. Halutaanko siihen satsata, ihan oikeasti? Jos ei, olisi ehkä parempi jättää sivut tekemättä. Ihan imagosyistäkin.

Tavoitteiden asettaminen

Organisaation Web-sivuston yleiset tavoitteet voisi ehkä yleisellä tasolla hahmotella näin:

Luettelo on tärkeysjärjestyksessä. Jos rahkeet eivät riitä kuin viimeksi mainittuun, niin sivusto kannattaa tehdä niin, ettei se luo odotuksia enemmästä.

Kohderyhmiä kannattaa miettiä yhteydessä siihen, mitä sivustolla halutaan millekin ryhmälle tarjota. Yleensä sivustoa ei ole mielekästä jäsentää kohderyhmien mukaan, vaan sivustoon mukaan otettava aineisto määräytyy eri ryhmille hyödyllisen aineiston summana. Eri asia on, että joiltakin osin voi olla aiheellista laatia erilaisia hakemistosivuja eri kohderyhmille.

Seuraavassa on astetta konkreettisempana esimerkkinä hahmotelma siitä, mitä suomalainen korkeakoulu voisi tavoitella Web-sivuillaan:

Mitä?

Mikä kannattaa?

Jonkin aineiston Web-julkaisemisen järkevyyttä harkittaessa on tietenkin verrattava sen vaatimaa työtä saavutettavaan hyötyyn. Tällöin on syytä erityisesti ottaa huomioon Webiin sijoitettavan aineiston ylläpidon (ajan tasalla pitämisen) vaatima työ. Silloin kun on kyse jossakin organisaatiossa suoritettaviin työtehtäviin liittyvästä Web-julkaisemisesta, pitää tietenkin arvioida hyötyä nimenomaan organisaation ja sen tavoitteiden kannalta.

Yleistä vai erityistä?

Saattaa olla tarpeen ottaa eri kohderyhmät huomioon esimerkiksi siten, että samasta aiheesta tehdään useita erilaisia Web-dokumentteja. Jos halutaan vaikkapa kertoa uusista tutkimustuloksista, niin voi olla hyvinkin aiheellista tehdä niistä toisaalta suurelle yleisölle tarkoitettu yleistajuinen esitys, joka korostaa tulosten käytännöllistä merkitystä, että kyseisen alan asiantuntijoille tarkoitettu hyvinkin seikkaperäinen tutkimusraportti, ehkä jopa lisäksi tutkimusmateriaali kuten mittausdatat. Tällaisten ääripäiden väliin mahtuu tietenkin monenlaisia välimuotoja. Hyvä lähtökohta on, että yleistajuisimmat ja tiivistetyimmät esitykset kannattaa viedä Webiin ensin. Esimerkiksi tutkimusraportin tiivistelmän julkistaminen Webissä on yleensä tärkeämpää kuin itse raportin. Saman alan muiden tutkijoidenkin kannalta on olennaista löytää tieto raportin olemassaolosta, kunhan sitten sivuilla yleisesti on tieto siitä, mistä laitoksen tutkimusraportteja voi tilata. (Realistisesti ajatellenhan tieteellisestä raportista kiinnostuneita ei maailmassa ole kovin monia, keskimäärin kai alle yksi ihminen.)

Webiin kannattaa sijoittaa erityisesti sellaista tietoa, jota ei ole kätevästi muutoin saatavilla ja jonka tarjoamiseen ei ole muita käytännöllisiä kanavia. Tyypillinen esimerkki tällaisesta ovat muutokset painetussa muodossa olevaan aineistoon kuten opetusohjelmaan tai aikatauluun taikka kirjassa havaittujen virheiden korjaukset.

Yksi tärkeä tapa arvioida Web-julkaisemisen tarpeellisuutta on miettiä, millaisia asioita ihmiset yleisesti kysyvät. Tyypillisiä esimerkkejä ovat erilaiset käytännön järjestelyt ja menettelyt mutta myös tavallisimmat ongelmatilanteet vaikkapa laitteiden käytössä. Web-julkaisemisella voidaan ehkä vähentää henkilökunnan työtä tällaisiin kysymyksiin vastaamisessa ja myös saada aikaan, että tieto menee perille oikeampana, koska se on esitetty kirjallisessa muodossa. Vaikka kysymyksiin jouduttaisiinkin vastaamaan puhelimitse, niin sellaista palvelua hoitavalle ihmiselle on hyödyksi, kun hän itse voi tarkistaa asian Web-sivulta ja ehkä antaa tai lähettää varmuuden vuoksi myös paperikopion siitä.

Millä kielellä?

Tehtäessä kokonaan uutta aineistoa Webissä julkaistavaksi kannattaa harkita, millä kielellä kirjoitetaan. Tähän vaikuttaa tietysti varsin paljon se, keitä varten teksti ensisijaisesti kirjoitetaan.

Esimerkiksi tutkimusta koskevat tiedot on useimmiten järkevää kirjoittaa ainakin ensi sijassa englanniksi. Saman alan muiden tutkijoiden voi olettaa osaavan englantia vaikka he olisivatkin suomalaisia. Mahdollisuuksien mukaan kannattaa huolehtia siitä, että jos aineisto on suomenkielistä, siitä on tarjolla myös ainakin tiivistelmä englanniksi, ja kääntäen.

Jos sama aineisto aiotaan tarjota useina erikielisinä versioina, on syytä ottaa huomioon, että työmäärä on melkoinen. Joissakin tilanteissa siihen voi kuitenkin olla suoranainen velvoite tai muu painava peruste. Web-sivun kääntäminen edellyttää normaalien kääntäjäntaitojen (kuten kohdekielen, lähdekielen ja asiasisällön jonkinasteista hallintaa) lisäksi myös jotakin tietoa Web-julkaisemisesta, ellei sitten kääntäjän työn tuloksia erikseen jälkikäsitellä, mikä aiheuttaa lisätyötä. Erikielisten versioiden tarjolle panemisesta ks. juttukokonaisuutta Tekniikoita monikielisiä Web-sivustoja varten.

Mahdollisia rajoituksia
Liikaa aineistoa?

Aineiston laajuus ei sinänsä ole Web-julkaisemisen este; jossakin vaiheessa voi palvelimessa käytettävissä olevan levytilan yläraja tulla vastaan, mutta yleensä rahalla saa lisää. Esimerkiksi diplomityö tai väitöskirja voidaan hyvin julkaista kokonaisuudessaan Webissä, vaikka onkin tärkeää, että sen lisäksi on tarjolla lyhyt selostus sen olennaisesta sisällöstä. Vielä parempi on, jos aineistosta on useita erilaajuisia versioita, esimerkiksi yhden kappaleen uutinen suurelle yleisölle, yhden sivun tiivistelmä tieteenalan tutkijoille ja harrastajille, muutaman sivun kooste saman erikoisaiheen tutkijoille ja täysi aineisto sille hyvin pienelle, mutta tärkeälle, joukolle, joka sen haluaa lukea. (Periaatteessa voisi olla tarjolla vieläkin laajempi versio, jossa on mukana myös alkuperäinen aineisto kuten mittausdata, teoksen eri versioita jne.) Ei pidä ajatella niin, että ei kukaan jaksa lukea väitöskirjaa kuvaruudultaan. Ei varmaan jaksakaan, mutta asiasta kiinnostunut voi tulostaa väitöskirjan tai osan siitä kirjoittimella, paperilta luettavaksi, taikka etsiä siitä jonkin erityisen kiinnostavan kohdan ja lukea sen kuvaruudulta. Mitä laajemmasta aineistosta on kyse, sitä tärkeämpää onkin ajatella sen tulostettavuutta paperille esimerkiksi sijoittamalla aineisto Webiin myös yhtenä yhtenäisenä dokumenttina.

Liikesalaisuuksien ja henkilötietojen suoja

Esteen Webissä julkistamiselle voivat muodostaa liikesalaisuudet tai muut salassapitovelvollisuudet. Useimmiten on melko selvää, mitä asioita tämä koskee. Tosin yksityinen ihminen ei ehkä tule ajatelleeksi, että jos hän on kehittelee keksintöä, siitä ei kannata kertoa julkisesti ennen kuin patenttihakemus on tehty, jos aikoo taloudellisesti hyötyä keksinnöstään.

Ihmisiä yksityisinä henkilöinä koskevia tietoja (tai heitä esittäviä valokuvia) ei ole syytä julkistaa ilman itse kultakin saatua nimenomaista lupaa. Tästä tarkemmin ks. kirjoitustani henkilötietojen suojan merkityksestä. Esimerkiksi tenttitulokset kuuluvat henkilötietoihin siltä osin, kuin kyse on henkilökohtaisista tuloksista eikä tilastotiedoista. Niinpä tulosten tiedottaminen opiskelijoille onkin syytä hoitaa henkilökohtaisella viestinnällä kuten meilitse ("sähköpostitse").

Tekijänoikeus

Aineiston Web-julkaiseminen merkitsee sen saattamista yleisön saataviin. Tyypillisesti aineisto muodostaa teoksen, ja tällöin sen saattaminen on tekijänoikeuslain perusperiaatteen mukaisesti tekijän yksinomainen oikeus. Toisin sanoen teoksen saa julkistaa vain sen tekijä taikka ihminen tai organisaatio, joka on saanut tekijältä nimenomaisen luvan julkistamiseen. Aihetta käsittelee tarkemmin artikkeli Miks mä muka en sais skännätä tätä veppisivulleni eli mitä jokaisen tietokoneen käyttäjän pitäisi tietää tekijänoikeudesta ja laajempi Tekijänoikeusfakki.

Tekijänoikeus voi siirtyä tekijältä esimerkiksi työnantajalle työsuhteen perusteella tai kirjankustantajalle kustannussopimuksen perusteella. Tällöin tekijä itsekin tarvitsee julkaisemiseen luvan. Tällä voi olla käytännöllistä merkitystä esimerkiksi silloin, kun teos on tehty työsuhteessa ja on senluonteinen, että työnantaja saattaisi haluta julkaista sen painetussa muodossa ansiotarkoituksessa. Web-julkaiseminen tietenkin veisi markkinoita sellaiselta julkaisemiselta. Toisaalta esimerkiksi jutun julkaiseminen lehdessä ei estä tekijää itseään julkaisemasta sitä muualla, myös Webissä, ellei hän ole sopimuksella (esim. "yksinjulkaisuoikeuden" luovuttamalla) rajoittanut oikeuksiaan.

Journalismin säännöt

Vaikka kaikki Web-julkaiseminen ei toki ole journalismia ainakaan sanan suppeassa merkityksessä, varsin monet hyvän journalismin säännöt kannattaa ottaa huomioon muutenkin kuin "nettilehteä" tehtäessä. Journalistiliitto on julkaissut Journalistin ohjeet. Niistä voisi erityisesti seuraavat nostaa esiin kaikkeen julkaisemiseen soveltuvina:

10. Asiatiedot on tarkistettava niin hyvin kuin mahdollista, myös silloin kun ne on jo aiemmin julkistettu.

11. Yleisön on voitava erottaa tosiasiat ja niiden taustoittaminen mielipide- ja sepitteellisestä aineistosta. Tämä periaate ei rajoita journalistisen tyylilajin ja muodon valintaa.

Web-julkaisemisessa on usein suotavaa faktojen tarkistamisen lisäksi linkeillä viitata lähteisiin, joista lukija voi itse tarkistaa tietoja ja sen, esittääkö kirjoittajan kuvaus tosiasiat oikealla tavalla. Aina tämä ei tietenkään ole mahdollista, vaan joudutaan tyytymään vanhanaikaisempiin lähdeviittauksiin.

Esimerkki sisältösuunnitelmasta

Seuraavassa tämän osuuden lopuksi esimerkkinä kaavamainen hahmotelma korkeakoulun toimintayksikön kuten laitoksen, laboratorion tai professuurin Web-sivuston sisällöksi:

Vrt. kuvitteellisen hypermystiikan laboratorion sivuihin. (Varoitus: vertaaminen todellisiin sivuihin voi järkyttää mielenrauhaasi.)

Manifesti: Web-julkaisemisen seitsemän periaatetta selityksineen

1 Mieti, miksi teet Web-sivuja

Sivujen tekemisen tarkoitus on jonkinlainen viestintä, olipa se luonteeltaan kaupallista, tiedottavaa, aatteellista, viihteellistä tai jotain muuta. Mitä haluat viestiä ja keille? Palveleeko se, mitä sivujen eteen teet, näitä tarkoituksia?

2 Rakenna Webin vahvuuksien varaan

World Wide Web on luonteeltaan maailmanlaajuinen, yhteisiin teknisiin sopimuksiin perustuva ja hypertekstiä tukeva. Käytätkö tätä hyväksesi? Hyvä sivu puhuttelee niin laajaa yleisöä, kuin sen tarkoitus suinkin sallii, noudattaa vakiintuneita ja yleisiä teknisiä käytäntöjä ja hyödyntää linkkejä sen sijaan, että yrittäisi sanoa kaiken yhdellä kerralla.

3 Tee sivut kaikkeen ja kaikille venyviksi

Web-sivut mukautuvat luonnostaan mitä erilaisimpiin esitystilanteisiin, kuten eri kirjasinkokoihin ja erilaisiin selainikkunoihin ja myös paperitulostukseen ja ääniesitykseen sopivia. Annatko sivujesi olla sellaisia vai yritätkö taistella mukautumista vastaan esimerkiksi pyrkimällä pakottamaan sivut vain yhteen esitystilanteeseen kuten määräkokoiseen kuvaruutuun sopiviksi?

Sivun lukeminen ääneen on hyvä testauskeino.

4 Noudata niitä vanhoja periaatteita, jotka sopivat myös Webiin

Journalismin, hyvän kielenkäytön, typografian, graafisen ilmaisun ja monen muun alan periaatteet ovat edelleen voimassa. Ne ovat usein muotoutuneet vuosisatojen, jopa vuosituhansien kuluessa, ja on parempi opiskella niitä kuin yrittää keksiä pyörää uudestaan, jolloin tuloksena olisi vain kulmikas tekele.

Mutta säännöistä ja käytännöistä osa on sidoksissa niihin muotoihin ja tilanteisiin, joissa toimitaan. Kiveen hakkaamalla kirjoitetun tekstin säännöt eivät kaikilta osin enää päde, eivätkä kaikki painojulkaisujen säännöt päde Webissä.

5 Kuvaile, älä määräile

Web-sivulla voidaan kuvata sen rakenne ja ehdottaa yksi tai useampia tapoja esittää se näkyvässä muodossa tai muutoin. Määräily ei toimi, koska kaikki, mitä sanot, voidaan jättää huomiotta.

6 Yksinkertaisuus ensin

Kaikkea ei kannata pitää yksinkertaisena, mutta yksinkertainen versio on parasta tehdä ensin. Se toimii, se on nopea tehdä, ja se voidaan pitää pohjana, jolle palataan, kun muu menee pieleen. On helpompi rakentaa yksinkertaiselle perustalle lisukkeita kuin raivata monimutkaista rakennelmaa.

Periaate tarkoittaa myös sitä, että ensin esitetään asian ydin yksinkertaisesti ja sitten sitä tarkennetaan ja kehitellään. Suurin osa ihmisistä lukee enintään otsikon ja ensimmäisen kappaleen, tai ainakin lukee jatkon vain, jos niissä oli jotain tärkeää. Tärkein on yleensä yksinkertaista, sellaista, joka koskee ja kiinnostaa monia ihmisiä. Tärkeimmän "säästäminen" loppuun on erittäin tylsää, ellei kyse ole suunnilleen dekkarista.

7 Viimeistele sopivasti

Hyvin tehty vaatii vielä viimeistelyn, joka voi koskea näkyvää ulkoasua (hiukan väriä tuonne, vähän väljyyttä tänne), kieliasua, asiatietoja, teknistä tarkistusta tai jotain muuta. On hyvä viimeistellä, ja on hyvä osata lopettaa, kun virittelystä ei enää ole kenellekään hyötyä.

Manifestissa esitettyjä periaatteita on selostettu ja perusteltu tarkemmin mm. seuraavissa kirjoituksissani: Merkkauskielten idea, Web Publishing Is Different, Augmentative authoring ja Guide to Web Accessibility and Design for All.

Linkkejä lisätietoihin

Suomeksi

Luultavasti paras luettelo suomenkielisistä ohjeista, jotka liittyvät Web-sivujen tekemiseen, on Makupalat-linkkikirjaston kohdassa Kotisivu. Siellä on linkkejä myös englanninkielisiin juttuihin, mutta kieli ilmenee yleensä linkin nimestä. Luettelo on kyllä aika laaja, mikä on kaksipiippuinen juttu. Makupaloissa on myös muita Webiin tavalla tai toisella liittyviä linkkikokoelmia, mm. osastoissa Internet, Ohjelma-arkistot sekä Tietotekniikka I ja Tietotekniikka II; viimeksi mainitussa on mm. ohjelmointiin (Java, JavaScript, ...) liittyviä linkkejä.

Nyrkkisäännöksi aineiston arviointiin voi antaa, että aloittelijalle tarkoitetussa HTML-oppaassa on sitä vähemmän varsinaista asiaa, mitä varhaisemmassa vaiheessa se kertoo, miten voit (muka) määrätä sivun taustavärin. Sehän ei toki ole ensimmäisiä asioita, jotka kannattaa oppia! Toinen tapa nopeasti arvioida HTML-opasta on katsoa, mitä se sanoo blockquote-elementistä; jos opas opettaa, että se tarkoittaa sisennystä (eikä lohkositaattia), niin oppaan tekijä on luultavasti ymmärtänyt monta muutakin asiaa värin.

Seuraavassa on muutama suomenkielinen esitys HTML:n keskeisistä rakenteista; ne kattavat suunnilleen saman aihepiirin, joten kannattaa valita se, jonka esitystyylistä pitää eniten:

Muista suomenkielisistä aineistoista mainittakoon seuraavat:

Englanniksi

Valtaosa Web-sivujen tekemistä koskevasta aineistosta on kirjoitettu englanniksi. Taso vaihtelee erittäin paljon. mutta jos ottaa lähtökohdaksi Tobias C. Brownin huolella kokoaman ja kommentoidun linkkilistan Web Site Development Information, löytää jyviä eikä akanoita.

Seuraavassa pari omaa suositustani erityisesti niille, jotka haluavat systemaattisesti opiskella sivujen tekemistä:

Yksityiskohtaista tietoa HTML:stä on englanniksi seuraavissa:

Lisätietoja CSS:stä löytyy sivun Keskeisiä CSS-linkkejä kautta.

Muilla kielillä

Sfnet.viestinta.www VUKK ja muut fakit

Vastauksia usein esitettyihin kysymyksiin Web-sivujen tekemisestä on sfnet.viestinta.www VUKK:ssa. Sieltä kannattaa yleensä ensimmäiseksi katsoa apua ongelmatilanteissa. Jos VUKK:sta ei löydy vastausta kysymykseesi, voit myös etsiä kyseisestä nyysiryhmästä artikkeleita avainsanojen perusteella esim. seuraavalla lomakkeella:

Artikkelien etsintä sfnet.viestinta.www-ryhmästä Google Groups -järjestelmällä:

:

Englanninkielisiä fakkeja on useitakin erittäin hyödyllisiä, mm. seuraavat:

Englantia osaava voi myös etsiä vastauksia kysymyksiinsä ryhmistä comp.infosystems.www.authoring.html ja alt.html sekä muista comp.infosystems.www.authoring-ryhmistä. Mutta ensin kannattaa aina katsoa fakeista; yleensä sieltä löytyy vastaus nopeammin, ja se on todennäköisesti vielä oikea.

Peruskäsitteiden määritelmiä

Tässä määritellään vain muutamia Web-sivujen tekemiseen keskeimmin liittyviä peruskäsitteitä. Muiden osalta viitataan dokumenttiin Datatekniikan sanastoja.

palvelin (engl. server)
laite tai ohjelmisto, joka hoitaa jotakin erityistä tehtävää kuten tulostusta, datan varastointia tai meilin kulkua ja tarjoaa siihen liittyviä palveluita verkon kautta; vrt. Web-palvelin
protokolla (engl. protocol)
yhteyskäytäntö eli sopimus (määritelmä) joka määrittelee datansiirrossa sovellettavat menettelyt; protokollilla on Internetissä ratkaiseva merkitys, ja niitä on useilla eri tasoilla, fyysisestä datansiirtotavasta alkaen
selain (engl. (Web) browser)
ohjelma, joka pystyy hakemaan Web-dokumentteja Web-palvelimilta ja esittämään ne käyttäjälle näkyvässä tai muutoin havaittavassa muodossa; esim. Internet Explorer, Netscape, Opera, Lynx, iCab
URL
määrämuotoinen osoite, joka viittaa Internetissä olevaan "resurssiin" kuten Web-sivuun
Web-palvelin (engl. Web server, HTTP server)
palvelin, joka tarjoaa Web-sivuja luettaviksi selaimille HTTP-protokollaa käyttäen; palvelinohjelmistoja on monia erilaisia, yleisin ja tunnetuin lienee Apache

Pelkän tekstin esittäminen muodollisesti HTML-dokumenttina

Seuraavat ohjeet koskevat tilannetta, jossa sinulla on aineisto pelkkänä tekstinä ja haluat saada sen nopeasti Webiin siten, että se on alun pitäenkin muodollisesti HTML-dokumenttina. Menettelyn idea on siinä, että nyt voit ilmoittaa aineistosi pysyvän osoitteen, joka säilyy, vaikka myöhemmin muutat sen oikeaksi HTML:ksi. Olennaista on, että tiedoston nimen loppuosa on jo valmiiksi .html (tai mitä kussakin palvelimessa käytetäänkin HTML-muotoisille dokumenteille).

Tällöin voidaan toimia seuraavasti:

  1. Tee tekstitiedostosta kopio, jolle annat nimen, joka loppuu merkkeihin .html
  2. Tarkista, esiintyykö tiedostossa jokin seuraavista merkeistä: & (et-merkki), < (pienempi kuin -merkki), > (suurempi kuin -merkki). Jos on, korvaa niiden kaikki esiintymät erityisillä merkinnöillä &amp; ja &lt; ja &gt;.
  3. Käsittele kyseistä kopiota editorilla niin, että lisäät aivan sen alkuun seuraavat kolme riviä, missä sanan otsikko tilalla on haluamasi otsikkoteksti: 
    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<title>otsikko</title>
<pre>
    ja aivan sen loppuun seuraavan rivin: 
    </pre>
  4. Kopioi tulos Web-palvelimeen.

Tällöin aineisto on muodollisesti HTML-muodossa mutta se toimii käytännössä kuten pelkkä teksti. Vertaa seuraavia, niin et todennäköisesti huomaa mitään eroa:

Merkinnöillä <pre> ja </pre> voidaan ilmoittaa, että HTML-dokumentin osana on aineistoa, joka tulee tulkita pelkäksi tekstiksi.

Viimeisen päivityksen ajankohta: 2009-06-21.
Tämä sivu kuuluu Jukka "Yucca" Korpelan avoimeen tietosivustoon Datatekniikka ja viestintä, osaan Web.