Mielőtt folytatnánk kedvenc weboldalunk, a CSS Zen Garden tanulmányozását, térjünk vissza egy rövid időre a sorozat előkészítő részében már pedzegetett weboldalrétegekhez. Miről is van szó?
RÉTEGES FELÉPÍTÉS
Bár első ránézésre ez nem egyértelmű, a mai modern (X)HTML-alapú weboldalak különböző, egymásra épülő rétegekből állnak. A legalsó a tartalmi réteg, amely az (X)HTML elemekkel leírt dokumentumstruktúrát és az oldal tartalmi elemeit (szövegek, képek stb.) foglalja magába, és semmilyen formázást vagy más tervezési elemet nem tartalmaz! Azt, hogy az oldal hogyan fog festeni, a CSS-stíluslapokkal leírt megjelenés réteg határozza meg. A stíluslapok tartalmazzák az oldal dizájnját, pontosan leírják, hogy a tartalmi rétegben definiált oldalstruktúra egyes részei, elemei hol és hogyan jelenjenek meg a böngészőben. Bár maga a CSS is lehetőséget kínál a különböző formázásokra (például hogy egy hivatkozás hogyan jelenjen meg önmagában, és hogyan változzon meg, ha rámutatunk az egérrel), de valójában a harmadik, viselkedés réteg az, amelyik a JavaScript programnyelven keresztül lehetővé teszi, hogy az egyes oldalelemekhez különböző eseményeket társítsunk, és rendelkezzünk afelől, hogy mi történjen, amikor ezek az események bekövetkeznek.
Az XHTML réteg hordozza a tartalmat és az oldalstruktúrát, a CSS réteg írja le dizájnt, ketten alkotják a CSS Zen Garden főoldalának kinézetét
A három réteg három teljesen eltérő technológiára épül - a tartalmi az (X)HTML-re; a megjelenés a CSS-re; a viselkedés a JavaScriptre -, és ideális esetben teljesen elkülöníthetők egymástól. Némi egyeztetés után akár három különböző személy egymástól teljesen függetlenül is dolgozhat ugyanazon a weboldalon: a szerző létrehozza az oldal tartalmát, felépíti annak struktúráját; a tervező megalkotja az oldal dizájnját, megjelenését; és ha szükséges, a programozó gondoskodik az események és aktív oldalelemek működéséről. A valóságban ezek a munkakörök általában nem, vagy nem így különülnek el: a tartalom előállítására a szerző - jó esetben - valamilyen szövegszerkesztőt használ; a tervező egy grafikus alkalmazásban álmodja meg az oldal küllemét; végül mi egy személyben leszünk az, aki a tartalmat struktúrába önti, a képként megkapott dizájnt stíluslapra alakítja át, és megírja a szükséges JavaScript kódot.
Ugyanakkor az is könnyen belátható, hogy az egyes rétegek szorosan egymásra épülnek abban a tekintetben, hogy nincs semmi értelme a megjelenítési rétegnek, ha nincs alatta az a tartalom, amelynek a kinézetéről gondoskodnia kéne. És bár írogathatunk olyan JavaScript programokat, amelyek elfutnak önmagukban is, a viselkedés réteget jelentő programkódnak is pontosan ismernie kell, hogy milyen strukturális és tartalmi elemek alkotják az oldalt, amelyet vezérelhet, illetve adott esetben azt is, hogy ezekhez milyen megjelenítési lehetőségek társulnak a stíluslapon.
ISMÉTLÉS A TUDÁS ANYJA!
A rétegek nagyjából meghatározzák a tanulás sorrendjét is: először nyilván a tartalmi réteg létrehozását kell elsajátítanunk, ezután érdemes foglalkozni a CSS-sel, és végül a JavaScripttel tehetjük teljessé a képet.
Ennek megfelelően az első leckében elkezdtünk ismerkedni az (X)HTML nyelvvel, megtanultuk a weboldalt leíró tagek fogalmát, valamint nagy vonalakban áttekintettük a szabályos XHTML-oldal felépítését, benne a dokumentumtípus-meghatározást (DTD), a fejlécet (‹head›...‹/head›), valamint a törzsrészt (‹body›...‹/body›). Hozzáfogtunk a CSS Zen Garden oldal „boncolásához", és ennek kapcsán találkoztunk először az oldalt főbb strukturális részekre osztó ‹div› címkével.
A CSS Zen Gardent éppen azzal a céllal hozták létre, hogy demonstrálják a weboldalak réteges felépítésének működését, előnyeit. A különböző dizájnok kiválasztásával a változatlan tartalmi réteg fölött cserélgethetjük a megjelenési réteg tartalmát, és így teljesen azonos tartalmú, de gyökeresen eltérő külsejű oldalakat kapunk. Most azonban, mielőtt folytatnánk forráskódjának tanulmányozását és ezen keresztül a főbb (X)HTML építőkockák megismerését, meg kéne szabadulnunk a megjelenítési rétegtől - mégpedig azért, mert az oldal megjelenését leíró stíluslap ügyes trükkökkel elrejt előlünk bizonyos oldalelemeket, ami kissé megnehezítené a velük való ismerkedést. (Később, amikor majd a CSS lehetőségeit vesszük szemügyre, részletesen bemutatjuk ezeket a fogásokat.)
A stíluslapok kikapcsolásával eltűnik a dizájn, az (X)HTML elemeket a böngésző a saját alapértelmezett formázásainak megfelelően jeleníti meg
Továbbra is a Firefox böngészőt használva jelenítsük meg a korábban már megismert és telepített Web Developer eszköztárát - akár az ikonjára kattintva, akár a Nézet -› Eszköztárak menün keresztül -, majd a CSS menüben használjuk a Disable Styles -› All Styles funkciót. A funkció neve kicsit becsapós, ugyanis ezzel nem a teljes megjelenítési réteget kapcsoljuk ki a tartalmi réteg fölött, hanem az oldal tervezője által definiált stíluslapot cseréljük le a böngésző saját, alapértelmezett stíluslapjára. Ez egészen egyszerű módon, minimális formázással jeleníti meg a különböző (X)HTML-elemeket, amely a tanuláshoz most épp megfelelő számunkra.
FONTOSABB ÉPÍTŐKOCKÁK
Az első leckében az oldal tényleges tartalmával rendelkező törzsrész (‹body›...‹/body›) elemzése során arra a megállapításra jutottunk, hogy nagyjából az egész oldalt egy container azonosítóval ellátott ‹div› fogja össze, amelyet három elkülönülő blokkra oszt fel az intro, a supportingText és a linkList azonosítójú ‹div›. Láthattuk azt is, hogy ezek az oldal mely részeit is írják le pontosan. Folytassuk a forráskód tanulmányozását, és koncentráljunk az intro részre, amely szintén három elemből áll: ezeket a pageHeader, a quickSummary és a preamble azonosítóval ellátott ‹div›-ek jelölik.
‹h1›...‹/h1›
A pageHeader (szó szerinti magyar fordításban: oldalfejléc) tartalmazza az oldal címét (‹h1›...‹/h1›) és alcímét (‹h2›...‹/h2›). Az (X)HTML nyelv összesen hatféle címsort különböztet meg, ezek jelölésére a ‹h1›, ‹h2›, ‹h3› ... ‹h6› tageket és azok lezáró párjait használhatjuk. A címke nevében a h betű az angol heading szó rövidítése, míg az utánuk álló szám a címsor-hierarchiában elfoglalt helyüket jelzi: minél kisebb, annál magasabb szintű címsorról van szó. Ha valaki látta már a Wordben a különböző Címsor bekezdésstílusokat, akkor valószínűleg tudja, hogy ezek hierarchikusan egyre kisebb rendű, rangú szövegrészeket jelölnek (főcím, fejezetcím, alfejezetcím stb.), és például ezeket használja a program az automatikus tartalomjegyzékek elkészítéséhez. A Wordtől eltérően az (X)HTML-ben nincs külön címke a dokumentum címének jelölésére, pontosabban a ‹title› taget - mint azt az előző hónapban láttuk - az oldal fejlécében (‹head›...‹/head›) egészen másra használjuk. Ebből az következik, hogy amikor a dokumentum struktúrájának létrehozásán dolgozunk, az oldal címét általában a ‹h1›...‹/h1› tagpárral jelöljük, az alcímet ‹h2›...‹/h2›-vel, a fejezetcímeket, alfejezetcímeket pedig az összes többivel, ahogy ezt a CSS Zen Garden esetében is láthatjuk.
A címsorok alapértelmezett mérete (balra) senkit ne zavarjon meg, CSS-sel kedvünkre átalakíthatjuk őket
Két nagyon fontos tudnivaló van ezzel kapcsolatban, amit érdemes jól az eszünkbe vésni. Az egyik, hogy a címsorok funkciója nincs kőbe vésve; ha tehát oldalunkon nincs cím és alcím, de van fejezetcím vagy bármilyen más, címjellegű tartalmi rész, akkor a ‹h1› is nyugodtan használható ennek jelölésére. Sokan azért riadnak vissza ettől, mert a hierarchiának (és az alapértelmezett stíluslapnak) megfelelően a böngészők a ‹h1›-et óriási méretű betűkkel szokták megjeleníteni, míg a ‹h3›-nál viszont nagyjából pont jó az alap betűméret, így inkább azt használják. Ez nem jó gondolkodás, és ez a másik nagyon fontos dolog, amit meg kell értenünk: amikor a dokumentum tartalmát, annak struktúráját hozzuk létre, nem szabad azzal foglalkoznunk, hogy ebből mi hogyan jelenik meg aktuálisan a böngészőben! Csak azzal törődjünk, hogy mindig a funkciójának, tartalmának megfelelő taget használjuk az adott szövegrészek jelölésére, függetlenül attól, hogy az most hogy jelenik meg. Később látni fogjuk, hogy saját stíluslapokkal az alapértelmezett formázások milyen pofonegyszerűen felülbírálhatók, és minden (majdnem) pont úgy fog kinézni, amilyennek szeretnénk.
‹p›...‹/p›
A quickSummary (magyarul: rövid összefoglaló) rész két bekezdésben foglalja össze az oldal tartalmát, és lehetőséget kínál a forráskód és a stíluslap letöltésére, míg a preamble (előszó) rövid szöveges kedvcsináló a weboldal további mondanivalójához. Látható, hogy mindkettő jobbára bekezdésekből áll, illetve a preamble részben találkozhatunk a korábban említett ‹h3› címsorral is.
A bekezdés, azaz a ‹p› és ‹/p› címkék használata nagyjából pofonegyszerű: ha szöveges tartalommal dolgozunk, és az nem címsor vagy felsorolás, akkor az esetek túlnyomó többségében bekezdésként jelöljük, és kész. Ez az egyik leggyakoribb dokumentumelem, amellyel a weboldalakban találkozni fogunk (a p betű egyébként az angol paragraph szó rövidítése, ami magyarul bekezdést jelent).
‹a›...‹/a›
Bár a hivatkozással, azaz az ‹a›...‹/a› tagpárral valójában már találkoztunk az előző hónapban a címkék fogalmának és felépítésének megismerése során, azért ismételjük át gyorsan, hogy miről is van szó, hogyan is működik a dolog. Ugye emlékszünk még, hogy a HTML szóban a HT a HyperText kifejezés rövidítése, ami arra utal, hogy a szöveg olyan hivatkozásokat (eredetileg: hiperhivatkozásokat) tartalmaz, amelyek a szöveg más-más részeire utalnak, és ha rákattintunk egy ilyen hivatkozásra, akkor villámgyorsan a hivatkozott résznél kötünk ki. Ez csak leírva ilyen bonyolult, a mindennapi böngészés során szinte folyamatosan hivatkozásokra kattintunk, így navigálunk az adott oldalon belül, így jutunk el egyik oldalról a másikra, így töltünk le programokat, zenéket, bármit az internetről.
A CSS Zen Garden forráskódjának 46. sorában láthatunk példát két hivatkozásra is: az első az oldal forráskódjának, a második a stíluslapjának letöltését ajánlja fel. (Az már más kérdés, hogy egyik sem indít el tényleges letöltést; mindkét esetben megjeleníti a hivatkozott állomány tartalmát a böngésző. Ha ténylegesen le akarjuk tölteni őket, a jobb egérgombbal előhívható menüből kell kiválasztanunk a Hivatkozás mentése más néven funkciót.) Az angol anchor (horgony) szóból származó ‹a› és ‹/a› tagek közötti „html file", illetve „css file" szavak jelentik a tényleges hivatkozást: ez fog megjelenni az oldalban, erre tudunk majd rákattintani. A href attribútuma tartalmazza a hivatkozás címét - ez esetben a /zengarden-sample.html, illetve /zengarden-sample.css -, a title attribútum pedig némi magyarázatot fűz mindehhez. Utóbbi nem látszik közvetlenül az oldalon, hanem amikor az egérrel rámutatunk a hivatkozásra, úgynevezett tooltip formájában jelenik meg az egérkurzor mellett. Használata nem kötelező, de a bővebb információ hasznos lehet azok számára, akik valamilyen speciális eszközt használnak az internet böngészésére, gondoljunk például a látáskárosultak felolvasóprogramjaira.
A ‹div›, a ‹h1›, ‹h2›, ‹h3›, a ‹p› és az ‹a› tagek ismeretében tulajdonképpen tökéletesen tudjuk értelmezni a CSS Zen Garden forrásának intro és supportingText részeit. Két olyan címke van még, amely előfordul ezekben, és nem volt még szó róluk: a ‹span› és az ‹acronym›.
‹span›...‹/span›
A ‹span› nem rendelkezik önálló jelentéssel; arra való, hogy a dokumentum szöveges részein - leggyakrabban bekezdéseken - belül elkülönítsünk, megjelöljünk bizonyos részt vagy részeket, amelyeket a többitől eltérő módon szeretnénk formázni. (Kicsit hasonlít a ‹div›-re, és szokták is őket együtt emlegetni: míg a ‹div› a dokumentumon belül kerít el a dokumentum többi részétől elhatárolt blokkokat, a ‹span› nagyon hasonló módon egy szövegrészen belül.) Sajnos a CSS Zen Garden nem igazán jó példa a használatára, mert itt minden címsoron és bekezdésen belül a teljes szövegre „ráhúzták" a ‹span›...‹/span› párost, amellyel tulajdonképpen csak még egy extra formázási lehetőséget biztosítottak ezekhez az oldalelemekhez. Valójában nem így, hanem szövegrészleteken szokták inkább használni, úgyhogy túlzott figyelmet most ne tulajdonítsunk neki.
‹acronym›...‹/acronym›
Az angol acronym szó magyar jelentése: mozaikszó. Mint láthatjuk, az ebből képzett ‹acronym› tag funkciója pontosan az, hogy megjelöljük a mozaikszavakat a szövegben, amennyiben valamilyen további szándékunk van velük kapcsolatban, például a folyó szövegtől eltérő módon szeretnénk őket formázni, vagy meg akarjuk magyarázni a jelentésüket. Használata természetesen nem kötelező, sőt meglehetősen ritka. A title attribútumba írt szöveg szintén tooltipként jelenik meg, ha rámutatunk a megjelölt mozaikszóra az egérrel, illetve a felolvasóprogramok felismerik az ilyen jelöléseket, és felolvassák azok tartalmát (ami egyébként akár élvezhetetlenné is teheti az oldal tartalmát, ha lépten-nyomon ugyanabba a megmagyarázott mozaikszóba botlunk, tehát ésszel éljünk a lehetőséggel).
‹ul›, ‹ol›, ‹li›
Az utolsó fontos struktúraelem, amelyre szép példát találunk a CSS Zen Garden forrásában, a felsorolás. A harmadik főbb oldalblokkban, a linkList azonosítóval ellátott ‹div›-ben járunk, amelyet mesterségesen kicsit túlbonyolítottak: látható, hogy a linkList2 ‹div› ugyanúgy felöleli a teljes dokumentumrészt, mint a linkList. Ennek célja nyilván az volt, hogy gazdagabb formázási lehetőséget nyújtson a stíluslapot készítők számára - ne foglalkozzunk vele. Koncentráljunk inkább arra, hogy a linklist2-n belül három további részre válik szét az oldal (lselect, larchives, lresources), amelyek mindegyike egy-egy címsort (‹h3›) és egy felsorolást tartalmaz.
Egy felsorolás a következőképpen épül fel:
‹ul›
‹li›Első listaelem‹/li›
‹li›Második listaelem‹/li›
‹li›Harmadik listaelem‹/li›
‹/ul›
Tehát az egészet egy ‹ul›...‹/ul› tagpár fogja közre, az egyes listaelemeket pedig a ‹li›...‹/li› tagek jelölik.
Balra a nem számozott lista (a Word ezt hívja felsorolásjeles listának), jobbra pedig a számozott lista látható
Alapvetően kétféle felsorolástípust használhatunk: az ‹ul›...‹/ul› az úgynevezett „nem számozott" (unordered list), míg az ‹ol›...‹/ol› a számozott (ordered list) lista. Az előbbi esetben a listaelemeket pöttyökkel vagy más grafikai elemmel szokták jelölni, az utóbbiban viszont számokkal, mivel itt a lista valamilyen sorrendet is jelöl. (A korábbi szövegszerkesztős analógiánál maradva a Wordben az előbbinek a Felsorolás, utóbbinak a Sorszámozás funkció felel meg.) Az (X)HTML-ben mindkettő esetén ‹li›...‹/li› tagpárral jelöljük a listaelemeket (az angol list item, szó szerint listaelem kifejezés rövidítése). Azt, hogy a lista hogy néz ki, van-e egyáltalán valamilyen grafikai dolog a listaelemek előtt, vagy hogy milyen számozást használunk a jelölésükhöz, és az honnan kezdődik, mind a stíluslapon fogjuk beállítani.
Fontos megértenünk, hogy a weboldal tartalmi részének és struktúrájának felépítése során minden olyan dolgot, ami kicsit is hasonlít egy felsorolásra vagy listára, azt a felsorolásként kell, érdemes definiálni, még akkor is, ha ez első hallásra vagy ránézésre kicsit furcsának is tűnhet. Gondoljunk például egy navigációs menüre, amellyel csodálatos weboldalunk különböző aloldalaira lehet eljutni. Ránézésre nem tűnik felsorolásnak, de valójában pontosan az: menüpontok felsorolása, ezért így is kell definiálnunk az (X)HTML kód írásakor. Majd a stíluslapban a megfelelő formázással gondoskodunk arról, hogy véletlenül se egy pöttyökkel ellátott lista legyen, hanem egy látványos menü.
Az igazsághoz hozzátartozik, hogy van egy harmadik felsorolástípus is: az úgynevezett definíciós lista, ez azonban teljesen másképp épül fel, és elég ritkán is használják, ezért erre esetleg majd egy későbbi leckében térünk ki.
‹img›
Az ‹img› taget használjuk képek beszúrására, elhelyezésére az oldalban. A CSS Zen Gardenben nincs rá példa - itt érdemes megállni egy pillanatra, és eltöprengeni ezen. Ha valaki eltöltött egy kis időt azzal, hogy megnézegesse az oldalhoz készült különböző dizájnokat, bizonyára látta, hogy számtalan gyönyörű, látványos, színekben, képekben (!), valamint a legkülönbözőbb grafikai elemekben tobzódó dizájn készült az évek során. Hogyan lehetséges ez, merül fel a kérdés, ha egyszer nincs is kép az XHTML forráskódban? A válasz pedig erre is az, hogy természetesen a CSS segítségével, amely lehetővé teszi, hogy a különböző oldalelemek (például ‹div›-ek) dekorálásához háttérképeket használjunk. Sőt a CSS pozicionálási és formázási lehetőségei gazdagabbak és precízebbek, ezért megfontolandó, hogy mikor használunk egy képet ténylegesen képként egy XHTML-oldalban, és mikor dekorációként CSS-ből. A kérdésben benne van a válasz is: ha egy képnek nincs semmi más szerepe az oldalban, csak az, hogy dekoráljon, díszítsen egy oldalelemet, akkor CSS-ből használjuk. Ha a kép valamilyen jelentéssel, információval bír (például egy fotó vagy grafikon), tehát önmaga is tartalmi elem, akkor képként szúrjuk be az XHTML-oldalba.
Az ‹img› címke több szempontból is speciális: ez ugyanis az első úgynevezett üres tag, amellyel praxisunk során találkozunk. Az üres tag olyan oldalelemet jelöl, amelynek nincs szöveges tartalmi része, épp ezért záró címkére sincs hozzá szükség. Nézzünk egy példát:
‹img src="images/logo.jpg" width="300" height="200" alt="PC World logo" /›
Az src attribútum (az angol source, forrás szó rövidítése) tartalmazza a kép helyét, elérési útját. Kezdők gyakran követik el azt a hibát, hogy saját számítógépükön tárolt képeket úgy illesztenek be az oldalba, hogy az elérési útban szerepel a partíció betűjelétől kezdve a teljes mappastruktúra, majd az oldalt feltöltve egy kiszolgálóra, csodálkoznak, hogy a kép nem jelenik meg. ?ltalában érdemes a képeket az (X)HTML állományoktól elkülönítve, egy külön mappában tárolni (a fenti példában ez az images); és a mappán keresztül hivatkozni a képre. Ez működni fog saját számítógépünkön, és a webkiszolgálón is.
A width és height a kép szélességét és magasságát adják meg képpontban. Használatuk nem kötelező, a böngésző is ki tudja számolni, de ehhez meg kell várnia, amíg a kép betöltődik. A pontos méretek definiálásával tehát felgyorsíthatjuk a műveletet. ?rdemes tudni, hogy megadhatók a valódi mérettől eltérő értékek is, ilyenkor a böngésző akkorára torzítja a képet. A torzítást vegyük szó szerint, ugyanis az eredmény az esetek többségében elég pocsék. Több szempontból is jobban járunk, ha mi magunk készítjük el a képek különböző méretű változatait valamilyen grafikus alkalmazásban: a végeredmény összehasonlíthatatlanul jobb minőségű, valamint a kisméretű kép - a kisebb fájlméret folytán - gyorsabban töltődik be az oldalba, mint ha egy nagyobbat akarnánk a böngészővel kicsire torzítani.
Az alt attribútum, amely alternate text (helyettesítő szöveg) kifejezésből kapta a nevét, pontosan arra való, hogy néhány szóban leírjuk a kép tartalmát, jelentését. Nagyon fontos, hogy ez nem jelenik meg a grafikus környezetben futó böngészőkőn (és kizárólag az Internet Explorerben tűnik fel tooltipként). Ezt tipikusan az olyan böngészőkhöz találták ki, amelyek nem tudnak képet megjeleníteni, a megadott szöveggel viszont tájékoztathatjuk az olvasót a kép tartalmáról.
Még sokan mások...
Tulajdonképpen az összes alapvető XHTML-struktúraelemet áttekintettük; ezek használatával a legtöbb weboldal tartalma és struktúrája már leírható. Nem esett azonban szó két nagyon fontos nagyobb csoportról: a táblázatokról és az űrlapokról. Mindkettő meglehetősen terjedelmes és nehéz téma - később, külön leckékben részletesen tárgyalni fogjuk őket. Persze a fentieknél jóval több tag áll a rendelkezésünkre, ezekre is a későbbiekben, használatuk bemutatásánál fogunk kitérni.
AZ XHTML PARANCSOLATAI
A továbbiakban azokról a legfontosabb formai szabályokról lesz szó, amelyeket az XHTML megkövetel ahhoz, hogy a weboldalunkat leíró dokumentum jól formázott legyen. Ezek betartása rendkívül fontos, ha érvényes, szabályos XHTML-dokumentumot szeretnénk létrehozni, tehát azok is figyelmesen olvassák, akik csak most ismerkednek a nyelvvel, azok pedig, akik korábban bütyköltek már ezt-azt HTML-ben, pláne! Valójában jóval több szabály van, de az alábbi hat a legfontosabb, tekintve, hogy ezeket már első oldalaink létrehozása során is ismernünk és alkalmaznunk kell.
1. A DTD használata kötelező!
Ezt a szabályt már az előző leckében megtanultuk: az XHTML-dokumentumnak mindig érvényes dokumentumtípus-definícióval (DTD) kell kezdődnie. A DTD mondja meg, hogy az XHTML-nek melyik verzióját, és annak melyik változatát használjuk.
A XHTML 1.0-nak például háromféle változata van: a Strict (szigorú), a Transitional (átmeneti) és a Frameset (ezt felejtsük is el rögtön!). Az első kettő közötti fő különbség abban áll, hogy mennyire engedik meg a megjelenéssel, dizájnnal kapcsolatos címkék (‹center›, ‹font› és egyéb szörnyűségek), illetve attribútumok (border, bgcolor, alink, vlink stb.), használatát az oldal forrásában. A Strict semennyire; álláspontja szerint az XHTML-dokumentum szóljon a tartalomról, annak struktúrájáról, és egyáltalán ne legyenek benne kinézetre vonatkozó információk, az ilyen problémáinkat oldjuk meg stíluslappal. (Ismerős valahonnan?) Ha valaki korábban egyáltalán nem foglalkozott weboldalkészítéssel, nem kérdéses, hogy számára a Strict típus a kötelező haladási irány, mivel így a legkisebb az esélye annak, hogy valami „rosszat" tanul meg. A Transitional kicsit engedékenyebb; ez főleg azok számára készült, akik a HTML „mindent szabad" mentalitásából fokozatosan szeretnének áttérni az XHTML szűkebb korlátok közé szorított világába.
2. Kisbetűk használata kötelező!
A HTML nem tesz különbséget a között, hogy a weboldal kódját kisbetűkkel vagy nagybetűkkel írjuk-e. Megengedi mindkettőt, mi több, akár keverhetjük is a kettőt, ami nyilván a lehető legrosszabb, amit csak tehetünk.
A jóval szigorúbb XML különbséget tesz a kis- és nagybetűvel írt jelölők között, amit az XHTML olyan formában örökölt meg, hogy a szabvány által ismert és megengedett valamennyi taget és attribútumot kötelező kisbetűvel írni. A ‹div› és a ‹DIV› tehát két különböző dolog: a ‹div› egy létező XHTML-címke, a ‹DIV› meg valami más, aminek semmi keresnivalója egy XHTML-re épülő weboldalban. A szabály egyébként az attribútumok értékére is vonatkozik: minden olyan esetben, amikor egy attribútum a szabványban előre meghatározott értékeket vesz fel, azokat ugyanúgy kötelező kisbetűvel írni. Amikor egy attribútum értéke ránk van bízva, használhatunk kisbetűt, nagybetűt vegyesen. (Utóbbira láthattunk példát a CSS Zen Garden oldal forrásában, a ‹div› tagek id attribútumának értékeinél.)
3. Értékek idézőjelek között!
((szabaly3_nemok.png és szabaly3_ok.png)) Gyakori rossz példa volt a HTML korai időszakában, hogy egy attribútum utáni egyenlőségjelet követően csak úgy odaírták annak értékét (például width=300).
Az XHTML-ben az attribútum értékét kötelező idézőjelek közé tenni, tehát a fenti példa helyesen így néz ki: width="300".
A szabálynak van még egy kitétele, ám ahhoz, hogy ezt megértsük, tudnunk kell, hogy a HTML szabványban vannak úgynevezett logikai attribútumok, amelyek önmagukban definiálnak valamilyen tulajdonságot, nincs külön értékük. Ilyen például az egyes űrlapelemeknél használt disabled attribútum, amely letiltja az adott űrlapelem használatát (például egy jelölőnégyzet ilyenkor kiszürkül, nem tudjuk kipipálni). A szabály úgy rendelkezik, hogy ezek az attribútumok nem állhatnak egyedül, kötelező hozzájuk értéket rendelni. Legegyszerűbb megoldásként általában saját magukat szoktuk megadni értékként, valahogy így: disabled="disabled".
4. Minden tag legyen lezárva!
Bár a HTML szabvány is pontosan meghatározta a tagpárokat, bizonyos esetekben engedékenyen lehetővé tette a záró címkék elhagyását. Az XHTML-ben ez nem megengedett. Minden felhasznált címkének lezártnak kell lenni, még azoknak is - tessék megkapaszkodni! -, amelyeknek nincs lezáró párja. Az ‹img› esetében már találkoztunk az egy kifejezésből álló, üres tag fogalmával. Ezeket az XHTML szabvány szerint úgy zárjuk le, hogy a végén levő nagyobb jel elé egy perjelet teszünk: ‹img ... /›
.
5. Címkék megfelelő egymásba ágyazása
Az egymásba ágyazás elsőre talán kissé zavaros fogalom lehet, de ha megnézzük a CSS Zen Garden forrását, láthatjuk, hogy másból sem áll, mint egymásba ágyazott címkékből, gondoljunk csak arra, hogy az oldalt egyetlen ‹div›...‹/div› tagpár fogja közre, és ezen belül, ebbe beleágyazva találjuk az oldal egyes részeit tovább részletező tageket. A szabály úgy szól, hogy az egymásba ágyazott elemek nyitó és záró címkéi nem keresztezhetik egymást.
Tehát először mindig a legutoljára megnyitott (beágyazott) címkét kell lezárni, és csak ezután következhet annak a címkének lezárása, amelybe az egészet beágyaztuk.
Számtalan példát láthattunk erre, például a ‹p› és a ‹span› esetében: először a ‹p›-t nyitjuk meg, majd a ‹span›-t, tehát a szöveg végén először a ‹span›-t kell majd bezárnunk, és csak utána a ‹/p›-t.
6. Kötelező információszolgáltatás képekről
Az ‹img› tag esetén volt szó a képet helyettesítő szöveget tartalmazó alt attribútumról. Az XHTML kötelezővé teszi ennek használatát, tehát egy képnek kötelezően mindig kell hogy legyen alt attribútuma.
MINT A KRESZ
Mi történik, ha nem tartjuk be az XHTML szabályait? Mi történik, ha betartjuk? Mindkét kérdés rossz: a szabály azért szabály, hogy betartsuk, és kész. Persze, emberből vagyunk, így hibázhatunk is, tehát?
Az, hogy egy weboldal hogyan fog megjelenni egy böngészőben, két dolgon múlik: rajtunk és a böngésző fejlesztőin. Csapatmunkáról van tehát szó, amelyben a mi feladatunk az, hogy a szabványnak megfelelő, annak szabályai szerint felépülő weboldalakat hozzunk létre. A böngészők fejlesztőinek feladata, hogy szoftverük a szabványban leírtaknak megfelelően jelenítsék meg a weboldalt. A két fél közül nekünk van könnyebb dolgunk, a fejlesztők egyelőre nem állnak helyzetük magaslatán, a különböző böngészők ráadásul eltérő mértékben támogatják a szabványokat. Ez jelen pillanatban azzal az átokkal sújt minket és minden weboldalkészítőt, hogy oldalunkat nem elég egyszer, egyféleképp elkészíteni, hanem „optimalizálni" kell azt legalább a legnépszerűbb böngészők tudásához. Ez egy ritka pocsék munka, de jó alaposan megnehezíthetjük a saját dolgunkat, ha már weboldalunk (X)HTML kódja sem a szabványnak megfelelő. Ekkor ugyanis a böngészők nekiállnak trükközni, hogy kitalálják, mégis mi a búbánatot szerettünk volna írni a hibás helyen, és persze mindegyik böngésző egymástól eltérő trükköket ismer, tehát irgalmatlan káosz és sírás lesz a végeredmény.
A W3C féle ellenőrző oldal pár pillanat alatt megmondja, hogy a weboldal megfelel-e a szabványnak, vagy nem, akkor milyen hibák találhatók benne
Hogyan biztosíthatjuk azt, hogy weboldalunk megfelel a szabványoknak? Úgy, hogy ellenőrizzük az erre szolgáló eszközökkel, csúnya idegen szóval validáljuk. A különböző szabványok fölött bábáskodó World Wide Web Consortium (W3C) által készített webes ellenőrző eszköz, a validator.w3.org átnézi weboldalunkat, és összeveti annak tartalmát a DTD-ben meghatározott szabványos leírónyelvvel és annak szabályaival. Ha mindent rendben talál, akkor közli velünk, hogy oldalunk a szabványnak megfelelő érvényes weboldal, ha viszont nem, akkor kapunk egy listát a hibákról, és máris hozzáláthatunk azok javításához.
Egy magára valamit is adó weboldalkészítő nem nyugszik addig, míg oldala nem valid.
Lábjegyzet: Ki nevet a végén?
Az XHTML látszólag csupa jó dolgot hozott az internet világába, megítélése mégsem egységesen pozitív, és általában véve rengeteg vita van körülötte. Profi weboldalkészítők egy csoportja – például a CSS-guruként nyilvántartott Eric Meyer – is elhatárolódott tőle, és tüntetőleg HTML 4.01-et használnak oldalaikban. Vajon miért?
Az XHTML létrehozása során az XML adatleíró nyelv szigorúságát örökölte. Utóbbi olyannyira szigorú, hogy a böngészők a legapróbb formai hibánál is azonnal abbahagyják az XML-dokumentum értelmezését, és hibaüzenetet jelenítenek meg. Érdekes, hogy amikor egy XHTML-ben írt weboldalt böngészünk, mégsem találkozunk ezzel a jelenséggel, még akkor sem, ha direkt vétünk a leírónyelv szabályai ellen. Ennek az az oka, hogy a böngészők külön-külön értelmezőt használnak a weboldalak, illetve az XML dokumentumok feldolgozására. Eddigi oldalainkat mindig az előbbi, engedékeny feldolgozó jelenítette meg, ami lehet, hogy számunkra remekül megfelelt, ám sajnos nem ez a megfelelő eljárás: az XHTML-dokumentumokat XML-ként kellene értelmeztetni a böngészőkkel. A formátum 1.0-s változatának esetében a W3C még megengedi a HTML-ként való értelmezést, de már ott is szorgalmazza az XML-t, míg a nyelv összes többi változatánál (1.1 és a készülő 2.0) már kizárólag csak az utóbbi jöhet szóba (lásd: www.w3.org/TR/xhtml-media-types/).
Nos, aki ki akarja próbálni, hogy mi a különbség, problémahegyekkel szembesül. Rengeteg dolog nem, vagy nem úgy működik, ahogy megszoktuk. Érdemes elolvasni Roger Johansson összefoglalóját (The perils of using XHTML properly), vagy magyar nyelven Úr Bence XHTML-oktató oldalát, ahol nemcsak összefoglalja, de példákon szemlélteti is a két megjelenítési mód közötti különbségeket.
Az XHTML ellenzői épp azt hangoztatják, hogy irgalmatlan hosszadalmas és bonyolult folyamat az XML-formátumnak ténylegesen megfelelő weboldalakat készíteni, ami egy kezdőtől végképp nem várható el. Különösen azért nem, mert a mérleg másik serpenyője üres: szenvedéseinkért nem igazán jár semmiféle jutalom, nincs királykisasszony vagy fele királyság. A módszernek egyszerűen nincs semmi kézzelfogható előnye, eltekintve attól, hogy büszkék lehetünk magunkra, és hogy az olyan eszközök és alkalmazások is fel tudják majd dolgozni oldalainkat, amelyek kizárólag az XML nyelvén értenek. Az XHTML támogatói erre azt válaszolják, hogy nincs mérleg vagy másik serpenyő: a XHTML használatának ez az egyetlen, helyes formája, ezt kell megtanulni, így kell csinálni. Minden más megközelítés téves és/vagy hibás.
Ez azonban csak az egyik szög az XHTML koporsójában. A másik a támogatás hiánya: az Internet Explorer – mi más? – jelenlegi verziói ugyanis nem hajlandók XML-ként értelmezni az XHTML-állományokat, és a Microsoft már hírül adta, hogy e „jó szokása” mellett a böngésző nemrég bejelentett, 8-as változatában is kitart (nyilván nem kis felháborodást váltva ki ezzel az XHTML elkötelezett híveiből).
A fentiekből – számunkra elsőre legalábbis – az következik, hogy az XHTML 1.0 feletti változatai nem igazán fognak elterjedni, sőt, sokan vissza fognak állni HTML-re. A W3C berkeiben a világháló atyjának tekintett Tim Berners-Lee értő felügyelete mellett készül a HTML számos érdekes újítást rejtő 5.0-s változata; az első vázlat január végén került nyilvánosságra.
A jó hír az, hogy az egész XML-mizéria ránk egyáltalán nem vonatkozik. Ahhoz ugyanis, hogy megmondhassuk a böngészőnek, hogy XML-ként értelmezze oldalunkat, vagy rendszergazdának kell lennünk, aki hozzáfér a webkiszolgáló beállításaihoz, vagy programozónak. Ez a „veszély” nyilván nem fenyegeti olvasóink 99 százalékát, tehát megnyugodhatunk: a saját szórakozásunkra összerakott oldalakat mindig HTML-ként fogja értelmezni a böngésző.
A tanulság pedig az, hogy teljesen mindegy, mit használunk weboldalaink készítéséhez, legyen az akár HTML, akár XHTML, tartsuk be a nyelv szabályait. Pont.
