Validia vai ei – mitä lähdekoodista paljastuu?
Otathan huomioon, että tämä artikkeli on yli 14 vuotta vanha, joten sisältö ja linkit eivät ole välttämättä ihan ajan tasalla. Tuoreena lukemisena samasta kategoriasta: Verkkopalveluiden alustat Suomessa - markkina alkaa kypsyä.
Vieraskynä-palstallamme on silloin tällöin vierailevana bloggaajana joku Vierityspalkin toimituksen ulkopuolinen taho. Jos olet kiinnostunut vierailemaan Vieraskynä-palstallamme, ota yhteyttä toimitukseen.
________________________
Tapio Nurminen
W3C:n Why Validate? antaa hyviä muistutuksia syistä, joiden takia HTML-koodin validointi on tärkeää.
- Validointi auttaa varmistamaan sivuston toimivuuden eri selaimissa ja eri päätelaitteissa. Vaikka virheellisesti koodattu sivu näkyisikin joissain selaimissa oikein, ongelmat saattavat ilmaantua toisissa selain- ja laiteyhdistelmissä.
- Validi HTML-koodi auttaa sivua toimimaan moitteettomasti myös tulevien selainversioiden kanssa.
- Validointi helpottaa ylläpitoa. Toimivan HTML-koodin ja tyylitiedostojen jatkokehitys voidaan siirtää vaivatta uusille osapuolille.
- Validointi opettaa parhaita käytäntöjä ja ohjaa pohtimaan laajempia käsitteitä kuten sivuston yleistä saavutettavuutta.
- Validointi on ammattilaisuuden merkki. Ammattitaitoiset web-osaajat ovat ylpeitä kyvystään luoda semanttista ja oikein muodostettua koodia, jossa ulkoasu ja sisältö on erotettu toisistaan. Validointi auttaa erottamaan osaajat aloittelijoista.
Seuraavassa on vertailtu muutamia suomalaisia web- ja ohjelmistotaloja ja niiden HTML-koodin validiutta. Testaus tehtiin lauantaina 21.8.2010.
Virheettömät (aakkosjärjestyksessä)
- Exove (XHTML 1.0 Transitional)
- Frantic (XHTML 1.0 Transitional)
- Reaktor (XHTML 1.0 Transitional)
- Sininen Meteoriitti (XHTML 1.0 Transitional)
- Soprano Brain Alliance (XHTML 1.0 Strict)
- Syneus (HTML5)
Lähes virheettömät (virheiden määrän mukaisessa järjestyksessä)
- Valve
- XHTML 1.0 Transitional
- 1 virhe: kuvan alt-attribuutti puuttuu
- Innofactor
- XHTML 1.1
- 2 virhettä, 2 varoitusta
- tyhjiä taulukkoelementtejä (<table></table>)
- Tieto
- XHTML 1.0 Transitional
- 3 virhettä
- sama ID määritetty moneen kertaan
Enemmän ongelmia
- Mearra
- XHTML 1.0 Strict
- 7 virhettä
- kuvan asettelu käyttää vanhentunutta ”align”-attribuuttia
- kuvalta puuttuu alt-attribuutti
- h4-tagia (block-level element) on käytetty inline elementin (span) sisällä
- Nodeta
- XHTML 1.0 Transitional
- 18 virhettä, 2 varoitusta
- pakolliset alt-attribuutit puuttuvat
- img-tageja ei ole suljettu
- Eficode
- XHTML 1.0 Strict
- 24 virhettä
- kuvatageista puuttuvat alt-attribuutit
- lomake sisältää virheellistä HTML:ää
- White Sheep
- HTML 2.0 (! – ilmiselvästi väärä, standardi julistettu vanhentuneeksi kesäkuussa 2000)
- 128 virhettä, 48 varoitusta
Jostain syystä Ruby on Railsilla kehitystyötä tekevät talot (Nodeta ja Eficode) näyttävät sijoittuvan listalla heikohkosti. Suomen RoR-kehittäjillä on vielä työtä tehtävänä tällä saralla.
Koodaajien yleisin selitys heikkotasoiselle HTML-koodille on se, että ”asialla ei oikeasti ole väliä”. Kunhan sivu näkyy selaimessa oikein, tämä on pääasia. HTML-koodin oikeellisuus viittaa kuitenkin usein myös syvällisempiin ongelmiin. Jos HTML:n ja CSS:n virheillä ei ole väliä, jaksetaanko samassa talossa panostaa myöskään palvelinpuolen koodin virheiden etsimiseen ja korjaamiseen?
Virheellinen HTML-koodi voi myös haitata esimerkiksi jQueryn hyödyntämistä ja hidastaa kehitystyötä. Kuvista unohtuneet alt-attribuutit viittaavat puolestaan siihen, että erityiskäyttäjien tarpeet ovat unohtuneet. Verkkosivujen käyttäjissä voi olla myös näkörajoitteisia. Yhdysvalloissa asiasta on nostettu jopa oikeusjuttuja*.
Samalla pitää toki muistaa, että pelkkä validi (X)HTML-koodi ei tee saitista toimivaa tai helposti ylläpidettävää. Mieleen nousee ainakin uusmediatalo, jolta Helsingin yliopisto tilasi aikanaan XHTML-koodia. Talo toimitti sivupohjat, joissa kaikki otsikot oli tehty kuvatiedostoina. Koodi meni validaattorista läpi.
Joka tapauksessa suomalaisen HTML-koodin taso on vuosien varrella noussut huimasti. Siinä missä sivustot saattoivat aiemmin sisältää kymmeniä virheitä, tällaisia saitteja näkee yhä vähemmän. Parantuneesta tasosta voi kiittää etenkin valmiita sivupohjia, joiden avulla vaikkapa aloitteleva WordPress-blogaaja voi helposti pystyttää tyylikkään ja koodiltaan validin sivuston.
Tapio Nurminen
CEO, Flo Apps Oy
(*Toim. huom. Linkkejä poistettu toimimattomina.)
22 kommenttia on “Validia vai ei – mitä lähdekoodista paljastuu?”
Kommentointi on suljettu.
Jussi Pasanen
Mielenkiintoinen artikkeli. Oletettavasti testaus on tehty käyttäen W3C:n Markup Validation -palvelua ja kohdistettu ainoastaan esimerkkiyritysten sivuston etusivuun? Mikäli näin on tämä olisi tekstissä hyvä mainita.
Sivuhuomiona, W3C:n validaattori antaa floapps.com/ -sivulle 14 virhettä ja yhden varoituksen (linkki tuloksiin), eli parannettavaa löytyy sieltäkin :)
Kennu
HTML5 näyttää ottavan mielenkiintoisen rennon tavan markupin validointiin XHTML:n aikakauden jälkeen. Se ei perustu XML:ään eikä SGML:ään vaan ihan omaan ”tagikeittoonsa”, jossa tageja ei ole pakko sulkea eikä attribuuttien tarvitse olla lainausmerkeissä, mutta tiettyjä sääntöjä pitää kuitenkin noudattaa.
Tai teknisesti ottaen HTML5-dokumentin voi kyllä merkitä xhtml+xml-tyyppiseksi, jolloin sen tulee olla valiidia XML:ää, mutta kumpikohan muoto ottaa enemmän tuulta alle? Historian valossa vaikuttaa siltä, että kooderit preferoivat tarkkaan muotoiltua XML:ää, kun taas visuaalisempien henkilöiden on ehkä helpompi tuottaa rennompaa HTML:ää.
Oletuksena -merkityt dokumentit ovat kuitenkin sitä tagikeittoa, koska webbiserverit antavat oletustyypiksi text/html. Valtaosa webin kaikista sivuista tullee olemaan tämän tyyppisiä pitkällä tähtäimellä.
Joka tapauksessa kaikkien täytyy opetella uudet säännöt siitä, mikä on valiidia HTML5:tä ja mikä ei. Mielenkiintoista nähdä, miten tämä vaikuttaa sivujen validiuteen keskimäärin.
Kennu
Jahas tämä WordPress suodattaa html-tagit kokonaan pois. ”-merkityt” sanan kohdalla piti siis lukea [!doctype html]-merkityt.
Jussi
Itsekin tulee mentyä monesti sieltä missä aita on matalin, eli sivuston toimivuus on tärkeämpi kriteeri kuin koodin validoiminen, mutta olipa silti hilpeää havaita että kaikilta testaamiltani kirjoittajan yrityksen sivuilta löytyy myös virheitä 6-14 kappaletta, eli ne kuuluisivat artikkelin ”enemmän ongelmia”-kategoriaan – suutarin lapsella ei tosiaan ole kenkiä. ;)
Hyvä kirjoitus joka tapauksessa, tälläisiä vieraskynä-artikkeleita lisää.
Ville Säävuori
Tämä oli oikein mainio juttu — kiitos vieraskynälle!
HTML5 on kehittäjien näkökulmasta huikea parannus edellisiin standardeihin, koska siihen ollaan kehittämässä erittäin tarkkaan määriteltyä spesifikaatiota selaintoteutuksen suhteen. Tarkoitus on siis tehdä määrittelystä niin tiukka, että kun standardi on lyöty lukkoon, kaikki sitä tulevat selaimet tukevat sitä samalla tavalla, eli nykyisen kaltainen selainhelvetti olisi tämän jälkeen historiaa. On tottakai epärealistista odottaa täydellisyyttä, mutta uskon itse siihen, että tällä tavalla nykyisestä voidaan ainakin päästä isoja harppauksia parempaan suuntaan.
Validin merkkauksen osalta on mielestäni hämmentävää, että ammattilaisiksi itseään kutsuvat tahot eivät osaa tai vaivaudu tarkastamaan tuotoksiaan. Todella usein näkee myös tapauksia joissa pelkästään etusivu on hiottu validiksi (jotta voidaan esimerkiksi vilauttaa sitä asiakkaalle), mutta kaikki alasivut rehottavat miten sattuu.
Käytännössä oikeassa elämässä täytyy usein tehdä hankalia kompromisseja. Meillä noudatetaan useimmiten Python-henkistä ”practicality beats purity”-asennetta: tehdään validia siten kun järkevissä rajoissa voidaan. Omalla saitillamme on tehty melko eksoottisia ratkaisuja joidenkin kolmansien osapuolten koodin kanssa (esim. Facebookin tykkää-iframe) jotta ne on saatu survottua validiin muottiin. Kyllähän sitä ammattiylpeyttäkin pitää olla :)
Disclaimer: olen Syneuksella töissä ja Vierityspalkin toimituksen jäsen. (Tämän artikkelin kanssa en ollut millään tavalla tekemisissä.)
Janne Toivoniemi
Ainakin White Sheepin saitti menee validaattorin läpi heittämällä. Ovatko korjanneet koodin tänään vai onko kirjoittajalla ollut vanhentunutta tietoa?
Tapani
EI!
Tapio Nurminen
@Jussi, kuten artikkelissa mainitaan, testaus tehtiin 9 päivää sitten. Tuolloin oman yritykseni saitin koodi oli validia HTML5:ä, mutta Facebookin RDFa:n lisääminen pari päivää sitten head-osioon rikkoi oikeellisuuden. Nyt meidän määritykseksi on muutettu XHTML+RDFa 1.1 ja koodi on taas validia.
@Villen kanssa on näemmä tehty sama havainto eli eniten joutuu nykyään kikkailemaan, että saa nuo kolmansien osapuolten kilkkeet (Facebook-, Twitter- ym. napit jne.) validoitumaan.
@Janne: Kuten jutussa todetaan, White Sheepin saitti ilmoitti olevansa HTML 2.0:a testaushetkellä. Nyt kun ovat korjanneet deklaraation XHTML:ksi, koodi on validia.
Jussi
@Tapio, kuten mainitsin, testasin useammankin oman saittinne, en vain tätä uusinta. Hyvä kuitenkin että homma oli noin pienestä kiinni tuon floapps.com:in osalta.
Tapio Nurminen
@Jussi, siis tarkoitatko että testasit asiakkaille tekemiämme töitä vai mitä saitteja? Testailin äkkiseltään muutamia asiakastöitämme ja kyllä ne enimmäkseen validoituvat. Kuten kaikki tietävät, siinä vaiheessa kun ylläpito siirtyy asiakkaalle, he saattavat sisällönhallinnan kautta syöttää sivuille kaikenlaista huttua… Voit halutessasi laittaa listaa ei-valideista saiteista meidän palautelomakkeen kautta.
Jussi
Tapio, tsekkasin tuon uuden saitin lisäksi tietokannat.fi:n (ihmettelin myös miksi tuo on vielä tuollaisenaan olemassa) ja flomembers.fi:n ja tosiaan kaikki kolme sisälsivät virheitä.
Mutta eipä tästä tosiaan kannata enää pidemmin jauhaa, asia on kuitenkin teilläkin hoidossa. :)
Alice in Wonderland
Minkä ihmeen takia tällainen artikkeli on kirjoitettu? Kiinnostaako käyttäjiä ihan kauheasti validoituuko saitti kunhan se toimii?
Ja millä perusteella nuo yritykset on valittu (otanta toimivia, otanta ei toimivia?)?
Ei ole vieraskynä aiemmin näin matalalla kyntänyt.
Perttu Tolvanen
Kiitos Tapio artikkelista. Hauska katsaus muutaman alan toimiston saittiin. Validius ei ole ollut pinnalla viime aikoina, joten ihan hyvä sitäkin nostaa esiin yhtenä saittien teknisen toteutuksen mittarina.
Varmasti tuota saittien koodin semantiikkaa ja saavutettavuutta voisi arvioida muillakin mittareilla, mutta tästä on hyvä aloittaa.
Kokonaisuutenahan taso on varmasti mennyt eteenpäin, mutta ihan mielenkiintoista että edelleen uusia ongelmia ilmenee (kuten nuo upotettavat widgetit ym).
Kennulle erityiskiitos ansiokkaasta kommentoinnista.
Anonyymi
Huomion kiinnittäminen sivujen validoitumiseen on ihan hyvä asia ja sen puolesta puhuu moni kirjoittajankin mainitsema seikka.
Mutta.
Pitää muistaa, että pelkkä validointi ei tee sivua hyväksi tai edes tyydyttäväksi. Itse asiassa, validi HTML on urakan puoleen väliin jättämistä. Esimerkkisivustoissa on validista koodista huolimatta suorastaan kammottavia tapauksia semantiikan kantilta katsottuna.
Validaattorit ovat käteviä apuvälineitä debuggaukseen, eivät muuta. Niitä saa ja pitää käyttää mutta tärkeämpää on ymmärtää elementtien merkitykset.
Jonkin suosituksen julistaminen ja validaattori eivät tee sivusta oikeasti yhtään mitään. Onneksi sentään ne validi-sitä-ja-tätä -bannerit ja -napit ovat kadonneet sivustoilta. Ovathan?
Toivon Vierityspalkkiin syvemmälle HTML:n semantiikkaan ja sen merkitykseen ja hyötyihin tunkeutuvaa artikkelia.
Tapio Nurminen
@Anonyymi:
Kiitos hyvästä kommentista. Olet oikeassa, validaattori ei kiinnitä huomiota esimerkiksi siihen, miten tolkuttomasti vaikkapa div-tagia on joillain sivustoilla käytetty. Viittasin siihen artikkelissakin:
”Samalla pitää toki muistaa, että pelkkä validi (X)HTML-koodi ei tee saitista toimivaa tai helposti ylläpidettävää.”
Mutta kuten toteat, aiheesta voisi kirjoittaa paljon enemmän.
Tuomas Tolppi
Anonyymi vei sanat suusta. Vaikka validius ei tee mitään sivustoa sinällään ”hyväksi”, kuuluu se mielestäni web-suunnittelun perusteisiin.
Toivon myös syvällisempää artikkelia HTML:n semantiikasta ja vaikkapa samanlainen kooste sen tasosta tietyillä sivustoilla.
Kennu
Kukaan ei muuten tainnut vielä nostaa esiin Googlen etusivun valiidiutta:
http://validator.w3.org/check?uri=http://www.google.com/&charset=(detect+automatically)&doctype=Inline&group=0
35 Errors, 2 warning(s)
Henkilökohtainen suhtautumiseni validointiin muuttui aika paljon sen jälkeen, kun huomasin miten Google siihen suhtautuu.. Melko pragmaattisesti siis.
Anonyymi
Google on ehkä vähän huono esimerkki koodin validiudesta puhuttaessa. Yhtiöhän ei tuota edes sisältöä vaan tietokantalistauksia ja niitäkin ns. insinööridesignilla.
Jussi Pasanen
Tuomaksen ylläolevan pointti on oiva, olen samaa mieltä että validointi kuuluu web-suunnittelun perusteisiin.
Yksittäisten validointiongelmien lisäksi olisi mielenkiintoista kuulla miten eri tahot ovat saaneet validoinnin nivottua kiinteäksi osaksi sivuston tuotantoprosessia. Itse olen havainnut, että työkalut kuten Firefoxin HTML Validator ja Firebug-lisäpalikat ovat aivan ehdottomia. Mitä automaattisempaa validointi on sitä vähemmän tarvitaan satunnaista ’drive-by’-validointia ja lopputulos on yleensä kokonaisuutena parempi.
Tuomas Tolppi
Google tosiaan on huono esimerkki validiudesta puhuttaessa, enkä sen sivustojen perusteella lähtisi omia käytäntöjä muuttamaan.
Tässäpä vielä jonkinlainen vastaus suoraan Googlelta miksi esimerkiksi Google.com ei ole validia koodia: http://www.youtube.com/watch?v=FPBACTS-tyg
Anonyymi
Googlen käyttäminen verukkeena siihen, ettei tee työtään hyvin, on epämiellyttävää.
Antti
Validoinnista puhuttaessa tuli mieleeni Jeff Croftin artikkeli, jonka teemaa myös Anonyymi sivusi.
”Your markup validator, whether it’s the one on the W3C site or one built into your favorite coding tool, is a debugging tool […] Your markup validator, whether it’s the one on the W3C site or one built into your favorite coding tool, is not a measuring stick for greatness.”
jeffcroft.com/blog/2008/feb/24/your-markup-validator/