pisara-meressa.net

Yksi www-sivujen tekemisen perustavanlaatuisista ongelmista on se, että useissa ympäristössä tuettujen kirjasinten määrä on hyvin rajattu. Niitä on kourallinen, ja ne tunnetaan ns. web-safe fontteina. Yleisimmin web-safe fontteina pidetään mm. Verdanaa, Arialia, Times new romania, Comic sansia, Courier newiä ja Impactia. Näiden lisäksi on käytössä ns. kirjasinperheet, jotka kertovat selaimelle vähän, minkä tyylistä haluttaisiin. Siinäpä se, ja tämä valikoima on vähän - erityisen vähän, kun halutaan koristeellisia ja vaikuttavia otsikoita.

Ratkaisu varsinaiseen ongelmaan olisi, että htmlssä/stylesheetissä voisi sanoa, että käytä fonttia, joka on paikassa jossa sen sinulle kerron olevan. Tähän on olemassa jo CSS-spesifikaatiokin (CSS level 2). IE 5 tukee sitä (Gecko ei!). Lisätietoja em. @font face-ratkaisusta saat seuraavista linkeistä:

• http://www.richinstyle.com/guides/fontface2.html
• http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/fontface.asp

Ongelmana vain on, että fontteja ei voi vain pistää .ttf- tai muussa muodossa palvelimelle, vaan ne on konvertoitava sopivaan muotoon. Meillä jo olikin eri selaimissa toimiva muoto pfr (portable font resource), mutta valitettavasti se oli kaupallinen vaatien kalliin lisenssin, ja luonnollisesti firma meni nurin eikä tekniikkaa enää tueta. Meille jäi .eot-muoto, jota vain IE tukee. Voit kokeilla tekniikkaa hakemalla esimerkki-eotfontteja ja kokeilemalla seuraavanlaista tyylitiedostoa:

@font-face { 	font-family: Dragon; 	src: url("Dragonwick.eot") } body { font-family: Dragon; }

Eot-tiedostojen luontiin omista tiedostosta tarvitset Microsoftin WEFT-työkalun. Tekniikka toimii, mutta pelkkä IE-ratkaisu ei tietenkään ole mikään ratkaisu.

• IE:ssä toimiva ratkaisu käytännössä
• Bugzillan bugi aiheesta
• BitStream Truedocin (pfr) tilanne ja ongelma yleensä

Otsikko kuvana

Itsestäänselvin ratkaisu asiaan on kirjoittaa teksti haluamansa näköiseksi ja tehdä siitä kuva. Tällöin sen saa näyttämään ihan millaiselta haluaa. Tekniikassa on kuitenkin merkittäviä ongelmia:

• kuvien teko käsin joka otsikolle on hidasta ja vaivalloista
• otsikkoa ei voi valita, etsiä, kopioida tai muutenkaan käsitellä tekstinä
• otsikot jäävät hakukoneilta huomaamatta
• tekstipohjaiset selaimet jättävät otsikot pois, kuten myös ääniselaimet
• kuvat vievät enemmän kaistaa

Haitat ovat erityisesti suuremmilla sivustoilla merkittäviä, joten jotain piti keksiä. Isoimman kohun ja muutoksen ajatusmaailmassa aiheutti nyt jo klassikoksi muodostunut Fahner Image Replacement-tekniikka.

Fahrner Image Replacement

Fahner Image Replacement eli lyhyemmin FIR on saanut nimensä kehittäjänsä, Todd Fahrnerin mukaan. FIR-tekniikka esiteltiin alun perin maaliskuussa 2003 tässä artikkelissa, jonka kirjoitti Doug Bowman. Ideana oli tarjota nättejä kuvia niitä tukeville selaimille, kun taasen ääniselaimet, hakukoneet ja muut saisivat tekstinsä, ja html-lähdekoodikin pysyisi nättinä, sellaisena kuin se on tarkoitettukin. Oi, hienoa! Tekniikka käytti CSS:ää piilottamaan teksti sitä tukevilta selaimilta ja sijoittamaan siihen sen sijaan saman tekstin kuvana.Ajattelumalli oli mullistava. Vaihtoehtoja ei tähän mennessä oltu ajateltu, ja uudet tuulet puhalsivat. Valitettavasti myös soraääniä alkoi esiintyä. Tuli ilmi, että ääniselaimet eivät toimineetkaan tekniikan kanssa. Vaikutusvaltainen Dave Shea kirjoitti vielä samana vuonna artikkelin In Defense of Fahrner Image Replacement, jossa hän alleviivasi etuja, joita tekniikka mukanaan toi, ja esitteli mm. overflow hidden-ratkaisun ääniselainongelmaan. Soraäänet eivät kuitenkaan hiljentyneet, ja legendaarinen A List Apart julkaisi Joe Clarkin artikkelin Facts and opinion about Fahrner image replacement, joka kokosi ansiokkaasti yhteen tekniikassa havaittuja ongelmia. WWW-designerit ympäri maailman ideoivat ja toteuttivat erilaisia ratkaisuja ongelmaan, muun muassa käyttäen läpinäkyviä yhden pikselin kuvia ja erilaisia CSS-sääntöjä. Dave Shean kirjoitus Revised Image Replacement kokosi yhteen ja esitteli valtavan määrän näitä ratkaisuja tuoden esiin hyvät ja huonot puolet. Mitään lopullista ratkaisua ongelmaan ei kuitenkaan saatu.

Javascript Image Replacement

Seuraavan kerran kohahti, kun Peter-Paul Koch esitteli menetelmän, jota jälkeenpäin kutsuttiin JIR:iksi. Suuri idea tällä kertaa oli käyttää Javascriptiä tekemään tekstin korvaus kuvilla. Tällä saavutettiin merkittäviä etuja: voitiin muun muassa testata, tukiko asiakasohjelma oikeasti kuvia. Käsitys ääniselainten CSS-tuesta oli ollut virheellinen ja siihen perustuvat ratkaisut toimivat miten sattuu, mutta tällä kertaa pystyttiin esittelemään tekniikka, joka oikeasti toimi niidenkin kanssa. (Netscape 6.1-ja vanhemmissa Mozillapohjaisissa selaimissa oli bugi, jonka takia tekniikka ei niissä toiminut, mutta muuten siinä ei ollut ongelmia.) Ja taas kuohuttiin. A List Apart ja Christian Heilmann esitteli tekniikan paranneltuna, Javascript Image Replacement.

Dynaamisuus astuu mukaan

Tarina ei kuitenkaan ollut vielä ohi. Kaikissa ratkaisuissa tähän mennessä oli käytetty staattisia kuvia: kuvat luotiin etukäteen ja tallennettiin palvelimelle käyttöä varten. Jossain vaiheessa herättiin huomaamaan, että eihän se ollut tarpeellista: kuvat voitiin luoda lennosta! Tällöin määriteltyjen tagien sisällä saattoi olla mitä tahansa tekstiä, ja se korvattiin vastaavalla kuvalla. Stewart Rosenberger kuvasi ja dokumentoi toteutustavan A List Apartin artikkelissa Dynamic Text Replacement. Kielenä oli PHP, mutta teoriassa tähän voitaisiin käyttää mitä tahansa palvelinpuolen kieltä, joka pystyy kuvien generointiin. Kuvat voitiin helposti myös tallentaa väliaikaisesti, jolloin samaa kuvaa ei tarvinnut luoda moneen kertaan uudestaan. Ratkaisu otti jopa huomioon tulostusnäkökulman tarjoatakseen paremmin tulostukseen soveltuvia tekstivaihtoehtoja tässä tapauksessa.
Samoihin aikoihin joku muukin oli pohtinut samaa ongelmaa tullen eri ratkaisuun. Tämä joku oli Shaun Inman, jonka vastaus oli Inman Flash Replacement, IFR. Vastaus tuli 2004 - IFR: An FIR Alternative ja IFR revisited and revised. Käyttämällä Flashia kuvien sijasta onnistuttiin pääsemään eroon merkittävistä ongelmista:

• Flash-tiedosto tarvitsi ladata vain kerran, kun taas jokainen eri otsikkokuva oli ladattava sivulle erikseen
• Flash-tekstin voi valita, sitä voi etsiä ja sen voi kopioida
• Tekniikka toimi alusta lähtien täysin ääniselaimien ja muuten estoja käyttävien selaimien kanssa

Muun muassa Sprint.com otti tekniikan käyttöön, jolloin se tuli testatuksi todellisella suursivustolla ja raskaassa rasituksessa. Yksityiskohtia säädettiin flashkoodista ja ratkaisun koodaus monimutkaistui, mutta ennen kaikkea valinta toimi. Tulokset kuulostivatkin paperilla järisyttävän hyvältä:

Bandwidth
26 K Savings in shop.css code (when we finally remove all reference to graphic titles)
8 k Savings in heads.css code (when we finally remove all reference to graphic titles)
20 K Savings in the actual graphics (average of .5k each X 40 titles per session [total guess])

54 K Total savings per visitor
Server load

We will be switching from 3-5 unique titles per page, to 6 total files that will cache for
all pages. Doing some math off the top of my head, that should save us 472 Million file loads
per month (130 Million page views per month X 4 titles per page = 520 Million vs 8 Million
visitors X 6 files = 48 Million files loaded). This doesn’t even consider the Safari bug
that loads all 300-500 graphics each time they view a page that won’t be an issue any more.
I can’t venture to guess how this will effect server performance, and how that transfers
into a dollar amount.

Work load

Guesses that are probably on the low side:

VizD’s save 30-40 hrs a year
Code save 60-80 hrs a year

If you did a conservative estimate of the time to create, cutout, save, add to code, add to
stylesheet, test, check in, etc… for each title, we figure around a total of 5 minutes per image.

Viimeisin villitys: sIFR

Tästä tekniikasta Mike Davidson sai aikaan vielä jotain, jota kutsutaan sIFR:iksi, Scalable Inman Flash Replacement. Flashkoodia oli edelleen paranneltu, jopa sille tasolle että se osaa ottaa huomioon selaimen kirjasinkokoasetuksen ja käytettävissä olevan tilan, toimien oikein. How and when to use sifr kuvasi onnistuneesti miten tekniikasta sai kaiken irti. SIFR julkaistiin LGPL-lisenssin alla, sillä sen implementointi ei enää ollut vaivatonta ja jokaisen tyypin tehtävissä. Näin se oli kaikkien halukkaiden käytettävissä. SIFR ei vaadi enää mitään muutoksia html-koodiin, CSS:n, javascriptin ja Flashin tehdessä kaiken työn. Kaikki aiemmin saavutetut edut olivat käytettävissä, ja flash tekniikkana tarjoaa jopa antialiasointia ja muuta joita normaalilla otsikolla ei saavuteta. Kun tähän vielä lisätään linkkihoverointipäivitys, olemme päässeet tähän päivään. Vielä joitain asioita on esitetty paranneltaviksi, ja eihän mikään ole täydellistä, mutta pitkälle ollaan päästy. Tarina onkin opettavainen kertomus siitä, mihin Internet-yhteisö pystyy, kun he voivat vapaasti hyödyntää toistensa saavuttamia tuloksia.

Yhteenveto nykytilanteesta

• hakukoneystävällinen
• tulostusystävällinen
• ääniselainystävällinen
• kuvat kieltänyt käyttäjä näkee tekstiotsikot, ne sallinut kuvat
• voi käyttää staattisia tai dynaamisia kuvia
• flickerfree

javascript ja staattiset kuvat

• yhteensopivin nykytekniikan kanssa
• kuvat silti tallennettava käsin

palvelinpuolen generointi

• työmäärä vähenee merkittävästi
• cachen avulla samaa kuvaa ei tarvi generoida monesti
• toimii yhä kuin alkuperäiset kuvat
• fontti ja muita tietoja voidaan välittää parametreilla
• dictionary-attackilta suojauduttava
• esim. javan kuvagenerointiominaisuudet?

flash replacement

• kaistaa säästyy, kun samalla instanssilla voidaan hoitaa eri kuvat
• levytilaa säästyy, 1 flash/tyyli (js n. 10k, flash 8-20k)
• työtunteja säästyy
• sallii myös esim. hoveroinnit ja linkit (tietyin varauksin)
• skaalautuu tekstikoon mukaan
• skaalautuu käytettävissä olevan koon mukaan
• otsikkoa voi käsitellä tekstinä (valinta, kopiointi)
• valmiskirjasto perusteellisesti testattu ja optimoitu
• flash tarjoaa mm. antialasoinnin
• flash 7: fontti ja sen väri voidaan kertoa CSS:llä
• vaatii flash-ohjelmointitaitoa/SIFR-kirjaston (LGPL)
• jos ~10 tai enemmän samalla sivulla, prosessointi hidastuu
• joillain käyttäjillä voi olla flashplugineita, jotka liittävät flashien yhteyteen ylimääräisiä nappeja
• flash ei välttämättä toimi ihan samoin htmlssä layoutmielessä kuin kuvat
• käyttäjinä mm. Nike, ABC News, Aston Martini, MikeIndustries.com