HTML‐opas

Yleistä HTML:stä

HTML on nettisivujen tekoon käytettävä kieli. Se on paljon suuremman ja vanhemman kielen, SGML:n, sovellus. HTML perii monia piirteitä SGML:stä, kuten tämänkin dokumentin lähdekoodissa näkyvät rasittavat entiteettikoodit (sitä &auml;‐roskaa), <!‐‐‐ ‐‐>kommentit, merkinnässä käytettävät kulmasulkeet (eli suurempi kuin ja pienempi kuin merkit) ja tasorakenteen, jossa merkintöjen sisällä voi olla lisää merkintää. Tämä opas käsittelee HTML‐kielen versiota 4.0, joka kirjoittamisen aikoihin oli niistä uusin. Kuitenkin suurin osa sanotusta pätee myös XHTML:n versioon 1.0, jota tämäkin dokumentti itse asiassa sisältää. Kielen uudemmat, dynaamiset ominaisuudet ja palvelinpuolen osallistumista vaativat rakenteet (kuten kaavakkeet) jätetään tietoisesti huomiotta. Viitauksia kielen vanhempiin versioihin löytyy jonkin verran, mutta jos vaihtoehtoja on, niiden kuvaamia menetelmiä ei tulisi käyttää. Siitäkään huolimatta, että ne saattavat tarjota helpompia tapoja saavuttaa samat päämäärät. Näitä tapoja kuvaillaan lähinnä siksi, että ne ovat laajalti käytössä ja joskus niihin joutuu myös yhteensopivuussyistä turvautumaan. (Itse asiassahan sama merkintä on saatavilla myös HTML 4.0 Transitional ‐versiossa.)

HTML tulee sanoista HyperText Markup Language, joka tarkoittaa hypertekstin merkintäkieltä. Hyperteksti on tekstiä, jossa käytetään linkkejä paikasta toiseen ja kaikenkaltaisia multimediajuttuja luomaan perinteisestä suoraan luettavasta kirjan kaltaisesta tekstistä poikkeava verkkomainen rakenne. Ideana on, että lukija itse valitsee miten tekstinsä lukee. Tärkeää on myös, että dokumentin rakenne heijastaa sen tarkoitusta. Esimerkiksi taulukoita ei tulisi käyttää vain ulkonäön takia, vaan vain jos niissä todella on taulukkomuotoista tietoa. HTML tarjoaa runsaasti mahdollisuuksia siistien rakenteiden tuottamiseen. Esimerkkejä ovat listat, kappaleittainen teksti, kuvat, dokumentin ulkopuoliset objektit, kuten java‐kielellä toteutetut ohjelmat, taulukot, osoitteet, eri tavoin tehostettu teksti ja niin edelleen. Seuraavassa esitellään lyhyesti tärkeimpiä HTML:n rakenteita. Myös tämän dokumentin lähdekoodia kannattaa vilkaista, koska se on melko tyylipuhdasta HTML‐kieltä.

HTML‐kielen yleiskuva

HTML‐kielinen dokumentti on tekstimuotoinen, normaalilla tekstieditorilla muuteltavissa oleva tiedosto. Tieto on talletettu tekstinä, jonka sekaan on sijoiteltu ns. merkintää (eng. markup). Merkintä on erikoismuotoista tekstiä, jonka kieltä ymmärtävät ohjelmat tunnistavat dokumentista ja tulkitsevat tavallisesta tekstistä poikkeavasti. HTML on myös ns. deklaratiivinen kieli—sen rakenteet ovat puhtaasti kuvailevia eivätkä ne tee mitään. Sen sijaan että jokin kielen merkintä vaikkapa vaihtaisi sivua tai tekstin väriä, HTML‐kielessä pyritään kertomaan mitkä tekstin osat täyttävät dokumentissa mitäkin roolia. Esimerkkinä tällaisesta kuvailevasta rakenteesta voisi olla vaikkapa jonkin tekstipätkän merkintä kappaleeksi tai otsikoksi.

HTML on myös ns. rakenteinen kieli. Tämä tarkoittaa, että kielen ominaisuuksia ei voi käyttää aivan miten vain, vaan niiden sisäkkäiseen käyttöön, keskinäiseen järjestykseen ja erilaisten rakenteiden ilmaisutapaan on olemassa kiinteä säännöstö. Perusperiaatteena on, että dokumentin ulkonäön asemesta ilmaistaan dokumentin rakenne: lista ei ole kasa sisennettyjä, ranskalaisin viivoin merkittyjä rivejä, vaan looginen yksikkä, joka koostuu sarjasta erillisiä tekstipaloja. Tämä rakenteen korostus johtaa nopeasti myös sisäkkäisten rakenteiden käyttöön: listassa yksi pala voikin tekstin asemesta olla kuva tai uusi lista ja koko ulompi lista voikin itse asiassa sijaita taulukossa. Joka puolestaan voi olla vaikkapa osa jotakin tekstikappaletta kirjan tietyn luvun tietyssä osassa. Kaikki tämä rakenne on periaatteessa mahdollista ilmaista HTML‐kielessä, vaikkakin hieman vähemmän informatiivisessa muodossa. SGML:n johdannaiset (HTML mukaan lukien) käyttävät yhden tällaisen rakenteisen dokumentin palikan abstraktiona käsitettä elementti.

HTML‐kielessä dokumentin elementit merkitään kulmasulkeisiin sijoitetuilla tageilla. Elementti koostuu alkutagista, attribuuteista, varsinaisesta sisällöstä ja lopputagista. Elementti alkaa alkutagilla <jotain> ja päättyy vastaavaan lopputagiin </jotain>. Tagin kirjaimet voivat olla suuria tai pieniä (kannattaa käyttää pieniä, koska niihin ollaan menossa). Silloin tällöin alkutagiin voidaan liittää attribuutteja. Se tapahtuu sijoittamalla attribuutit alkutagin sisälle, tyyliin <jotain attr1=arvo attr2=arvo> jne. Jos arvo on enemmän kuin yksiosainen, vaikkapa teksti, se tulee sijoittaa lainausmerkkeihin. Arvoissa ei valtapuolisesti voi käyttää kuin numeroita, kirjaimia ja muutamaa harvaa erikoismerkkiä. Niin tagit kuin attribuutitkin ovat dokumentin merkintää, joten ne eivät varsinaisesti kuulu dokumentin sisältöön—kun tuotettuja sivuja katsellaan Webissä, vain varsinainen tekstisisältö tulee näkyviin. Merkintä saa aikaan sen, että selain ymmärtää jotakin sivun rakenteesta ja osaa näyttää muutakin kuin vain sivukaupalla rakenteetonta tekstiä.

Perusrakenteet

Dokumentti

Dokumentin rakenne on seuraava: ensin aloitetaan HTML‐kielinen osio tagilla <HTML>, sitten tulee dokumentin otsake tagin <head> jälkeen ja vähintäänkin siinä edellytettävä otsikko, <title>‐</title>‐rajoitettuna. Näitä seuraavat varsinainen näkyvä dokumentti, <body> ja lopulta dokumentin lopetus, </html>. Monet HTML‐kielen osaset, kuten <head> ja <body> sallivat lopputagin poisjättämisen, koska selaimen pitäisi osata päätellä missä kyseiset tagit ovat. Niinpä <body>:n näkeminen katkaisee <head>:in ja </html>:n <body>:n. Jotkin tagit eivät salli lopetusta laisinkaan. Tällaisia ovat vaikkapa kuvat—niillä kun ei ole lainkaan sisältöä attributtitiedon lisäksi. Useimmiten tagit voi kyllä päättää, mutta lopetus on siitä huolimatta tapana jättää pois. Esimerkkinä toimii taulukoiden ja listojen sisältö.

Usein haluamme dokumentteihin jonkin kauniin taustakuvan ja tavallisesta poikkeavat värit. Tyylimääritykset CSS‐kielellä antavat tähän trendikkään tavan vaikkakin vanhemmissa HTML‐kielen versioissa on samaan hieman vähemmän nätti keino. Tämä tapa käyttää <body>‐elementin attribuutteja COLOR, BGCOLOR ja BACKGROUND. Ensimmäinen asettaa tekstin värin, toinen taustavärin ja kolmas taustakuvan lähteen. Jos vaihtoehtoja on, näitä ei pitäisi nykyään enää käyttää. Netscapen selaimet vain tuntuvat jumittavan tyylimääritysten kanssa, joten vaihtoehtoja ei ehkä sittenkään ole kovin paljon…

Otsikot ja erotinviivat

Seuraava tärkeä palanen on otsikko. Se merkitään tageilla <h1>:stä <h6>:een. Suurempi numero tarkoittaa alemman tason otsikkoa, siis pienempää. Tyylimäärityksillä voi kontrolloida tulosta tarkemmin. Otsikkojen tulee sijaita tekstien, taulukoiden ja muiden ulkopuolella, itse BODY‐osassa. Otsikkojen sisältö (tagien välissä oleva osa) kertoo otsikkoon tulevan tekstin. CSS‐kielen kakkosversio antaa myös mahdollisuuden otsikkonumeroinnin automaattiseen tuottamiseen, mutta toistaiseksi kyseiselle ominaisuudelle ei vielä löydy tukea selaimista.

Tärkein tapa erottaa kappaleita toisistaan on tietenkin otsikko. Joskus kuitenkin kaivataan myös tapaa erottaa tekstin osia, miltei kappaleen kokoisia tekstin paloja tai muuta vastaavaa ilman varsinaista omaa otsikkoa. Tällöin käytetään elementtiä nimeltä <hr> (Horizontal Rule). Visuaalisissa selaimissa (Netscape, Internet Explorer) se luo dokumenttiin vaakasuoran, mahdollisimman leveän erotinviivan. <hr> ei voi esiintyä <p>‐rakenteisessa tekstissä—jos erottimen sijoittaa näin, se katkaisee kappaleen. <div>:in ja vastaavien elementtien sisällä sitä voi kuitenkin käyttää vapaasti.

Teksti ja kappaleet

Kun haluamme dokumenttiin tekstiä, se tapahtuu tekstikappaleilla. Ne merkitään <p>‐tageilla. Ne eivät voi olla sisäkkäin, joten uutta kappaletta aloitettaessa edellistä ei tarvitse erikseen päättää. Toinen, yleisempi kappaletyyppi on <div>. Se sallii myös sisäkkäiset kappaleet, eli kappaleet joissa on kappaleita kappaleen sisällä. Niinpä se pitää aina myös päättää. <div> ei katkea vaikka eteen tulisikin esimerkiksi toinen <div> tai vaikkapa <p>. <div> on tarkoitettu lähinnä muiden elementtien ryhmittelyyn, vaikka sen käyttämisestä on kyllä muutakin hyötyä.

<div>in, <p>n ja itse asiassa miltei kaikkien muidenkin rakenteiden attribuuttina voi esiintyä LANG. Tämän dokumentin lähdekoodissa sitä on käytetty merkitsemään kappaleet suomenkielisiksi. Nykyään sen käytöstä ei paljon hyötyä ole, mutta tulevaisuudessa se sallii monikielisten dokumenttien rakentamisen. Tällöin selain valitsee oikean tekstin LANG‐koodien ja selaimen havaitseman käyttökielen mukaan. Kaksi muuta yleisattribuuttia ovat class ja id. Ensimmäinen merkkaa elementin jonkin tietyn luokan (class) jäseneksi. Tätä luokkaa voi sitten käyttää viittaamaan kaikkiin luokan jäseniin esimerkiksi tyylimäärityksissä. ID taas antaa yksittäiselle dokumentin osalle oman uniikin nimen. Näihinkin voi tyylimäärityksissä viitata. Valitettavasti vain Netscapen selain ei oikein hallitse id‐attribuuttia, vaan käyttää jo vanhentunutta name‐versiota. name on kuitenkin oikea tapa vain linkin nimenä, ei muutoin. Näiden lisäksi on myös olemassa yleisattribuutti osien otsikointiin. Sen nimi on title.

Ennen tyylimääritysten kehitystä käytössä olivat myös kaikkien piirrettävien elementtien attribuuteiksi sopivat clear ja float. Jälkimmäinen siirsi elementin vasemmalle tai oikealle kelluvaksi palikaksi, ensimmäinen taas kontrolloi sitä, miten kelluvien osien ohi virtaavat uudet elementit näytettiin. clear saattoi saada arvot left, right ja all, float arvot left ja right. Nämä ovat turhia ja vanhentuneita, sillä ne voidaan täysin korvata tyylimäärityksillä.

Usein teksti on sinällään varsin tylsän näköistä. Niinpä onkin tarpeen määritellä tekstiin tehokeinoja, jolla tärkeät asiat saadaan paremmin esille. Näitä onkin uusissa HTML‐versioissa paljon. Osa taas on vanhentunutta. Laillisia ovat mm. <em> (korostus), <dfn> (termin määrittely), <abbr> (lyhenne) jne. Tarkka lista löytyy HTML‐kielen määrittelystä. On huomattava että lailliset tehokeinot eivät tarkkaan kerro, minkä näköiseksi tehokeino tekstin tekee. Ne vain kertovat, mitä teksti tarkoittaa—tyyli pitää luoda erikseen tyylimäärityksillä. Vanhemmissa versioissa oli paljon suoria piirto‐ohjeita. Niitä voi edelleenkin käyttää, mutta parempi olisi että niin ei tehtäisi. Esimerkkejä ovat <i> (kursiiviteksti), <u> (alleviivaus) ja <strike> (läpilyönti), sekä <font>‐elementti face (fontti) ja size (koko) ‐attribuutteineen.

Kuvat

Usein haluamme dokumenttiin myös kuvia. Se tapahtuu otuksella nimeltä <img>. Attribuutteina ovat src joka kertoo mistä kuva löytyy sekä alt joka antaa ei‐graafisille selaimille tekstikuvauksen kuvasta. Periaatteessa alt on HTML 4.0:sta eteenpäin pakollinen attribuutti, koska ei‐graafisilla selaimilla sen teksti on kuvan ainoa näkyvä osa. Jos haluaa jaaritella pidemmin, käytetään longdesc attribuuttia. <img>t tulee aina sijoittaa jonkin kappaleen, taulukon tai muun rakenteen sisälle, ne eivät voi olla paljaana. Vanhemmissa HTML‐versioissa käytettin kuville myös width ja height attribuutteja, jotka asettivat kuvan korkeuden ja leveyden. Nykyään näistä ollaan luopumassa tyylimääritysten hyväksi. Niiden arvot voivat olla pikseleinä tai prosentteina selaimen ruudun mitoista. On selvää, että prosentit ovat turvallisempi tapa—dokumentin toimivuuden ei tietenkään pitäisi riippua ruudun koosta pikseleinä.

Linkit

Kuten ylhäällä mainittiin, linkit ovat tärkeä osa HTML‐kieltä. Ne määritellään <a>‐elementillä. Elementin sisältönä on linkin teksti ja linkin kohde annetaan attribuutilla href jonka arvona on linkin URI. (URI tarkoittaa tässä Internetin yleistä osoitemuotoa, Uniform Resource Identifieriä. Yksi käypä muoto on tyyppiä http://www.keke.fi/. Etuosa tällaisesta URL:stä tarkoittaa protokollaa jolla resurssiin päästään käsiksi, ja se voi olla vaikka mitä. Mieleen tulee vaikkapa muoto mailto:decoy@iki.fi jolla lähetetään ihmisille postia ja ftp://ftp.funet.fi/ joka viittaa Netin tiedostopalvelimiin. Tavallisin muoto on http://www.iki.fi/~decoy/front, jossa http: merkitsee, että dokumentti haetaan hypertekstin siirtokäytännöllä (HTTP, HyperText Transfer Protocol), // että osoite on absoluuttinen (siis ei riipu siitä, missä viittaava dokumentti sijaitsee), www.iki.fi palvelimen osoitetta (ja tuo www ei todellakaan ole ainoa vaihtoehto, esim. http://www‐library.itsi.disa.mil/), ja loput että viitataan kyseisen palvelimen hakemistossa ~decoy olevaan dokumenttiin front. On hassu homma, että ihmiset eivät jaksa kirjoittaa osoitteita kokonaan, sillä itse asiassa viitteiden ei tarvitse edes toimia puolihuolimattomasti toteutetuilla viittauksilla. Lisäksi viimeisen kauttaviivan pois jättäminen aiheuttaa pienen ylimääräisen viiveen ja hieman lisäkuormaa Nettiin selaimen kysyessä palvelimelta, mihin ilman kauttaviivaa annettu osoite taas oikeastaan viittasikaan. Opetus: tee asiat oikein vaikka vähempikin näyttäisi riittävän.

Dokumentin osaan viitataan osan id‐attribuutilla annettulla nimellä, joka erotetaan dokumentin nimestä #‐merkillä. Jos viittauksen kohde löytyy samasta dokumentista kuin linkkikin, dokumentin nimi voidaan jättää pois, jolloin viittauksen muodoksi tulee #nimi. Jos halutaan luoda viittaus keskelle tekstiä, käytetään samaista <a>‐elementtiä, mutta nyt ilman href‐attribuuttia. Tällöin dokumenttiin syntyy tyhjä linkki, jolla on nimi. Nimi annetaan tässä tapauksessa joko id‐ tai name‐attribuutilla. HTML‐kielen uusimmassa versiossa sama toimii myös muiden elementtien nimien perusteella, joten useimmiten tällaisten viittauspisteiden luonnilta vältytään. Vaihtoehtoisesti voidaan käyttää uutta <spot>‐elementtiä, joka sitten nimetään ID‐attribuutilla. Etuna on kauniimpi syntaksi: <spot>:ia, toisin kuin <a>:ta, ei päätetä.

Listat

Paitsi suoraa tekstiä, HTMLssä käytetään myös rakenteisia tekstin muotoja. Niitä ovat listat ja taulukot. Listoja on kolmenlaisia: järjestettyjä, järjestämättömiä ja määritelmälistoja. Järjestetty lista luodaan <ol>‐elementillä, järjestämätön <ul>llä ja määritelmälista <dl>llä. Ne kaikki pitää myös päättää, sillä listat voivat olla rekursiivisia (listoja listojen sisällä). Kahden ensimmäisen listan jäsenet merkitään peräkkäisillä <li> tageilla, joita ei yleensä päätetä. Määritelmälista poikkeaa hieman muista, sillä siihen tulee kahden tyyppisiä jäseniä: <dt> on termin nimi, ja termin määrittely seuraa <dd>‐elementissä. Kannattaa muistaa, että listan sisällä ei voi olla tekstiä, vaan ainoastaan listan alkioissa.

Listoille on vanhemmissa HTML‐versioissa varsin eksoottisia optioita. Jos haluat tietää lisää, käy W3C:n sivuilla. Niiden linkki löytyy yltä…

Taulukot

Taulukot ovat varmasti yksi tärkeimmistä HTML:n ominaisuuksista. Niitä luodaan <table>‐elementeillä ja nekin pitää päättää. Taulukoidenkin sisällä voi olla lisää taulukkoja. Taulukon sisältö annetaan riveittäin; kukin rivi määritellään <tr> (Table Row) elementtinä. Tätä ei päätetä. <th>‐elementit (Table Header) tuottavat otsikkosoluja, <td>‐elementit (Table Data) taas tavallisia. Solun attribuuteista merkittävimmät ovat colspan ja rowspan jotka antavat solun koon taulukon sarakkeina tai riveinä. Näitä käytetään isojen solujen rakentamiseen. Jos taulukolle halutaan antaa otsikko, sellainen voidaan määritellä <caption>‐elementillä. Se sijoitetaan taulukon sisälle, mutta rivien ja solujen ulkopuolelle.

Kehykset

Kehykset ovat tekniikka, jolla web‐dokumentteihin saadaan useampia toisistaan riippumattomasti selattavia osia, jotka näkyvät graafisissa selaimissa ruudun jakautumisena suorakulmaisiin osioihin (kehyksiin), joista kukin käyttäytyy kuin erillinen selain. Käytetyt linkit voivat vaikuttaa kehyksien rajojen yli tai, erikoistapauksena, luoda uusia selainikkunoita. Kehykset tukevat myös rekursiivista määrittelyä jossa kehyksen sisällä näytetään uusi kehyksiä sisältävä dokumentti. Kehyksien hyvänä puolena on syntyvien dokumenttien nopea ja jäsentynyt selaus graafisilla selaimilla sekä siisti look. Huonoina puolina ovat kehno tuki muilla kuin johtavilla graafisilla selaimilla, syntyvien dokumenttien vaikea hallinta, tietty ristiriita HTML‐kielen perusperiaatteiden kanssa (kehykset kun ovat palstojen ja taulukoitujen dokumenttien tavoin pohjimmiltaan graafinen rakenne), nimeämisongelmat sekä häiritsevästä käytöstä (joka varsinkin erilaisilla taloudellisesti tuetuilla sivuilla (ilmaispornopalvelimet sekä mainoksilla tuetut ilmaispalvelimet kuten GeoCities) on johtanut häiritsevään uusien ikkunoiden luontiin).

Netscapen vetämänä HTML 4.0 ‐standardiin lisättiin kehysmäärittelyiden mahdollisuus. Aiemmin kehykset olivat Netscapen oma erikoisuus, ja niiden määrittely oli vähintäänkin epämääräistä. HTML‐kielen neljännessä versiossa määrittelyä selvennettiin siten, että ruudun jakaminen kehyksiin tapahtuu aina erillisestä dokumentista (frameset‐määrittely), jonka dokumenttityyppi eroaa tavallisen dokumentin tyypistä ja joka sitten kehysmäärittelyssä viittaa kehyksien varsinaisen sisällön muodostaviin HTML‐dokumentteihin.

Kehysmäärittelyn muodostaa dokumentti, jonka dokumenttityyppi määritellään merkkijonolla <!DOCTYPE html PUBLIC "‐//W3C//DTD HTML 4.0 Frameset//EN" "http://www.w3.org/TR/REC‐html40/frameset.dtd">. Tällaisen dokumentin määrittelyssä <body>‐osio on kielletty, ja sen sijaan käytetään <frameset>‐nimistä. Framesetin attribuuttina annetaan jakopisteet vaaka‐ ja pystysuunnassa sekä kehyksien reunoihin ja vieritykseen liittyvää tietoa. Sisältönä on <frame>‐määrittelyjä, jotka antavat varsinaisten kehysten geometrian ja viittaavat HREF‐attribuutilla sisällön muodostaviin HTML‐dokumentteihin. Lisäksi kannattaa käyttää myös <noframes>‐osion suomaa mahdollisuutta vaihtoehtoiseen esitykseen varsinaisten kehysten esittämiseen kykenemätömällä selaimella. Nästä vain <frame>‐oliot voi jättää päättämättä. Linkkien käyttö ei merkittävästi eroa tavallisista dokumenteista, ainoana erona on TARGET‐attribuutti, jolla linkin kohde voidaan määritellä haettavaksi muuhun kuin linkin sisältävään kehykseen. Attribuutin arvona on kehysmäärittelyssä kohdekehykselle NAME‐attribuutilla annettu nimi. Tai, erikoistapauksena, alaviivaalkuinen varattu nimi, joita on useita. Näillä luodaan uusia ikkunoita ja avataan dokumentteja kehyksiin joiden nimeä ei tiedetä (esim. koko ikkunan kokoiseksi tai nykyisen kehyksen sisältävään kehykseen). Kehykset eivät kuitenkaan kuulu puhtaaseen HTML 4.0‐kieleen. Niinpä dokumenteissa jotka viittaavat toisiin kehyksiin target‐attribuutin avulla onkin dokumentin tyyppinä käytettävä siirtymäajan HTML‐määrittelyn mukaista syntaksia. Tämä tapahtuu vaihtamalla yllä esitettyyn kehysmäärittelyn tyyppiin Frameset:in tilalle Transitional ja frameset.dtd:n tilalle transitional.dtd.

Omana mielipiteenäni on, että kehykset eivät ole hyvää tyyliä, ellei sivu ole tyypiltään sellainen, että se on suunnattu yksinomaan tietylle tunnetulle selaimelle joka tuntee kehykset ja lisäksi sivun graafinen rakenne ehdottomasti vaatii kehyksiä. Useimmiten näin ei ole, etenkään tietopohjaisilla sivuilla (hyödyllisillä sivuilla). Syynä tähän on, että kehykset ovat useimmiten lähinnä keino pitää pikalinkkejä nopeasti saatavilla, rakentaa graafisesti näyttäviä sivuja tai tuottaa polymorfisia hakemistorakenteita. Ensimmäisestä tarkoituksesta selviää yhtä hyvin tavallisilla linkeillä, jotka on liitetty sivuun, toisesta hyvällä tyylimääritysten tuntemuksella ja kolmannesta palvelimen puolella generoidulla koodilla. Jos kehykset siis ovat lähinnä keino brassailla, miksi tehdä niitä käyttäen sivuista epäyhteensopivia yksinkertaisempien, vanhempien tai erikoisryhmille tarkoitettujen selainten kanssa? Kieltämättä jotkin asiat kuitenkin hoituvat kehyksillä helposti. Hyvä niin. Kehyksiä käytettäessä sivuista tulisi kuitenkin aina muistaa tarjota myös kehyksetön versio, vaikka tämä tekeekin ylläpidosta työlästä ja sivujen rakenteesta sotkuista.

Miksi?

Tähän asti esitetyt neuvot ovat luonteeltaan melko puristisia ja poikkeavat tuntuvasti totutusta graafisesta web‐suunnittelusta. Graafiselle asulle ei juuri ole annettu painoarvoa ja dokumenttien rakenteellisille yksityiskohdille taas sitäkin enemmän. Niinpä on ehkä aihetta selittää hieman tarkemmin HTML:n teoreettista puolta, sitä mitä HTML itse asiassa on, mitä se on tarkoitettu tekemään ja mistä traditiosta sen suunnittelu on ottanut voimansa.

HTML ja SGML

Ylhäällä on jo mainittu, että HTML on SGML:n sovellus. SGML onkin selkeästi iäkkäämpi kieli ja sen alkuperäinen käyttöalue ja ‐tarkoitus eroavat tuntuvasti HTML:n nykyään varsin viihteellisestä sovellusalueesta—SGML on alunperin lähinnä teknisen dokumentaation ja vastaavan hyötytekstin tallentamiseen kehitetty standardi. Sen ensimmäiset alkumuodot ovat lähtöisin 70‐luvun lopusta, IBM:n dokumentaatio‐osastolta. SGML kehittyi vastaliikkeeksi ajan julkaisujärjestelmien varsin rakenteettomille ja osin manuaalista kirjanpainantaa matkineille sivunasettelu‐ ja dokumentaatiojärjestelmille. Ideana oli tuottaa helposti ylläpidettävä, koneellisesti tulkittavissa oleva yhdenmukainen formaatti rakenteiselle tiedolle, kuten sanakirjoille, termipankeille, teknisille ohjeille ja muulle vastaavalle hyvin tarkkoja kaavoja ja dokumenttipohjia noudattavalle tiedolle.

SGML:n lähtökohtana oli, että dokumenttiin tulisi eksplisiittisten taittosääntöjen ja sivunasettelukäskyjen asemesta koodata dokumentin semanttinen rakenne. Eli sen sijaan, että käsketään esim. vaihtaa sivua erikseen jokaisen kappaleen jälkeen, koodataankin vain tieto abstrakteista kappalerajoista ja muista tärkeistä dokumenntin osista. Vasta varsinaisessa taittovaiheessa dokumentti sitten ajettaisiin tietynnäköisiksi sivuiksi, joissa vaikkapa jokaisen tekstikappaleen jälkeen tulisi rivivaihto. Etuna olisi yhdenmukainen dokumentaatio, jonka rakenne olisi koneellisesti käsiteltävissä, jossa merkityt dokumenttilohkot olisivat periaatteessa itseriittoisia ja jonka rakenteen oikeellisuus pystyttäisiin koneellisesti varmistamaan (validoimaan).

On selvää, että mikään yksittäinen, täysin loppuun määritelty kieli ei kykene tällaisia vaatimuksia täyttämään, sillä eri dokumentaatiotarpeisiin tarvitaan hyvin erilaisia dokumentin rakenteita—sanakirjassa oleelliset termien, niiden selitysten ja ristiviittausten koodaamiseen käytettävät rakenteet tuskin ovat tärkeitä kaunokirjallisessa tekstissä. Niinpä SGML:n suunnittelussa päädyttiinkin kehittämään itse SGML:ään yleisimmät dokumenteille yhteiset työkalut (kuten yksinkertainen linkkimekanismi, pääpiirteinen merkinnän koodaustapa, tavat käyttää erikoismerkkejä ja viittauksia dokumentin ulkopuolisiin tietoyksiköihin jne.) sekä erillinen osakieli, jolla uusia, sovelluskohtaisia SGML:n sovelluksia pystytään nmäärittelemään. Tällainen sovellusmäärittely jakautuu kahteen osaan: SGML‐deklaraatioon ja dokumenttityypin määrittelyyn (DTD, document type definition). Näistä ensimmäinen määrää dokumenteissa käytettävän merkkijoukon (esim. ASCII‐merkistö tai vaikkapa joku kiinan kirjoitusmerkkien koodaus) sekä melkoisen joukon erilaisia SGML‐optioita (esim. voidaanko yhdessä dokumentissa käyttää useita eri DTD:itä) ja rajauksia (esim. kuinka pitkiä elementtien nimet saavat olla). DTD puolestaan määrittelee sen, mitä elementtejä dokumentissa voidaan käyttää, millaisia rakenteita niistä saa rakentaa (esim. kirjan lukuun voidaan vaatia vähintään yksi otsikko ja sen perään vähintään yksi tekstikappale) sekä mitä ja minkä tyyppisiä attribuutteja elementteihin kuuluu. Yleensä SGML‐deklaraatiota ei paljon muutella, vaan käytetään yhtä SGML‐standardin spesifioimista perusdeklaraatioista. Tämä on muun muassa HTML:n käyttämään kulmasuljemerkintään ja siihen, että periaatteessa HTML:ssä ei voi olla kuin perus‐ASCII:sta lainattuja merkkejä.

Askel HTML:ään onkin kaiken tämän jälkeen varsin luonteva: HTML on SGML:n yksinkertaisinta vakiodeklaraatiota käyttävä SGML:n sovellus, joka on määritelty HTML DTD:ssä. Kullekin HTML‐kielen versiolle on oma DTD:nsä ja nämä määräävät sen, mitä elementtejä ja attribuutteja HTML‐kielessä on. Käytännön pikkukomplikaationa monet selainvalmistajat ovat laajentaneet HTML‐kielessä sallittuja rakenteita omillaan, ja näin usein näkee käytettävän elementtejä ja attribuutteja, joita HTML‐kielessä ei itse asiassa lainkaan ole. Pahin asia on, että vain harvat varmistavat sivujensa oikeellisuuden tai välittävät dokumentin rakenteesta ja näin pahat tavat (kuten <multicol>‐teksti ja taulukoilla rakennettu palstoitus) pääsevät elämään omaa elämäänsä.

Oikea syntaksi

Monet ihmettelevät, miksi laajennuselementtejä ja ‐ominaisuuksia—jotka siis kuitenkin toimivat tunnetuimmilla selaimilla ja näyttävät mukavilta—ei saisi käyttää. Oma mielipiteeni on hyvin selvä: tällöin sivun tekijä sulkee kategorisesti pois kaikki ne, joiden selain ei satu tukemaan kyseisiä laajennoksia ja lisäksi tekee sivuista sellaisia, että ne eivät enää noudata HTML:n tai SGML:n perusperiaatteita—koko HTML‐kielen idea on, että hyvin erilaiset käyttäjät ja selainohjelmistot pystyisivät tulkitsemaan samoja, yhdenmukaisia sivuja. Epäyhteensopivista sivuista tulee hyvin vaikeita ylläpitää (esim. omat sivuni eivät edes yrittäisi pysyä kunnossa ilman säännönmukaista validointia), virhealttiita (esim. taulukoilla ja läpinäkyvillä kuvilla kikkailu pilaa tekstiselaimella katsottaessa sivut täysin), koneelliseen käsittelyyn kelpaamattomia ja kaiken kukkuraksi kannustavat selainvalmistajia täysin Netin periaatteiden vastaiseen, pitkän päälle kestämättömään laajennussotaan.

Erilliset tyylimääritykset

Nykyisten WYSIWYG‐editorien, helppokäyttöisten julkaisuohjelmien ja hypergraafisten web‐palvelujen aikana ero dokumenttien sisällön ja ulkoasun välillä on paljolti hämärtynyt. Jaottelu tyyliin ja sisältöön on kuitenkin ensiarvoisen tärkeä—jos tietoa aiotaan millään tavalla käsitellä koneellisesti tai sitä pitäisi pystyä esittämään useammissa eri muodoissa eri käyttäjille, on selvää, että graafinen asu ja dokumentin varsinainen sanoma pitäisi erottaa toisistaan. Selvimmin tämä ero näkyy jos ajatellaan sellaisia erikoistarpeita kuin ei‐graafinen selailu (esim. puhtaaksi tekstiksi, puheeksi tai pistekirjoitukseksi renderoivat selaimet) tai esimerkiksi hakukoneiden saamaa hyvin yksinkertaista kuvaa web‐sivuista. Jos ulkoasu on kovin tiukasti sidottu sisältöön, päädytään hyvin helposti esitystapaan, joka vastaa tiedon esittämistä kiinteänä kuvana. Tällaista esitystä onkin sitten tunnetusti jo varsin vaikeaa esittää äänenä tai puhtaana tekstinä, etenkään täysin automaattisesti.

Suurempien sivustojen kanssa on muitakin vahvoja syitä erottaa esityksen tyyli‐informaatio tiukasti sisällöstä. Tärkein on ylläpidettävyys: jos tyylitieto on täysin erillistä, sen voi sijoittaa erilleen varsinaista web‐sivuista, samaa tietoa voi käyttää kaikille rakenteeltaan samankaltaisille sivuille ja niin esitystavan muuttaminen vaatiikin vain yhden tyylitiedon muuttamisen. Lisäksi varsinaisissa dokumenteissa oleva tieto siistiytyy ja tulee helpommin hallittavaksi.

Selainten kehitys on tuonut webiinkin mahdollisuuden erottaa tyylitieto dokumenteista. Tähän käytetään sivujen ulkopuolisia tyylikieliä, joista eniten käytetty ja parhaiten tuettu on CSS. XML:n mukana on kehitetty myös vahvempaa XSL‐kieltä, jolle tuki on kuitenkin vielä melko olematonta. CSS:n kaltaiset ratkaisut ovat graafisemminkin orientoituneelle sivuntekijälle melkoinen siunaus, sillä ne sallivat huomattavasti perinteistä tyylitagisoppaa laajemmat mahdollisuudet sivujen ulkoasun hallintaan.

Edistyneempiä aiheita

SGML‐kielen eksoottisemmat rakenteet

Alussa mainittiin jo, että HTML on SGML:n sovellus. SGML sallii kuitenkin paljon varsin eksoottisia rakenteita. HTML:n määrittely hyödyntää näistä vain pientä osaa, mutta sallii kuitenkin paljon ominaisuuksia, joita selainten naiivit HTML‐toteutukset eivät välttämättä ota huomioon.

SGML‐sovellusten yksi perusperiaate on, että dokumentit pitäisi aina mahdollisuuden tullen validoida, eli niiden oikeellisuus pitäisi tarkistaa. Selaimet sitä vastoin eivät moisesta hienostelusta tiedä, vaan seuraavat netin löyhempiä periaatteita—lähinnä tämä tarkoittaa, että selaimet hyväksyvät todella monia rakenteita, jotka eivät ole oikeaa HTML‐kieltä. Esimerkkinä ovat merkinnältään virheelliset dokumentit (tyypillisimmillään muotoa <em><strong></em></strong> olevat merkinnät), HTML:n määrittelystä poikkeavien merkkijoukkojen käyttö (vaikkapa ääkkösten käyttö Windowsin standardimerkistöstä ja samalla vaadittava selaimen ohjeistus HTTP‐protokollan otsikkotiedoissa annettavalla merkistöohjeella), HTML:n dokumenttityypissä pakollisiksi merkittyjen elementtien (esim. <html></html>) pois jättäminen ja varsinkin SGML‐käsittelyssä vaadittavien dokumentin otsaketietojen unohtaminen (yksi oikeellinen versio näkyy tämän dokumentin lähdetiedoston ensimmäisenä rivinä). On vahinko, että tällaiset rakenteet sallitaan, sillä moisen kikkailun toimimisesta eri arkkitehtuureilla ei ole mitään takeita. On turha kuvitella että yksikään SGML‐editori suostuisi tekemään virheellisillä dokumenteilla juuri mitään hyödyllistä.

SGML:ssä moni käytännön ongelma on ratkaistu eri tavalla kuin netissä. Niinpä näitä ratkaisutapoja ei välttämättä ole toteutettu selaimissa. Tyypillisiä esimerkkejä ovat SGML:n merkityt sektiot, jotka näkyvät dokumentin lähdekoodissa muodossa <![tyyppi[dataa]]>. Nämä olisivat varsin hyödyllisiä, jos niitä vain uskaltaisi käyttää—ne mahdollistavat dokumentin osien merkitsemisen hylättäviksi vaikka ne kuitenkin parsitaan ja tarkastetaan osana dokumenttia, pitkien tekstikappaleiden merkitsemisen tavallaan ehdollisiksi sekä tekstin jäsentämisen estämisen vaikkapa esimerkin omaisen SGML‐koodin sisällyttämiseksi dokumenttiin ilman että sitä yritetäisiin tulkita validiksi dokumentin osaksi (nythän pitää tageissa käyttää merkkientiteettejä estämään elementtien tunnistaminen).

Toinen tyypillinen eroavaisuus (ja tätä tuetaan vielä harvemmin) on tuki internal DTD subset:ille. Tämä on dokumenttityypin määrittelyyn hakasulkeissa sisällytettävä osa, jolla dokumenttityyppiin pystyy tekemään pieniä muutoksia (esim. määrittelemään uusia entiteettejä ja/tai elementtejä). Tämän mahdollistama dokumentin ulkopuolisten entiteettejen sisällyttäminen olisi kiva ominaisuus, sillä nythän moista inkluusiomahdollisuutta ei välttämättä ole lainkaan (vaikkakin SSI mahdollistaa vastaavan toiminnan selaimen näkymättömissä ja XML tuonee mukanaan sulauttavat linkit).

Pelottavinta kuitenkin on, että selainten yrittäessä hyväksyä vähän mitä sattuu, jotkut SGML:n perusperiaatteet on jätetty huomiotta. Yksi pahimmista ongelmista on tyyli‐informaation käsittely—useimmat selaimet pitävät kerran aloitetut tyylimerkinnät voimassa kunnes ne lopetetaan, vaikka välissä alkuperäisen tyylitagin sisältänyt elementti olisi jo ehtinyt loppua. Tämä on SGML:n näkökulmasta järjetöntä ja kertoo selaimen jättäneen HTML‐dokumentin hyödyllisen sisäkkäisten elementtien hierarkian tulkitsematta kunnolla. Tämän kaltainen käsittely kertoo, että selainten suunnittelijat ovat jättäneet allaolevan SGML‐arkkitehtuurin huomiotta ja lähteneet omille teilleen. Voi hyvin olla, että tällaisiin ominaisuuksiin luottavat sivut eivät enää parin vuoden päästä toimikaan oikein, kun taas oikeelliset sivut jatkuvasti toimivat tukevammin, ja vieläpä useammilla eri selaimilla.

SGML, XML ja HTML

Muutamia vuosia sitten Webin räjähtäessä suuremman yleisön tietoisuuteen HTML‐kielen äkillinen suosio käänsi huomion myös alla lepäävään SGML:ään. Nopeasti todettiin, että edellisessä kappaleessa mainitut puutteet SGML‐tuessa eivät ehkä olleetkaan niin paljon selainvalmistajissa vaan SGML:ssä itsessään—jo aiemminkin teknisen dokumentaation ammattilaiset olivat päivittäisessä työssään törmänneet SGML:n lähes ylitsepääsemättömään monimutkaisuuteen. Niinpä syntyi tarve huomattavasti suoraviivaisemmalle rakenteisen dokumentaation mallille. Näin varsinkin kun HTML:n rajoitukset ja sen laajentamisesta aiheutuneet ongelmat alkoivat vaatia ratkaisukseen SGML:n kaltaista metakieltä jolla Webissäkin voisi tuottaa omia dokumenttityyppejä. Tuloksena tästä syntyi XML, Extensible Markup Language, joka on lähinnä pitkälle yksinkertaistettua SGML:ää.

Käytännössä XML kiinnittää SGML:n ns. deklaraation, joka määrää käytettävissä olevat SGML:n laajennusominaisuudet, merkkijoukon, SGML:n jäsentämiseen käytettävät välimerkit (esim. kulmasulkeet tagien ympärillä) ja erinäisiä kokorajoituksia. XML:ssä kaikki nämä ovat kiinteitä ja yksinkertaisimmissa mahdollisissa asetuksissa. XML myös poistaa SGML:n ns. inkluusio‐ ja ekskluusio‐elementit (nämä sallivat tietyissä rajoissa elementissä sallittavien sisäkkäisten elementtien riippuvan siitä, missä sisältävä elementti esiintyi) sekä yksinkertaisti huomattavasti sääntöjä jotka liittyvät XML‐dokumentin jäsentämiseen. Tuloksena on kieli, joka on tuntuvasti SGML:ää helpompi (ja halvempi) toteuttaa ja sopii varsin kevyisiinkin käyttötarkoituksiin. Lisäksi kielestä ei katoa mitään erityisen merkittävää. XML:ssä myös ennalta määrittelemättömiä dokumenttirakenteita voidaan käyttää, mutta tällöin sovellusten täytyy tietenkin tietää rakenteesta jotakin jotta ne voivat käyttää merkintää hyväkseen.

XML:n merkittävin puoli on kuitenkin sen ympärille nopeasti kehittyvät sovellukset. XML sinänsä on lähes huvittavan yksinkertainen kieli, kun taas sille määritellyt ominaisuudet/laajennokset (kuten nimiavaruudet) sekä sillä määritellyt eri tarkoituksiin käytettävät osakielet (kuten vektorigraafiikkaan tarkoitettu SVG tai matemaattiselle merkinnälle luotu MathML) ovat parhaimmillaan kertaluokkaa monimutkaisempia kuin SGML konsanaan. XML:n suunnittelussa modulaarisuudella on ollut merkittävä osa—ideana on, että SGML:n suurten monoliittisten dokumenttityyppien asemesta määritellään useita pieniä sovelluksia joista sitten XML:n oheisstandardien (nimiavaruudet, XLink/XPointer, XML fragment interchange, XSL jne.) avulla saadaan väsättyä kokonaisia merkityksellisiä dokumentteja.

Niinpä XML onkin ehkä enemmän arkkitehtuuri kuin sen helppo ydinstandardi antaisi ymmärtää. XML lähistandardeineen laajentanee lähivuosina merkittävästi netin mahdollisuuksia esittää rakenteista tietoa ja lienee vähintään yhtä tärkeää opeteltavaa kuin HTML pari vuotta sitten. HTML:ään jo tottuneelle helpoin tapa lienee siirtyä SGML:llä määritellystä HTML:stä XML:llä määriteltyy XHTML:ään—erot ovat pieniä mutta XML‐tuen lisääntyessä uusien standardidokumenttien muotojen hyödyntäminen XHTML:n seassa pitäisi tulla mahdolliseksi ehkä jo varsin piankin.