Validi vain etusivultaan?

Aina kun joku ison firman saitti saadaan validina ulos, standardipiireissä kohistaan ja iloitaan. Erittäin usein on kuitenkin vaivauduttu siivoamaan ainostaan etusivu. Alasivut voivat olla virheitä täynnä, mutta kukaan ei keksi enää parannettavaa. What more could you want? Indeed.

Esimerkiksi kelpaa tämä nyt kohistava AT&T, jolla tosin ymmärtääkseni oli ennenkin validi etusivu, nyt vain graafinen ilme muuttui. Satunnaisotannalla löysin vain yhden alasivun, joka validoitui. Miksi tavoitella validia koodia vain etusivulla? Siksi, että voisi paistatella alan piirien myötähyminässä? Kehno motiivi, mutta sentään motiivi ohjaa oikeaan suuntaan. Mozilla-kehittäjä Henri Sivosen mainioon listaan HOWTO Spot a Wannabe Web Standards Advocate (via) voisi siis lisätä yhden kohdan.

Verkkosivuille linkittäminen

Mikko Heikkinen kirjoittaa linkkaamisen vaikeudesta. Fennican viitteisiin tai hakutuloksiin linkkaaminen on mahdotonta huonon sessionhallinnan tuloksena. Todennäköisesti taustalla olevaa järjestelmää ei ole alun perin verkkokäyttöön suunniteltukaan, mikä ei tietenkään ole mikään perustelu.

Samanlaista käyttäjien ja oman liiketaloutensa kiusaamista harrastavat monet suomalaiset verkkokaupat. Ensimmäisenä tulee kirjoista mieleen Suomalainen kirjakauppa, jonka kehykseen voi kyllä linkata, mutta kirjan esittelysivulta ei pääse takaisin itse kauppaan mitenkään.

Samankaltaisesti käyttäytyy jopa Suomen suurin verkkokauppa, NetAnttila, jonka tuotteiden osoitteita voi yrittää poimia kehyksen kautta, mutta nämä linkit vain vaikuttavat toimivan, aivan kuten Fennican tapauksessa. Viallisia, sessionaikaisia linkkejä tarjoillaan myös kerro ystävälle ja tulosta tämä sivu -toimintojen alla. Vain todella nokkela keksii, että vasta oikeasti linkin itselleen lähettämällä saa myös oikeasti toimivan osoitteen.

Kehyksiä surutta käyttävään vero.fi -palveluun linkkaaminen sen sijaan onnistuu ainakin teoriassa kikkailematta. Etusivulta kolmen klikkauksen päässä on ohje Linkittäminen/viittaaminen vero.fi -palveluun. Ohjeet ovat seikkaperäiset ja ymmärrettävät, mutta tuskin tulee mieleen, että tällainen ohje voisi edes olla olemassa. Linkki ohjeeseen tai mieluummin valmis linkki sivuun pitäisi olla joka sivulla. Kun kerran joka sivuun kuitenkin tulostetaan sen ID, voisi samalla tulostaa myös tekstin linkki tähän sivuun toimivalla linkillä varustettuna.

Verkkokaupan pitäjien varsinkin pitäisi tajuta, että linkit ovat niille ilmaista mainosta ja siten elintärkeitä sisääntulevan liikenteen lähteitä. Kehyksistä on hyvin vähän oikeaa hyötyä, varsinkin kun toisessa vaakakupissa painaa reippaasti lisääntyvä kävijämäärä. Hakukoneissakin menestyy, kahdesta syystä: linkit kasvattavat PageRankia ja kehyksettömän sivun indeksoivat hakukoneet kuin hakukoneet ilman ongelmia.

Verkkokaupassa kävijöiden määrän maksimointi on ensisijainen asia, sillä siitä riippuu hyvin suoraan liiketoiminnan tulos, mutta hyvin tärkeää se on myös pelkästään viestinnällisillä sivustoilla. Toivottavasti kehykset, hölmö sessionhallinta ja varsinkin näiden kuolettava yhdistelmä poistuvat käytöstä mahdollisimman nopeasti.

SmartyPants ja suomen kieli

“ on vasen lainausmerkki (“). Suomessa sitä ei käytetä, vaan lainauksen aloittava ja lopettava merkki on sama, eli oikea lainausmerkki ” (”). Sama koskee puolilainausmerkkejä, eli tyypillisimmin apostrofeja (heittomerkkejä): ’ (’) aloittaa ja lopettaa lainauksen. Vasenta heittomerkkiä ‘ (‘) ei suomen kielessä käytetä.

SmartyPants on fiksu pikku apuohjelma, joka muun muassa konvertoi lainausmerkkien sijaan yleisesti ja virheellisesti käytetyt tuumamerkit oikeiksi HTML-entiteeteikseen. Se ei kuitenkaan ota huomioon käytettävää kieltä. Otettuani SmartyPantsin PHP-version käyttöön, totesin tämän ongelman. Osoittautui, että ongelmaan oli helppo ratkaisu.

Korvasin SmartyPantsin koodista kaikki viitteet vasempaan lainausmerkkiin ja puolilainausmerkkiin, eli korvasin kaikki viittaukset “:aan ”:lla ja ‘:aan ’:lla. Ensin mainittuja löytyi kaksitoista ja seuraavia yhdeksän. Hyvin tuntuu nyt pelaavan, tiedä sitten mitä menin rikkomaan.

Lähteenä käytin Markus Itkosen mainiota Typografian käsikirjaa (siinäpä verkkokauppa, joka inhoaa itseensä linkkaamista).

Lisäys: Mozilla-pohjaiset selaimet lisäävät oletusarvoisesti lainausta merkitsevän q-elementin ympärille tuumamerkit. Tämän voi korjata seuraavalla säännöllä:

q::after, q::before {
	content: "201D";
}

Suomen helpoin

Osuuspankki on avannut uuden verkkopankkikäyttöliittymän ja mainostaa sitä Suomen helpoimmaksi Internet-pankiksi. Näkemys helppoudesta on kummallinen.

Kaikki linkit on korvattu nappuloin, mikä tuntuu todella oudolta. Kerrataanpa perusjako: nappuloiden on tarkoitus lähettää lomakkeelle syötetty tieto palvelimelle, linkkien on tarkoitus johdattaa uuteen verkko-osoitteeseen. Miksi kaikille webiä käyttäneille tuttu käyttölogiikka on pitänyt keksiä uudelleen? Heti ensimmäisellä sivulla kehotetaan valitsemaan tunnistautumustapa, vaikka tapoja on tarjolla vain yksi. Kun vain yksi vaihtoehto on tarjolla, valintaan pakottaminen on ainoastaan hämmentävää.

Valinta tehdään klikkaamalla nappulaa, joka suorittaa JavaScriptin pätkän, joka ohjaa toiselle sivulle eli toimii kuten yksinkertainen linkki toimisi. Ilman JavaScriptiä ei siis pääse yhtään minnekään. Tämä rajoitus on aivan turha eikä siitä edes varoiteta missään, huolimatta HTML-speksin helppokäyttöisestä noscript-tagista.

Tekstin koon vaihtaminen toimii vain Internet Explorerissa, mutta silloinkin vain kun JavaScript kytketään päälle. Näin ei tällä hetkellä voi kuitenkaan toimia, jos ei tahdo koneelleen kutsumattomia vieraita. Tämän, kuten myöskin värit vaihtavan toiminnon olisi helposti voinut tehdä palvelinpäässä, jolloin ei oltaisi oltu riippuvaisia selaimen asetuksista ja merkistä.

Sivut julistavat olevansa XHTML:ää, mutta eivät sitä ole. Taitto on tehty kiinteän levyisin taulukoin, mutta sentään pikselikuvia ei ole käytetty. Varsinkin heikkonäköisten keskuudessa varsin yleisellä 800×600-resoluutiolla osa tekstistä jää ruudun ulkopuolelle ja pakottaa selaimen esittämään sivuttaisvierityspalkin aivan turhaan, mikä syö tilaa ennestään pieneltä ruudulta ja vaikeuttaa sivujen lukemista. Näin yksinkertainen sivu pitäisi helposti saada mahtumaan 640×480-resoluutioon tai jopa pienempäänkin.

Onkohan mainostettua ulkopuolisen yrityksen tekemää käytettävyystestiä suoritettu muilla kuin yleisimmän selaimen oletusasetuksilla? Esimerkiksi sokeaa web-lomakkeella avustavat labelit, fieldsetit ja legendit puuttuvat kokonaan.

Entä mistäköhän johtuu, että helppokäyttöisyyden, selkeyden ja esteettömyyden luullaan tarkoittavan rumaa, vastenmielistä ja karua ulkoasua?

Standardien seuraamisen vaikeus

Kokeiltuaan varsin naiivilla tavalla XHTML:n mukaista MIME typeä Milan Negovan on tullut siihen tulokseen, että application/xhtml+xml:ää ei tulisi käyttää web-sovelluksissa. Perustelunsa ovat tosin aika kehnot.

Selkeä pääsyy Nogovanin niskoitteluun on se, että hän käyttää web-sivujensa taustateknologiana Microsoftin ASP.NETiä ja on ilmeisen mieltynyt sen huomattavasti työtä vähentävään mutta webin rikkovaan Web Forms -malliin. Hän vertaa ASP.NETin valmiskontrolleja valmiiksi leikattuun leipään. Vertaus olisi parempi, jos se ottaisi huomioon sen semanttisen HTML:n irvikuvan, jota ASP.NET tuottaa. Kenties lisäaineet, jotka huolimatta viipaloinnista saavat leivän pysymään tuoreena ja pehmeänä voisivat edustaa sitä puolta. Lisäaineet kyllä hoitavat varsinaisen tehtävänsä, mutta eivät ole erityisen terveellisiä eikä lisäaineleipä enää maistukaan leivältä (toisin kuin ennen vanhaan) vaan kylmältä teollisuustuotteelta. Se kehnoista vertauksista.

Nogovanin esimerkkinä käyttämän ValidationSummaryn tuottama HTML on kammottavaa:

<code><table id="_ctl0_vs" class="vsummary" cellpadding="0"
cellspacing="0" border="0" width="100%">
<tr><td>
<font color="Red">Enter site URL<br></font>
</td></tr>
</table></code>

Edellisen tarkoitus on antaa käyttäjälle palautetta täyttämättä jääneestä lomakkeen kentästä. Asian voisi toki hoitaa tyylikkäämmin, kuten valveutuneet hyvin tietävät. Negovan itkee sitä, että käyttämällä application/xhtml+xml:ää Mozilla ei suostu näyttämään sivua jossa on päätteetön br-elementti. Kuten Anne van Kesteren kommenteissa kysyy, miksi ihmeessä sitten käyttää koko XHTML:ää? Jos välittää enemmän siitä, että oma työ on vähän helpompaa kuin että selaimelle menee vain puhdasta markupia, eikö olisi kaikille palvelus tyytyä HTML 4.01 Transitionaliin? (Ei olisi.)

Seuraava esimerkki on vielä edeltävääkin hirveämpi. Negovan valittaa, ettei ASP.NETin tuottama javascript suostu toimimaan Mozillassa application/xhtml+xml:ää käytettäessä. Kyseessä on ehkä pahin koko ASP.NETin yksittäinen suunnitteluvirhe, jo pelkällä nimellään kauhua herättävä javascript:__doPostBack(), joka muuttaa linkin lomakkeen lähettäväksi javascriptiksi. Paitsi ettei linkki ole missään vaiheessa linkki. En tiedä, kuinka ASP.NETin arkkitehdit osasivat perustella tuon kammotuksen tarpeellisuuden.

A-elementti on tarkoitettu muuttumattomille urleille ja input-elementti on lomakkeen vaihtuvasisältöisille kentille ja nappuloille. Jako on selkeä, eikä sen sotkemisesta seuraa muuta kuin käyttäjien hämmentyminen ja käyttömahdollisuuksien liian tiukka rajaaminen (yritäpä avata tuollainen linkki uuteen ikkunaan tai välilehdelle, turha toivo). Standardien noudattaminen on muutakin kuin validoituvuus, vähän kuten lain kirjaimen noudattaminen on eri asia kuin lain hengen noudattaminen.

Negovan käyttää linkkiä räikeästi väärin etusivullaan olevassa kyselylomakkeessa. Siihen vastaaminen tapahtuu luonnollisesti radio-buttonista vaihtoehto valitsemalla ja sitten lähetyspainiketta painamalla. Sen sijaan vastaukset saa näkyviin linkin näköistä alleviivattua tekstiä klikkaamalla. On typerää, että tuo linkiksi naamioitu skripiti lähettää lomakkeen, joka pitää sisällään Viewstaten eli tilatietoa. Koska sivulla ei ole mitään muuta “tilaa” kuin sen oletustila (paitsi tieto siitä onko äänestänyt, mutta senpä pitäisikin olla tallennettuna keksiin), on ajatus entistä typerämpi. Kuinka vaativaa on kirjoittaa: <a href="default.aspx?results=true">See results</a> ja parametrin perusteella päättää näytetäänkö äänestyslomake vaiko tulokset? Ilmeisesti aivan liian.

Milan Negovan pelkää, että käyttäjien syöttämä epävalidi XML voi rikkoa hänen huolella rakentamansa XHTML-sivun siten, että sen tilalla on selaimessa vain tyly virheilmoitus. Pelko on aiheellinen, muttei tilanteen estäminen ole edes kovin vaikeaa. Ensimmäinen sääntö on olla sallimatta HTML:ää. Tämä tapahtuu HTML-enkoodaamalla ihan kaikki käyttäjien syöte.

Jos on tarve kappalejakoa enemmän mahdollistaa rakenteiden kuvaamista, voi joko rakentaa oman yksinkertaisen kuvauskielen joka parsitaan XHTML-muotoon tai sitten sallia mahdollisimma pieni osajoukko XHTML-elementtejä syötteeseen. Tämä pieni osajoukko on helppo “validoida”, eli käytännössä varmistaa päätöstagien olemassaolo, mitään attribuutteja tuskin tarvitaan. Ja jos todella tarvitaan koko XHTML:n nimiavaruus käyttöön, voi käyttää HTMLTidyä varmistamaan siistin lopputuloksen.

Pelko rikkoutuneesta Citi Bankin sivusta on aiheeton, sillä kyllähän isoilla organisaatioilla on resursseja huolehtia HTML:nsä puhtaudesta. Pienemmät eivät tähän ehkä vielä pysty, mutta tarvittavat ammattitaito leviää kyllä niihinkin. Lopultakin, kyse on vain siitä, että tiettyjä metodeja noudatetaan kaiken sisään saapuvan syötteen suhteen. Tietoturvasta välittävä jo tekee näin joka tapauksessa.

Hassua, että Nogovanin sivujen alaotsikkona on ASP.NET with emphasis on web standards. Ehkä hän on matkinut populäärin lähestymistavan muualta webistä, mutta selvästi näyttää sitä, ettei hän ole alkuunkaan sisäistänyt otsikkoaan.