Tässä luvussa kerrotaan yleisiä asioita tästä VUKK:sta ja sfnet.viestinta.www-uutisryhmästä.
Svwww on lyhenne uutisryhmän sfnet.viestinta.www nimestä. Mainittu ryhmä puolestaan on Sfnet-hierarkiaan kuuluva uutisryhmä, jossa keskustellaan www:hen liittyvistä asioista. Ryhmällä on myös kaksi alaryhmää, sfnet.viestinta.www.palaute ja sfnet.viestinta.www.uutuudet.
Lisätietoja uutisryhmistä yleensä löydät esimerkiksi Jukka Korpelan Nyysioppaasta. Kannattaa myös tutustua ryhmäkuvauksiin, jotka kertovat ryhmien sisällöstä. Svwww:n ja sen alaryhmien kuvaukset löytyvät Sfnetin sivuilta. Ennen ryhmään kirjoittamista kannattaa tutustua tämän VUKK:n lisäksi myös ryhmässä käytävään keskusteluun, jotta ryhmän tavat käyvät tutuiksi.
Vukk on lyhenne sanoista Vastauksia Usein Kysyttyihin Kysymyksiin (engl. FAQ). Tähän tiedostoon on kerätty vastauksia yleisimpiin ryhmässä kysyttyihin kysymyksiin sekä linkkejä muihin tietolähteisiin. Koska iso osa varsinkin ensikertalaisten esittämistä kysymyksistä on jo valmiiksi vastattuna tässä dokumentissa, kannattaa tähän kerätty materiaali lukaista läpi ennen kyselyitä. Näin saat vastauksen nopeammin ja säästät ryhmäläisten huomiota uusiin kysymyksiin.
Tässä vukk:ssa ei vastata kaikkiin kysymyksiin kattavasti. Tarkoitus on tarjota kysymyksiin tiiviit asiapitoiset vastaukset ja linkkejä jatkolukemistoon. Vukkia laajennetaan jatkuvasti kattamaan uudet kysymykset. Mikäli sinulla on parannusehdotuksia, voit lähettää ne ylläpitäjälle. Älä kuitenkaan lähetä kysymyksiä vastattavaksi ylläpitäjälle, vaan osoita ne svwww-ryhmälle. Tällöin muutkin hyötyvät vastauksesta, ja se voi ennen pitkää löytää tiensä vukkiin.
Vukkia ylläpidetään kahtena versiona: yhtenä isona html-tiedostona sekä kysymyksittäin jaettuna. Versioiden sisältö on identtinen. Uusimmat versiot löydät aina vukk:n kotisivuilta osoitteesta http://www.heikniemi.net/svwww-vukk/. Tehdyt päivitykset kirjataan muutostiedostoon.
Suositeltavin tapa on viitata yksittäisen kysymyksen sisältävään sivuun. URL-osoitteet ovat muotoa http://www.heikniemi.net/svwww-vukk/k3.html, jossa k:n ja .html:n välissä sijaitseva kysymysnumero vaihtelee (esimerkkinä käytetty osoite viittaa tähän kysymykseen, joka siis on numero 3).
Vukkia ovat koostaneet ajan saatossa useat henkilöt. Tällä hetkellä vukkia toimittaa Jouni Heikniemi, jolle voi lähettää sähköpostia osoitteeseen jouni@heikniemi.net.
Ryhmän vukk:n synnytti vuonna 1999 Sami Lempinen, joka myös ylläpiti sisältöä vuoden 2001 syksyyn asti. Häntä avustivat urakassa mm. Heikki Kantola, Teemu Nurminen, Kai Puolamäki ja Jere Käpyaho. Heidän lisäkseen useat svwww:n lukijat luovuttivat omia kirjoituksiaan vanhan vukk:n osiksi.
Ryhmäkuvauksen määritelmän mukaan ryhmässä keskustellaan "seitistä (WWW), siihen liittyvistä ohjelmista, standardeista ja käytännöistä sekä seitin tarjoamista palveluista" . Tämä tarkoittaa sitä, että keskustelu on sallittua paitsi teknisistä asioista, myös webistä ja sen käytöstä yleensä.
Ryhmään sopivat hyvin keskustelut verkkopalveluiden laadusta (ks. kuitenkin joitain poikkeuksia), www-tekniikoista, selaimista, www-grafiikasta sekä www:n kehityksestä yleensä. Kannattaa kuitenkin huomioida, että kaikki mikä jotenkin etäisesti liittyy webiin ei välttämättä ole parhaassa paikassaan svwww:ssä. Ryhmävalinnoissa kannattaa käyttää harkintaa ja ohjata keskustelua edelleen sopiviin ryhmiin tarpeen mukaan.
Webiin liittymättömistä asioista tai sellaisista asioista, joiden ydinasia ei oikeastaan kosketa www:tä. Parempi on yleensä myös jättää pois keskustelu, joka koskettaa vain yhtä sivustoa (palauteryhmä on erikseen - ks. kysymystä sivuilmoituksista). Tervetullutta ei myöskään ole sellainen keskustelu, jossa asia-argumentointi on jo unohdettu. Selain- ja käyttöjärjestelmäsodat kuuluvat paremminkin ryhmään sfnet.atk.sodat. Tässä joitain tavallisimmista sellaisista aiheista, joista ei kannattaisi yrittää virittää keskustelua svwww:ssä:
Käytä alaryhmiä svwww.palaute ja svwww.uutuudet. Jos haluat erityisesti palautetta, crosspostaa viesti sekä .palaute- että .uutuudet-ryhmiin ja aseta jatkot pelkästään palauteryhmään. Uutuudet-ryhmää ei tulisi normaalisti käyttää keskusteluun! Jos haluat pelkästään kysyä palautetta sivuistasi, muotoile asiallinen viesti aiheesta palauteryhmään. Muista mainita sivuston URL-osoite. On myös hyvätapaista kuvailla lyhyesti sivuston keskeinen sisältö. Samalla voit tarkentaa, mistä erityisesti haluat palautetta ja mistä et.
Muista, että myös svwww:ssä ilmoittaessa on hyvä toimia netiketin mukaisesti. Älä missään nimessä lähettele mainoksia sivuistasi jatkuvasti vain saadaksesi lisää kävijöitä. Uutuusryhmä on tarkoitettu uudistuneista sivuista tiedottamiseen, ei mainostamiseen.
Lähes kaikki tieto on jo webissä. Käytä sitä hyväksesi tietoa etsiessäsi: ennen kysymistä tarkista, löytyykö webistä vastausta vaivattomasti. Ainakin seuraavia resursseja kannattaa käyttää:
Tässä luvussa vastataan kysymyksiin mallia "Mikä on...?" - eli kerrotaan protokollista, standardeista ja muista sellaisista.
HTML (Hypertext Markup Language) on merkintäkieli, jolla kuvaillaan www-sivujen sisällön rakenne. Kielen juuret ovat 1990-luvun alkupuolella, kun Tim Berners-Lee kehitti WWW:n. Sen jälkeen HTML:n kehitystä on ohjannut World Wide Web Consortium (W3C). HTML on edennyt versioon 4.01, johon sen kehitys on myös lopetettu - nykyisin vastaavaa tekniikkaa kehitetään XHTML-nimellä.
Olennaista HTML:ssä on sivujen rakenteen kuvaaminen. HTML:llä ei voi määritellä sivujen ulkoasua täsmällisesti, vaan sillä hahmotellaan rakenne (esim. kappaleiden rajat, otsikot jne.). Sivujen ulkoasun määrittelyä varten W3C on kehittänyt tyylisivut eli CSS:n. Käytännössä vuosien saatossa HTML:ään on kertynyt kuitenkin paljon myös ulkoasun määrittelyyn liittyvää ainesta. Viime vuosina on kuitenkin palattu puhdasoppisempaan sisällön ja ulkoasun erotteluun, ja tämä kehitys näyttää jatkuvan.
Lisätietoa HTML:stä:
SGML (Standard Generalized Markup Language) on yleinen dokumenttien rakenteen kuvailukieli. WWW:hen se liittyy lähinnä sitä kautta, että HTML-kieltä voidaan sanoa SGML:n sovellukseksi. Aiheesta kertoo tarkemmin Jukka Korpelan kirjoittama lyhyt johdatus. SGML:stä on myös yksinkertaistettu versio XML, jolla on myös oma, alati kasvava merkityksensä www-maailmassa.
XHTML (Extensible Hypertext Markup Language) on HTML-kielen seuraaja. Tällä hetkellä XHTML:n uusin versio on 1.0, ja se seuraa aikajärjestyksessä HTML 4.01:tä. XHTML:n suurin ero HTML:ään nähden on se, että siinä missä HTML pohjautuu SGML:ään, XHTML on rakennettu XML:n varaan. Tästä seuraa joitain rakenteellisia eroja perinteisten HTML- ja XHTML-dokumenttien välille. Ks. kysymystä XHTML:n ja HTML:n eroista.
Lisätietoja XHTML:stä löytyy mm. W3C:n XHTML-suosituksesta.
XML (Extensible Markup Language) on SGML:n pohjalta kehitetty metakieli - siis kieli, jolla voi tehdä kieliä. XML on suunniteltu erityisesti Internet-käyttöön ja on huomattavasti SGML:ää yksinkertaisempi. Useat W3C:n kehittämät tulevaisuuden www-tekniikat pohjautuvat juuri XML:n käyttöön.
Jonkinlainen suomenkielinen johdanto aiheeseen on Jouni Heikniemen kirjoittama "Mikä on XML?". Lisätietoja XML:stä saa mm. W3C:n XML-sivuilta sekä Robin Coverin The XML Cover Pages -sivustolta.
Kielillä on paljon yhteistä: käytännössä koko sanasto on yhteinen, eli HTML:stä tutut elementit ja niiden määreet löytyvät myös XHTML:stä. Erojakin kuitenkin löytyy, sillä XHTML on XML-pohjainen kieli, joten sitä koskevat myös XML:n rajoitukset. XHTML:ää kirjoitettaessa on huomioitava erityisesti seuraavat asiat:
<body>, ei <BODY>, ja sama pätee myös attribuuttien eli määreiden nimiin.border="0".p-elementtiä ei saa jättää auki, vaan se täytyy sulkea vastaavalla </p>-tagilla. Käytössä on myös erityinen lyhennys tyhjille elementeille: <br/>, joka usein yhteensopivuussyistä kirjoitetaan muodossa <br />.XHTML on tarkoitettu säännöiltään huomattavasti HTML:ää tiukemmaksi. Siinä vaiheessa kun varsinaiset XHTML-selaimet yleistyvät, todennäköisesti vaatimukset syntaktisen oikeellisuuden suhteen kiristyvät: jos dokumentissa on yksikin virhe, sitä ei välttämättä näytetä ollenkaan tai lopputulos voi ainakin olla jotain hyvin outoa. XHTML:ään siirryttäessä on siis entistä tärkeämpää huolehtia siitä, että sivut noudattavat asianmukaisia standardeja.
CSS tarkoittaa tyylisivuja, Cascading Style Sheets. CSS on tekniikka, jolla määritellään ulkoasu HTML-kielellä kuvatulle rakenteelle. Siis kun esimerkiksi HTML:ssä merkintä <h1>Yleistä selaimista</h1> ilmoittaa kyseessä olevan otsikon, CSS-määrittely H1 { font-size: 200% } määrittelee otsikon kirjasinkoon kaksinkertaiseksi normaalitekstiin nähden. Yksinkertaistettuna siis HTML kuvailee mitä sisältö on, ja CSS määrittelee, miten se näytetään.
CSS on W3C:n kehittämä tekniikka, joka näki ensimmäisen kerran päivänvalon vuonna 1996, kun CSS:n taso 1 julkaistiin. CSS2 julkaistiin 1998, ja CSS3 on parhaillaan kehitteillä. CSS2-toteutukset ovat vielä osittain varsin ontuvia, joskin varsinkin Mozilla- ja Opera-selaimet ovat kehittyneet tässä suhteessa viime vuosina. W3C on tuottanut CSS 2.1 -määrityksen, joka on korjailtu ja hieman supistettu versio CSS2:sta; käytännössä se korvaa CSS2:n.
Lisätietoja tekniikasta saat esimerkiksi seuraavista linkeistä:
WML tarkoittaa web-maailmassa kahta asiaa. Se voi olla joko WAP-puhelinten ohjaukseen käytetty merkintäkieli (Wireless Markup Language) tai sitten Website Meta Language -niminen web-sivujen tekemiseen käytetty esikäsittelyohjelma, joka mahdollistaa mm. sivupohjien käytön vaivattomasti laajoillakin sivustoilla.
WAP-WML:stä lisätietoja löytyy mm. Nokian WapForumista ja metakieli-WML:stä puolestaan kielen omalta sivulta. Metakieltä opastaa myös Kai Puolamäen artikkeli aiheesta.
Molemmat ovat siirtokäytäntöjä eli protokollia, joiden varaan web rakentuu. HTTP tulee sanoista HyperText Transfer Protocol, ja HTTPS on sen kryptattu versio ("HTTP over Secure Sockets Layer").
HTTP on se yhteinen kieli, jota selaimet ja kaikki maailman www-palvelimet puhuvat. Protokolla perustuu siihen, että asiakasohjelma (selain, hakurobotti tms.) avaa TCP/IP-yhteyden palvelimelle, yleensä porttiin 80, ja lähettää pyyntönsä. HTTP-pyynnöt ovat muotoa "lähetä minulle tiedosto /index.html" tai "tässä on palvelimen käsiteltäväksi lomake, jonka kentässä nnn on tieto yyy ...". Palvelin vastaa lähettämällä sopivan vastauksen, tavallisimmin html-sivun tai binääridataa kuten kuvia, ohjelmia tai ääntä. HTTP mahdollistaa myös muita toimintoja, joista tavallisimpana esimerkkinä ehkä selaimen ohjaaminen uudelle sivulle (ks. kysymystä aiheesta).
HTTP:stä on kaksi eri versiota, HTTP/1.0 vuodelta 1990 ja HTTP/1.1 vuodelta 1997. Jälkimmäinen on levinnyt jo kohtuullisen laajasti käyttöön, mutta monet yksinkertaisemmat asiakasohjelmat ja hakurobotit käyttävät edelleen 1.0-versiota. Nykyaikaiset palvelimet tukevat pääosin molempia versioita ja HTTPS:ää ongelmitta.
Dokumenttityyppi tarkoittaa tietoa siitä, mitä SGML:n tai XML:n pohjalle laadittua kielioppia (syntaksia) käytetään. Web-sivujen yhteydessä dokumenttityypin ilmoituksella (sivun alussa oleva <!DOCTYPE-alkuinen rivi) kerrotaan, mitä HTML:n tai XHTML:n versiota sivun tekemisessä on käytetty. Tällaisen ilmoituksen vaikutukset ovat kuitenkin varsin vaihtelevat.
Validaattorin kannalta dokumenttityypin merkitys on olennainen, sillä validointisäännöt luonnollisesti riippuvat siitä, mitä muodollista kielimääritystä vasten validoidaan. Jos esimerkiksi sivu määritellään olemaan puhdasoppisempaa HTML 4.01 Strict -versiota, validaattori puuttuu sellaisiinkin seikkoihin, jotka se sivuuttaisi väljempää HTML 4.01 Transitional -varianttia käytettäessä. Useimmiten itse asiassa validaattori jopa kieltäytyy käsittelemästä sivua ilman doctype-määritystä, tai joka tapauksessa ainakin vaatii valitsemaan dokumenttityypin käsin - eihän koko validoinnissa muuten olisikaan järkeä!
Selaimet voivat muuttaa käytöstään dokumenttityypin määrityksen mukaan, vaikkakaan kovin oikein ne eivät tässä suhteessa toimi. Käytännössä tavanomaisin doctypen vaikutus on selaimen - ja erityisesti IE6:n - valinta ns. quirks- ja standard-tilojen välillä. Quirks-tilassa selaimet pyrkivät matkimaan vanhempien selainten virheitä HTML:n ja CSS:n joidenkin piirteiden käsittelyssä, kun taas standard-tilassa HTML:ää tulkitaan paremmin W3C:n suositusten mukaisesti. Usein doctype-rivin lisääminen tai poistaminen voi siis vaikuttaa myös siihen, miten sivu taittuu selaimella. Juuri muihin kuin visuaalisiin seikkoihin doctype-rivi ei vaikuta. Lisätietoa dokumenttityyppien vaikutuksesta selaimiin (doctype sniffing) löytyy esimerkiksi Henri Sivosen artikkelista Activating the Right Layout Mode Using the Doctype Declaration.
Tavanomaisimmat dokumenttityypin ilmoitukset HTML 4.01:n Strict- ja Transitional-versioille ovat seuraavassa. Uusia verkkosivuja tehdessä kannattaa pyrkiä Strict-version käyttöön. Myös dokumenttityypin ilmoitus kannattaa tällöin pitää dokumenteissa mukana, koska se saa selaimet toimimaan paremmin standardeja noudattaen.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
XHTML:n vastaavat ilmoitukset ovat seuraavat:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
Tässä luvussa käsitellään grafiikan käyttöä webissä.
Web-käytössä värit ilmaistaan sekoittamalla RGB-järjestelmän perusvärejä: punaista (red), vihreää (green) ja sinistä (blue). Kunkin perusvärin määrä jossain yksittäisessä värissä ilmaistaan numeroin 0-255, jossa 0 ilmaisee olematonta ja 255 täyttä värikylläisyyttä. HTML:ssä värit ilmaistaan aina heksadesimaalijärjestelmässä ja kaksinumeroisena, jolloin vastaavat ääriarvot ovat 00 ja FF. Isoilla ja pienillä kirjaimilla ei ole eroa. Värit liitetään peräkkäin RGB-järjestyksessä: ensin punainen, sitten vihreä ja kolmanneksi sininen. Värikoodin eteen laitetaan vielä risuaita (#). Esimerkiksi ilmaisu #ffffff tarkoittaisi sitä, että kaikkia värejä on maksimimäärä, jolloin tuloksena on täysin valkoinen väri. Toisaalta #ffff00 tarkoittaa, että punaista ja vihreää olisi maksimimäärä ja sinistä ei ollenkaan - tällöin tuloksena on kirkasta keltaista.
CSS:ssä voidaan käyttää edellämainitun lisäksi myös lyhennettyä värimäärittelyä, jossa kunkin perusvärin määrä ilmaistaan vain yhdellä heksadesimaalinumerolla, ja koko värikoodi muodostetaan tuplaamalla esitetyt arvot. Esimerkiksi CSS-väri #fa0 tarkoittaa väriä #ffaa00. Lisäksi HTML:ssä on määritelty 16 vakioväriä, joihin voi viitata myös nimellä (esim. color="red").
Katso myös kysymystä ns. web-väripaletista.
Web-paletti (tunnetaan myös nimillä Netscape-paletti ja websafe-paletti) on 216 värin joukko, joka mitä todennäköisimmin näkyy oikein eri koneympäristöissä myös vähemmillä värimäärillä. On periaatteessa suositeltavaa käyttää näitä värejä varsinkin laajoissa väripinnoissa, joskin käytännössä asian merkitys on vähentynyt näyttöjen värimäärän kasvun myötä.
Paletin värit muodostetaan siten, että heksamuotoisen värikoodin kunkin elementin tulee olla jokin seuraavista: 00, 33, 66, 99, CC tai FF. Näin siis esimerkiksi väri #CCFFFF on web-paletissa, mutta #CAFFFF tai #BBFFFF eivät.
Lisätietoja saat Pekka Ruipon väripalettia käsittelevältä sivulta.
Gif (Graphics Interchange Format) tallentaa maksimissaan 256 väriä, joten Gif sopii parhaiten vähäväristen kaavioiden ja piirrosten esittämiseen. Toisin kuin jpg, gif-pakkaus on häviötön, joten suorat viivat ja terävät raja-alueet eivät kärsi pakkaamisesta. Tärkeä gif-kuvan etu muihin käsiteltyihin muotoihin nähden on se, että gif-tiedostot voivat sisältää myös animaatiota sekä läpinäkyviä pintoja. Eräs Gif:n ongelma on se, että pakkaamiseen käytetyn LZW-algoritmin patenteista käydään oikeuskiistoja; ks. esim. Free Software Foundationin näkemystä asiasta.
Jpeg (Joint Picture Experts Group) eli jpg-kuvamuoto on parhaimmillaan valokuvien ja muiden fotorealististen kuvien tallentamisessa. Jpg pystyy pienentämään isojakin kuvia hyvin pieneen tilaan, koska se osaa hävittää kuvasta sellaista tietoa, jota silmä ei huomaa. Jpeg-kuvat ovat myös täysvärisiä. Tehokkaan pakkausalgoritmin huono puoli on se, että pienet yksityiskohdat ja terävät yksiväriset pinnat muuttuvat helposti suttuisiksi. Jpeg-kuvissa ei voi olla läpinäkyviä kohtia.
Png (Portable Network Graphics) on uudempi kuvamuoto, joka pääosin korvaa Gif:n. Png-pakkaus on myös häviötön, mutta kuvat voivat olla myös täysvärikuvia, toisin kuin gif-muodossa. Png tuo mukanaan myös uusia ominaisuuksia kuten osittaisen läpinäkyvyyden. Periaatteessa png:llä voidaan korvata kaikki gif-kuvat, mutta selainten heikohko tuki png-kuville voi olla haitaksi. Käytännössä varsinkaan vanhemmat selaimet eivät näytä välttämättä PNG-kuvia ollenkaan, ja uudemmissakin on ongelmia läpinäkyvyyden oikean toteutuksen kanssa.
Lisätietoja kuvamuodoista:
Vaikeaa on, sillä webissä ei vielä ole yhteisesti hyväksyttyä vektorigrafiikkamuotoa. Ainakin uudemmissa Internet Explorereissa on mahdollista käyttää VML-muotoa, mutta sitä ei tueta kovin laajalti. Varsinainen uusi tekijä alalla on W3C:n kehittämä SVG (Scalable Vector Graphics) -kuvamuoto, mutta sille on toistaiseksi varsin vähän tukea.
Eräs tapa vektorigrafiikan käyttöön on Macromedian Flash-laajennus, mutta se vaatii toimiakseen selaimilta erillisen pluginin, eikä lisäksi toimi kovinkaan tyydyttävästi ilman Flash-tukea. Ratkaisu on siis huono mm. harvinaisempien selainten käyttäjien kannalta (tekstiselaimista nyt puhumattakaan). Lähinnä Flashin käyttö tulee kyseeseen joissain intro-tyyppisissä esityksissä, jotka eivät sisällä mitään tärkeää informaatiota.
Tässä luvussa vastataan sellaisiin kysymyksiin, jotka liittyvät sivujen luomiseen ja julkaisuun liittyviin ongelmiin. Merkkauskieliä koskevia teknisiä kysymyksiä käsitellään VUKK:n loppuosassa.
Tämä on makuasia, josta voi kiistellä rajattomasti. Editorit jakautuvat raa'asti ottaen kahteen osaan: koodieditorit ja WYSIWYG-editorit. Ensinmainitut vastaavat toiminnallisuudeltaan lähinnä perinteisiä tekstureita (Notepad/Muistio ym.), mutta kehittyneemmät ohjelmat hallitsevat mm. syntaksin värittämisen ja koodin automaattisen tarkastelun. Lisäksi mukana on usein ohjeita ja velhoja monimutkaisempien rakenteiden tekemiseen. WYSIWYG-editoreissa toisaalta kokonaisuus suunnitellaan pitkälti ulkoasuvetoisesti, läiskimällä ruudulle elementtejä, joiden mukaan koodi sitten generoidaan.
Selvää on, että teksturityyppisen editorin käyttäminen vaatii enemmän HTML:n osaamista, ja toisaalta tuottaa tyypillisesti standardinmukaisempaa ja siivompaa HTML-koodia. Toisaalta teksturin käyttö muuttuu isojen dokumenttien kohdalla työlääksi, varsinkin jos sivu sisältää suuria määriä sisällön ulkopuolista aineistoa (kuten JavaScriptiä). Jos HTML pysyy käsissä, todennäköisesti selkeämpi (ja ylläpidettävämpi!) lopputulos syntyy kirjoittamalla koodia käsin. WYSIWYG-editorilla sivuston rungon kasaa nopeasti, mutta koodin hiominen loppuvaiheessa voi osoittautua melko työlääksi.
Hyviä teksturityyppisiä HTML-editoreita Windows-puolella ovat ainakin HTML-Kit, 1st Page 2000 ja Macromedia HomeSite. Näistä viimeksimainittu on maksullinen. Tavallisimmat Windows-maailman WYSIWYG-editorit ovat Nvu, Macromedia Fireworks, Macromedia Dreamweaver ja Adobe Golive. Nvuta lukuunottamatta kaikki mainitut WYSIWYG-editorit ovat maksullisia, joten tuoreen tutustujan kannattaa aloittaa siitä - varsinkin kun ohjelmalle on saatavilla myös suomenkielisiä käyttöohjeita ja käännöstiedosto.
Onko sinulla kiinnostavaa sisältöä? Jos on, kävijöitä alkaa tulla itsestäänkin ennen pitkää. Jos sivusi käsittelevät vain sinua itseäsi, voi olla että kävijävirtaa ei koskaan tulekaan - ellet sitten ole hyvin kiinnostava persoona. Älä liioittele tiedottamisessa: puskaradio kyllä mainostaa hyviä sivuja, kunhan annat ajan kulua. Lisäksi voit harkita seuraavia keinoja:
Et mitenkään. Jos estäisit, selaimetkaan eivät voisi näyttää sivua. Javascriptillä ym. on mahdollista vaikeuttaa sivun lähdekoodin katsomista, mutta estäminen on mahdotonta. Ns. obfuskaattoriohjelmat voivat sotkea koodin vaikealukuiseksi, mutta yhtä lailla on olemassa koodia siistiviä ohjelmia - varsinaista ratkaisua ei siis ole.
Tässä luvussa käsitellään web-sivujen tekemiseen tarvittavia ulkoisia palveluita: kotisivutilaa, kävijälaskureita, vieraskirjoja ja sen sellaisia.
Ilmaispalveluntarjoajia on sekä Suomessa että ulkomailla, ja niitä voit etsiä hakusanoilla "Free Web Hosting" tai "Ilmainen kotisivutila". Usein ilmaiselta vaikuttavat palvelut eivät kuitenkaan todellisuudessa ole sitä - ainakaan pysyvästi. Lisäksi ilmaisuuden mukana saa sivuilleen usein mainoksia tai muuta riesaa. Usein kohtuuhintainen maksullinen palvelu tarjoaa kuitenkin huomattavasti paremman luotettavuuden ja nopeuden, ja tyypillisesti oma Internet-yhteyspakettikin sisältää riittävän kotisivutilan.
Selvitäpä, mitä operaattorisi tarjoaa. Tavalliset kuluttaja-ISP:t Suomessa eivät tosin yleensä tarjoa mitään. Ilmaiseksi vieraskirjan saa ainakin Freebokista, ja palveluita löytyy lisää esim. Dmoz-linkkihakemiston Guestbooks-osiosta. Jos sivusi ovat sellaisella palvelimella, jossa voit itse ajaa PHP-skriptejä, voit myös itse asentaa jonkin PHP-pohjaisen vieraskirjan. Niitä on tarjolla vaikka miten paljon; pitkä luettelo löytyy esim. Resourceindexistä.
Laskureita on tarjolla runsaasti. Monilla ISP:illä on tarjolla oma laskurinsa; sellaisesta löytää tyypillisesti ohjeita ISP:n asiakaspalvelusivuilta. ISP:iden laskurit ovat yleensä toiminnoiltaan melko yksinkertaisia, mutta laajempia tilastointipalveluitakin on saatavilla ilmaiseksi eri puolilla Internetiä.
Laskurit perustuvat tyypillisesti siihen, että sivulle sijoitetaan pieni kuva, joka ladataan mittauspalvelusta. Tämä palvelu pitää kirjaa kuvan latauskerroista ja niiden perusteella arvioi sivuston käyttöastetta. Vaihtoehtoisesti analyysi voidaan tehdä suoraan tutkimalla ISP:n www-palvelimen lokia, mutta tällaista palvelua ei tavallisilla Internet-palveluntarjoajilla yleensä ole. Molemmissa menetelmissä on ongelmansa; erityisesti laskurien luotettavuus on kyseenalainen.
Ilmaislaskureita voi koittaa etsiskellä oman ISP:n sivujen lisäksi mm. Yahoon Access Counters -listasta ja Adbility.comin vastaavasta luettelosta.
Lyhyesti: Mikään laskuri ei ole täysin luotettava. Tietyillä menetelmillä voidaan päästä kohtuullisen lähelle totuutta, mutta parhaat näiden menetelmien toteutukset ovat tällä hetkellä kaupallisia (ja kalliita) tuotteita. Ilmaislaskurien kuvaan tai web-lokin analysointiin perustuva laskenta kärsii monista epäluotettavuustekijöistä, joista seuraavat ovat merkityksellisimmät:
Laskureihin liittyviä ongelmia käsittelee laajemmin (englanniksi) Jeffrey Goldbergin artikkeli.
Lomakkeen tekeminen sinänsä on yksinkertaista, mutta pelkällä lomakkeella ei pitkälle pötkitä. Useilla ISPeillä onneksi on valmiiksi asennettuna jokin CGI-ohjelma, joka osaa lähettää lomakkeen sisällön sähköpostilla haluttuun osoitteeseen - tämä onkin yleisin tapa käsitellä lomakkeelta tuleva palaute. Tutki oman palveluntarjoajasi valikoimia ja selvitä, löytyykö sopivaa lomaketta valmiina.
Jos ei löydy, eräs (huonohko) vaihtoehto on laatia palautelomake, jonka action-attribuutin arvo on ns. mailto-osoite (esim. <form action="mailto:oma@osoite.invalid">...</form>). Ongelmaksi muodostuu kuitenkin se, ettei tällaisen lomakkeen oikeaa toimintatapaa ole määritelty mitenkään - se siis voi toimia joissain selaimissa ja olla toimimatta joissain toisissa. CGI:lle lähetettävä lomake on ehdottomasti parempi, mutta valitettavasti myös vähän vaativampi ratkaisu.
Tärkein lähtökohta on se, että sivusi ovat teknisesti kunnossa. Niiden on syytä olla kelvollista HTML:ää ja hyvin luettavissa myös muuten kuin Flashia tukevalla IE:llä. Muista, että hakukoneen näkemys sivuistasi vastaa suunnilleen tekstiselainta: esimerkiksi kuvien alt-teksteihin on syytä panostaa! Jonkin verran voit parantaa hakukoneille antamaasi vaikutelmaa myös käyttämällä tiettyjä meta-elementtejä, mutta niiden antama apu on vain rajallinen. Huomaa, että meta-elementtien väärinkäyttö todennäköisesti aiheuttaa enemmän harmia kuin hyötyä.
Ennen muuta hakukoneiden listoille päätyminen kysyy aikaa. Jossain vaiheessa sivut päätyvät sinne melkeinpä väkisin. Prosessin nopeuttaminen usein vaatii luottokortin höyläystä, mutta muutaman kuukauden odottamalla pääsee ilmaiseksi. Voit nopeuttaa prosessia lähettämällä sivujesi urlin hakukoneille; useimmilla hakukoneilla on lomake tätä tarkoitusta varten. Monet hakukoneet indeksoivat sivusi myös sitä nopeammin, mitä enemmän niille on linkkejä ulkopuolisilta sivuilta.
Jos jostain syystä haluat estää sivustosi (tai sen osan) näkymisen hakukoneissa, voit käyttää paria erilaista menetelmää. Toinen vaihtoehto on niin sanottu robots exclusion standard, joka on tekstitiedostoon pohjautuva hakurobottien ohjailumekanismi. Toinen vaihtoehto puolestaan on HTML-sivuun upotettavien meta-elementtien käyttö. Näistä molemmista kertoo tarkemmin Jouni Heikniemen kirjoitus "Kuinka estää hakukonetta löytämästä minua?".
Tässä luvussa käsitellään erityisesti selaimiin liittyviä kysymyksiä.
Vaikka mitä. Marginaaliosuuksia riittää kymmenille eri selaimille, mutta käytännössä lähes kaikki surffaavat IE:llä, Netscapella ja Operalla. Kirjoitushetkellä (tammikuu 2002) IE:n versioita 4-6 käyttää yli 80% surffaajista, Netscapeja reilut 10% ja loput pilkkoutuvat Operalle ja muille selaimille. Tiedoista on kuitenkin tärkeää huomata se, että a) selainten laskemiseen liittyvät pääosin samat epävarmuudet kuin muuhunkin kävijälaskentaan (ks. erillinen kysymys), b) kaikkia selaimia ei voida tunnistaa luotettavasti ja c) selainten prosenttiosuudet vaihtelevat huomattavasti kävijäkunnan mukaan (esim. Linux-aiheisilla sivuilla IE:n osuus on huomattavasti pienempi).
Selaintilastoja voi katsella esimerkiksi echoecho.comin etusivulta. Tilastoihin on kuitenkin suhtauduttava äärimmäisen varovaisesti, mm. siksi, että tilastot harvemmin kattavat muuta kuin yhden tai muutaman sivuston, ja esimerkiksi webmaster-henkiselle sivulle kertyy huomattavasti enemmän uusien selainten käyttäjiä kuin Internetin peruskäyttäjiin keskittyvälle sivulle.
Tuen tasossa on suuria eroja. Opera ja Mozilla tukevat sekä CSS1- että CSS2-määrityksiä varsin hyvin. Myös sekä Netscapen että IE:n uudet versiot ovat tuen osalta varsin hyvällä tasolla, mutta vanhemmissa pulmia riittää; erityisesti Netscapen nelosversiot ovat varsinkin joidenkin CSS:n ominaisuuksien osalta ongelmallisia.
Selainten CSS-tuesta löytyy tarkemmin tietoa mm. css.nu:n kasaamasta bugilistasta.
Ongelma johtuu yleensä siitä, että tiedoston tarjoileva web-palvelin on konfiguroitu väärin. Kun selain pyytää palvelinta lähettämään jonkin tiedoston, palvelin palauttaa itse datan lisäksi myös Mime-tyypin, joka kertoo millainen tiedosto on tulossa. Jos palvelin ei tunnista jotain tiedostotyyppiä, se usein lähettää tyyppitiedon text/plain, joka tavallisesti näytetään suoraan ruudulla. Binääridataa sisältävän tiedoston kohdalla tämä johtaa sekalaisten merkkien tulostumiseen.
Usein tällaisessa tapauksessa käy niin, että sivu toimii IE:llä oikein, kun taas Netscape ja muut selaimet näyttävät sotkua. Tämä johtuu siitä, että IE usein ohittaa palvelimen lähettämän mime-tyypin ja käsittelee tiedoston sen päätteen tai sisällön mukaan. Netscape toimii siis standardien mukaan oikein, mutta lopputulos on usein yksittäistapauksissa IE:n menetelmää huonompi. Joka tapauksessa oikea ratkaisu on konfiguroida Mime-tyypit kuntoon.
Tässä luvussa käsitellään ns. validaattoriohjelmia ja niiden sukuisia välineitä.
Validaattori on ohjelma, jolla voi tarkistaa HTML-muotoisen dokumentin muodollisen oikeellisuuden eräissä suhteissa. Validaattori esimerkiksi havaitsee monia kirjoitus- ja rakennevirheitä HTML-merkkauksessa. Teknisesti sanottuna validaattori tarkistaa, vastaako dokumentti ilmoitettua dokumenttityypin kuvausta (doctype-määrittelyä). Ilmaisia validaattoripalveluita ovat mm. W3C:n validaattori, Web Design Groupin validaattori sekä Page Valet. Varsin näppärä on myös suomenkielinen LeHTori.
Laajemmin samaa asiaa käsittelee Jori Mäntysalon kirjoitus HTML-validaattori - mikä se on.
Kannattaa. Sivujen validointi on syytä hoitaa viimeistään siinä vaiheessa, kun sivu olisi muuten valmis ja sen julkaisua harkitaan, mutta mielummin jo aikaisemmin. Validoimalla löydät monia yksinkertaisia kirjoitus- ja ajatusvirheitä, jotka voivat vaikeuttaa sivujen testausta selaimilla. On kuitenkin syytä huomata, että validoinnin lopputulos ei vielä takaa mitään, sillä validaattorit vertailevat sivua HTML- tai XHTML-kielen muodolliseen määrittelyyn, mutta toistaiseksi juuri mikään selain ei toimi täysin näiden määrittelyjen mukaan. Siispä validaattorista siististi läpi solahtava sivu saattaa olla lähes täysin toimimaton, kun taas moni virheitä suoltava sivu voi käytännössä toimia. Käytännössä kuitenkin validaattorin hyväksymällä sivulla on parhaat mahdollisuudet toimia kaikissa selaimissa ainakin jotenkin.
Todennäköisesti siksi, että ne on tehty väärin :-) Oikea tapa tehdä sisäkkäinen lista on sulkea koko sisempi lista ulomman listan li-elementin sisään tähän tapaan:
<ul>
<li>Tämä on ensimmäisen listan osa</li>
<li>
<ul>
<li>Tämä on sisemmässä listassa</li>
</ul>
</li>
</ul>
Useissa tilanteissa &-merkki aloittaa HTML:n sääntöjen mukaan ns. entiteettiviittauksen. Esimerkiksi © tarkoittaa copyright-merkkiä ja &foo taas on määrittelemätön ja siten virheellinen entiteettiviittaus. Validaattori tulkitsee, että URL:ssä esiintyvät &-merkit aloittavat viittauksen. Ratkaisu on korvata &-merkit samaa merkkiä tarkoittavalla entiteetillä &, esim. näin: <a href="koe.cgi?parametri=arvo&parametri2=arvo2">.
Tämä luku kertoo ohjelmoinnista www-ympäristössä sekä palvelimen että asiakaspään osalta. On hyvä huomata, että apua erityisesti vaativammissa palvelinohjelmointia koskevissa kysymyksissä löytyy myös uutisryhmästä sfnet.atk.ohjelmointi.
SSI (Server Side Includes, josta joskus puhutaan harhaanjohtavasti myös SHTML:nä) on nimitys tekniikalle, jossa WWW-palvelin esikäsittelee sivun ennen sen palauttamista selaimelle. Tavallisin SSI:n käyttö on osiin jaetun sivun palasten yhdistäminen. Esimerkiksi kaikille sivuille yhteinen navigaatiotaulukko voidaan sijoittaa omaan tiedostoonsa, jolloin muilla sivuilla voidaan vain viitata tähän yhteen tiedostoon. Tavallisesti tämä toteutetaan lisäämällä sivulle rivi merkintä tyyliin <!--#include virtual="tiedostonimi"-->, jolloin include-merkinnän kohdalle pulautetaan mainitun tiedoston sisältö.
SSI:llä voidaan usein tehdä myös muita toimintoja kuten kirjoittaa sivulle tiedosotn viimeinen muutospäivämäärä. Näistä toiminnoista löytyy yleensä lisäapua palveluntarjoajasi ohjetiedostoista. Huomaa, että joissain ympäristöissä SSI-käsittely tehdään vain .shtml-päätteisille tiedostoille.
Lisätietoja SSI:stä löytyy esimerkiksi seuraavasta osoitteesta: http://www.cs.helsinki.fi/u/hahonen/uusmedia/sisalto/cgi_perl_ssi/ssi.html
CGI on lyhenne sanoista Common Gateway Interface. Se tarkoittaa rajapintaa, jonka kautta ohjelmat voivat tuottaa www-sivuja yhteistyössä palvelimen kanssa. Käytännössä tämä yhteistyö ilmenee yleensä lomakkeiden käsittelynä: HTML-lomakkeen sisältö lähetetään palvelimelle, joka siirtää sen edelleen CGI-rajapinnan mukaisesti tietyn ohjelman käsiteltäväksi. Tämä ohjelma tuottaa vastaussivun (esimerkiksi uuden lomakkeen tai kiitossivun) ja palauttaa sen CGI:n määrittelemällä tavalla palvelimelle, joka toimittaa vastauksen edelleen asiakkaalle (selaimelle).
On tärkeää huomata, että CGI ei ole ohjelmointikieli. Useimmat CGI-ohjelmat tehdään joko C:llä tai Perlillä.
Huomaa, että CGI-tekniikka ei tyypillisesti ole käytössä kuluttajille myytävissä Internet-palveluissa. Palveluntarjoajilla voi kuitenkin olla joitain valmiita CGI-ohjelmia; näistä yleensä löydät käyttöohjeet palveluntarjoajan sivuilta.
Molemmat ovat web-palvelimella ajettavia skriptausympäristöjä, joilla voidaan toteuttaa sivuille erilaisia toimintoja. Samalla niillä voidaan korvata useissa tapauksissa myös CGI-ohjelmat (ks. kysymystä "Mitä on CGI?"). PHP-koodia suoritetaan Apache-alustalla ja ASP:tä puolestaan Microsoftin Internet Information Server -palvelimella. PHP on C:n ja Perlin risteytys, ja sillä tehdyt ohjelmat muistuttavat hyvin läheisesti mainittuja kieliä. ASP ei ole ohjelmointikieli, vaan alusta eri kielten tulkkaukseen; tavallisimmin ASP-koodi kirjoitetaan Visual Basicia muistuttavalla VBScriptillä, mutta myös mm. JavaScriptin kaltainen JScript on käytettävissä.
ASP:n uudempi versio on ASP.net, joka perustuu Microsoftin .net-arkkitehtuuriin. ASP.net-sivut rakentuvat olio- ja tapahtumapohjaisuuden varaan, joten niiden tekeminen muistuttaa osittain enemmän Windows-sovelluksen tekemistä kuin ASP- tai PHP-sivun vääntämistä. ASP.net-alustalla kielenä voi käyttää mitä tahansa .net-alustan kielistä - tavanomaisimpia ovat C# ja Visual Basic.net, mutta tukea löytyy sangen monille kielille aina Pythonista Coboliin asti. ASP.net on korvaamassa vanhaa ASP-mallia, mikä näkyy useilla ASP-aiheisilla sivustoillakin.
Kumpaakaan skriptausalustaa ei yleensä ole tarjolla kuluttajille myytävissä tavallisissa Internet-yhteyspaketeissa. Kirjoitushetkellä ainoa tietämäni poikkeus on MBinternet, jossa PHP:n käyttäminen onnistuu. ASP:tä käytetään lähinnä yrityssivustojen tekemisessä, PHP on mukana useissa erikseen ostettavissa hosting-paketeissa. Jos nämä palvelut ovat käytössä, siitä yleensä on palveluntarjoajan antamat tarkemmat ohjeet.
ASP:stä löytyy lisätietoja mm. ASPToday- ja 4GuysFromRolla.com-sivustoilta. ASP.netistä kertoo Microsoftin www.asp.net. PHP:stä voi lukea lisää esim. PHP:n kotisivuilta ja PHPWorld.com-saitilta.
Javascript on tulkattava ohjelmointikieli, jota käytetään www-sivuilla toiminnallisuuden ja käyttöliittymän toteuttamiseen. Kieli muistuttaa C:tä ja Javaa, mutta JavaScript on silti täysin eri kieli kuin Java. JavaScriptistä on tällä hetkellä olemassa versiot 1.0, 1.1, 1.2 ja 1.3, joista 1.1 ja 1.2 ovat lähinnä tällä hetkellä käytössä olevia versioita. Microsoft Internet Explorerin ymmärtämä JavaScript-murre on nimeltään JScript, ja JavaScriptin pohjalta on myös laadittu uusi standardoitu versio ECMAScript. Monista nimistä huolimatta kielet ovat valtaosiltaan keskenään hyvin samanlaisia.
Javascriptin voima piilee mahdollisuuksissa muokata sivua W3C:n määrittelemän DOM-oliomallin kautta. Lisäksi sillä on helppo tehdä yksinkertaisia ohjelmia ja kokeilla niitä. Kielen ongelmana ovat lähinnä selainten väliset yhteensopivuusongelmat ja sen epäluotettavuus - yhä useammat kytkevät JavaScriptin pois turvallisuusongelmia välttääkseen, joten sivuja ei voi pidä vain JavaScriptin varassa toimiviksi. Kaikissa käytössä olevissa selaimissa JavaScript-tukea ei myöskään ole ollenkaan.
Lisätietoa JavaScriptistä:
Java on Sun Microsystemsin alaisen JavaSoftin kehittämä C++:aa muistuttava oliopohjainen ohjelmointikieli, jonka erityispiirteenä on laitteistoriippumattomuus. Javalla tehdyt ohjelmat käännetään tavukoodiksi, jonka Java-virtuaalikone osaa suorittaa. Virtuaalikoneita on saatavilla lähes kaikkiin laitteistoympäristöihin, joten kerran tehty Java-ohjelma voidaan suorittaa lähes millä vain laitteella.
Internetin kannalta Java on merkityksellinen erityisesti siten, että myös suosituimmissa selaimissa on mukana Java-virtuaalikone, jolloin Java-ohjelmia voidaan upottaa www-sivuille sovelmiksi eli appleteiksi. Näin Javan avulla www-sivuille voidaan tuoda sellaista toiminnallisuutta, joka ei pelkällä HTML:llä onnistu. Tämän lisäksi Javalla on käyttöä myös palvelinpäässä, jossa servletit korvaavat hiljalleen mm. CGI-ohjelmia.
Javasta on useita versioita. Vuonna 1997 esitelty Java 1.1 on edelleenkin käytännön standardi silloin, kun halutaan tehdä sovelmia jotka toimivat vaivattomasti ilman lisäpalikoita. Vuonna 1999 esitelty Java 1.2 (joka tunnetaan myös nimellä Java 2) sisältää monia uusia ominaisuuksia, mutta sitä ei toistaiseksi tueta kovin laajalti selaimissa.
Lisätietoa Javasta:
Tämä luku kertoo www-palvelimista ja niiden konfiguroinnista.
Web-palvelimella tarkoitetaan sellaista laitetta, ohjelmistoa tai niiden yhdistelmää, joka tarjoaa www-sivuja asiakkaiden haettavaksi. Yleensä tarkoitetaan samalla myös julkisessa verkossa toimivaa palvelinta, siis sellaista, joka on osa "World Wide Webiä". Web-palvelimena voi toimia lähes mikä tahansa laite, jolle sopiva ohjelmisto vain löytyy. Sellaisia löytyykin lähes kaikille mahdollisille käyttöjärjestelmille.
Unix-alustalla tavanomaisin palvelinohjelmisto on selkeästi Apache, joka tosin on saatavilla myös Windows-maailmaan. Windowsissa valtikkaa pitelee kuitenkin Microsoftin IIS (Internet Information Server). Molemmat palvelimet ovat ilmaisia ja kykenevät suorituskykynsä puolesta mihin vain. Normaalikäyttäjä joutuu näistä helpommin tekemisiin Apachen kanssa, sillä Internet-palveluntarjoajat käyttävät sitä kotisivupalveluiden tarjoamiseen, kun taas IIS on käytössä lähinnä yritysten Windows NT -palvelimissa.
Www-palvelinohjelmistoja löytyy paljon muitakin. Eräs tavallisimmista on IIS:n kevytversio PWS (Personal Web Server), joka pyörii myös desktop-käyttöjärjestelmissä (Windows 95/98/Me). Lisää vaihtoehtoja löytyy Internetin tiedostopalveluista (ks. esim. Tucowsin valikoima) runsaastikin, mutta niille on vain vähän tarvetta: suurimmat ja kauneimmatkin ovat ilmaisuutensa vuoksi kaikkien ulottuvilla.
Oikea tapa on käyttää ns. HTTP-autentikointiin pohjautuvaa menetelmää. Toteutustapa riippuu käytössä olevasta palvelinohjelmistosta. Useimmiten suojaus halutaan tehdä Apache-palvelimeen, jota käytännössä kaikki palveluntarjoajat käyttävät. Siinä ratkaisu usein onnistuu käyttämällä ns. htaccess-tiedostoa ja lisäämällä sinne sopivat rivit. Tähän on yleensä tarjolla ohjeet suoraan palveluntarjoajaltasi, jos suojauksen rakentaminen on ylipäätään mahdollista. Yleisempiä ohjeita löytyy esimerkiksi seuraavista lähteistä:
Jos et jostain syystä voi käyttää "oikeaa tapaa", toiseksi paras vaihtoehto on suojata ohjelma salasanaa kysyvällä HTML-lomakkeella, jonka tulos käsitellään CGI-ohjelmalla. Tällöin salasanat voidaan jättää palvelimelle ja antaa niiden tarkistaminen CGI:n huoleksi. Huonoin vaihtoehto ovat Javascript-pohjaiset "suojaukset", jotka eivät oikeasti suojaa mitään ja aiheuttavat myös käytettävyysongelmia.
Palvelimen tulee lähettää selaimelle Location-otsake, jolloin selain tietää hakea sivun uudesta osoitteesta. Apache-palvelimella uudelleenohjauksen toteutus onnistuu helpoiten .htaccess-tiedostoa muokkaamalla. Esimerkiksi rivi
RedirectMatch permanent .* http://www.heikniemi.net/muutto.html
... saa aikaan sen, että kaikki sivupyynnöt ohjautuvat yhteen tiedostoon. Tämä auttaa, jos vaikkapa suljet sivusi ja haluat tiedottaa siitä hallitusti yhdellä sivulla. Toisaalta jos sivusi ovat muuttaneet palvelimelta toiselle, on yleensä tarkoituksenmukaisempaa vain vaihtaa osoitteen alkuosaa. Silloin auttavat seuraavanlaiset rivit:
Redirect permanent /~jth http://www.heikniemi.net Redirect permanent /%7ejth http://www.heikniemi.net Redirect permanent /%7Ejth http://www.heikniemi.net
Tällöin esim. tiedostoa /~jth/opas.html kaipaava selain päätyisi tiedostoon http://www.heikniemi.net/opas.html. Kolme riviä tarvitaan siksi, että tilden (~) voi kirjoittaa kolmella eri tavalla. Tarkemmin redirectien käyttöä opastaa Apachen FAQ.
Tarvittaessa uudelleenohjauksen voi tehdä myös CGI-ohjelmasta kirjoittamalla location-otsakkeen käsin. Esimerkiksi seuraava Perl-skripti ohjaa käyttäjän Googlen etusivulle:
#!/usr/local/bin/perl
print "Status: 301 Moved\r\n" .
"Location: http://www.google.com/\r\n" .
"\r\n";
Huomaa, että edelliset esimerkit lähettävät käyttäjälle HTTP-vastekoodin 301, joka tarkoittaa sivujen pysyvää siirtymistä. Jos osoitteenmuutos on tilapäistä lajia, voit käyttää HTTP-palautuskoodia 302. Tämä onnistuu jättämällä Redirect-määritteistä permanent-sana pois.
Huom! Tämä vastaus koskee vain Apache-palvelinta. Uuden tiedostotyypin määritteleminen palvelimenlaajuisesti vaatii ylläpito-oikeudet. Mikäli jonkintyyppiset tiedostot eivät siis toimi kunnolla (suttua selainikkunassa ym.) palveluntarjoajallasi, voit ilmoittaa heille asiasta. Mikäli käyttämässäsi palvelussa on mahdollista soveltaa .htaccess-tiedostoja, voit korjata asian omien hakemistojesi osalta myös itse.
Lisää .htaccess-tiedostoon rivi AddType audio/mpeg .mpkolmonen, jolloin ".mpkolmonen"-päätteiset tiedostot lähetetään audio/mpeg-tyyppisinä. Jos et tiedä tiedoston oikeaa mediatyyppiä, sitä voi etsiä IANA:n mediatyyppiluettelosta.
Tähän lukuun on kerätty kaikki HTML-, CSS- ym. tekniikoihin liittyvät sekalaiset kysymykset.
Et kovin luotettavasti mitenkään. Joissain selaimissa voi toimia ratkaisu tyyliin <A HREF="mailto:user@site?subject=Your%20Subject">, mutta joissain se taas estää koko viestin lähettämisen. Järkevämpää onkin hoitaa otsikkoasia muuten kuntoon, esimerkiksi varaamalla yksi sähköpostiosoite pelkkää palautetta varten. Tällöin otsikko ei olisi niin olennainen. Vaihtoehtoisesti homman voi hoitaa jonkin järkevän palautelomakkeen kautta.
HTML 4.0 Frameset -määrityksen mukainen tapa poistaa kehykset on frame-elementin muutaman attribuutin määritteleminen nollaksi tähän tapaan: <frame src="vasen.html" name="left" scrolling="NO" noresize frameborder=0 marginwidth=0 marginheight=0>. Monet selaimet kuitenkin näyttävät edelleen reunuksen tällä tavoin tehdyille kehyksille. Homma ratkea lisäämällä attribuutti border=0, mutta tämä estää sivun validoitumisen. Olennaisin haitta tällä hetkellä lienee kuitenkin vain muodollinen oikeellisuuden puute, sillä selaimet ohittavat ylimääräiset määreet kiltisti.
Olennaista on liittää kuvan vaihtuminen johonkin tapahtumaan (event). Yleensä haluttu tapahtuma on hiiren liikkuminen kuvan päälle tai pois siitä. Nämä tapahtumat tunnetaan nimillä onMouseOver ja onMouseOut. Ohessa hyvin yksinkertainen esimerkki:
<script type="text/javascript"><!--
function vaihda() {
if(document.images)
document.kuva.src = '2.gif'; }
//--></script>
<img src="1.gif" alt="[valokuva kissanristiäisistä]" name="kuva">
<p>
<a href="index.html" onmouseover="vaihda()">Teksti</a>
JavaScriptin toimintaa selvittää perusteellisemmin Jukka Korpelan web-julkaisemisen oppaan jakso 3.2.
CSS-ilmaisulla text-decoration: none. Yksinkertaisimmillaan siis vaikkapa näin: <a href="kohde.html" style="text-decoration: none;">Kohteeseen</a>. Huomaa kuitenkin, että alleviivaus on käyttöliittymällisesti tärkeä ominaisuus, sillä se auttaa käyttäjiä tunnistamaan linkit linkeiksi. Alleviivausta ei siis kannata poistaa huvin vuoksi!
Silloin, kun attribuutin arvossa on vain aakkosia A-Z, numeroita 0-9, pisteitä tai väliviivoja. Toisaalta ei ole mitään syytä olla käyttämättä niitä muutenkin - erityisesti, koska XHTML:ssä ne vaaditaan kaikkien arvojen ympärille. Tällä hetkellä siis HTML-lähdekoodissa esimerkiksi ilmaisu border=0 on ok, mutta XHTML:ssä vaadittaisiin border="0". Mutta HTML:ssäkin esimerkiksi href=../index.html olisi väärin, sillä kauttaviivan sisältävä arvo on syytä kirjoittaa lainausmerkkeihin. Jos et vielä vakuuttunut, lue Jukka Korpelan kirjoitus aiheesta.
Nimensä mukaisesti Meta-elementit ovat tietoa itse dokumentista, ja ne sijoitetaan html-dokumentin head-osioon. Ehkä tavallisimmat Meta-elementit ovat description ja keywords, joilla voidaan pyrkiä ohjaamaan joidenkin hakukoneiden toimintaa. Keywords-elementillä voidaan antaa hakukoneelle lista sanoista, joilla etsimällä juuri tämän sivun pitäisi löytyä. Description-elementin sisältö puolestaan on lyhyt, asiallinen kuvaus sivun sisällöstä, jonka jotkut hakukoneet voivat näyttää hakutulosluettelossa. Esimerkki näiden käytöstä:
<meta name="keywords" content="WWW, HTML, FAQ, VUKK, sfnet.viestinta.www, viestinta"> <meta name="description" content="Uutisryhmän sfnet.viestinta.www VUKK (FAQ)">
Meta-elementtien käytöstä ei ole haittaa, mutta on myös varsin kyseenalaista, onko siitä hyötyä. Varsinkin keywords-elementti on kärsinyt inflaation, sillä siihen on yritetty tunkea kaikkea mahdollista kävijöiden houkuttelemiseksi. Niinpä liian aggressiivisesti käytetty keywords-elementti voi johtaa jopa koko sivun hylkäämiseen hakukoneen indeksistä. Keywordsiä parempi tapa onkin usein se, että merkitsee sivun rakenteet oikein (mm. otsikot H1..H6-elementein), jolloin hakukoneet voivat etsiä tärkeät sanat dokumentista itse.
Laita taulukon soluun jotain näkymätöntä sisältöä. Helpoin ratkaisu on non-breaking space -merkki eli , mutta mikäli se on liian suuri, voit käyttää myös yhden pikselin korkuista läpinäkyvää kuvaa.