Suutarin lasten kengät

Jos yhtään seuraa mistä webissä web-kehittäjien ja designereiden parissa puhutaan, niin osaa varmasti mainita esimerkiksi standardien, semanttisesti oikean markupin tai CSS:n käytön puolesta taistelun. Helposti siis luulisi, että ajatusmaailma olisi laajasti omaksuttu. Seuraavassa tuloksia ehdottoman epätieteellisestä tutkimuksesta suomalaisten uusmediayritysten web-sivujen teknisestä laadusta.

Kävin läpi kaikki Rekaksoispisteen Yritysoppaassa listatut yritykset, jotka selkesti mainostavat omilla sivuillaan toteuttavansa web-sivuja. Jätin siis tutkimatta mainos- ja markkinointitoimistot sekä mobiilifirmat ja sensellaiset.

Jokaisen yrityksen kotisivulla tarkastelin seuraavia asioita: mitä Content-Typeä käyttäen sivu selaimelle välitettin, mitä Doctypeä käytettiin jos käytettiin, oliko käytetty XML-julistusta ja kuinka monta virhettä W3C:n validaattori sivulta löysi. Mikäli validaattori valitteli että käytettyä merkistöä ei löytynyt, merkitsin tämän tiedon ylös ja vihjasin sille oikean merkistön tarvittaessa. Mikäli sivusto oli toteutettu kokonaan tai osittain Flashilla, kirjasin sen ylös ja havainnot saitin käyttökelpoisuudesta ilman Flash-pluginia.

Tutkittavia sivuja oli yhteensä 41 kappaletta. Ainoastaan viisi sivua validoitui. Kymmenen sivua ei edes käyttänyt doctypeä, 22 käytti joko HTML 4.01 tai 4.0 Transitionalia, viisi XHTML 1.0 Transitionalia ja yksi XHTML 1.0 Strictiä. Kukaan ei käyttänyt HTML 4.01 Strictiä, mikä saattaisi olla paras kompromissi tällä hetkellä. Kaikki sivut tulivat XHTML:stä huolimatta palvelimelta text/html -MIME-typellä varustettuna, mikä on ymmärrettävää kun valtaselain ei muuta tue.

Yhdeksän sivua käytti joko kokonaan tai osittain Flashiä, mutta vain kolme näistä tarjosi lisäpalikattomille tekstiversiota. Yksi näistä kolmesta oli tiedoiltaan selvästi vanhentunut. Ne kuusi, jotka eivät Flashittömiä huomioineet eivät tarjonneet edes yhteystietoja, vastassa oli pelkkää tyhjyyttä. Aika tylyä.

Tässä valossa täytyy sanoa, vaikka työnantaja ei varsinaisesti uusmediayritys olekaan, että olemme sentään Kynämiehen sivuilla saavuttaneet jotain poikkeuksellista. Tehkää perässä, pyydän.

Lisäys 9.7.2009: Kun tämä kirjoitus julkaistiin, joku tulistui siitä niin paljon, että perusti oikein kokonaisen, anonyymin blogin Bloggeriin, jossa haukkui minut maanrakoon. Blogia ei ole enää olemassa, enkä muista sen sisällöstä juuri mitään. Pelastin alla olevan kommentin, josta käy jotain ilmi.

Code inline vai code behind?

Richard Tallent linkkasi (9.7.2009: toimimaton linkki poistettu) jo vähän aikaa sitten lyhyeen keskusteluun code inlinen ja code behindin välisestä paremmuudesta, jossa oli itse antanut ainoan viisaan kommentin. Muut eivät taida lainkaan välittää siitä millä ennestään pahasti rikkonaista webiä rikkovat.

ASP.NET:in code behind -mallia perustellaan useimmiten sillä, että se mahdollistaa koodin eriyttämisen esityskerroksesta. Tilanne saattoi vielä muutama vuosi sitten taulukko- ja pikselitaiton kulta-aikana ollakin näin. Alati kasvava CSS:n hyödyntäminen on johtanut siihen, että HTML tekee yhä useammin sitä mitä sen suunniteltiinkin tekevän: kuvaa dokumentin rakennetta. Esityskerroksen visuaalinen osa, eli CSS, on jo luonteeltaan erotettu selkeästi sisällöstä, joten ASP.NET:in mallille on käyttöä enää vain pikselitaittoa suosivien ajastaan jälkeen jääneiden kehittäjien käsissä. Kaikki ulkoasumuutokset tehdään CSS-tiedostoon, ja jos HTML:ää on tarve muokata ollaan muokkamassa dokumentin rakennetta. Rakennetta muokattessa myös esityslogiikka on vaarassa muuttua, mikä tekee näistä kahdesta käytännössä erottamattomat.

Toinen Code Behind -mallin käytön perustelu on tuottavuuden lisääntyminen. Se saavutetaan muka sillä, että web designer ja ohjelmoija voivat työskennellä saman sivun parissa toisiaan häiritsemättä. Saavutettava hyöty on todellisuudessa minimaalinen, sillä käytännössä vain kaikkein tarpeellinen esitysrakenteeseen liittyvä koodi jää “kehittymättömimmissäkin” tekniikoissa sivun yhteyteen. Kaikki muu koodi sijoitetaan sivun ulkopuolelle yksinkertaisimmillaan SSI:n avulla, jos suunnittelussa on käytetään edes vähän järkeä.

Visual Studio 2005 tulee ymmärtääkseni tarjoamaan Code In Page -mallia oletusarvoisena, mikä on loistava juttu. Kunhan vain kehittäjäyhteisön enemmistö tajuaisi tämän.