XSS-haavoittuvuudet ovat yllättävän yleisiä ja myös melko helposti löydettävissä. Kaikesta huolimatta niihin suhtaudutaan usein liiankin kevyesti.

Kesäkuussa Mikko Hyppönen kirjoitti F-Securen blogissa XSS-haavoittuvuudesta, joka oli löytynyt heidän omalta sivustoltaan. Tämän johdosta päätin kirjoittaa artikkelin tietoturvaongelmasta, jota mielestäni aliarvioidaan.

Hyppönen tiivisti ongelman ytimen erinomaisesti toteamalla “Jos edes tietoturvayhtiöt eivät saa omia sivujaan täysin aukottomiksi, niin minkälaista toivoa on yhtiöillä, joiden erikoisosaamisala ei ole tietoturva?”.

Allekirjoitan Hyppösen väittämän täysin: kirjoittaessani tätä artikkelia kävin läpi 15 satunnaista sivustoa Suomen 25 vierailluimmasta sivustosta. Lyhyehköillä, manuaalisilla testeillä löysin XSS-haavoittuvuuden yhdeksästä eri palvelusta. Kahdeksassa näistä palveluista on käyttäjäosio, kahdessa palvelussa liikkuu oikea raha.

Tässä artikkelissa käyn läpi XSS-haavoittuvuuksien eri muotoja, mitä ne todellisuudessa mahdollistavat, ja yhtälailla sitä, mitkä ovat XSS:n heikkoudet. Käyn läpi myös yhden kuvitteellisen esimerkin, jonka tarkoituksena on havainnollistaa tarkemmin XSS:n käyttöä todellisessa tilanteessa.

Artikkeli ei tarjoa neuvoja XSS-haavoittuvuuksien torjumiseksi, sillä aihe on monin osin teknologiariippuvainen. Artikkelin lopussa on kuitenkin listattuna muutama hyödyllinen linkki, jotka osaltaan antavat vinkkejä myös torjumiselle.

Mistä oikeastaan on kyse?

• XSS-haavoittuvuuksien määrän on arvioitu olevan noin 80% kaikista tietoturvahaavoittuvuuksista (Symantec, 2007),
• OWASP (The Open Web Application Security Project) listaa XSS-haavoittuvuudet vuoden 2010 toiseksi pahimmaksi tietoturvauhkaksi,
• XSS-haavoittuvuuksia on esiintynyt myös erittäin tunnetuilla sivustoilla, kuten Facebook, Twitter tai Wikipedia.

Lyhyenä johtopäätöksenä voidaan todeta, että XSS on laaja ja vakavasti otettava uhka, jolta edes suuret toimijat eivät voi välttyä.

XSS-haavoittuvuuksien muotoja

XSS-haavoittuvuuksia on olemassa ainakin neljää eri muotoa:

1. URL:n välityksellä suoritettava haavoittuvuus,
2. Sivustolle lähetetyssä syötteessä esiintyvä haavoittuvuus,
3. Selainpuolen logiikassa esiintyviä virheitä hyödyntävä haavoittuvuus,
4. Ulkoista syötettä hyödyntävä haavoittuvuus,

Lisäksi viidentenä uhkana on syytä listata “käyttäjän itsensä ajama haittakoodi”.

1) URL:n välityksellä suoritettava haavoittuvuus

Tämä lienee yleisin muoto haavoituvuudelle. Osoitteen välityksellä suoritettu haavoittuvuus on myös lyhytikäinen ja helpoiten havaittavissa.

Jos sivusto ei osaa validoida oikein URL:ssa välitettyjä parametreja, niin tämän haavoittuvuuden hyödyntäminen on helppoa. Tällöin URL voisi näyttää esimerkiksi tältä: http://www.domain.tld/?page=Main”%3e%3c%73%63%72%69%70%74%20%73%72%63=//%62%69%74%2e%6c%79/%78%73%73_1%3e.

Uskallan väittää, että keskivertokäyttäjä (keskiverto, et siis sinä) ei näe tässä mitään epäilyttävää. Lisäksi keskivertokäyttäjän selain näkee tässä harvemmin mitään epäilyttävää. Ja vaikka näkisikin, niin sen kiertämiseksi on yleensä keinoja. Tämän lisäksi URL:n lyhennystä tarjoavat palvelut tarjoavat mahdollistavat käyttäjän hämäämisen.

2) Sivustolle lähetetyssä syötteessä esiintyä haavoittuvuus

Tämä tapaus on astetta vakavampi, sillä kyseessä on sivustolla pysyvästi esiintyvä haavoittuvuus.

Perusideana on löytää sivuston lomakkeista kenttiä, joiden kautta haittakoodi on lisättävissä. Esimerkkinä mainittakoon, että tällainen haavoittuvuus löytyi mm. Facebookista vielä muutama kuukausi sitten, jossa ryhmän nimeä ei validoitu, kun se esitettiin dynaamisissa hakutuloksissa.

Nykyään monet sivustot ovat rakennettu valmiiden tuotteiden tai frameworkien päälle, joissa tämänkaltaiset haavoittuvuudet on lähes poikkeuksetta estetty.

3) Selainpuolen logiikassa esiintyvät virheet

Tämä haavoittuvuuden muoto on idealtaan samankaltainen kuin kohdan #1 haavoittuvuus. Tässä tapauksessa haittakoodia ei lisätä HTML-rakenteeseen vaan se suoritetaan jo olemassa olevan Javascript-koodin avulla.

Tällainen haavoittuvuus esiintyy harvemmin. Tilanteissa, joissa sivustolle lisätään skriptejä dynaamisesti, suoritetaan eval() funktio tai muulla tavoin manipuloidaan DOM-rakennetta hyödyntäen suoraan URL:ssa välitettyjä parametreja, on tämän haavoittuvuuden hyödyntäminen täysin mahdollista.

4) Ulkoista syötettä hyödyntävä haavoittuvuus

Tämä haavoittuvuus on harvinaisempi ja esiintyy lähinnä silloin, kun ollaan toimittu todella ajattelemattomasti.

Esimerkkinä on tilanne, jossa sivustolla julkaistaan Twitter-feed jonkin hash-tagin perusteella kuitenkaan validoimatta feediä, tai käsittelemällä feediä selainpuolella (kohta #3). Näin kävi muun muassa tapauksessa #cashgordon.

5) Käyttäjän itsensä ajama haittakoodi

Tämä haavoittuvuus on ikävä siitä syystä, että sivuston ylläpitäjällä ei käytännössä ole vaikutusmahdollisuuksia haavoittuvuuden esiintymiseen. Haavoittuvuus perustuu sille, että käyttäjä saadaan itse ajamaan JavaScriptiä selaimessaan.

Mutta miksi käyttäjä ajaisi selaimessaan JavaScriptiä?

Tämä haavoittuvuus perustuu kolmeen asiaan: 1) peruskäyttäjä ei tiedä tämän olevan kovin vaarallista, 2) suositus haittakoodin ajamiseksi tulee monesti muilta, yleensä tutuilta ihmisiltä ja 3) uteliaisuus ei ole synti.

Asetelma on käytännössä hyvin samanlainen kuin sähköposteilla leviävien matojen ja viruksien osalta.

Moni meistä on nähnyt tämän tapahtuvan esimerkiksi Facebookissa. Kuvitellaan skenaario: luodaan ryhmä, jossa kerrotaan dislike-toiminnon saamisesta käyttöön ajamalla yksinkertainen komento selaimen osoitepalkissa. Tämän avulla lisätään sivulle skripti, joka tekee automaattisen status-päivityksen, jolloin huijaus leviää.

Tämä skenaario on itse asiassa totta. Tällä tavoin huijausta saatiin levitettyä satojen tuhansien Facebook-käyttäjien keskuudessa. Enkä yhtään ihmettele.

XSS tarkoittaa aina ongelmia

Alla on listattuna muutama ongelma, jotka ensimmäisenä tulevat mieleeni XSS-haavoittuvuuksista:

Käyttäjän syöte on selkokielistä

Tärkeimpänä huomio on, että injektoitu sivu voi kerätä talteen selkokielisenä kaiken, mitä käyttäjä sivulle syöttää. Käyttäjä voi luulla normaalisti kirjautuvansa palveluun syöttäen tunnuksen ja salasanan ollen täysin tietämätön, mihin tiedot todellisuudessa päätyvät.

Käyttäjä luottaa tuttuun sivustoon

Toinen tärkeä huomio on, että XSS mahdollistaa toimimisen ympäristössä, johon käyttäjä luottaa. Tämä madaltaa kynnystä sille, että käyttäjä on valmis luovuttamaan arkaluontoisia tietoja. Kun tutun palvelun ruudulle ilmestyy dialogi, joka luotettavasti esittää syitä, miksi käyttäjän on syötettävä tunnuksensa ja salasanansa, ei käyttäjä välttämättä osaa epäillä mitään.

XSS-haavoittuvuus indikoi myös muista tietoturvaongelmista

Jos sivustolta löytyy XSS-haavoittuvuus, niin ei ole epäkohteliasta olettaa sivustolla olevan myös muita puutteita tietoturvassa. XSS-haavoittuvuus antaa usein viittaukseen siihen, että sivusto ei ole rakennettu valmiin tuotteen päälle, jolloin tietoturvaan liittyvät seikat on täytynyt miettiä erikseen. Vaikka sivusto olisikin tehty hyödyntäen valmista frameworkia, niin tällöin on tehty auttamattomasti väärin.

Joka tapauksessa on varmaa, että XSS-haavoittuvuus houkuttelee ei-toivottuja vieraita sivusto(i)lle.

Virheillä on tapana toistua

Kun sivuston luonut taho on tiedossa, syntyy uudenlainen ongelma: googlaamalla tai vierailemalla tahon oman sivustolla on usein löydettävissä muut saman tahon luomat sivustot, joilla samat tietoturvaongelmat mahdollisesti toistuvat.

Käyttäjän silmissä jokainen haavoittuvuus on yhtä vakava

Kun käyttäjä kuulee sivustolla olleen tietoturvaongelmia, hänen luottamus sivustoa kohtaan on usein menetetty. Sillä on harvemmin väliä, onko joku onnistunut saamaan haltuunsa yksittäiset tunnukset, viemään koko tietokannan tai tehnyt vain pientä kiusaa XSS-haavoittuvuuden avulla. Peruskäyttäjiä ei niinkään kiinnosta tekniset yksityiskohdat tai sivuston ylläpitäjän selitykset tietoturvaongelmien eri vakavuusasteista.

Kuvitteellinen esimerkki XSS-haavoittuvuudesta

Tämän esimerkin tarkoituksena on havainnollistaa, minkälaisen tilanteen XSS-haavoittuvuus voi mahdollistaa.

Alkutilanne

Olemme löytäneet XSS-haavoittuvuuden hyvin suositulta keskustelupalstalta. Haavoittuvuus voidaan ajaa lisäämällä haittakoodi yhdessä keskustelusäikeen tunnisteen parametrissä: http://www.foobarforum.com/?threadID=42%27%3e%3c%73%63%72%69%70%74%20%73%72%63=//%62%69%74%2e%6c%79/%78%73%73_1%3e

Valtaosa merkeistä on UTF-8 formaatissa. Osoitteen lyhentämiseksi voimme toimia myös siten, että muutamme vain osan merkeistä UTF-8 formaattiin. Vaihtoehtoisesti voisimme käyttää URL:n lyhentäjiä.

Valmistelut

Olemme siis luoneet keskustelun, jonka ID on 42. Lisäksi olemme luoneet skriptin, jota kutsumme. Tämä skripti ajaa haittakoodin sekä tekee tarvittavat muutokset, jotta loppuvaikutelma on luotettava.

Olemme aiemmin luoneet käyttäjätunnuksia muille suosituille keskustelupalstoille sekä kirjoittaneet muutamia viestejä, jotta luodut tunnukset ovat muiden käyttäjien silmissä luotettavampia.

Tämän jälkeen luomme viestejä muille keskustelupalstoille, joissa viittaamme XSS-haavoittuvuuden sisältävälle keskustelupalstalle:

Olemme kirjoittaneet viestin työajan ulkopuolella, kuitenkin keskustelupalstojen käyttäjien ollessa vielä aktiivisia. Eli keskustelupalstoilla vierailevien käyttäjien määrä on suuri, mutta ylläpitäjän viive haavoittuvuuden korjaamiseksi voidaan olettaa olevan pidempi.

Viestin tarkoitus on olla riittävän houkutteleva, mutta samalla uskottava. Keskustelupalstat ovat usein rakentuneet jonkin teeman ympärille (tekniikka, musiikki, perhe, jne.), jolloin houkuttelevien palkintojen ja muiden lupausten keksiminen on hyökkääjän kannalta triviaalia.

Hyökkäyksen kannalta on ongelmallista, että ennemmin tai myöhemmin joku käyttäjistä huomaa linkin hyödyntävän XSS-haavoittuvuutta – ilmoittaen asiasta sekä keskustelupalstalle että kohdesivuston ylläpitäjälle. Olemme kuitenkin jakaneet linkkiä useilla eri sivustoilla, jolloin vierailevia käyttäjiä tulee useista lähteistä.

Varsinainen ongelma

Koska olemme kiinnostuneet käyttäjätunnuksista, meidän on ylläpidettävä tarinaa, joka saa käyttäjän kirjautumaan tai rekisteröitymään palveluun. Lisäksi meidän on huolehdittava siitä, että käyttäjä ei välillä poistu injektoidusta dokumentista:

Olemme muokanneet dokumentin sisältöosiota jättäen ympäröivä rakenne alkuperäiseen muotoonsa, pois lukien sivuston oma kirjautumisosio (1). Kerromme käyttäjälle aiemmin kuvaillulla tavalla, että sivustolle on kirjauduttava sisään, jotta (kilpailu)viesti on nähtävissä. Samalla tarjoten myös toista lomaketta (2) sisäänkirjautumista varten.

Kumpikaan kirjautumislomakkeesta ei todellisuudessa ohjaa uudelle sivulle vaan ainoastaan lähettää syötetyt tiedot hyökkääjän palvelimelle sekä näyttää “väärä käyttäjätunnus tai salasana” -ilmoituksen haavoittuneessa dokumentissa.

Jos käyttäjä on jo rekisteröitynyt palveluun, on myös mahdollista, että hänellä on käytössään selaimen suorittama tunnuksen ja salasanan esitäyttö sivuston omaan sisäänkirjautumislomakkeeseen. Tässä tilanteessa saamme suoraan poimituksi tunnuksen ja salasanan.

Lisäksi tarjoamme rekisteröitymismahdollisuutta (3), joka tässä tapauksessa avaa täytettäväksi dynaamisesti luodun dialogin. Samoin menettelemme myös “unohtuneen salasanan” (4) kohdalla.

Hyökkäyksen elinkaaren kannalta on tärkeää saada käyttäjä pidetyksi haavoittuneessa dokumentissa mahdollisimman pitkään.

Jokaiselta löytyy (tai ainakin pitäisi löytyä) useampia eri salasanoja, joita käyttää eri palveluissa. Tämän myötä on aivan mahdollista, että jo rekisteröitynyt käyttäjä tulee kokeilleeksi useampia käyttämiään salasanojaan yrittäessään kirjautua palveluun. Käyttäjän pyytäessä uutta salasanaa on varsin tavallista tiedustella käyttäjän sähköpostiosoitetta sekä mahdollisesti vastausta johonkin turvakysymykseen. Tämä mahdollistaa jälleen uusien, arkaluontoisten tietojen keruun.

Tämän kaiken lisäksi on mahdollista, että löydämme meitä hyödyttävää tietoa myös evästeistä tai muista sivustolla käytettävistä muuttujista.

Lopputulos

Tarjoamme käyttäjälle useamman mahdollisuuden syöttää joko olemassaoleva tunnus ja salasana palveluun tai rekisteröityä palveluun, jolloin voimme pyytää käyttäjältä muita henkilökohtaisia tietoja.

Vaikka lopputuloksena olisi se, että emme saisi yhdenkään käyttäjän tunnuksia, niin vahinko on jo tapahtunut. Vähintä (tai järkevintä), mitä haavoittuneen sivuston ylläpitäjä voi tehdä, on kertoa tilanteesta ja kehoittaa kaikkia käyttäjiä vaihtamaan salasanansa omassa palvelussaan sekä myös muissa palveluissa, joissa on käytössä sama salasana.

Johtopäätös

Kuten aiemmin totesin, XSS-haavoittuvuuksia löytyy jatkuvasti niin pieniltä kuin suurilta sivustoilta. Tein itse vain pienen pintaraapaisun käydessäni läpi joitakin Suomen suosituimpia sivustoja todeten, että yli puolessa palveluista löytyy haavoittuvuus. Kaiken kaikkiaan olen tänä vuonna raportoinut reilu viisikymmentä haavoittuvuutta, näiden tapausten ollessa yleensä todella ilmeisiä.

Olen valmis tekemään johtopäätöksen, että XSS-haavoittuvuuksiin joko suhtaudutaan verkkopalveluiden ylläpitäjien näkökulmasta liian kevyesti tai tietoisuus tästä haavoittuvuuden muodosta on aivan liian vähäinen. Toisena johtopäätöksenä on, että loppukäyttäjän ei voida koskaan olettaa olevan riittävän valveutunut tai vastuussa haavoittuvuuteen lankeamisesta, vaan vastuu on aina sivuston ylläpitäjällä.

XSS-haavoittuvuuksien hyödyntäminen vaatii jonkin verran luovuutta ja mielikuvitusta, eli “ei se tarina, vaan miten se kerrotaan”. Jos tavoitteena todella on aiheuttaa haittaa, niin keinojen keksiminen ei viime kädessä ole ongelma.

Luettavaa

• Wikipedia: Cross Site Scripting
• XSS Cheat Sheet
• XSSed – Cross Site Scripting attacks information and archive
• “alert(‘xss’) – The slow death of XSS”
• Opera Dev Community: JavaScript for Hackers
• Video: JavaScript: The Evil Parts (Billy Hoffman, JSConf 2010)
• Listaus XSS-haavoittuvuuksista Suomessa (päivitetty viimeksi 19.4.2008)

Katso demo

Lataa tiedostot

Tämä opas on henkinen jatko-osa jutulle nimeltään Ajax:in alkeet jQueryn avulla. Demosivu muistuttaa pitkälti edelliskertaista sivua, mutta joitakin muutoksia on tullut:

index.html:

<!DOCTYPE html>
<html lang="fi">

<head>
	<meta charset=utf-8>
	<title>Otsikko</title>

	<script src="http://www.google.com/jsapi"></script>
</head>

<body>

	<h1>Otsikko</h1>

	<ul id="navigointi">
		<li><a id="etusivu" href="#">Etusivu</a></li>
		<li><a id="uutiset" href="#">Uutiset</a></li>
		<li><a id="yhteystiedot" href="#">Yhteystiedot</a></li>
	</ul>

	<div id="sisalto">

	</div>

</body>
</html>

Nyt navigointilinkit eivät johda mihinkään ja sivun varsinainen sisältö on poistettu, sillä tulemme hoitamaan tämän kaiken jQueryn ja Ajaxin avulla. Näinhän ei tietenkään oikealla sivulla koskaan tulisi toimia, mutta jotta juttumme pääasia tulisi mahdollisimman selväksi, oiotaan mutkia tältä osin hiukan.

Kaikki sisältö on siirretty yhteen dokumenttiin nimeltään ajax.html, jotta jatkossa osioiden käsittely jQueryllä olisi hiukan helpompaa. Heitetään soppaan vielä mukaan pieni kuvagalleria jokaiselle osiolle:

ajax.html:

<div id="etusivu">
	<h2>Etusivun jutut</h2>

	<p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua...</p>

	<ul id="kuvalinkit">
		<li><a href="#" class="kuva1">Kuva 1</a></li>
		<li><a href="#" class="kuva2">Kuva 2</a></li>
		<li><a href="#" class="kuva3">Kuva 3</a></li>
	</ul>

	<div id="galleria">
		<div class="kuva1"></div>
		<div class="kuva2"></div>
		<div class="kuva3"></div>
	</div>
</div>

<div id="uutiset">
	<h2>Uutiset</h2>

	<p>Päivän tärkeimmät tapahtumat.</p>

	<ul id="kuvalinkit">
		<li><a href="#" class="kuva1">Kuva 1</a></li>
		<li><a href="#" class="kuva2">Kuva 2</a></li>
		<li><a href="#" class="kuva3">Kuva 3</a></li>
	</ul>

	<div id="galleria">
		<div class="kuva1"></div>
		<div class="kuva2"></div>
		<div class="kuva3"></div>
	</div>
</div>

<div id="yhteystiedot">
	<h2>Yhteystiedot</h2>

	<p>Osoite, puhelinnumero yms...</p>

	<ul id="kuvalinkit">
		<li><a href="#" class="kuva1">Kuva 1</a></li>
		<li><a href="#" class="kuva2">Kuva 2</a></li>
		<li><a href="#" class="kuva3">Kuva 3</a></li>
	</ul>

	<div id="galleria">
		<div class="kuva1"></div>
		<div class="kuva2"></div>
		<div class="kuva3"></div>
	</div>
</div>

Galleriat sisältävät kolme ”kuvaa” jotka tulevat päivittymään #sisalto-divin sisällä dynaamisesti käyttäjän klikkaillessa kuvalinkkejä. Tässä esimerkissä simuloimme kuvia tyhjillä diveillä. Kuvat on oletuksena piilotettu näkyvistä display: none; -määreellä.

Kirjoitetaan navigoinnista vastaava jQuery uusiksi:

google.load("jquery", "1.4.2");
google.setOnLoadCallback(function() {

	// Ladataan etusivun sisällöt näkyviin
	$('#sisalto').load('ajax.html #etusivu');

	// Vaihdetaan näkymää klikatun linkin mukaan
	$('#navigointi a').click( function() {

		$('#sisalto').load('ajax.html #' + $(this).attr('id'));

		return false;

	});

});

Ensimmäinen jQuery-loitsu on varmaankin aika selvä. Toisessa pätkässä lataamme klikatun linkin id:tä vastaavan div:in ajax.html:stä.

Seuraavaksi voimmekin jatkaa edellisen perään galleriamme toiminnallisuus. Logiikka on pitkälti sama, kuin aiemminkin:

google.load("jquery", "1.4.2");
google.setOnLoadCallback(function() {

	// Ladataan etusivun sisällöt näkyviin
	$('#sisalto').load('ajax.html #etusivu');

	// Vaihdetaan näkymää klikatun linkin mukaan
	$('#navigointi a').click( function() {
		$('#sisalto').load('ajax.html #' + $(this).attr('id'));
		return false;
	});

	// Avaa klikattu kuva ja piilota edellinen
	$('#kuvalinkit a').click( function() {

		$('#galleria .' + $(this).attr('class')).show('slow')
		.siblings()
		.hide('slow');

		return false;

	});
});

Kaiken järjen mukaan edellisen koodin pitäisi toimia aivan kuten navigoinninkin, mutta klikatessa kuvalinkkejä kuvat eivät kuitenkaan aukea. Mitä oikein tapahtui?

Ken vanhoja muistaa, sitä tikulla silmään

Kun selain on saanut ladattua sivun rakenteen, DOM:in, jQuery käy sen läpi ja lisää mm. klikkausten tapahtumakäsittelijät (click event handlers) vaadituille elementeille, meidän tapauksessamme kuvalinkeille. Kun lataamme Ajax-kutsulla #sisalto-diviin jonkin sisältönäkymistä, muokkaamme tätä rakennetta jälkeenpäin. jQuery ja JavaScript ovat tällä hetkellä hieman ulalla, sillä kukaan ei ole kertonut heille, että sivuilla on jotain tapahtunut. Meidän täytyy siis kertoa JavaScriptille jotenkin, että sivu on päivittynyt ja sen täytyy ottaa huomioon myös uusi sisältö.

Kun ei homma itseltä onnistu, delegoidaan

jQueryn tuorein päivitys, 1.4.2, toi mukanaan uuden .delegate()-metodin, jolla saamme ongelmamme ratkaistua. Delegate-metodin toimintaperiaate ei välttämättä aukea aivan heti kaikille joten otetaanpa alkuun pieni annos JavaScriptin teoriaa:

Tapahtumien kupliminen, tai event bubbling, on olennainen osa koko JavaScriptin filosofiaa. Kun käyttäjä klikkaa elementtiä sivuilla, alkaa taustalla erikoinen tapahtumaketju. Katsotaan vaikka esimerkiksi demosivumme linkkilistaa: Klikatessa linkkiä listassa, laukeaa klikkaustapahtuma tässä kyseisessä HTML-elementissä. Tämän jälkeen linkkielementti ”mainostaa” tätä tapahtumaa isäntänään olevalle LI-elementille. LI-elementti taas heittää tämän viestin ylöspäin UL-elementille ja näin jatketaan ylöspäin aina dokumenttipuun alkuun asti, ellei kuplimista jostain syystä erityisesti haluta katkaista.

Delegate-metodin temppuna on hakea jokin ylempi elementti sivuilta ja sitoa kuplimisen kautta jonkin alempana dokumenttipuussa olevan elementin tapahtuma, tässä tapauksessa klikkaus, siihen. Jotta saisimme delegate-metodin käyttöömme, pitää meidän valita sivuilta jokin kaikille linkeille yhteinen elementti, jota ei päivitetä Ajax-kutsuja tehdessä. Body on useasti aika varma valinta. Käytämme body:a hyväksemme kierrättämällä klikkaustapahtumat sen kautta ja delegoimme tapahtumat alaspäin uusille, Ajax:lla tuoduille elementeille.

Muutetaan alkuperäisiä kuvanvaihtolinkkiemme tapahtumakäsittelijöitä hiukan niin, että otamme delegate-metodin mukaan leikkeihin:

// Avaa klikattu kuva ja piilota edellinen
$('body').delegate('#kuvalinkit a', 'click', function() {
	$('#galleria .' + $(this).attr('class')).show('slow')
	.siblings()
	.hide('slow');
	return false;
});

Nyt kuvalinkit pelaavat kaikissa alinäkymissä kauniisti. Olisimme voineet sitoa delegoinnin myös lähemmäksi kuvalinkkejä demosivullamme, esimerkiksi #sisalto-diviin, mutta suorituskyvyllisesti tällä ei näin pienessä demossa ole merkitystä.

Mitä suuremmaksi Ajax-projektit kasvavat, sitä arvokkaammaksi suorituskyvyn parantajaksi delegate nousee. Vanhemmissa jQuery-versioissa käytetty live()-metodin perusidea on pitkälle sama, kuin delegatella, mutta se sitoo tapahtumakäsittelijät aina dokumentin alkuun. Delegatella voimme sitoa klikkausten seurannan mahdollisimman lähelle klikkauksen alkujuuria ja näin vähentää selaimen taakkaa JavaScriptin käsittelyssä.

jQueryn ja JavaScriptin optimoinnista syvemmin kiinnostuneiden kannattaa katsoa Paul Irish:in esitelmä aiheesta: jQuery Anti-Pattern for Performance.

Valmiin demon voit katsastaa täältä.

Lataa tiedostot

Katso demo
Lataa tiedostot

Monille ensimmäinen kosketus dynaamisten sivujen rakentamiseen on PHP:n include-ominaisuus jolla HTML-sivu voidaan koostaa useammasta pienemmästä kappaleesta. Näin esimerkiksi sivun navigointia ei tarvitse ei tarvitse toistaa HTML-koodissa uudestaan joka sivulla, vaan se voidaan hakea yhdestä tiedostosta joka kerta.

Tänä päivänä sivulle voi helposti tuoda sisältöä myös sivun latauksen jälkeen. Tähän käytetään AJAX-tekniikkaa, joka mahdollistaa sivun sisällön päivittämisen ilman, että koko sivu ladataan uudelleen.

Käytän esimerkeissä jQuery JavaScript-kirjastoa, joka harmonisoi mukavasti selainten erilaisen käyttäytymisen JavaScriptin kanssa, sekä helpottaa ja nopeuttaa kaiken kaikkiaan koodin kirjoittamista.

Tehdään alkuun yksinkertainen mallisivu, jolla on vain pieni navigointi ja yksi div-elementti, johon dynaaminen sisältö ladataan. Ei mitään liian jännää:

<h1>Otsikko</h1>

<ul>
 <li><a id="etusivu" href="index.html">Etusivu</a></li>
 <li><a id="uutiset" href="uutiset.html">Uutiset</a></li>
 <li><a id="yhteystiedot" href="yhteystiedot.html">Yhteystiedot</a></li>
</ul>

<div id="sisalto">
 <h2>Etusivun jutut</h2>
 <p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua...</p>
</div>

Seuraavaksi voimme tehdä navigointia vastaavat sisältöosiot omiin tiedostoihinsa:

uutiset.html

<h2>Uutiset</h2>

<p>Päivän tärkeimmät tapahtumat.</p>

yhteystiedot.html

<h2>Yhteystiedot</h2>

<p>Osoite, puhelinnumero yms...</p>

Lisää vielä seuraava rimpsu sivusi head-osioon:

<script src="http://www.google.com/jsapi"></script>

Edellinen koodinpätkä mahdollistaa jQueryn käytön suoraan Googlen palvelimelta, joten sinun ei tarvitse asentaa kirjastoa välttämättä itsellesi.

Nyt meillä on kaikki tarvittava sisältö ja voimme alkaa rakentamaan JavaScriptiä, joka hoitaa sisällön hakemisen #sisalto-diviin kun käyttäjä klikkaa navigoinnin linkkiä. Käytämme jQueryn .load()-metodia, jonka syntaksi on hyvin yksinkertainen:

// Ladataan jQuery Googlen palvelimelta ja ajetaan JS vasta kun
// koko dokumentti on latautunut.
google.load("jquery", "1.4.2");
google.setOnLoadCallback(function() {

	// Kun Uutiset-linkkiä klikataan:
	$('#uutiset').click( function() {

		// Lataa uutiset.html-tiedoston sisältö 'sisalto'-divin sisään.
		// Samalla vanha sisältö pyyhkiytyy pois.
		$('#sisalto').load('uutiset.html');

		// Lopuksi estämme selainta turhaan seuraamasta linkkiä
		// klikattuun osoitteeseen.
		return false;

	});

	// Toistetaan sama temppu yhteystiedoille
	$('#yhteystiedot').click( function() {
		$('#sisalto').load('yhteystiedot.html');
		return false;
	});

});

Tällä hetkellä emme ole vielä tehneet mitään etusivulle vievälle linkille ja tässä yksinkertaisessa esimerkissä kaikki toimii jo nyt ok, mutta voimme ladata myös etusivun sisältöosuuden uudestaan etusivulle.

	// Ladataan etusivun sisällöt takaisin näkyviin ilman
	// koko sivun uudelleen päivittämistä
	$('#etusivu').click( function() {
		$('#sisalto').load('index.html #wrapper');
		return false;
	});

Syntaksi on hiukan muuttunut tällä kertaa. Koska etusivun jutuille ei ole olemassa omaa erillistä HTML-tiedostoaan, vihreiden arvojen kunniaksi kierrätämme index.html-tiedoston uusiokäyttöön, mutta otamme siitä vain tarvitun osan, eli sisällön:

$('#sisalto').load('index.html #wrapper');

Jos yrittäisimme käyttää edellisten esimerkkien koodia ja lataisimme vain suoraan #sisalto-divin vanhan #sisalto-divin sisään tapahtuisi aika epätoivottu reaktio:

<div id="sisalto">
 <div id="sisalto">
 <h2>Etusivun jutut</h2>
 <p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua...</p>
 </div>

</div>

Koska Yo Dawg-efekti ei ole tavoitteissamme, lisäämme alkuperäiseen index.html-tiedostoon ylimääräisen wrapperin heti #sisalto-divin jälkeen. Ylimääräisen HTML:n lisääminen ei ole kovin elegantti ratkaisu, mutta jokainen voi kotitehtävänä miettiä, miten edellä esitetty ongelma kierretään tyylikkäämmin.

Valmiin demon voit katsastaa täältä.

Lataa tiedostot

Mikä Savalanche?

Savalanche on uudenlainen verkkokauppapalvelu, joka rakentuu Internetin sosiaalisen median palveluiden päälle – tai oikeastaan niiden sisälle. Savalanchessa kuka tahansa voi perustaa kaupan, jopa ilman omia tuotteita. Kaupassa voi nimittäin myydä muiden tahojen maahantuomia tai valmistamia tuotteita, näin esimerkiksi suositun blogin tai keskustelupalstan ylläpitäjä voi helposti ansaita lisätuloja.

Savalanche on periaatteessa tavanomainen täyden palvelun verkkokauppapalvelu, jolla yritys voi viedä tuotteensa myyntiin web-sivuilleen ja esim. Facebookin kaltaisiin sosiaalisiin medioihin. Juju piileekin siinä, että Savalanchea hyödyntäen kuka tahansa voi rakentaa laajan, monikanavaisen verkkokauppaverkoston. Lisäksi palvelulla voidaan myös kerätä varoja esim. hyväntekeväisyyteen tai urheiluseuroille.

Kolme muskettisoturia

Savalanche palvelun takana ovat kolme suomalaista IT-alan konkaria, jotka aikaisemmassa elämässään ovat olleet suunnittelemassa, rakentamassa ja myymässä suuria tietojärjestelmiä ja ohjelmistoja matkapuhelinteollisuuden tarpeisiin. He muodostavat yhdessä Vuole Digitalin.

Apuja kehitystyöhön on löytynyt omien alojensa asiantuntijayrityksistä. Palveluun uskovat muutkin, sillä tuotekehitystä ovat olleet tukemassa mm. Tekes ja Finnvera.

Kuinka palvelu erottuu tavanomaisista verkkokaupoista?

Savalanchessa verkkokaupan voi perustaa ilman ainuttakaan omaa tuotetta. Kuulostaa ehkä kummalliselta, mutta tämä on juuri se todellinen oivallus, sillä myymällä tuotteita muiden valikoimista voi ansaita provisiota ilman omaa varastoa tai muuta päänvaivaa. Sen lisäksi käyttäjät voivat myydä myös omia tuotteitaan kuten normaalissa verkkokaupassa. Laajuudeltaan tuotevalikoima voi olla muutamasta kappaleesta satoihin.

Kuulostaisiko ura verkkokauppiaana hyvälle? Kohta se on helppoa kuin heinänteko. Savalanche on rakennettu toimimaan yhdessä Facebookin kaltaisten sosiaalisen median palveluiden kanssa. Kuka tahansa voi perustaa verkkokaupan Facebook-sivuilleen muutamassa minuutissa.

Savalanchen avulla käyttäjät voivat halutessaan kerätä rahaa myös hyväntekeväisyyteen tai yhdistyksille, urheiluseuroille, koululuokille jne. Tärkeän työn tukeminen on entistä helpompaa.

Savalanche on muutamasta markkinoilla olevasta social shopping -palveluista poiketen voimakkaammin social selling -palvelu, jossa ihmiset luovat ystäväpiiriään ja samanhenkisiä ihmisiä kiinnostavia kauppoja ja valikoimia crowdsourcing -hengessä.

Savalanche käytännössä

Verkkokaupan perustaminen omille sivuilleen, Facebookiin tai blogiin tapahtuu Savalanche.com:ssa, tai suoraan Savalanchen Facebook-sovelluksessa. Kaupan perustaminen on täysin ilmaista ja vaikeustaso on samaa tasoa web-sähköpostipalveluun rekisteröitymisen kanssa. Tämän jälkeen käyttäjälle alkaa kertyä myyntituottoja sitä mukaa, kun hänen kaupastaan ostetaan tuotteita.

Savalanchen kautta esim. maahantuojat voivat listata tuotevalikoimansa tai varastonsa sisällön palveluun, jolloin kuka tahansa kiinnostunut voi myydä heidän tuotteitaan perustamassaan verkkokaupassa. Senkin pitäisi olla lupauksen mukaan nopeaa, helppoa ja ilmaista.

Kenelle Savalanche on suunnattu?

Savalanchen pitäisi soveltua periaatteessa kaikille. Palvelusta hyötyvät niin maahantuojat ja tuotteiden valmistajat kuin kuka tahansa Internetin aktiivi. Olennaisinta on tietysti se miten paljon lukijoita tai kavereita on palvelussa, sillä tuottomahdollisuudet kasvavat sen mukaan.

Helpotusta pitäisi tulla myös nuoremmalle väelle ja varsinkin heidän vanhemmilleen. Urheiluseurat, koululuokat, yhdistykset ynnä muut voivat hankkia lisävaroja tai korvata perinteisen (ja usein kovin turhauttavan) ovelta ovelle -myynnin keskittämällä varainkeruun Savalanchen avulla webbiin.

Savalanchesta on iloa myös tiskin toiselle puolelle. Selailemalla kiinnostavaa blogia tai ystävien kauppoja valikoimat vastaavat myös todennäköisesti omia tarpeita ja kiinnostuksen kohteita. Esimerkiksi maastopyöräilyaiheisen keskustelupalstan ylläpitäjällä on todennäköisesti erittäin hyvät valmiudet valita verkkokauppaansa sellaisia tuotteita, jotka kiinnostavat myös hänen lukijoitaan.

Kohti tulevaisuutta

Kuuleman mukaan Savalanche käynnistyy suljettuna pilottina kesän 2010 aikana. Palveluun tehdään silloin viimeiset säädöt ja varmistetaan, että luvattu helppokäyttöisyys ja selkeys toteutuvat myös käytännössä. Savalanchen pitäisi aueta kaikille suomalaisille syksyllä 2010. Gfx.fi toivottaa onnea uudelle lupaavalle palvelulle ja sen kehitystiimille. Jäämme odottamaan jännityksellä tulevaa syksyä.

P.S. Palvelun kehittäjät tarvitsevat kesän 2010 pilottiin vielä muutaman beta-testaajan. Heräsikö kiinnostus? Lisätietoja saat sähköpostilla osoitteesta info@savalanche.com.

Listalle on valittu 3. asteen opintopaikkoja ympäri Suomen – sisältäen ammattikorkeakouluja ja yliopistoja. Listalta löytyy mm. ohjelmointiin, graafiseen suunnitteluun ja viestintään liittyviä koulutusohjelmia. Lista on aakkosjärjestyksessä. Koulut ovat itse toimittaneet esittelymateriaalin koulutusohjelmistaan.

Jyväskylän ammattikorkeakoulu

Jyväskylän ammattikorkeakoulun Teknologiayksikössä olevalla ICT-tulosalueella on
kolme koulutusohjelmaa, joissa koulutetaan tietoverkkoihin liittyvää osaamista:

• Mediatekniikan koulutusohjelma, jossa opiskellaan mm. verkkomultimediaa
• Ohjelmistotekniikan koulutusohjelma, jossa aiheina ovat mm. web- ja mobiiliohjelmointi
• Tietotekniikan koulutusohjelma, jossa keskitytään tietoverkkojen suunnittelun ja ylläpidon koulutukseen.

Lisätietoja koulutusohjelmista

Kymenlaakson ammattikorkeakoulu

Alla tietoa Kymenlaakson ammattikorkeakoulun digialan koulutuksesta sekä sitä läheltä liippaavista suuntautumisvaihtoehdoista.

Viestintä

Kymenlaakson ammattikorkeakoulu tarjoaa viestinnän koulutusohjelmassa av-median, digitaalisen median sekä graafisen suunnittelun koulutusta.

• Av-median suuntautuminen tuottaa osaajia audiovisuaalisen alan toteutus- ja suunnittelutehtäviin.
• Monipuolinen verkko-osaajien suuntautumisvaihtoehto on Digitaalinen media, jossa suunnitellaan ja toteutetaansisältöjä 3D-, peli-, web-, ja mobiiliympäristöihin. Digitaalisen median sv:ssa opiskellaan muun muassa käyttöliittymäsuunnittelua, e-markkinointia, hakukoneoptimointia, sisällöntuotantoa, web-ohjelmointia sekä mobiili- ohjelmointia. Samoin tarjolla on pelituotantoon liittyvä opinto-osio. Sen painopiste on pelien suunnittelussa, konseptoinnissa, käsikirjoittamisessa sekä visuaalisten sisältöjen tuotannossa.
• Graafinen suunnittelija hallitsee kuvallisen viestinnän eri medioissa.

Lisätietoja koulutusohjelmasta

Tietotekniikka

KyAMK:n tietotekniikan koulutusohjelman ohjelmistotekniikan suuntautumisvaihtoehdon opiskelijat sijoittuvat valmistumisensa jälkeen ohjelmistojen ja web-palvelujen kehitystehtäviin. Koulutus keskittyy ohjelmointiin ja tapahtuu osittain Ohjelmistoakatemiassa oikeissa ohjelmistoprojekteissa. Eritysalana KyAMK:ssa on valinnainen peliohjelmoinnin koulutus (18 op), jonka toteutukseen osallistuu peliteollisuus.

Lisätietoja koulutusohjelmasta

HAAGA-HELIA AMK

HAAGA-HELIAsta löytyy mm. tietojenkäsittelyn koulutusohjelman opetusta.

Tässä linkki suomenkieliseen opetussuunnitelmaan ja tässä linkki opiskelijatöiden esittelysivustoon, jota kehitetään parasta aikaa.

Vaasan ammattikorkeakoulu

Vaasan ammattikorkeakoulussa (Vamkissa) on tarjolla mm. tietojenkäsittelyn ja tietotekniikan koulutusohjelmat.

Vaasan ammattikorkeakoulussa löytyy alan koulutusta tietojenkäsittelyn koulutusohjelman muodossa. Koulutusohjelmassa valmistutaan ict-alan tradenomiksi ja digitaaliset palvelut on yksi suuntautumisvaihtoehdoista. Tietojenkäsittelyn koulutusohjelman tiedot löydät täältä. Vastaava ruotsinkielinen ohjelma on informationsbehandling, josta löytyvät tiedot täältä.

Digitaalisen palvelun sisältö: Digitaaliset palvelut: graafisen tuotannon työkalut, sisällöntuotanto verkossa, Flash ja animaatiot, multimedian tuotannon työkalut, videokuvaus ja editointi, 3d-mallinnus ja animaatiot.

Tietotekniikkaa on tarjolla meillä suomenkielisessä koulutusohjelmassa  ja englanninkielellä Information Technology -koulutusohjelmassa.

Hämeen ammattikorkeakoulu

Alta löydät Hämeen ammattikorkeakoulun tietojenkäsittelyn ja liiketalouden
koulutusohjelmien tiedot ja linkit.

Kaikki käyttävät nettiä, me teemme sitä!
Opiskele tietojenkäsittelyn tradenomiksi Hämeenlinnassa Hämeen ammattikorkeakoulussa.

Asiakastyytyväisyys, innovatiivisuus ja yhteistyökyky!
Opiskele liiketalouden tradenomiksi Hämeenlinnassa Hämeen ammattikorkeakoulussa. Kurssisisältönä mm. Digital Enterprise 30 op.

Tampereen yliopisto

Tampereen yliopiston informaatiotieteiden tiedekunnassa on mm. seuraavia koulutuksia:

Interaktiivisen median maisterikoulutus

Tietojenkäsittelytieteiden koulutusohjelma:
Koulutusohjelmassa mm. käyttöliittymien ohjelmistokehitykseen tai vuorovaikutteiseen teknologiaan syventävät maisterikoulutukset

Vaasan yliopisto

Teknisen viestinnän koulutusohjelma.

Vuonna 1996 perustetun Teknisen viestinnän koulutusohjelman perusajatuksena on se, että viestintätieteiden ja tietotekniikan opiskelijat opiskelevat yhdessä koko koulutusohjelman ajan, vaikka he kuuluvatkin eri tiedekuntiin (filosofiseen ja teknilliseen) ja eri pääaineisiin.

Koulutusohjelman opiskelijoilla on yhteiset perus- ja aineopinnot sekä syventävät opinnot. Muut opinnot, kuten sivuaineet, suoritetaan oman
oppiaineen ja tiedekunnan vaatimusten mukaan. Myös tutkinnot ovat tiedekuntakohtaisia. Koulutusohjelmasta valmistuu humanististen tieteiden kandidaatteja, filosofian maistereita, kauppatieteiden kandidaatteja ja kauppatieteiden maistereita.

Koulutusohjelmasta valmistuneet opiskelijat työskentelevät mm. www-toimittajina, www-ohjelmoijina, teknisinä viestijöinä (projektipäälliköinä erilaisissa dokumentointiprojekteissa, visuaalisina suunnittelijoina, teknisinä kirjoittajina jne.).

Satakunnan ammattikorkeakoulu

Satakunnan ammattikorkeakoulussa (SAMK) liiketoiminnan ja kulttuurin alalla on kaksi koulutusohjelmaa, jossa käsitellään verkossa tapahtuvaa suunnittelu- ja tuotantotyötä:

Viestintä
Kuvataide

Koulutusohjelmien kuvaukset löytyvät yllä olevista linkeistä.

Oulun ammattikorkeakoulu

Alaan liittyviä koulutusohjelmia:

Viestintä
Tietojenkäsittely

Koulutusohjelmien kuvaukset löytyvät yllä olevista linkeistä.

Aalto-yliopiston taideteollinen korkeakoulu

Graafinen suunnittelu:
Opetusalueet kattavat graafisen viestinnän kaikki mediamuodot ja levityskanavat. Opiskelija saa valmiudet toimia erilaisissa alan työtehtävissä, kuten suunnittelijana, kuvittajana, taittajana, kirjagraafikkona, pakkaussuunnittelijana, mainosgraafikkona, informaatiosuunnittelijana sekä av- ja animaatiosuunnittelijana. Maisterin tutkinto kehittää valmiuksia konseptisuunnitteluun ja art director -tehtäviin sekä luo mahdollisuuksia tutkimuksen tekemiseen ja jatko-opintoihin siirtymiseen.

New Media ja Sound Design in New Media
(+ suuntautumisvaihtoehtona uusi Game Design and Production):
http://www.taik.fi/mela/ ja http://mlab.taik.fi/

Uuden median opetukseen ja tutkimukseen erikoistuneen Medialaboratorion opetusaloja ovat uusmedian sisältötuotanto, ‘tiedon design’, vuorovaikutteinen kerronta, virtuaaliympäristöt sekä tulevaisuuden mediaratkaisut.

Oulun Yliopisto

Oulun yliopistossa selkeiten digimedian kenttään osuvat seuraavat:

Tietotekniikka
Tietojenkäsittelytieteiden koulutusohjelma

Kajaanin ammattikorkeakoulu

Kajaanin ammattikorkeakoulussa on Suomen ainoa korkeakoulututkintoon tähtäävä koulutus pelikehityksen alalle. Lisätietoa koulutuksesta löytyy osoitteesta: http://www.kajak3d.com

Laurea-ammattikorkeakoulu

Digitaalisen median koulutusohjelma

Tietojenkäsittelyn koulutusohjelmasta valmistutaan tradenomiksi. Koulutus antaa valmiudet toimia laaja-alaisesti tietojenkäsittelytehtävissä. Mahdollisia tehtäviä ovat mm. verkkosivujen suunnittelu, ohjelmistokehitystyö, käytettävyystutkimus, visuaalinen suunnittelu, yritysviestinnän teknisten ratkaisujen kehittäminen.

Opintoihin kuuluu pakollisena osana niin tietojenkäsittelyn, liiketalouden kuin viestinnänkin perusopinnot. Verkkosivujen kehittämisen perusosaamista syvennetään ohjelmointiosaamisen sekä käyttäjäkeskeisen käyttöliittymä- ja ohjelmistosuunnittelun alueille. Osaaminen syvenee myös visuaalisen suunnittelun ja erilaisten mediaelementtien käytön osalta.

Eikä tässä kaikki…

Yllä oleva lista on vain pieni osa mahdollisista opiskelupaikoista Suomen rajojen sisäpuolella. Jos huomaat tutun oppilaitoksen tai koulutusohjelman puuttumisen listalta niin lisää sen tiedot kommentin yhteyteen. Miten on – Häämöttääkö sinulla edessä opiskeleminen vai joko koulut on käyty?

CSS3-transitiot esiteltiin käytännössä loppuvuodesta 2007 Safarin toimesta. Tuohon aikaan, niihin viitattiin termillä “CSS Animations”, mutta terminologia muuttui Safarin esitellessä omat selainkohtaiset ominaisuutensa, joita nykyään kutsutaan CSS-animaatioiksi.

Olen jakanut tämän aiheen kahteen artikkeliin. Ensimmäisessä artikkelissa käsittelen CSS3 Transitioita yleisesti. Lisäksi esittelen perustason käyttötapauksia muutamien CSS-arvojen avulla, joita voi hyödyntää CSS3-transitioita ja -transformaatioita luotaessa.

Tämä artikkeli sisältää myös viittauksia erinomaisiin CSS3-artikkeleihin. Joten artikkelin luettuasi, voit niiden avulla päivittää ja parantaa tietouttasi CSS3-transitioista.

Kuten jo totesin, aihe on jaettu kahdeksi artikkeliksi. Ensimmäisen osan nimi on “CSS3 Transitiot – olemmeko jo perillä?”, tarjoten yleisen katselmuksen CSS3-transitioiden tämänhetkiseen tilaan. Toisen osan nimi on “CSS3 Transitions – ongelmatilanteet ja ratkaisut”, joka pureutuu syvemmälle transitioihin ja niiden eroihin eri selainten välillä.

Ensimmäinen artikkeli rakentuu seuraavista osista:

• Kuinka päästä alkuun – mitä sinulta täytyy löytyä
• Perusteiden perusteet – mitä sinun on hyvä tietää transitioista
• Perusteet – mitä sinun täytyy tietää transitioista (demo-osio)
• Johtopäätökset – eli olemmeko jo perillä vai emme?
• Ulkoiset viittaukset – missä sinun kannattaa vierailla artikkelin luettuasi

Kuinka päästä alkuun

Alkuun päästäksesi tarvitset ainakin yhden selaimen, joka tukee CSS3-transitioita:

• Apple Safari (tuettuna Safari 3.1:sta ja iPhone OS 2.0:sta lähtien)
• Google Chrome
• Mozilla Firefox 3.7 alpha (tunnetaan myös Minefield:ina)
• Opera 10.5x (tuettuna myös Opera Mobile 10 beta 2)

Entä Internet Explorer?

Tällä hetkellä on ilmoitettu, että edes Internet Explorer 9 ei tule tukemaan CSS3-transitioita. Paras tuki Internet Explorerin transitioille ja transformaatioille voidaan luoda hyödyntämällä Matrix Filteria.

Lisäksi suosittelen lukemaan artikkelin Cross-Browser Animated CSS Transforms — Even in IE, jonka on kirjoittanut Zoltan “Du Lac” Hawryluk. Hän on myös cssSandpaperin luoja.

Perusteiden perusteet

Ikävä kyllä CSS3-transitioiden luomiseksi ei ole olemassa vain yhtä sääntöä. Itse asiassa, jokaisella selaimella on oma selainkohtainen tapansa kirjoittaa sääntöjä. Onneksi syötettävien arvojen syntaksi on eri selainten välillä keskenään samanlainen.

Mihin ominaisuuksiin transitiot vaikuttavat?

Valtaosa ominaisuuksista tukevat transitioita enkä lähde listaamaan niitä ykistellen. Selainten välillä on kuitenkin joitain eroja ja selkein niistä on tällä hetkellä se, että Firefox 3.7a ei tue ollenkaan transformaatioiden transitiointia.

Arvot transitioiden luomiseksi

Transitiot voidaan määritellä maksimissaan neljän eri arvon avulla:

Lyhyt muoto:

-webkit-transition: property_name duration timing_function delay;
-moz-transition: property_name duration timing_function delay;
-o-transition: property_name duration timing_function delay;
transition: property_name duration timing_function delay;

Voit myös määritellä jokaisen arvon yksityiskohtaisesti:

(Kohde)ominaisuus:

-webkit-transition-property: property_name;
-moz-transition-property: property_name;
-o-transition-property: property_name;
transition-property: property_name;

Kesto:

-webkit-transition-duration: duration;
-moz-transition-duration: duration;
-o-transition-duration: duration;
transition-duration: duration;

Kesto (kuten viivekin) voidaan syöttää joko sekunteina (esim. 0.5s) tai millisekunteina (esim. 500ms). On kuitenkin tärkeää huomata, että ilman määrettä transitio ei toimi laisinkaan.

(Liikkeen) ajoitus-funktio:

-webkit-transition-timing-function: timing_function;
-moz-transition-timing-function: timing_function;
-o-transition-timing-function: timing_function;
transition-timing-function: timing_function;

Käytössä olevat ajoitus-funktiot:

• cubic-bezier(cp1_x, cp1_y, cp2_x, cp2_y)
• ease – sama kuin cubic-bezier(0.25, 0.1, 0.25, 1.0).
• linear – sama kuin cubic-bezier(0.0, 0.0, 1.0, 1.0).
• ease-in – sama kuin cubic-bezier(0.42, 0, 1.0, 1.0).
• ease-out – sama kuin cubic-bezier(0, 0, 0.58, 1.0).
• ease-in-out – sama kuin cubic-bezier(0.42, 0, 0.58, 1.0).

Viive:

-webkit-transition-delay: delay;
-moz-transition-delay: delay;
-o-transition-delay: delay;
-transition-delay: delay;

Viive (kuten kesto) voidaan syöttää joko sekunteina (esim. 0.5s) tai millisekunteina (esim. 500ms).

Yleisesti ottaen transitiot kannattaa määritellä oletustason selektorille, ilman pseudo-luokkia. Tämän ansiosta transitio tapahtuu molempiin suuntiin, esimerkiksi vietäessä kursori elementin päälle ja pois elementin päältä.

Muista myös, että joudut syöttämään jokaisen ominaisuuden neljästi saavuttaaksesi kattavan selaintuen. Siksi on melkein aina parasta käyttää lyhyttä muotoa pitääksesi CSS-koodin siistinä.

Perusteet

Tässä vaiheessa on hyvä demonstroida muutamia transitioita. Sinun tulee joko viedä kursori elementin päälle tai klikata elementin alla olevaa painiketta, jotta transitiot toimivat.

Kaikki koodiesimerkit on kirjoitettu jättäen selainkohtaiset määritykset pois tilan säästämiseksi.

Perus-transitio: Ulottuvuudet ja skaalaaminen

Aloitan esimerkillä yksinkertaisimmasta transitiosta. Samalla tässä tulee demotuksi, mitä eroa on perusominaisuuksilla width+height sekä scale-transformaatiolla.

#widthHeight {transition:all 500ms;}
#widthHeight:hover {width:200px; height:200px; line-height:200px;}
#scale {transition:all 500ms;}
#scale:hover {transform:scale(2.0, 2.0);}

Kuten huomaat, leveys ja korkeus -arvot kasvattavat elementtiä normaalisti, mutta skaalaus vaikuttaa samoin kuin, jos elementti olisi suhteellisesti positioitu. Scale-transformaatiossa origo on keskellä, kun taas leveyttä ja korkeutta säädettäessä origo on vasemmassa yläkulmassa.

Transitio ajoitus-funktioilla

Alla on kaksi lohkoa, jotka pyörivät; ensimmäinen pyörii hyödyntäen linear ajoitus-funktiota käyttäen ja toinen käyttää ease ajoitus-funktiota.

#rotateLinear {position:relative; clear:both; left:0px; transition:all 2500ms linear;}
#rotateEasing {position:relative; clear:both; left:0px; transition:all 2500ms ease;}
#rotateLinear:target {left:200px; transform:rotate(360deg);}
#rotateEasing:target {left:200px; transform:rotate(360deg);}

Kuten luultavasti huomasit, elementtien liike oli keskenään erilaista, mutta itse transitio päättyy samaan aikaan (2500ms jälkeen).

Transitio viiveellä

Viiveestä on joskus hyötyä. Ja viiveen käyttöönottaminen transitioissa on vaivatonta:

#bgColorDelay {background-color:#12142B; transition:background-color 500ms linear 800ms;}
#bgColorDelay:hover {background-color:#336699;}

Peräkkäiset transitiot

Useita transitioita voidaan ajaa myös peräkkäin. Tälle ei ole olemassa mitään oletusarvoa, mutta “ketju” voidaan saada aikaiseksi hyödyntäen viivettä:

#widthHeightOpacity {transition:width 500ms, height 500ms linear 500ms, opacity 500ms linear 1000ms;}
#widthHeightOpacity:hover {width:200px; height:200px; opacity:0.1;}

Tässä on kuitenkin yksi miinus: transitio esitetään samassa järjestyksessä riippumatta siitä viedäänkö kursori elementin päälle vai pois sen päältä. Useimmissa tapauksissa, siinä ei ole mitään järkeä. Siksipä meidän tulee määritellä transitiot (aikaisempiin esimerkkeihin nähden) käänteisessä järjestyksessä:

#widthHeightOpacity {transition:width 500ms 1000ms, height 500ms linear 500ms, opacity 500ms linear;}
#widthHeightOpacity:hover {width:200px; height:200px; opacity:0.1; transition:width 500ms, height 500ms linear 500ms, opacity 500ms linear 1000ms;}

Muita transitioita?

Mahdollisesti on asioita, joita en tässä vaiheessa ymmärrä mainita. Mutta esimerkkien pääpaino on osoittaa kuinka yksinkertaista transitioiden käyttöönottaminen on (vaikka ne vaativatkin hieman lisätyötä kattavan selaintuen saavuttamiseksi).

Johtopäätökset

Olemmeko jo perillä? Kyllä, olemme ainakin yli puolen matkan. Transitiot ovat yleisesti ottaen todella tyylikkäitä, kunhan niitä käyttää oikeissa tilanteissa.

Olen kuitenkin henkilökohtaisesti hieman epäileväinen CSS3-transitioiden suhteen: tässä vaiheessa niihin ei voi täysin luottaa ja lisäksi ne vaativat läpikohtaista selaintestaamista. Tulen käsittelemään näitä ongelmakohtia seuraavassa osassa. Lisäksi tulen vertailemaan CSS3-transitioita Javascript-kirjastojen (tässä tapauksessa jQuery) tarjoamien animaatioiden välillä.

Jos kuitenkin olet tekemisissä alustan kanssa, joka hyödyntää puhtaasti WebKit:iä (kuten iPhone tai Adobe AIR) niin älä jää ihmettelemään, vaan ota kaikki ilo irti sekä CSS3-transitioista ja Webkit-animaatioista.

Ulkoiset viittaukset

Alla on listattuna hyviä viitteitä eri resursseihin, joita sekä selainvalmistajat että yksityishenkilöt ovat tuottaneet. Suosittelen ehdottomasti lukemaan ne.

• Safari CSS Visual Effect Guide: Transitions
• Mozilla CSS transitions – MDC
• Opera: CSS3 Transitions support in Opera Presto 2.3

• CSS3.info
• CSS3, Please! The Cross-Browser CSS3 Rule Generator
• CSS Fundamentals: CSS 3 Transitions | NetTuts+
• CSS Transitions 101 | Webdesigner Depot
• Going Nuts with CSS Transitions | 24 ways
• Safari CSS Visual Effect Guide: Animations

Kommentteja?

Kommentteja artikkelista otetaan mielellään vastaan. Lisäksi, jos sinulla on lähettää hyviä viitteitä CSS3-transitioita käsitteleviin artikkeleihin, niin näistä on varmasti suurta apua minulle ja lukijoille.

Kotisivujen jurakaudella kotisivubisnes oli totta tosiaan erilaista kuin tänä päivänä. Päivittäminen oli teknistä ja kallista puuhaa, joten sitä pyrittiin välttämään viimeiseen asti. Jos asiakas halusi sivuille päivitystä, täytyi pirauttaa mainostoimiston tekniselle kaverille, joka tuntihintaan lisäsi ajankohtaisen uutisen sinne, pilkun tänne.

Päivitystyötä helpottavien julkaisujärjestelmien esiinmarssi viimeisen kymmenen vuoden aikana on muuttanut tilannetta ratkaisevasti. Enää sisällönpäivityksessä ei ole kyse mustasta magiasta, vaan toimistot uskaltavat myydä asiakkailleen ihan oikeasti helppokäyttöistä ja käyttökelpoista päivitystyökalua. Kerrotaan järjestelmän eduista, ja luvataan että ”jos sulta tään Wordin ja Lärvikirjan käyttö onnistuu, niin osaat sää sitte tänkin, heh heh!”.  Hommanhan pitäisi olla nimenomaan näin, mutta kertoisiko joku miksi sitten niin moni julkaisujärjestelmällä varustettu sivu jää kaikesta tästä huolimatta päivittämättä?

Räätälöity tuote, only for you!

Eletään vuotta 2010. Voisiko olla, että hyvän ja elävän palvelun tuottamiseksi asiakas tarvitsisi muutakin apua kuin könttähintaan tuntien puitteissa pykätyn päivitysjärjestelmän? Jos asiakkaan asiakkaat ansaitsevat fiksut ja selkeät kotisivut, voisiko asiakas itse ansaita oikeasti helppokäyttöisen ja hänen tarpeitaan ajatellen säädetyn julkaisualustan? Saisiko asiakas peräti tietää, mitä kaikkea netissä voitaisiin ihan pienelläkin vaivalla tehdä?

Tulee ymmärtää, että lähes kaikki web-sivustoja päivittävät henkilöt tekevät päivitystä oman työnsä ohessa. Jokainen osaa konettaa käyttää, mutta kukaan heistä ei ole digialan ammattilainen. Jos yrityksen yhteystiedot muuttuvat, päivitetään uudet tiedot nettiin tietenkin vaikka hampaat irvessä, koska asia on niin tärkeä. Mutta mikäli päivityksessä jokin tökkii, ei aamupalaverissa pyydetä teknologiajohtajalta blogikirjoitusta, lisätä messuilmoitusta tai suunnitella kevätkampanjan esittelyä näyttävästi myös kotisivuilla.

Ihmiset innostuvat edelleen helposti nähdessään omaa kädenjälkeään julkiwebissä. Jos päivitys ei suju kuin tanssi, innostus hiipuu. Sivuston kehitystä ja päivitystyötä ei koeta tärkeäksi, jos se on hankalaa! Tämä korostuu eksponentiaalisesti silloin, kun asiakkaan ydinosaaminen ei rullaa webissä.

Onko julkkari aina vain julkkari?

Pieni pulma on siinä, että sanalla ”julkaisujärjestelmä” voidaan tarkoittaa lähes mitä tahansa. Järjestelmä voi olla Wordpress, Joomla, Drupal tai digiyrityksen oma, vuonna 1999 lanseerattu ja sittemmin pintakuorrutettu muinaismuisto. ”Helppo päivitettävyys” voi tarkoittaa mitä tahansa. ”Yksinkertainen” voidaan käsittää usealla eri tavalla. Varsinainen ongelma tulee kuitenkin vastaan siinä, että edes käytetty julkaisualusta ei kerro vielä ollenkaan koko kuvaa lopullisesta tuotteesta. Ei edes valveutuneelle asiakkaalle, joka tietää eri järjestelmien erot ja ymmärtää omat tarpeensa täydellisesti!

Käsitteen hämäryys johtuu pitkälti siitä, että webbitoimistoissa julkkaritöitä tehdään monesti liukuhihnalta. Teknisen puolen kaveri vääntää yhden valmiiksi kuin kone, ja siirtyy sitten seuraavaan keissiin. Hommassa on sen verran kiire, ettei tekijää kiinnosta miten Maikki Mallikas 43v kokee työkalun nähdessään sen ensimmäisen kerran omalla koneellaan. Myynnin Pena hoitaa koulutuksen, mä teen niinku ennenki että sekin tajuu. Tekijän mielipide on se, että hommahan selvästi toimii – näin helppoa se on, katsokaas – ja se saa luvan riittää. Näitä on tullut tehtyä viime vuosina monia, ja valituksia ei ole kuulunut. Teen siis hyvää työtä.

Kuitenkin massatuotannossa käy usein niin, että julkaisujärjestelmään jää näkyville sellaisia toimintoja, joita ei yksittäisissä tapauksissa käytetä. Voikohan asiakkaalla mennä sormi suuhun? Mitähän nuo tiedostokategoriat ovat? Entä avainsanat? Keskustelun asetukset? Ei tällaisesta koulutuksessa puhuttu…

Asiakas ei ymmärrä, ja kokee ettei käsitä työkalusta kaikkea. Epävarmuus iskee aivan turhaan.

Harmi kyllä päivitystyökalujen ongelmat harvoin rajoittuvat vain siihen, että ylimääräistä informaatiota ei ole karsittu pois. Usein myös ominaisuudet toteutetaan tavalla joka kyllä toimii, muttei välttämättä ole kaikkein intuitiivisin. Budjetit ovat rajalliset, ja siitä syystä asioita ei ole varaa pyöritellä kaiken aikaa, vaan mennään siitä mistä aita on matalin. Mennään sieltä mistä on aiemminkin menty. Onko näin toimiminen kaiken aikaa järkevää bisnestä?

Sivujen koostajana paljon töitä tehneenä minua aina masentaa, kun poikkean kuukausia aiemmin toteuttamalleni saitille vain huomatakseni, että ensimmäisen ”Sivusto on julkaistu”-viestin jälkeen ajankohtaispalstalle ei ole ilmaantunut mitään. Viimeisin päivitys mihinkään on tehty viikko sivujen julkaisun jälkeen. Tiedän että sivut on kyllä maksettu, olen saanut palkan ja asiakas on ollut niihin ilmeisen tyytyväinen. Mutta väkisinkin mieleen hiipii ajatus: eikö tehtäväni alan ammattilaisena ole nimenomaan auttaa asiakasta kommunikoimaan webissä omien asiakkaidensa kanssa? Enkö ole jossain suhteessa tässä tavoitteessani nyt epäonnistunut?

Asiakasko tietää mitä tahtoo?

Kun asiakas hakee kotisivuilleen uutta ilmettä ja tyyliä vuonna 2010, hän hakee myös apua kiinnostavan sisällön tuottamiseen ja kävijöiden houkutteluun, ymmärsi hän sitä itse tai ei. Mainostoimisto ei useastikaan voi tuottaa asiakkaan sivujen sisältöä, vaan aloitteen on tultava asiakkaalta itseltään. Toimisto voi kuitenkin ehdottomasti miettiä tapoja opettaa asiakasta aktivoimaan kotisivuissa piilevät voimavarat.

On molempien tahojen yhteinen etu, kun asiakkaan web-presenssi elää ja voi hyvin. Tulee käsittää, että harva asiakas todella ymmärtää internetin mahdollisuuksia tiedonjakokanavana, varsinkaan jurojen punastelijoiden luvatussa maassa, Suomessa. Web on hieno asia! Asiakasta tulee innostaa kantamaan oman kortensa kekoon! Mikään ei ole typerämpi sijoitus kuin nettisivut, joilla ei ole mitään eikä koskaan vieraile ketään.

Kokemani perusteella web elää erittäin nopeasti, mutta asiakkaille suuremmat mullistukset tulevat aina pienellä viiveellä. Ennen riittivät pelkät näyttävät sivut, sitten keksittiin myydä päivitettävyyttä ja rich mediaa. Tärkein asia tästä hetkestä ikuisuuteen on kuitenkin sisältö. Ehkä seuraavaksi myytäisiinkin apua sisällöntuottoon?

Niin, tai ehkä ei. Se on aika vaikeaa hommaa. Emmä kyllä tiedä mitä meidän asiakkaat oikeasti haluu.

90-luku oli todellista Internetin esiinmarssin aikaa. Internet, ja myös kaikki sen ympärillä, kehittyivät huimaa tahtia. Nettiyhteydet, tietokoneet sekä muut laitteet tuplasivat nopeutensa vähän väliä. Internetin isäksi kutsutun Tim Berners-Lee:n johdolla perustettiin W3C, joka otti hoitaakseen HTML-standardin ylläpidon ja kehitystyön.

Netscape ja IE kävivät veristä kamppailua nettiselainmarkkinoilla. Koko ajan kehitettiin jotain uutta ja kaikki olivat innoissaan. Vuosituhannen taitteeseen mennessä oli HTML:stä julkaistu jo 4.01 suositus ja IE oli ottanut suvereenisti ykköspaikan käytetyinpänä selaimena. Mutta mitä sitten tapahtui?

2000-luku: W3C ja XHTML

W3C päätti 2000-luvulla ottaa uutta suuntaa HTML:n kanssa kehittäen uuden XML-pohjaisen XHTML-suosituksen. XHTML:n tarkoituksena oli tehdä uusi modulaarinen pohja internetsivuille ja tarkentaa koodauksen sääntöjä. 1.0 suositus julkaistiinkin jo 2001 ja siihen päivitys heti perään.

Samaan aikaan IE:n kehitystahti hiipui melkoisesti. Microsoft, joka oli tönäissyt Netscapen täysin pois markkinoilta ja kahmaissut itselleen lähes 100%-osuuden markkinoista, ei enää lähtenyt samalla tavalla rynnistelemään eteenpäin kuten muutamia vuosia aikaisemmin, vaan resurssit ohjattiin jonnekin muualle. Tämä oli kova isku W3C:lle, jonka oli tajuttava että netti elääkin täysin selainvalmistajien armoilla, ja jos heitä ei uudet suositukset ja yhteistyö innosta, on XHTML:n tai minkä tahansa muun asiaan liittyvän vieminen eteenpäin melko hankalaa.

2004 – Firefox 1.0

Selainmarkkinoilla elettiin siis pitkään hiljaisempaa vaihetta, mutta 2004 tapahtui jotain suurta. Netscapen tuhkista nousseen Mozilla Foundationin ja AOL:n tuella julkaistiin uusi kauan kaivattu selain Firefox 1.0. Firefox oli kuin Obama selainmarkkinoilla, todellinen ilmiö joka sai paljon julkisuutta osakseen ja loi uutta toivoa jämähtäneeseen tilanteeseen.

Markkinointi toimi ja muutamassa vuodessa Firefox otti 20% osuuden selainmarkkinoista ja yhdessä Operan ja Safarin kanssa aiheuttivat hämmennystä IE:n leirissä. Pikkuhiljaa alkoi taas kaikki selainvalmistajat tuomaan uusia ja parempia versioita julkisuuteen ja www-suunnittelijat alkoivat rohkeammin käyttää uudempaa teknikkaa sivujen rakennuksessa.

2004 – WHATWG

Vuonna 2004 kohistiin myös HTML:n parissa. Tietyt selainvalmistajat kuten Apple, Mozilla ja Opera huolestuivat W3C:n XHTML visioista. Haluttiin palata vanhaan kunnon HTML:ään, tutkia ja korjata puutteita ja kehittää sitä eteenpäin, eikä niinkään kehittää jotain täysin uutta.

Edellämainittujen tahojen aloitteesta syntyi WHATWG (Web Hypertext Application Technology Working Group). WHATWG potkaisi HTML5 kehityksen kunnolla käyntiin. Kehitystyöhön haluttiin tuoda lisää avoimuutta ja ensimmäisenä tartuttiin selkeisiin ongelmiin mihin vuosien saatossa oli törmätty. Yksi iso asia on koittaa pudottaa tiettyjen yrityksien takana olevat, lähes standardeiksi muodostuneet erilliset sovellukset kuten Flash ja Silverlight. HTML5 olisi avoin pohja uudelle netille, joka toisi mukanaan jo nykyään täysin arkipäivää olevat videon ja äänen ja paljon muuta, ilman erillisiä lisäpalikoita.

2007 – W3C + WHATWG

W3C tajusi muutaman vuoden päästä, että HTML5:ssä on totta tosiaan järkeä ja otti vuonna 2007 projektin siipiensä suojaan. Nyt yhdessä WHATWG:n kanssa kehitystyötä viedään eteenpäin. Ihan hetkessä siirtyminen uuteen ei tule tapahtumaan. Selaimet ottavat uusia ominaisuuksia omakseen aina päivitysten yhteydessä hiljalleen, hurjimmat tornihuhut HTML5 aikakaudesta ajoittuvat vasta vuodelle 2022.

Netistä poimittuja:

1989 – Alkuperäinen ehdotus WWW toimintamallista, Berners-Lee:
http://www.w3.org/History/1989/proposal.html
1996 – HTML 2.0 tutoriaaleja, Eric Meyer:
http://www.case.edu/help/Help_www2.html
1996 – 3COM robotics 56k TV-mainos:
http://www.youtube.com/watch?v=0oJhthSoCFk
1997 – Mozilla ja IE riidoissa:
http://home.snafu.de/tilman/mozilla/stomps.html
1998 – Microsoftia vastaan nostetaan syyte monopoliaseman väärinkäytöstä:
http://www.justice.gov/atr/public/press… 8/1764.htm
1998 - Aol ostaa Netscapen:
http://news.cnet.com/2100-1023-218360.html
2000 – XHTML tulee:
http://www.alistapart.com/articles/xhtml/
2004 – Firefox 1.0 julkaisupäivä lähenee:
http://labnol.blogspot.com/2004/10/fire…unced.html
2005 – Spread the Firefox, sivusto vauhdittamaan Firefoxin leviämistä:
http://www.spreadfirefox.com
2005 – HTML:n tulevaisuus, WHATWG:
http://brunovernay.wordpress.com/2005/1…-1-whatwg/
2009 – HTML5 tulevaisuus, Bruce Lawsonin presentaatio @ FOWA 09:
http://vimeo.com/6985053

Automaattinen rullaus

Sivustoa ei enää ainoastaan vieritetä alaspäin. Rullauksella voidaan luoda aivan uusia sisällöllisiä ja visuaalisia kokemuksia. Tsekkaa esimerkit.

http://www.bountybev.com/

http://gavincastleton.com/

http://arbel-designs.com/

Kohokuviointi – bling bling

Kohokuviointi on helppo ja nopea tapa lisätä sivuston elementeille ja typografialle näyttävyyttä. Valitse uppokuvio tai kohokuvio, miksei jopa molemmat.

http://graphik.fi/

http://niittymaa.com/

http://www.mailchimp.com/

Ruutu ruudun sisässä

iPhone, iMac ja erilaiset läppärit toimivat usein kuvan tai animaation raameina. Nättiä, mutta niin tylsää. Kyseinen trendi on puhkikulutuksen kynnyksellä. Käytä varoen.

http://www.webbyran.nu/

http://liftux.com/

http://selectstartstudios.com/

Video on keksitty uudelleen

Videoformaatti ei ole enää kömpelö ja tahmeasti toimiva pieni pikseliruutu, vaan varteenotettava vaihtoehto aina resurssien sen mahdollistaessa. Toimiva video nappaa vierailijan huomion ja jää muistiin. Videota voidaan jalostaa monella eri tavalla – luovuus on valttia.

http://wearehughes.com/

http://www.yit.fi/together/

http://survivetheoutbreak.com/

Puhekupla

Puhekupla esiintyy tekstissä, kuvissa, navigaatiossa, logossa ja oikeastaan ihan missä vain. Visuaalisuuden lisäksi se ohjaa samalla katseen suuntaa haluttuun pisteeseen.

http://duplos.org/

http://sxsw.madebymany.co.uk/

http://morphix.si/

Jatkoa luvassa…

Web-tekijät keksivät uusia tapoja hyödyntää teknologiaa luoden samalla innovatiivisia käyttäjäkokemuksia. Trendit kohtaavat ja törmäyksen yhteydessä syntyy uusia trendejä. Suurimman comebackin tekee video ja se tulee yhdessä 3D-animaation kanssa mullistamaan web-suunnittelua. Seuraavassa julkaisussa luvassa taas lisää silmänkarkkia, nam!

Lue julkaisun ensimmäinen osa tästä.

CSS3:sta puhutaan usein yhtenä standardina. Tämä on muutamallakin tavalla hieman harhaanjohtavaa, sillä W3C ei julkaise standardeja vaan suosituksia ja CSS3 koostuu erillisistä moduuleista, joita kehitetään omaan tahtiinsa ja joita selainvalmistajat voivat lisätä selaimiinsa sitä mukaa miten parhaaksi katsovat.

Selaintuki CSS3:n uusille ominaisuuksille vaihtelee jonkin verran eri selainten välillä, pois lukien Internet Explorer, joka tukee vain web-fontteja. Seuraavaksi esiteltävät ominaisuudet toimivat kaikissa muissa suosituimmissa selaimissa (Firefox, Chrome, Opera, Safari), ellei jutussa erikseen toisin ole mainittu.

Varo teräviä kulmia!

Useimmat meistä ovat varmasti jossain vaiheessa joutuneet kiroilemaan elementtien kulmien pyöristyksen kanssa. Monet ratkaisivat ongelman tekemällä pyöreät kulmat kuvankäsittelyohjelmassa ja lisäämällä ne sivuille käyttäen ylimääräisiä HTML-tageja. Jos pyöristettyjen elementtien täytyi vielä skaalautua sivusuunnassa, tarvittiin hirvittävää CSS-jonglöörausta ja jos sivun väreihin joutui myöhemmin tekemään korjauksia, tarkoitti tämä jälleen kuvankäsittelyohjelman avaamista ja kaikkien kuvien muokkaamista yksi kerrallaan.

CSS3 poistaa nämä ongelmat kertaheitolla. Pyöristetyt kulmat kaikille sivun diveille onnistuu seuraavasti:

  div {
    -moz-border-radius: 15px;
    -webkit-border-radius: 15px;
    border-radius: 15px;
  }

Firefox ja Safari/Chrome tarvitsevat pyöristysten kanssa vielä oman etuliitteensä määrityksen eteen. Opera tukee reunojen pyöristystä suoraan ilman etuliitettä versiosta 10.50 eteenpäin. Vanhemmat selaimet ja kaikki IE:t aina versioon 8 asti eivät ymmärrä reunanpyöristyksiä, joten ne näyttävät kulmat normaalisti neliskanttisina.

Microsoft on lupaillut tuoda ainakin reunojen pyöristykset seuraavaan selainversioonsa. Reunojen pyöristyksiin, kuten muihinkin CSS3-ominaisuuksiin voi halutessaan lisätä IE:tä varten määrityksen -ms-etuliitteellä.

Reunoja voidaan pyöristää myös yksi kerrallaan:

  div {
    -moz-border-radius-topleft: 15px;
    -webkit-border-top-left-radius: 15px;
    border-top-left-radius: 15px;
  }

Edellisessä esimerkissä kannattaa huomata Firefoxin hieman eroava syntaksi. CSS3:n Backgrounds and Borders -moduuli on jo Candidate Recommendation tilassa, joten luultavasti myös Firefox ja muut Gecko-moottoria käyttävät selaimet siirtyvät käyttämään samaa syntaksia muiden selainten kanssa.

Teksti- ja laatikkovarjot

Toinen ominaisuus, joka aiemmin on voitu toteuttaa vain kuvien avulla on varjon lisääminen tekstin tai muiden sivuelementtien taakse. Syntaksi on hyvin yksinkertainen:

  p {
    text-shadow: 1px 2px 3px #555;
  }

Edellinen lisää kappaleen taustalle harmaan teksivarjon joka on tekstistä yhden pikselin oikealla, kaksi alaspäin ja hajoaa kolmen pikselin alueelle. Text-shadow on laajasti tuettu ja se ei tarvitse erikseen selainkohtaisia etuliitteitä. Box-shadow toimii samalla periaatteella, mutta Gecko- ja Webkit-selaimet tarvitsevat vielä etuliitteet:

  div {
    -moz-box-shadow: 10px 10px 15px #555;
    -webkit-box-shadow: 10px 10px 15px #555;
    box-shadow: 10px 10px 15px #555;
  }

Läpinäkyvyys RGBA:n avulla

Lähes kaikki selaimet ovat tukeneet CSS:n osittaista läpinäkyvyyttä opacity-ominaisuuden kautta jo pitkään, mutta opacityn käytössä on yksi suuri ongelma: Läpinäkyvyys periytyy aina myös lapsielementeille.

RGBA-värit ratkaisevat tämän ongelman tuomalla väreihin mukaan alpha-kanavan. Alpha-kanavan avulla voidaan säätää elementtien läpinäkyvyyttä vaikuttamatta lapsielementtien näkyvyyteen:

  div {
    background: rgb( 0, 255, 0 );
    background: rgba( 0, 255, 0, .5 );
  }

Elementille voidaan määrittää läpinäkyvyys välillä 1-0, jolloin 1 tarkoitaa 100% väritäyttöä ja 0 Täydellistä läpinäkyvyyttä. RGBA:ta käyttäessä on aina muistettava määrittää perinteiset värit vanhemille selaimille niiden ymmärtämässä muodossa tai muuten elementit perivät värinsä isäntäelementiltänsä. Edellisen esimerkin ensimmäinen rivi voidaan korvata myös perinteisemmillä heksa-arvoilla: #0f0.

Gradientit ilman kuvia

Liukuvärit eli gradientit on suosittu ja nopea tapa kohentaa sivujen ulkoasua. Aiemmin ainoa vaihtoehto on ollut lisätä gradientit sivuille jpg:nä tai läpinäkyvällä png-kuvana. CSS3:lla on mahdollista nopeuttaa sivujen latautumista joskus jopa huomattavasti siirtämällä gradientit selaimen laskettavaksi.

Annetaan diveille pohjalta alkava musta gradientti, joka päättyy divin yläreunaan:

  div {
    background: -webkit-gradient(linear, left top, left bottom, from(transparent), to(#000));
    background: -moz-linear-gradient(100% 100% 90deg, #000, transparent);
    background: -o-linear-gradient(100% 100% 90deg, #000, transparent);
    background: linear-gradient(100% 100% 90deg, #000, transparent);
  }

Gradientit toimivat tällä hetkellä vasta Webkit- ja Gecko-pohjaisissa selaimissa, mutta tuki on todennäköisesti tulossa pian myös Operaan, jota varten edelliseen on lisätty varmuuden vuoksi määritys -o-etuliitteellä. CSS-gradientit ovat osa Image Values -moduulia, joka on vasta Editor’s Draft -vaiheessa, joten muutokset lopulliseen syntaksiin ovat vielä erittäin mahdollisia.

CSS-gradientit taipuvat monenlaisiin hienouksiin perus väriliukujen lisäksi. Kannattaa katsastaa vaikka Chris Coyierin opas aiheesta CSS-tricksistä.

Animaatiota CSS:n avulla

Animaatio netissä on pitkään ollut pääosin vain Flashin ja JavaScriptin heiniä. Nyt pientä interaktiivisuutta on helppo lisätä sivuille myös ilman ohjelmointitaitoja. Lisätään kaikkiin sivun linkkeihin pieni animoitu siirtymä eri tilojen välille:

  *:link,
  *:visited,
  *:hover,
  *:active,
  *:focus {
    -webkit-transition:
      color .25s linear,
      background-color .25s linear,
      border-color .25s linear;
    -moz-transition:
      color .25s linear,
      background-color .25s linear,
      border-color .25s linear;
    transition:
      color .25s linear,
      background-color .25s linear,
      border-color .25s linear;
  }

CSS-animatioita tukee tällä hetkellä vain Opera ja Safari/Chrome. Myöskin tuleva Firefox 3.7 -versio mitä todennäköisimmin tukee tätä ominaisuutta.

Fontit

CSS3:n avulla on mahdollista ladata käyttäjän koneelle fontteja suoraan sivuilta. Enää siis sivujen typografian ei tarvitse rajoittua muutamaan web-turvalliseen fonttiin.

Ladattavan fontit eivät ole oikeastaan uusi juttu. Ne olivat osa jo vanhaa CSS 2 -suositusta, mutta ne pudotettiin pois versiosta 2.1. Erikoisesti tässä asiassa IE on ollut edelläkävijä, sillä se on tukenut @font-face -ominaisuutta jo 4.0-versiostaan asti. Tosin ainoastaan omassa eot-formaatissaan, valitettavasti.

Fontteja sivuille lisätessä kannattaa olla tarkkana, sillä usein jopa ostettujen fonttien käyttöä saatetaan rajoittaa webissä. Lisenssiehdot kannattaa aina lukea huolella. Ilmaisia fontteja voi metsästää vaikka Webfonts.info:sta.

Ladattavien fonttien lisääminen on helppoa. Halutut fontit ladataan CSS:n alussa:

    /* Fonts by Jos Buivenga (exljbris) -> www.exljbris.com */
    @font-face {
      font-family: CallunaRegular;
      src: url("Calluna-Regular.otf") format("opentype");
    }

Hra. Buivenga antaa ilmaiset fonttinsa muuten vapaaseen käyttöön, mutta pyytää, että vähintään CSS-tiedostossa mainitaan yhteystiedot hänen sivuilleen.

Kun fontti on ladattu, voidaan sitä kutsua myöhemmin CSS:ssä kuten tavallisiakin fontteja:

  body {
    font-family: CallunaRegular, 'Palatino Linotype', Palatino, serif;
  }

Jos käyttäjän selain ei tue @font-face -määritystä, käytetään sen sijasta seuraavaksi listassa tulevaa tuettua fonttia.

Tulevaisuus

Tällä hetkellä CSS3:n käyttö on vielä hiukan työlästä monien selainkohtaisten etuliitteiden johdosta, mutta tilanne tulee vielä helpottumaan, kunhan moduulit kehittyvät ja W3C niitä yksi kerrallaan nostaa suosituksen asemaan.

Tässäkin muodossa CSS3 nopeuttaa sivujen kehitystä huomattavasti, sillä vaikka lopullisilla sivuilla ei käyttäisikään CSS:ää esimerkiksi reunojen pyöristyksessä, on niillä erilaisten ulkoasuvaihtoehtojen prototyyppaaminen huomattavasti nopeampaa suoraan selaimessa ilman tarvetta avata kuvankäsittelyohjelmaa ennen kuin miellyttävä lopputulos on löytynyt.