Käännös: Yoji Hirabayashi, Mikko Kekki ja Pekka Peltonen.

Sisältö

  1. Johdanto
  2. Historiaa
  3. Web-standardit
  4. Rakenne ja esitystapa
  5. (X)HTML
  6. CSS
  7. Esteettömyys
  8. URLit
  9. Referenssit
  10. Sanasto

1. Johdanto

Tämä dokumentti selvittää kuinka ja miksi web-standardien avulla voidaan luoda web-sivusto tavalla, joka ei vain säästä aikaa ja rahaa vaan tarjoaa myös paremman käyttäjäkokemuksen vierailijalle. Lisäksi käsitellään muita metodeja, ohjeistuksia ja hyviä toimintatapoja, jotka auttavat tuottamaan esteettömiä, korkealaatuisia web-sivustoja.

2. Historiaa

Kun Internet 90-luvun puolivälissä löi itsensä läpi, selainkehittäjät eivät olleet sisällyttäneet niihin CSS-tukea niin hyvin, että web-kehittäjät olisivat voineet muotoilla HTML-dokumentin ulkoasua sen avulla. CSS-tuen puute on osittain ymmärrettävää, koska CSS Level 1:n määritykset julkaistiin vuonna 1996 ja CSS Level 2:n vuonna 1998.

CSS-tuen puute selaimissa, yhdistettynä graafikkojen vaatimuksiin kontrolloida ulkoasua yhtä tarkasti kuin mihin printtimediassa oli totuttu, johti väistämättä mielivaltaiseen HTML:n väärinkäyttöön, jonka avulla saavutettiin haluttu lopputulos. Esimerkkinä käänteentekevä ajatus käyttää attribuuttia border=0 piilottamaan rajat taulukolta, jota saattoi käyttää näkymättömänä “verkkona” kontrolloimaan koko esitysasua. Toisena esimerkkinä läpinäkyvä “spacer GIF”-kuva, jonka avulla myös voitiin kontrolloida esitysasua.

Koska HTML:ia ei koskaan tarkoitettu kontrolloimaan dokumentin esitysasua, käytettiin erilaisia “hackeja”, viallista koodia ja selainkohtaisia laajennuksia. Dokumentin oikeellisuuden tarkistus, validointi, oli jotain, josta vain harvat tiesivät tai käyttivät. Tagisoppa -sana kuvaa erinomaisesti tällaista koodia.

Sitä mukaa, kun uusia versioita selaimista julkistettiin, niiden CSS-tukea paranneltiin ja laajennettiin, muttei kuitenkaan niin nopeasti kuin olisi pitänyt. Selainvalmistajien hitaasta CSS-tuen parantamisesta huolimatta olemme nyt siinä pisteessä, että tarpeeksi moni käyttää selainta, jonka CSS-tuki on hyväksyttävällä tasolla, joten ei ole mitään syytä olla käyttämättä HTML:ia siihen, mitä varten se on alunperin kehitettykin: kuvaamaan dokumentin rakennetta, ei esitystapaa. Sitä varten meillä on nimenomaisesti esitystapaa varten kehitetty CSS.

3. Wed-standardit

Mitä ovat web-standardit?

Web-standardit ovat W3C:n ja muiden standardeja kehittävien tahojen hyväksymiä teknologioita, joiden avulla luodaan ja laaditaan web-pohjaista sisältöä. Nämä teknologiat on myös suunniteltu varmistamaan julkaistavien dokumenttien tulevaisuus ja tekemään niistä saavutettavia mahdollisimman monelle.

Rakenteelliset kuvauskielet

Esitysasun kuvauskielet

Objektimallit

Skriptikielet

Tämä dokumentti keskittyy rakenteeseen (XHTML 1.0 Strict), esitystapaan (CSS Level 1 ja Level 2) ja skriptaukseen (ECMAScript 262), mistä ei tosin ole juurikaan esimerkkejä.

Kun dokumentin sanotaan tukeutuvan web-standardeihin, tarkoitetaan sillä, että dokumentti yllämainittujen teknologioiden käyttämisen lisäksi:

Huomaa, “toimii millä tahansa selaimella” ei tarkoita samaa kuin “näyttää samalta kaikilla selaimilla”. Dokumentin näkyminen samanlaisena kaikilla selaimilla on käytännön mahdottomuus. Edes käyttämällä pelkkää kuvaa ei voida taata sivuston näkymistä samanlaisena kaikilla selaimilla. Webissä julkaistuja dokumentteja tarkastellaan monilla erilaisilla päätelaitteilla ja useilla eri käyttöjärjestelmillä, erikokoisilla monitoreilla, joissa on erilaiset asetukset, ilman monitoria sekä käyttäjien omilla asetuksilla (mm. tekstin koko). Hyväksymällä tämän säästät itseäsi turhautumiselta. Jokaisen web-sivuja suunnittelevan tulisikin ymmärtää alansa tekniset perusedellytykset samaan tapaan kuin printtimedian ja elokuva-alan täytyy tuntea omansa.

Miksi pitäisi käyttää web-standardeja?

Jotkut web-kehittäjät ja -suunnittelijat vastustavat web-standardien käyttöä. Yleisiä argumentteja ovat Se on liian vaikeata, Toimii se ilmankin ja Käyttämäni työkalut luovat epäkelpoa koodia.

On helppo reagoida tunteenomaisesti ja suhtautua kielteisesti jonkin uuden oppimiseen ja sellaisten tekniikoiden hylkäämiseen, jotka jo tuntee ja joihin on tottunut. Kuitenkin, jos tilannetta tarkastelee johdonmukaisesti, huomaa, että web-standardien opettelulla ja käyttämisellä on paljon etuja. Muutama esimerkki:

Web-standardit voivat säästää sivuston kehittäjien kustannuksia ja tarjoavat parempia käyttäjäkokemuksia. Sitä paitsi, web-standardit ovat tulevaisuutta. Jos et jo käytä web-standardeja, on aika aloittaa. Muuten saatat jäädä jälkeen kehityksessä.

Lisäluettavaa (englanniksi):

Validointi

Validointi on prosessi, missä tarkistetaan, että dokumentti noudattaa käytetyn merkintäkielen sääntöjä. Toimintaa voisi verrata kirjoitetun tekstin oikeinkirjoituksen ja kielioppisääntöjen noudattamisen tarkistamiseen.

Validointi on tärkeä osa web-sivujen kehittämistä. Moni vaikeasti havaittava virhe selviää validoinnin aikana. Virhe voi olla niinkin yksinkertainen asia kuin näppäilyvirhe tai niin vakava kuin väärin käytetty elementti tai attribuutti.

Valitettavasti moni ei validoi dokumenttejaan. Jotkut eivät ehkä tiedä validoinnista ja toiset unohtavat sen. Lisäksi on niitä, jotka tarkoituksella välttävät validointia. Tästä voidaan syyttää pääasiassa selainvalmistajia. Useimmat selaimet yrittävät tulkita väärinkirjoitettua HTML:ia parhaansa mukaan ja yrittävät arvata kirjoittajan tarkoitusperiä sen sijaan, että näyttäisivät virheilmoituksen. Tällainen toiminta on johtanut huolimattomaan merkintätapaan, joka on hyvin yleistä nykyään. Tällaisen merkintätavan ongelma on siinä, että se johtaa ennalta-arvaamattomiin tuloksiin ja tukeutuu selainten virheensietokykyyn.

Ei ole mitään syytä olla validoimatta HTML:ia ja CSS:ia. Päinvastoin, siitä on vain hyötyä.

Why we won’t help you on Mark Pilgrimin erinomainen selvitys validoinnin eduista. Artikkeli selittää myös, miksi voi olla hankalaa saada apua keskustelufoorumeilta tai postituslistoilta, jos dokumenttia ei ole validoitu ennen avunpyyntöä.

Useissa HTML-editoreissa, kuten BBEditissä ja Homesitessa, on sisäänrakennettuja validointityökaluja. Jos kehitystyökalussa ei ole sellaista, voidaan käyttää W3C:n validointipalvelua, joka löytyy osoitteista:

Validaattoreiden virheilmoituksien ymmärtäminen voi olla joskus hieman hankalaa. Dokumentin alkupään virhe saattaa aiheuttaa useita lisävirheitä. Korjaamalla ensimmäinen virhe ja validoimalla uudelleen voivat virheet vähentyä huomattavasti. Joitakin tavanomaisia virheilmoituksia selitetään Black Widow Web Designin artikkelissa Common XHTML Validation Errors.

Aina kannattaa varmistaa, että koodi on täysin validia, mutta toisinaan validointivirheitä on vaikea välttää. Yleisin esimerkki on Flashin tai jonkun muun lisäohjelmaa (plugin) vaativan sisällön ymppääminen dokumenttiin. Lisälukemista ongelmista Flashin kanssa löytyy artikkeleista Flash Satay: Embedding Flash While Supporting Standards ja Embedding flash without <embed>.

4. Rakenne ja esitystapa

Web-standardeista puhuttaessa mainitaan usein kuinka tärkeätä on erottaa rakenne esitystavasta. Niiden eron ymmärtäminen voi olla aluksi vaikeaa, varsinkin jos ei ole tottunut ajattelemaan dokumentin semanttista rakennetta. Siitä huolimatta, tämän asian ymmärtäminen on tärkeätä, koska esitystavan hallinta CSS:lla helpottuu huomattavasti, jos rakenne ja esitystapa on erotettu toisistaan.

Rakenne koostuu dokumentin pakollisista osista sekä dokumentin sisällön semanttisesta ja rakenteellisesta merkinnästä.

Esitystapa on tyyli, joka annetaan sisällölle. Useimmiten esitystavalla tarkoitetaan dokumentin ulkonäköä, mutta se voi vaikuttaa myös siihen, miltä dokumentti kuulostaa - kaikki eivät käytä graafisia selaimia.

Erota rakenne ja esitystapa toisistaan mahdollisimman tarkkaan. Ihannetapauksessa HTML-dokumentissa on pelkästään rakenne ja sisältö. Esitystapaa hallitaan kokonaan CSS:lla.

Rakenteen erottaminen esitystavasta ei ole järin yleistä webissä tätä nykyä. Useimpien sivustojen HTML-koodista puuttuu paitsi rakenne myös semantiikka.

Taulukot leiskassa

Jotta rakenne voitaisiin erottaa esitystavasta, pitää käyttää CSS:ia taulukoiden sijasta dokumentin esitysasun hallintaan. Taulukoita sivun asetteluun käyttävästä tämä voi tuntua epämukavalta ja oudolta, mutta se ei ole niin vaikeaa kuin miltä se saattaa aluksi näyttää. Internetistä löytyy runsaasti apua ja asialla on niin paljon hyviä puolia, että ajattelutavan muutoksen opiskeluun kannattaa uhrata aikaa.

Lisäluettavaa (englanniksi):

Semanttinen HTML

Toinen tärkeä osa-alue rakenteen ja esitystavan erottamisessa on semanttisen merkinnään käyttäminen dokumentin sisällön rakenteen esittämiseen. Jos sellainen XHTML-elementti, joka on tarkoitettu tietyn sisällön rakenteen kuvaamiseen, on olemassa, ei ole mitään syytä käyttää jotain muuta. Toisin sanoen, älä naamioi CSS:lla jotakin HTML-elementtiä näyttämään joltakin toiselta elementiltä. Esimerkkinä <span>-elementin käyttö <h1>:n sijasta otsikon merkintään.

Käyttämällä semanttista HTML:ia saat dokumentin eri osista merkityksellisiä kaikille selaimille, oli kyse sitten uusimmista graafisista selaimista modernissa PC:ssä, vanhoista selaimista, jotka eivät ymmärrä CSS:ia, tai Unixin tekstipohjaisista selaimista.

Otsikot

Käytä otsikoiden merkintään elementtejä <h1>, <h2>, <h3>, <h4>, <h5> tai <h6> riippuen otsikoinnin hierarkiatasosta. <h1> tarkoittaa ylimmän tason otsikkoa.

Esimerkkejä:
<h1>Otsikko</h1>
<h2>Alaotsikko</h2>

Otsikko

Alaotsikko

Kappaleet

Käytä <p>-elementtiä kappaleiden merkintään. Älä käytä <br />-elementtiä kappalevälien muodostamiseen. Marginaalit kappaleiden välillä määritetään CSS:lla, minkä takia kappaleet on merkittävä oikein.

Esimerkki:
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing
elit. Donec risus. Ed rhoncus sodales metus. Donec adipiscing
mollis neque. Aliquam in nulla.</p>

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec risus. Sed rhoncus sodales metus. Donec adipiscing mollis neque. Aliquam in nulla.

Listat

Lista asioista pitää merkitä listana. XHTML:ssa on käytössä kolmea lajia listoja: järjestämätön lista, järjestetty lista ja määritelmälista.

Järjestämättömät listat (bulleted lists) alkavat <ul>:lla ja päättyvät </ul>:iin. Jokainen listattu asia on <li>-elementin sisällä.

Järjestetyt listat alkavat <ol>:lla ja loppuvat </ol>:iin.

Määritelmälistat ovat hieman erilaisia ja niitä voidaan käyttää listaamaan käsitteitä ja selityksiä. Määritelmälistat alkavat <dl>:lla ja loppuvat </dl>:iin. Jokainen käsite, joka selitetään on <dt>-elementin sisällä ja selitys on yhden tai useamman <dd>-elementin sisällä.

Esimerkkejä:
<ul>
    <li>Asia 1</li>
    <li>Asia 2</li>
    <li>Asia 3</li>
</ul>
<ol>
    <li>Asia 1</li>
    <li>Asia 2</li>
    <li>Asia 3</li>
</ol>
  1. Asia 1
  2. Asia 2
  3. Asia 3
<dl>
    <dt>website</dt>
    <dd>Kokoelma linkitettyjä web-sivuja, 
    jotka edustavat yritystä tai yksityistä henkilöä.</dd>

    <dt>web-sivu</dt>
    <dd>Webin informaation perusyksikkö, 
    joka sisältää tekstiä, kuvia tai muuta vastaavaa.</dd>
</dl>
website
Kokoelma linkitettyjä web-sivuja, jotka edustavat yritystä tai yksityistä henkilöä.
web-sivu
Webin informaation perusyksikkö, joka sisältää tekstiä, kuvia tai muuta vastaavaa.

CSS:n avulla listoja voidaan käyttää, vaikka ei haluttaisi esittää listan sisältöä perinteisen listan muodossa. Navigointipalkki, joka on linkkilista, on hyvä esimerkki tällaisesta. Listamuodon käyttämisestä menu-listana on se etu, että tällainen menu-lista on järkevän näköinen myös selaimilla, jotka eivät tue CSS:ia.

Lainaukset

<q>-elementtiä pitäisi käyttää lyhyitä rivinsisäisiä lainauksia varten. Selaimien pitäisi renderoida lainausmerkit automaattisesti ennen ja jälkeen sisällön, joka on <q>-elementin sisällä. Valitettavasti Internet Explorer ei sitä tee ja joissakin tapauksissa <q>-elementti voi aiheuttaa jopa esteettömyysongelmia. Tämän takia jotkut suosittelevat välttämään <q>-elementtiä ja syöttämään lainausmerkit manuaalisesti. Jos rivinsisäistä lainausta käytetään <span>-elementin sisällä jonkun sopivan luokan (class) kanssa, voidaan CSS:lla muotoilla lainausmerkkejä, mutta tällä ei ole varsinaista semanttista merkitystä. Lue Mark Pilgrimin artikkelista The Q tag yksityiskohtainen selvitys <q>-elementin ongelmista.

Pidempiin lainauksiin, jotka koostuvat yhdestä tai useammasta kappaleesta, pitää käyttää <blockquote>-elementtiä. Lainausta voidaan sitten muotoilla CSS:lla. Huomaa, että teksti ei ole sallittua suoraan <blockquote>-elementin sisällä - teksti pitää sisällyttää toiseen, yleensä <p>-elementtiin.

cite-attribuuttia voidaan käyttää sekä <q>:n että <blockquote>:n kanssa välittämään tieto lainauksen alkuperästä. Jos käytät <span>-elementtiä <q>:n sijasta rivinsisäisiin lainauksiin, et voi käyttää cite-attribuuttia.

Esimerkkejä:
<p>W3C sanoo, että <q cite="http://www.w3.org/TR/REC-html40/
struct/text.html#h-9.2.1">The presentation of phrase elements
depends on the user agent.</q>.</p>

W3C sanoo, että The presentation of phrase elements depends on the user agent..

<p>W3C sanoo, että <span class="quote">&rdquo;The presentation of phrase 
elements depends on the user agent.&rdquo;</span>.</p>

W3C sanoo, että “The presentation of phrase elements depends on the user agent.”.

<blockquote cite="http://www.w3.org/TR/1999/REC-html401-19991224/
struct/text.html">
    <p>&rdquo;The following sections discuss issues surrounding
    the structuring of text. Elements that present text (alignment
    elements, font elements, style sheets, etc.) are discussed
    elsewhere in the specification. For information about characters,
    please consult the section on the document character set.&rdquo;</p>
</blockquote>

“The following sections discuss issues surrounding the structuring of text. Elements that present text (alignment elements, font elements, style sheets, etc.) are discussed elsewhere in the specification. For information about characters, please consult the section on the document character set.”

Korostus

<em>-elementtiä käytetään korostamaan tekstiä ja <strong>-elementtiä voimakkaaseen korostukseen. Useimmat selaimet näyttävät korostetun tekstin kursiivina ja voimakkaasti korostetun lihavoituna. Tämä ei ole kuitenkaan ehdotonta, joten jos halutaan olla varmoja, miten korostettu teksti näytetään, kannattaa niiden esitystapa määrittää CSS:lla. Vältä korostuksen käyttämistä, jos tavoittelet vain visuaalista efektiä.

Esimerkki:
<p><em>Korostettu</em> teksti näytetään normaalisti kursiivina, 
kun taas <strong>voimakkaasti korostettu</strong> teksti 
näytetään yleensä lihavoituna.</p>

Korostettu teksti näytetään yleensä kursiivina, kun taas voimakkaasti korostettu teksti näytetään yleensä lihavoituna.

Taulukot

XHTML:n taulukoita ei pitäisi käyttää ulkoasun määrittelyyn eli layoutiin. Sen sijaan niitä pitäisi käyttää taulukkomuotoisen datan esittämiseen. Datataulukoiden saavutettavuuden varmistamiseksi on tärkeätä tietää erilaisista osasista, joista taulukko voi koostua, ja käyttää niitä. Esimerkkeinä taulukko-otsikot (<th>), yhteenvedot (summary-attribuutti) ja oheistekstit (<caption>-elementti).

Esimerkki:
<table class="example" summary="Tämä taulukko esittää Ruotsin 
vuosittaisen väestönkasvun vuosina 1999–2003.">
    <caption>Ruotsin vuosittainen väestönkasvu
    1999–2003</caption>
    <thead>
        <tr>
            <td>&#160;</td>
            <th scope="col">1999</th>
            <th scope="col">2000</th>
            <th scope="col">2001</th>
            <th scope="col">2002</th>
            <th scope="col">2003</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <th>Väestömäärä</th>
            <td scope="row">8 861 426</td>
            <td scope="row">8 882 792</td>
            <td scope="row">8 909 128</td>
            <td scope="row">8 940 788</td>
            <td scope="row">8 975 670</td>
        </tr>
        <tr>
            <th>Lisäys</th>
            <td scope="row">7 104</td>
            <td scope="row">21 366</td>
            <td scope="row">26 368</td>
            <td scope="row">31 884</td>
            <td scope="row">34 882</td>
        </tr>
    </tbody>
</table>
Ruotsin vuosittainen väestönkasvu 1999–2003
  1999 2000 2001 2002 2003
Väestömäärä 8 861 426 8 882 792 8 909 128 8 940 788 8 975 670
Lisäys 7 104 21 366 26 368 31 884 34 882

Tarkempia kuvauksia taulukoista ja niiden käytöstä löytyy artikkeleista Tables in HTML documents ja HTML Techniques for Web Content Accessibility Guidelines 1.0.

Lisäluettavaa (englanniksi):

5. (X)HTML

HTML 4.01:tä voi käyttää modernin, järjestetyn ja standardeja noudattavan sivun koostamiseen. Siitä huolimatta, XHTML 1.0 Strictin käyttö on suositeltavaa uusille verkkosivuille, jotta siirtymä puhtaan, semanttisesti oikeoppisen kuvauskielen käyttöön ja valmistautuminen mahdolliseen siirtymään XML:n ja muiden tulevaisuuden kielten käyttöön olisi helpompaa. Strictiä käytetään myös tämän sivun esimerkeissä.

XHTML 1.0 on HTML 4 uudelleen muotoiltuna XML 1.0:n kieliopin mukaan. XHTML 1.0 kehitettiin korvaamaan HTML. Strict-versio, jota suosittelen käyttämään, ei salli esitystapaan liittyvää merkintää (kuten ei salli HTML 4.01 Strictkään). Tämän takia XHTML 1.0 Strict pakottaa erottamaan rakenteen esitystavasta.

XHTML 1.1, joka on uusin versio XHTML:stä, on teknisesti hieman monimutkaisempi käyttää, koska spesifikaatio esittää, että XHTML 1.1 -dokumentit pitäisi tarjota MIME-tyypillä application/xhtml+xml. text/html-tyypin käyttö ei ole kiellettyä, mutta ei suositeltuakaan. XHTML 1.0 taas voi käyttää MIME-tyyppiä text/html. W3C:n dokumentti XHTML Media Types sisältää yleiskatsauksen mahdollisiin MIME-tyyppeihin.

Valitettavasti jotkut vanhemmat selaimet ja Internet Explorer eivät tunnista MIME-tyyppiä application/xhtml+xml, ja saattavat näyttää lähdekoodin suoraan, tai jopa kieltäytyä näyttämästä koko dokumenttia.

Jos haluat käyttää MIME-tyyppiä application/xhtml+xml, anna palvelimen testata kykeneekö sivua pyytänyt selain käsittelemään sitä ja tarjoa sivu sen mukaan selaimelle sopivaa tyyppiä käyttäen.

Jos käytät PHP:ia palvelinpuolen skriptaamiseen, voit käyttää seuraavaa skriptiä tarjoamaan dokumentteja eri MIME-tyypeillä eri selaimille:

<?php
if (stristr($_SERVER["HTTP_ACCEPT"], "application/xhtml+xml") || 
stristr($_SERVER["HTTP_USER_AGENT"],"W3C_Validator")) {
    header("Content-Type: application/xhtml+xml; charset=iso-8859-1");
    header("Vary: Accept");
    echo("<?xml version=\"1.0\" encoding=\"iso-8859-1\"?>\n");
    }
else {
    header("Content-Type: text/html; charset=iso-8859-1");
    header("Vary: Accept");
    }
?>

Skripti tarkistaa lähettääkö käyttäjä (user agent) Accept HTTP headerin, joka sisältää arvon “application/xhtml+xml”, vai onko käyttäjä W3C HTML Validator, joka ei lähetä sopivaa Accept HTTP headeria mutta silti pystyy käsittelemään application/xhtml+xml:ia. Jos jompikumpi näistä ehdoista täyttyy, dokumentti tarjotaan muodossa application/xhtml+xml. Näille selaimille lähetetään myös XML-deklaraatio. Muille selaimille, mukaan lukien kaikki Internet Explorerin versiot, tarjotaan dokumentti muodossa text/html. XML-deklaraatiota ei lisätä dokumenttiin, koska se asettaisi IE/Winin Quirks-tilaan (Quirks mode), mitä emme halua.

Content-Type headerin jälkeen lähetetään Vary header, joka kertoo välimuisteille, kuten proxy-palvelimille, että sisällön muoto vaihtelee dokumenttia hakeneen käyttäjän mukaan.

Kehittyneempi PHP-skripti sisällön tarjoamiseen tilanteen mukaan löytyy artikkelista Serving up XHTML with the correct MIME type. Tuo skripti ottaa huomioon, kuinka hyvin käyttäjä (user agent) väittää hallitsevansa tietyn MIME-tyypin (q-rating) ja muuntaa XHTML:n HTML 4:ksi ennen kuin lähettää dokumentin muodossa text/html niille käyttäjille, jotka eivät pysty käsittelemään muotoa application/xhtml+xml.

Tässä on samankaltainen skripti ASP- ja VBScript-kieliä käyttäville:

<%
If InStr(Request.ServerVariables("HTTP_ACCEPT"), "application/xhtml+xml") > 0 
Or InStr(Request.ServerVariables("HTTP_USER_AGENT"), "W3C_Validator") > 0 Then
    Response.ContentType = "application/xhtml+xml"
    Response.Write("<?xml version=""1.0"" encoding=""iso-8859-1""?>" & VBCrLf);
Else
    Response.ContentType = "text/html"
End If
Response.Charset = "iso-8859-1"
%>

Huomaa, että käyttäessäsi MIME-tyyppiä application/xhtml+xml, jotkut selaimet, kuten Mozilla, eivät näytä virheitä sisältäviä dokumentteja ollenkaan. Se voi olla hyvä asia sivuston kehitysvaiheessa, mutta aiheuttanee ongelmia käyttöönotetulla sivulla, jota päivittävät muutkin kuin XHTML-asiantuntijat, ellet pysty varmistamaan, että kaikki koodi säilyy validina. Siinä tapauksessa HTML 4.01 Strict voi olla parempi vaihtoehto.

Seuraavassa lista tärkeimmistä asioista siirryttäessä XHTML:n käyttöön HTML:n sijasta:

Lisäluettavaa (englanniksi):

Doctype eli dokumenttityyppi

Tällä hetkellä hyvin harvoille HTML-dokumenteille on määritetty oikea ja täydellinen dokumenttityyppi tai DTD (Document Type Declaration). Aiemmin se olikin lähinnä enemmänkin kosmeettinen kuin toiminnallinen osa dokumenttia. Muutama vuosi sitten dokumenttityypin määrittely alkoi vaikuttaa siihen, miten selain dokumentin esittää.

Kaikkien HTML- ja XHTML-dokumenttien täytyy määrittää dokumenttityyppi ollakseen valideja. Dokumenttityyppi määrää, mitä HTML- tai XHTML-versiota dokumentissa käytetään. Validaattori käyttää sitä validoimiseen ja selaimet käyttävät sitä päättäessään, mitä sivujen esitysmoodia käytetään. Jos oikea ja kokonainen dokumenttityypin määrittely löytyy dokumentista, monet selaimet asettuvat standardimoodiin, joka tarkoittaa, että ne seuraavat CSS-spesifikaatiota tarkemmin. Dokumentti myös saadaan nopeammin esiin, koska selaimen ei tarvitse tulkita ja yrittää toteuttaa epävalidia HTML:ää. Tämä myös vähentää eroja lopputuloksessa selainten välillä.

Seuraava dokumenttityyppi ilmoittaa, että dokumentti on XHTML 1.0 Strict-tyyppiä ja saa selainten niin sanotun “doctype switching”-toiminnon asettamaan ne standardimoodiin.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
Lisäluettavaa (englanniksi):

Merkistökoodaus

Kaikkien XHTML-dokumenttien pitää määrittää käytetty merkistökoodaus.

Paras tapa määrätä merkistökoodaus on asettaa verkkopalvelin lähettämään käytetty merkistökoodaus HTTP content-type-headerin mukana. Yksityiskohtaisia ohjeita tämän tekemiseen löydät käyttämäsi palvelinohjelmiston dokumentaatiosta.

Jos käytössä on Apache, voidaan merkistökoodaus määrittää lisäämällä yksi tai useampi sääntö .htaccess- tiedostoon. Esimerkiksi, jos kaikki tiedostot halutaan käyttämään utf-8:aa:

AddDefaultCharset utf-8

Tietty merkistökoodaus voidaan määritellä tiedostopäätteen perusteella:

AddCharset utf-8 .html

Jos palvelin tukee PHP-skriptejä, merkistökoodaus voidaan määrätä seuraavasti:

<?php
    header("Content-Type: application/xhtml+xml; charset=utf-8");
?>

Jos haluat tarjota sivusi HTML-muodossa, vaihda application/xhtml+xml muotoon text/html. Jos verkkopalvelinta ei jostain syystä saada määräämään merkistökoodausta oikein, voidaan käyttää <meta>-elementtiä dokumentin <head>-osassa. Se on hyvä tapa määrätä merkistökoodaus, vaikka palvelin olisikin oikein konfiguroitu.

Esimerkiksi seuraava <meta>-elementti kertoo selaimelle, että dokumentti käyttää ISO-8859-1 -merkistökoodausta:

<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1" />
Lisäluettavaa (englanniksi):

6. CSS

Aikoinaan lähinnä fonttien määrittelemiseen käytettyä CSS:ia voidaan nykyään käyttää kontrolloimaan koko esitysasua. Se kuitenkin vaatii täysin erilaisen lähestymistavan verrattuna taulukoilla toteutettuun vastaavaan.

Rakenteellisesti oikea ja semanttinen XHTML on välttämätöntä, jotta CSS:n avulla voidaan kontrolloida esitysasua tehokkaasti.

Selainten tuki

Kuten jo aiemmin mainittiin, selainten CSS-tuki on parantunut huomattavasti muutaman viime vuoden aikana. Valitettavasti kaikki selainkehittäjät eivät näytä olevan kiinnostuneita sisällyttämään avoimia standardeja, joten CSS-tuen taso vaihtelee selainkohtaisesti. Tämän lisäksi selaimissa on bugeja eli ohjelmiston suunnitteluvirheitä, jotka saavat selaimet käyttäytymään toisin kuin olisi tarkoitus.

Kirjoitushetkellä (2004) parhaiten CSS:ia tukevat selaimet ovat Mozilla (ja muut Mozillan ydintä käyttävät selaimet: Firefox, Camino, Netscape 6+), Opera ja Safari (ja muut WebCorea käyttävät selaimet: OmniWeb 4.5 ja uudemmat). Internet Explorer 6/Win ei sisällä yhtä hyvää CSS-tukea, mutta kuitenkin sen verran, että perusasiat onnistuvat myös siltä. Internet Explorer 5/Mac! tukee erittäin hyvin CSS 1:n määrityksiä, mutta vain rajoitetusti CSS 2:n määrityksiä. Windowsin IE 5.*-selaimet tukevat myös suurimmalta osin, joskin niissä on tiettyjä puutteita, jotka tulee tiedostaa. Sama pätee Netscapen 6-versiota edeltäviin versioihin.

Koska tällä hetkellä suurin osa ihmisistä käyttää Windowsin Internet Exploreria, on se yleensä asetettava pienimmäksi yhteiseksi nimittäjäksi. Ei kuitenkaan pidä kuvitella, ettei paremmin CSS:ia tukevien selainten ominaisuuksia voisi tai tulisi käyttää hyväkseen, kun halutaan tarjota niille paranneltu esitysasu.

Kaikissa nykyisin käytössä olevissa selaimissa ei ole sen tason CSS-tukea, että ne kykenisivät renderöimään CSS:lla toteutetun sivuston graafisesti miellyttävällä tavalla. Onneksi useilla sivustoilla vain muutamalla prosentilla vierailijoista on käytössään niin vanha selain, ettei se kykene renderöimään kunnolla CSS:lla toteutettua ulkoasua.

On kuitenkin tärkeää, ettei näitä henkilöitä jätetä ulkopuolelle. 90-luvulla oli muotia ohjata JavaScriptin avulla “väärän” selaimen (yleensä kaikki muut paitsi Windows Internet Explorer) käyttäjät sivulle, jossa oli kehotus päivittää selain sivustolle pääsyn varmistamiseksi.

Nykyään tähän on parempiakin tapoja. Eräs loogisen, semanttisen merkinnän suurimmista eduista on se, että dokumentit ovat esteettömiä ja käytettäviä ilman CSS-tukeakin. Esitysasu - tapa, jolla dokumentti näytetään - ei ole samanlainen kuin CSS:ia tukevissa selaimissa, mutta sisältö on silti saavutettavissa. Useimmissa tapauksissa ja useimmille vierailijoille sivuston sisältö on tärkeämpää kuin tapa, jolla se esitetään. Tästä syystä on parempi näyttää sivu ilman CSS:ää kuin jättää heidät kokonaan sivuston ulkopuolelle.

Tämän voi toteuttaa useallakin tavalla. Eräs yleisimmistä on linkittää CSS-tiedostoon @import-menetelmän avulla. Netscape 4 ja vanhemmat selaimet eivät ymmärrä sitä eivätkä näinollen käytä CSS-tiedostoa. On olemassa myös useita muita tapoja piilottaa CSS selaimilta. Useimmat niistä käyttävät hyväkseen tunnettuja bugeja selainten CSS-toteutuksessa. Tämä tarkoittaa myös sitä, että aina on olemassa riski, että päivitys korjaa bugin, jonka avulla CSS on piilotettu selaimelta, muttei ongelmaa, jonka vuoksi CSS on alunperin piilotettu. Sen vuoksi on parempi välttää näitä “hackejä” mahdollisimman pitkälle.

Myös palvelinpuolen tekniikoita voidaan käyttää selain-tarkistukseen ja tarkistuksen avulla lähettää oikea CSS-tiedosto (tai olla lähettämättä sitä ollenkaan) eri selaimille.

Lisäluettavaa (englanniksi)

Erilaisia tapoja liittää CSS

CSS:n voi liittää HTML-dokumenttiin monella tavalla.

Ulkoinen

CSS:n ulkoistamisessa yhdeksi tai useammaksi ulkoiseksi tiedostoksi on useita etuja. HTML-dokumentin koko pienenee ja CSS-tiedosto tallentuu selaimen välimuistiin ja se tarvitsee ladata vain kerran. Voit lisäksi hallita yhden tiedoston avulla kokonaisen sivuston ulkoasua. Ulkoinen CSS-tiedosto saattaa näyttää tältä:

h1 {
    font-weight:bold;
}

Huom: <style> -elementtiä ei käytetä ulkoisessa CSS-tiedostossa.

Voit liittää CSS-tiedoston HTML-dokumenttiin käyttämällä <link>-elementtiä:

<link rel="stylesheet" type="text/css" href="styles.css" />

tai käyttämällä @import sääntöä <style> elementtiin:

<style type="text/css">
@import url("styles.css");
</style>

Rivinsisäinen

Käyttämällä style-atribuuttia, voit liittää CSS:n suoraan HTML-elementtiin:

<h1 style="font-weight:bold;">Rubrik</h1>

Tätä tulisi välttää, koska siinä sekoitetaan rakennetta ja esitytapaa.

Sisäinen

Sisäinen CSS liitetään dokumenttiin <style>-elementin avulla, joka sisältyy dokumentin <head>-elementtiin:

<style type="text/css">

h1 {
    font-weight:bold;
}
</style>

Tätäkin tulisi välttää, koska on parasta erottaa HTML ja CSS eri tiedostoihin.

Lisäluettavaa (englanniksi):

CSS-syntaksi

CSS-sääntö koostuu selektorista ja yhdestä tai useammasta deklaraatiosta. Selektori määrittelee HTML-elementin, johon sääntöä sovelletaan. Jokainen deklaraatio koostuu ominaisuudesta ja arvosta. Deklaraatio-lohko aloitetaan {-merkillä ja suljetaan }-merkillä. Jokainen deklaraatio suljetaan puolipisteellä (;).

Yksinkertainen CSS-sääntö:

p {
    color:#0f0;
    font-weight:bold;
}

Tässä, p on selektori, jolloin sääntöä sovelletaan kaikkiin dokumentin <p>-elementteihin. Säännössä on kaksi deklaraatiota, jotka kertovat selaimelle, että <p>-elementin teksti on vihreää ja lihavoitu.

Yksityiskohtaisempaa kuvausta varten kannattaa tutustua seuraaviin oppaisiin: CSS Beginner's Guide, CSS from the Ground Up tai johonkin CSS-kirjaan.

Lisäluettavaa (englanniksi):

Ylimääräiset elementit ja luokat

Kun aloittaa tutustumisen CSS:iin, eräs yleisimmistä virheistä on tarpeettomien XHTML-elementtien, ylimääräisten luokkien sekä <div>-elementtien käyttö. Tämä ei välttämättä tarkoita sitä, ettei koodi olisi validia, mutta tässä kohdataan yksi syy siihen, miksi rakenne pitäisi erottaa ulkoasusta: näin saadaan aikaiseksi yksinkertaisempaa ja puhtaampaa merkintää.

Esimerkki tarpeettoman merkinnän käytöstä:

<h3><em>Headline</em></h3>

Mikäli otsikko halutaan kursivoida, kannattaa käyttää CSS:ia <h3>-elementtiin:

h3 {
    font-style:italic;
}

Liiallinen luokkien käyttö voi näyttää tältä:

<div id="main">
    <div class="maincontent">

        <p class="maincontenttext">
            Lorem ipsum dolor
        </p>
    </div>
</div>

Se voidaan korvata näin:

<div id="main">
    <div>
        <p>
            Lorem ipsum dolor
        </p>
    </div>
</div>

Elementtien kontrolloimiseksi div#main-lohkon sisällä, voidaan CSS:ssa käyttää kontekstuaalisia selektoreita. Tässä tapauksessa näin:

div#main p {
    /* rules */
}

Useimmissa tapauksissa CSS:ia voidaan käyttää tyylittelemään looginen XHTML-dokumentti ilman ylimääräistä merkintää. Joskus ylimääräinen merkintä on kuitenkin vaivan arvoista.

CSS-vinkkejä

Kun aloitat vakavamman CSS:n käytön, törmäät luonnollisesti jossain vaiheessa jonkinlaisiin ongelmiin. Jotkut aiheutuvat väärinymmärryksestä, toiset taas epäselvästä spesifikaatiosta tai viallisesta selaimesta. CSS Crib Sheet (suomeksi) on Dave Shean kokoelma hyviä neuvoja. Tässä muutama tärkein:

CSS-taitot

Verkosta löytyy useita esimerkkejä ja askel-askeleelta-oppaita CSS-taiton luomiseksi. Kannattaa aloittaa yksinkertaisesta, opetella, kuinka se toimii, ja sitten vasta siirtyä vaativampiin toteutuksiin.

Lisäluettavaa:

7. Esteettömyys

Esteettömyys ei tarkoita vain eri asteisista rajoituksista kärsivien huomioonottamista, joskin se on eräs suurimmista yksittäisistä syistä luoda sivustosta esteetön. Esteetön sivusto toimii paremmin kaikilla käyttäjillä. Samalla se on useamman henkilön saavutettavissa, useammalla eri selaimella ja useammalla eri laitteistolla.

Yleinen harhaluulo on, että esteetön sivusto on vähemmän viehättävä tai erilainen kuin esteellinen. Tämä ei pidä paikkaansa. Esteettömyyden ei tarvitse vaikuttaa esitysasuun mitenkään.

Esimerkki siitä, kuinka esteettömyys voi olla avuksi kaikille: Sivustolla on lomake, jonka avulla voidaan rekisteröityä seminaariin. Lomakkeelta voi valita yhden kolmesta vaihtoehtoisesta kaupungista. Jokainen kaupunki on radio-napin vieressä. Mikäli lomakkeen tekijä ei ole huolehtinut esteettömyydestä, graafista selainta käyttävien tulee valita pieni radio-nappi ja aktivoida se. Mikäli esteettömyys on tekijälle tuttua ja hän on merkannut radio-napit asiaankuuluvasti <label>-elementillä, on käyttäjällä mahdollisuus klikata pelkkää kaupungin nimeä tehdäkseen valintansa. Kumpi näistä on lomakkeen täyttäjän kannalta yksinkertaisempaa?

Käyttämällä semanttista koodausta hyvin muotoiltu XHTML vie pitkän matkaa lähemmäs esteettömyyttä. Ymmärtääksesi esteettömyyden perusidean, vilkaise dokumenttia tekstipohjaisella selaimella, kuten Lynx, ja tarkista saako dokumentista vielä selvää. Tämä ei tietenkään ole ainoa asia esteettömyyden arvioimisessa, mutta se on hyvä alku.

Kehykset

Monet web-suunnittelijat käyttävät kehyksiä erottamaan selainikkunan useaan itsenäiseen osaan, joista jokaisessa on erillinen HTML-dokumentti. Tämä saattaa joskus olla hyödyksi, esimerkiksi intranet-sovelluksissa. Julkisella sivustolla kyseisellä tekniikalla on useita haittapuolia:

Sitäpaitsi, teet asiat vain hankalammiksi itsellesi. Kehysten käyttö tekee sivustosta teknisesti monimutkaisemman.

Taulukot

On yleistä tulkita kehotus “älä käytä taulukoita layoutiin” samaksi kuin “älä käytä taulukoita ollenkaan”. Näin sitä ei kuitenkaan pitäisi tulkita. Mikäli olet merkitsemässä taulukkomuotoista dataa, se kuuluu taulukkoon ja sitä tulee siihen myös käyttää. Huomaa kuitenkin, kun luot taulukkomuotoista dataa, että on useita tapoja tehdä siitä loogisempi ja esteettömämpi.

Lisäluettavaa (englanniksi):

Lomakkeet

Lomakkeet ovat usein tarpeettoman vaikeakäyttöisiä, koska ne on luotu epäloogisesti. Toisaalta saattaa olla, että koodi pinnan alla ei käytä hyväkseen olemassaolevia elementtejä, joiden avulla lomakkeista saadaan esteettömämpiä ja helppokäyttöisempiä. Elementit <label>, <fieldset> ja <legend> ovat olemassa ja ne ovat tarkoitettu käytettäviksi.

Eräs yleisimpiä kysymyksiä onkin, kuinka muotoilla lomake. Jotkut ovat sitä mieltä, että lomakkeet ovat taulukkomuotoista dataa ja näin ollen ne tulisi merkitä taulukon avulla. Toiset taas ovat sitä mieltä, että lomakkeet tulisi muotoilla CSS:n avulla. Käytät sitten kumpaa tapaa tahansa, pidä huoli siitä, että lomakkeessa on järkeä ja se on käytettävissä, mikäli sitä ylläpitävä taulukko linearisoidaan.

Lisäluettavaa (englanniksi):

JavaScript ja evästeet

Vältä nojautumista JavaScriptiin. Useammat ihmiset kuin uskotkaan, ovat asettaneet JavaScript-tuen pois päältä selaimestaan, oli syynä sitten tietoturva tai popup-ikkunat. He saattavat myös käyttää selainta, jossa ei edes ole tukea JavaScriptille. Esimerkiksi The Counter.comin mukaan kuudella prosentilla surffajista ei ole JavaScriptia käytössä. W3Schools.com kertoo luvuksi kahdeksan prosenttia.

Useimmissa tapauksissa JavaScriptin käyttö ei hyödytä vierailijaa mitenkään. Tietysti on olemassa tilanteita, joissa JavaScriptin avulla voidaan parantaa käyttäjäkokemusta. Yksi esimerkki tästä on lomakekenttien tarkistus.

Huomaa, ettei edellämainittu tarkoita sitä, että JavaScriptista tulisi luopua, vaan sitä, että pitäisi välttää tekemästä sivustoa, jonka toiminta vaatii JavaScript-tukea.

Sama pätee evästeisiin. Älä käytä evästeitä siten, että niiden torjuminen estää koko sivuston toiminnan.

8. URLit

Tämä osuus ei varsinaisesti käsittele web-standardeja tai saavutettavuutta. Se on mukana sen takia, että tapa, miten sivuston osoitteet (URL) muodostetaan, voivat vaikuttaa huomattavasti siihen, miten hakukoneet indeksoivat sivuston ja miten käytettävä sivusto on kävijöilleen.

Jotkut hakukoneiden robotit eivät seuraa linkkejä, jotka loppuvat hakulausekkeeseen (query string). Tällainen URL on yleinen sivustoilla, jotka hakevat sisältönsä dynaamisesti tietokannasta, ja näyttää vaikkapa tällaiselta:

http://yourdomain.com/products.asp?item=34627393474632&id=4344

Helpoin tapa rakentaa URL niin, että se on paremmin robottien ja ihmisten käytettävissä, on muuttaa se näyttämään siltä kuin se osoittaisi hakemistoon. Edellä mainittu esimerkki voitaisiin muuttaa tällaiseksi:

http://yourdomain.com/products/item/34627393474632/id/4344/

Palvelin tulkitsee uuden URLin sisäisellä prosessilla ja muuntaa sen takaisin alkuperäiseen muotoon. Tämän osion lopussa on muutama linkki sivustoille, joissa on lisää tietoa, miten tämän voi tehdä.

Vielä parempi, vaikkakin hivenen mutkikkaampi, tapa URLien muuttamiseen on näkyvien URLien täydellinen uudelleenkirjoittaminen ihmisille lukukelpoiseen muotoon:

http://yourdomain.com/products/flowers/tulips/

Tällaisten osoitteiden etuna on, että hakurobotit luokittelevat sivun paremmin, ihmisten on helpompi lukea osoitteita ja vältetään paljastamasta, millaista palvelinteknologiaa käytetään sivuston rakentamiseen. Koska URLit eivät sisällä palvelinkohtaisia tiedostopäätteitä, kuten .asp, .cf, .cgi tai .jsp, on mahdollinen teknologian vaihto helpompaa.

Jos osoitteissa käytetään hakulausekkeita, on tärkeää muuntaa jokainen &-merkki HTML-vastineekseen &amp;. Jos näin ei tehdä, jotkut selaimet tulkitsevat (varsin oikeutetusti) merkin HTML-kokonaisuuden aluksi. Jos &-merkkiä seuraava teksti vastaa jotakin HTML-kokonaisuutta, muuntaa selain URLin ja useimmissa tapauksissa rikkoo hakulausekkeen.

Toinen mainitsemisen arvoinen asia on, että useimmille sivustoille aladomain www on tarpeeton ja http://yourdomain.com/-osoitetta pitäisi käyttää http://www.yourdomain.com/-osoitteen sijasta. Lisätietoa tästä aiheesta löytyy osoitteesta no-www.org. Käytät aladomainia www tai et, kannattaa asettaa palvelin toimimaan niin, että kaikki liikenne osoitteisiin http://www.yourdomain.com/ ja http://yourdomain.com/ päätyy samaan URIin.

Lisäluettavaa (englanniksi):

9. Referenssit

Valikoima suositeltavia kirjoja, web-sivuja ja postituslistoja

Kirjoja

CSS

Web-suunnittelu yleisesti

HTML

Esteettömyys

WWW-standardit

XHTML

10. Sanasto

Esteettömyys
Esteetön sivusto on saavutettava ja käytettävä kaikille vierailijoille, riippumatta käytössä olevasta laitteistosta tai ohjelmistosta.
CSS (Cascading Style Sheets)
Säännöt, jotka kuvaavat kuinka dokumentti esitetään.
HTML (HyperText Markup Language)
Käytetään merkitsemään dokumentin rakennetta.
Esitysasu
Sivuston ulkoasu.
Rakenne
Dokumentin sitova osa sekä looginen sisällön merkintä.
Merkintä
Dokumentin merkinnällä annat sen sisällölle rakenteen ja merkityksen.
Validointi
Validointi on prosessi, missä tarkistetaan, että dokumentti noudattaa käytetyn merkintäkielen sääntöjä. Sitä voi verrata kirjoitetun tekstin oikeinkirjoituksen ja kielioppisääntöjen noudattamisen tarkistamiseen.
W3C (World Wide Web Consortium)
Organisaatio, joka kehittää spesifikaatioita, ohjeistuksia ja työkaluja webiin.
Web-standardit
Web-standardit ovat W3C:n ja muiden standardoinnista vastaavien tahojen vakiinnuttamia teknologioita, joita käytetään luomaan ja tuottamaan web-pohjaista sisältöä.
XHTML (Extensible HyperText Markup Language)
HTML uudelleenmuotoiltuna seuraamaan XML:n sääntöjä.
XML (Extensible Markup Language)
Merkintäkieli, joka näyttää HTML:lta, mutta antaa tekijän kuvailla datan käyttämällä sopivia elementtejä.

Kommentteja, kysymyksiä tai ehdotuksia? Kerro meille.

© Copyright 2004 Roger Johansson - Käännös: Yoji Hirabayashi, Mikko Kekki ja Pekka Peltonen.