html5 - az új szabvány

Mark Pilgrim

HTML 5 AZ ÚJ SZABVÁNY

Ugorjunk fejest a webfejlesztés jövőjébe!

A kiadvány a következő angol eredeti alapján készült: Dive Into HTMLS

Copyright© 2011 by Mark Pilgrim. Some rights reserved! ©Kiskapu Kft. 2011

A kiadás a Creative Commons engedélyével készült a CC-BY-3.0 változat alapján.

Fordítás és magyar változat© 2011 Kiskapu Kft. Kapcsolódó jogok fenntartva! A kiadó a lehető legnagyobb körültekintéssel járt el e kiadvány elkészítésekor. A kiadó nem vállal semminemű felelősséget vagy garanciát a könyv tartalmával, teljességével kapcsolatban. A kiadó nem vonható felelősségre bármilyen baleset vagy káresemény miatt, mely közvetve vagy közvetlenül kapcsolatba hozható e kiadvánnyal.

Fordítás és lektorálás: Rézműves László

Műszaki szerkesztő: Tóth Klára

Tördelés: Tóth Klára

Felelős kiadó a Kiskapu Kft. ügyvezető igazgatója © 2011 Kiskapu Kft. 1134 Budapest, Csángó u. 8.;

Fax: (+36-l) 303-1619;

http://www.kiskapukiado.hu/; e-mail: [email protected]

ISBN: 978 963 9637 77 l

Nyomdai előállítás: Radin Group Felelős vezető: Antun Basic Kereskedelmi képviselet: Kvadrát '97 Kft.

Tel./Fax: +361 319 1599. Mobil: +36 302806656 E-mail:[email protected]

Tartalom

Előszó . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1. fejezet- Hogyan jutottunk el idáig?

Ugorjunk fejest! . . . . . . . MIME-típusok. . . . . . . . Hosszú kitérő a szabványok születéséről Töreden fejlődés . . . . . . . . . A HTML fejlődésének története 1997 és 2004 között . Minden, amit az XHTML-ről tudunk, téves Egy versenyképes látomás. Milyen munkacsoport?. Vissza a W 3C-hez. . Utószó . . . . . .

További olvasmányok

2. fejezet - A HTML5-képességek észlelése

Ugorjunk fejest! . . . . . . . . . Észlelési módszerek . . . . . . . . Modernizr: egy HTML5-észlelő könyvtár A rajzvászon . . . . . Rajzvászonra Írt szöveg. Videó . . . . . . . Videoformátumok Kérdezzük meg Leírókód professzort! Helyi tárolás. . . . . . . . . . Webmunkások . . . . . . . . . Kapcsolat nélküli webalkalmazások. Helymeghatározás Bevitelielem-típusok. . . Helyőrző szöveg . . . . Automatikus űrlapfókusz . Mikroadatok. . . .

További olvasmányok . .

13 13 14

. 23

. 25

. 26 . 28 . 30 . 32 . 33 . 34

. 35

. 35

. 36

. 37

. 38

. 40

. 41

. 44

. 44 . 45 . 46 . 48 . 49

51 . 52 . 53 . 54

3. fejezet- Mit jelent mindez?

Ugorjunk fejest! . . . 57 A dokumentumtípus. . 57 A gyökérelem . . 60 A <head> elem . . . . 61 Karakterkódolás . . . 62 Viszonyleíró elemek . . 64 Egyéb viszonyleíró elemek a HTML5-ben . 67 Új jelentéstükröző elemek a HTML5-ben . 71 Hosszú kitérő arról, hogy miként kezelik a böngészők

az ismereden elemeket. . 73 Címsorok . . . . . . . 77 Cikkek . . . . . . . . 80 Dátumok és időpontok. . 83 Navigáció . . . . . . 85 Láblécek . . . . . . 87 További olvasmányok . 90

4. fejezet- A rajzvászon ördöge (ne fessük a falra!)

Ugorjunk fejest! . . . . 93 Egyszerű alakzatok . . . 94 Rajzvászon-koordináták . 96 Útvonalak. . . 98 Szöveg . . . 101 Színátmenetek 105 Képek . . . 109 Mi a helyzet az Internet Explorerrel? 113 Egy teljes példa. . . 115 További olvasmányok 120

5. fejezet - Videó a Weben

Ugorjunk fejest! 121 Videorárolók. 122 Videokodekek 123 H.264 125 Theora . . . 126 VP8 . . . . 126 Audiokodekek 127 MPEG-1 Audio Layer 3 129 Advanced Audio Coding . 130 Yorbis . . . . . . . . 130 Ami a Weben működik . 131 A H.264-videók felhasználási engedélyével kapcsolatos kérdések. 134

Ogg-videók kódolása a Firefogg segítségéveL . . . . . . 136 Ogg-videók kötegelt kódolása az ffmpeg2theora segítségével 143 H.264-videók kódolása a HandBrake segítségével . . . . 145 H.264-videók kötegelt kódolása a HandBrake segítségével . .153 WebM-videók kódolása az ffmpeg segítségéve!. 154 És végül, a leírókód! . . . . . . . . 157 A MIME-típusok beleköpnek a levesbe 161 Mi a helyzet az Internet Explorerrel? 163 Egy teljes példa . . . !64 További olvasmányok . . . . . . 165

6. fejezet- Itt áll ön (és mindenki más)

Ugorjunk fejest! . 167 A Geolocation API 167 Mutasd a kódot! . 168 A hibák kezelése . 171 Választást! Szabad választást! 172 Mi a helyzet az Internet Explorerrel? 175 A felmentő sereg: geo.js. 176 Egy teljes példa . . . 178 További olvasmányok . 179

7. fejezet- A helyi tárolás múltja, jelene és jövője a webalkalmazásokban

Ugorjunk fejest! . . . . . . . . . . . . . . . . . . . . . 181 A helyi tárolásra a HTML5 előtt alkalmazott

trükkök rövid története . . 182 Bemutatkozik a HTML5-tároló . . . . . 183 A HTML5-tároló használata . . . . . . 185 A HTML5-tárolóterület változásainak nyomon követése. 186 A jelenleg használt böngészők korlátai . . . . . 188 A HTML-tároló működés közben . . . . . . 188 A kulcs-érték párokon túl: versengő elképzelések 191 További olvasmányok . . . . . . . . . . . 193

8. fejezet- Bontsuk a kapcsolatot!

Ugorjunk fejest! . 195 A gyorstárjegyzék. 196 Hálózati szakaszok 198 Tartalék szakaszok 199 Az eseményfolyam 201 A hibakeresés művészete, avagy "Ölj meg! Ölj meg itt és most!" 203 Építsünk egyet!. . . 206 További olvasmányok . . . . . . . . . . . . . . . . 207

9. fejezet- Örültűrlapok Ugorjunk fejest! . . . . . . Helyőrző szöveg . . . . . . Automatikus fókuszálású mezők E-mail címek . . . . .

Webcímek . . . . . . . Számok léptetőmezőkben . Számok csúszkákon Dátumválasztók Keresőmezők . . Színválasztók . . És még egy dolog ... További olvasmányok

1 O. fejezet- .,Elosztott", .,bővíthetőség" és más divatos szavak Ugorjunk fejest! . . . . .

Mik azok a mikroadatok? . .

A mikroadarok adatmodellje. Személyek felcímkézése. . .

Bemutatkozik a Google Rich Snippets . Szervezetek felcímkézése . . . .

Események felcímkézése . . . . A Google Rich Snippets visszatér . Kritikák felcímkézése További olvasmányok

Függelék A "mindent egyben tartalmazó

és majdnem ábécésorrendbe rendezett" útmutató, amelyet követve bármit észlelhetünk

Az elemek listája . . További olvasmányok

209

209

211

213

.215

217

220

221

224

226

226

228

229

230

232

236

243

246

251

257

259

263

265

265

271

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. 273

Előszó

Mi a HTMLS? A HTMLS a HTML következő nemzedéke, amely a HTML 4.01, az XHTML 1.0 és az XHTML 1.1 felváltására hivatott. A HTMLS olyan új szolgáltatásokat kínál, amelyek elengedhetetlenek a modern webalkalmazásokban, ezen kívül szabványossá teszi a webes felület számos olyan lehetőségét, amelyeket a webfejlesztök már évek óta használnak, de a szabványügyi bizottságok eddig még nem foglaltak írásba. (Meglepődnénk, ha megtudnánk például, hogy a Window objektumot még soha nem írták le hivatalosan? A HTMLS tesz először kísérletet arra, hogy formális leírást adjon sok-sok "de facto" szabványról, amelyeket a webböngészők már jó ideje támogatnak.)

Elődeihez hasonlóan a HTML5-öt is úgy tervezték, hogy rendszerfüggeden legyen. Ahhoz, hogy kihasználhassuk a HTMLS előnyeit, nem követelmény, hogy Windows, Mac OS X, Linux, Multics vagy bármilyen más konkrét operációs rendszert futassunk, csupán egy modern webböngészőre van szükségünk (de arra feltétlenül). Modern webböngészők ingyenesen elérhetők minden fontosabb operációs rendszerhez. Az Apple Safari, a Google Chrome, a Mozilla Firefox vagy az Opera legújabb változatai kivétel nélkül támogatják a HTMLS számos szolgáltatását. (A könyvben a böngészők megfelelőségéről részletesebb táblázatokkal is találkozni fogunk.) Az iPhone, iPad és Android mobilkészülékekre előre telepített mobil webböngészők mind kitűnő támogatást nyújtanak a HTMLS-höz. Még a Microsoft is bejelentette, hogy az Internet Explorer közelgő 9-es változata is ismerni fogja a HTMLS számos elemér.

Ebben a könyvben nyolc témakörrel foglalkozunk: • Új nyelvi elemek, például a <header>, a <footer> vagy a <section>

(3. fejezet) • A rajzvászon-az a kétdimenziós rajzfelület, amelyet JavaScript segítségé

vel programozhatunk (4. fejezet)

Előszó l 9

• A weboldalakba külső bővítmények segítsége nélkül beágyazható videók (5. fejezet)

• Helymeghatározás- hogyan oszthatják meg a weboldalak látogatói a tartózkodási helyüket a webalkalmazásokkal (6. fejezet)

• Tartós helyi tárolás külső bővítmények segítsége nélkül (7. fejezet) • Kapcsolat nélküli webalkalmazások, amelyek a hálózati kapcsolat meg

szakadása után is képesek működni (8. fejezet)

• A HTML továbbfejlesztett webes űrlapjai (9. fejezet) • Mikroadatok, amelyek lehetövé teszik, hogy a HTML5-be beépített szó

tárakon túl saját szótárakat hozzunk létre, és egyéni értékekkel lássuk el

a weboldalainkat (10. fejezet)

A HTML5-öt úgy tervezték, hogy amennyire lehetséges, visszamenőlegesen képes legyen együttműködni a meglevő webböngészőkkeL Az új szolgáltatások a már meglevökre épülnek, és megengedik, hogy helyettesítő tartalmat biztosítsunk a régebbi böngészőknek Ha pedig még jobban kézben szeretnénk tartani a weboldalaink működését, néhány sornyi JavaScript-kóddal kideríthetjük, hogy egy adott böngésző támogatja-e a HTML5 szükséges szolgáltatásait (2. fejezet). Ne a törékeny "böngészőszimatoló" kódokra támaszkodjunk annak meghatározásában, hogy mely böngészők támogatják a HTML5-öt:

a vizsgálatot végezzük el magának a HTML5-nek a segítségéve!!

A könyvben használt jelölések

A könyv tipográfiai jelölései a következők:

Dőlt betű

Az új fogalmakat, az URL-eket, az elektronikus levélcímeket, a fájlneveket és a fájlkiterjesztéseket dőlt betűvel írtuk.

Állandó szélességű betű (írógépbetű) Ezt a betűstílust használtuk a programkódokhoz, valamint ami-kor a törzsszövegen belül olyan programelemekre hivatkoztunk, mint

a változó- és függvénynevek, az adatbázisok, az adattípusok, a kör

nyezeti változók, az utasítások és a kulcsszavak.

10 l Előszó

Félkövér, állandó szélességű betű Ez a stílus azokat a parancsokat és más elemeket jelöli, amelyeket pontosan a megadott módon kell beírni.

Dőlt, állandó szélességű betű

Azokat az elemeket szedtük így, amelyeknek a helyére a megfelelő

- a felhasználó által megadott vagy a környezet által meghatározott

értékeknek kell kerülniük

Ez az ikon jelzi a tippeket, javaslatokat vagy általános megjegyzéseket.

Ha egy webcím vagy egy programutasítás nem fért el egy sorban, így je

löltük, hogy folytatólagosan írandó:

return ! ! (v. canPlayType && v. canPlayType (' video/ogg; codecs= "theora '" ) . � replace (/no/, ' ' ) ) ;

Megjegyzés a könyv különböző változatairól

A könyv eredeti kiadásának nyomtatott változatát a szerző által karbantartott

HTML5-forrásból készítették, amelyet a http://diveintohtml5.orgl címen

érhetünk el. Ha a nyomtatott változatot olvassuk, és kíváncsiak vagyunk

a többi hivatkozásra is, tekintsük meg az eredeti forrást. Mivel a szerző a http://diveintohtml5.org/ oldalt HTML5 nyelven tartja fenn, a könyvben

szereplő példakódok az oldalon működő változatban találhatók - sokat közülük némileg módosítani kellett a közzétételhez. Ha látni szecetnénk ezeket

a példákat, látogassunk el a http://diveintohtml5.orgl címre, de vegyük figyelembe, hogy az egyes böngészőkben nem biztos, hogy egyfon;nán működnek.

1. fejezet

Hogyan jutottunk el idáig?

Ugorjunk fejest!

Nemrég rábukkantam a Mozilla egyik fejlesztőjének írására, aki a szabványok

megalkotásának eredendő nehézségéről értekezett (http:!llists. w 3. orgiArchívesi Public/public-html/201 O jan/O l 01 h tm l}:

A megvalósírások és a szabványleírások bonyolult táncot lejtenek egy

más körüL Nem akarjuk, hogy a megvalósírások elkészüljenek, mielőtt

a szabványt véglegesítenék, mert a felhasznáJók ezeknek a megvalósítá

soknak a részleteitől kezdenek majd függni, és ez korlátozná a szabványt.

Ugyanakkor azt sem akarjuk, hogy a szabványleírás kész legyen, mielőtt

megszületne néhány megvalósítás, és a programozók kipróbálták volna

azokat, mert a szabványhoz szükség van visszajelzésre. Ez óhatatlanul

feszültséghez vezet, amivel viszont meg kell tanulnunk együtt élni.

Tartsuk észben a fenti idézetet, miközben elmesélem, hogyan is született meg

a HTML5.

MIME-típusok

Ez a könyv a HTML5-ről szól, nem a HTML korábbi változatairól, és nem is

az XHTML bármelyik változatáról. Ahhoz azonban, hogy megérthessük

a HTML5 történetét és megalkotásának mozgatórugóit, tisztában kell lennünk

néhány technikai részlettel- egészen pontosan a MIME-típusok mibenlétével.

Minden alkalommal, amikor a webböngészőnk egy oldalt kér, a webki

szolgáló először néhány fejlécet küld neki, mielőtt átadná az oldal tényleges

l. fejezet Hogyan jutottunk el idáig? l 13

jelölőnyelvi kódját. Ezek a fejlécek alapesetben láthatók, bár több webfejlesztő eszköz is létezik, amelyekkel láthatatlanná tehetjük őket, amennyiben erre lenne szükségünk. A fejlécek lényegesek, mert ezek árulják el a böngészőnek, hogy miként kell értelmeznie az utánuk következő oldalleíró kódot. A legfontosabb fejléc neve Content-Type, és így néz ki:

Content-Type: text/html

A text/html az oldal "tartalomtípusa" (content type) vagy "MIMEtípusa". Ez a fejléc az egyeden dolog, ami meghatározza, hogy valójában milyen forrásanyagról van szó, és ebből következően hogyan kell megjeleníteni. A képeknek saját MIME-típusuk van (a JPEG-képek esetében ez az image/

jpeg, a PNG-képeknél az image/png, és így tovább), és a JavaScript-fájlok is saját MIME-típussal rendelkeznek, akárcsak a CSS-stíluslapok. Mindennek megvan a maga MIME-típusa- a W ebet a MIME-típusok működtetik.

A valóság persze bonyolultabb ennél. A nagyon régi webkiszolgálók (és itt most 1993-ra gondolok) nem küldték el a Content-Type fejlécet, mert az akkor még nem is létezett (csak 1994-ben találták fel). Az egészen 1993-ig visszanyúló megfelelőség érdekében egyes népszerű webböngészők bizonyos körűlmények között figyelmen kívül hagyják a Content-Type fejlécet. (Ezt hívják "tartalomszimatolásnak ", angolul "content sniffing"-nek.) Általános alapszabályként azonban elfogadhatjuk, hogy minden, amivel csak találkozunk a Weben- HTML-oldalak, képek, parancsfájlok, videók, PDF-ek vagy bármi, aminek van URL-je - egy a Content-Type fejlécben megadott konkrét MIME-típus szerint jut el hozzánk a kiszolgálótól.

Ezt tűzzük a kalapunkra, mert még visszatérünk rá.

Hosszú kitérő a szabványok születéséről

Miért létezik az <img> elem? Nem hiszem, hogy ezt a kérdést gyakran teszszük fel magunknak. Valaki bizonyára megalkotta- ilyesmik nem pattannak elő csak úgy a semmiből. Ez minden elemre, minden jellemzőre és minden HTML-szolgáltatásra érvényes, amit valaha csak használtunk: valakik létrehozták őket, eldöntötték, hogyan működjenek, aztán leírták ezt az egészet. Az alkotók nem istenek, csupán egyszerű halandók, így nem is hibátlanok. Persze okos emberek, de csak emberek.

14 l Hogyan jutottunk el idáig? l. fejezet

A "nyílt terepen" fejlesztett szabványokban az az egyik legjobb, hogy viszszarnehetünk az időben, és megválaszolhatjuk az ilyen kérdéseket. A vita levelezőlistákon zajlik, amelyeken az üzeneteket általában archiválják, és nyil

vánosan kereshetövé teszik. Ezért aztán úgy döntöttem, hogy végzek egy kis

"email-ásatást", hogy rábukkanjak az <img> elem eredetére. Olyan régre kellett visszamennem, amikor a World Wide Web Consortium (W3C) nevű szervezet még nem is létezett: a Web kezdeteihez, amikor a két kezünk ujjain

megszámolhattuk az összes webkiszolgálót (na jó, talán néhány lábujjat is igénybe kellett vennünk).

1993. február 25-én Marc Andreessen ezt írta:*

Szeretnék javasolni egy új, nem kötelező HTML-címkét: IMG Kötelező argumentuma: SRC= "ur 1 ".

Egy bitképes vagy pixelképes fájlt nevezne meg, amelyet a böngésző a hálózaton keresztül megkísérelhet letölteni és képként értelmezni, majd beszúrni a szövegbe ott, ahol a címke szerepel. Példa:

<IMG SRC= "file: l /foobar. com/foo/bar/blargh. xbm ">

(Záró címke nincs; az IMG önálló címke lenne.) Ezt a címkét ugyanúgy be lehetne ágyazni egy horgonyba, mint bármi mást. Ilyenkor egy ikon válna belőle, amelyet ugyanúgy aktiváini lehetne, mint egy szokványos szöveghorgonyt. A böngészők rugalmasak lehetnek abban, hogy mely képformátumokat támogatják- az Xbm és az Xpm például jó választás. Ha egy böngésző nem tudja értelmezni az adott formátumot, tetszés szerint járhat el. (Az

X Mosaic egy alapértelmezett bitképet jelenít meg helyőrzőként.) Az X Mosaicban ez beépített képesség. Nálunk működik, és legalábbis belső használatra igénybe fogjuk venni. Természetesen nyitott vagyok minden javasia tra, hogy mikém kezelhetnénk ezt a címkét a HTML-ben. Ha valakinek jobb ötlete van, mint amit én az imént bemutat tam, kérem,

* hrtp:lll997.webhisrory. org/www.lisrsiwww-ralk.1993ql/0182.hrml. A következő néhány oldalon leírt Üzenetválrás a "Nexr message" (Következő üzener) és "Previous message" {Előző üzenet) hivatkozásokra kaninrva köverherő.

1. fejezet Hogyan jutottunk el idáig? l 15

tudassa velem. Tudom, hogy a képformátum szempontjából ködös megoldás, de egyelőre nem tudok jobbat annál, mint hogy egyszerűen azt mondjuk, hogy "csinálja a böngésző azt, amire képes", és várunk, hogy megszülessen a tökéletes megoldás (egy nap talán a MIME).

Ez az idézet némi magyarázatra szorul. Először is, az Xbm és az Xpm a Unix rendszerek népszerű grafikus formátumai voltak akkoriban, a Mosaic pedig az egyik legrégebbi webböngésző. (Az X Mosaic ennek volt a Unix rendszereken futó változata.) Amikor Marc ezt az üzenetet írta 1993 elején, még nem alapította meg azt a vállalatot, a Mosaic Communications Corporationt, amely híressé tette, és még nem kezdett el dolgozni a vállalat legfőbb termékén, a Mosaic Netscape-en. (A vállalat és a program későbbi nevei talán ismerősebbek: a Netscape Corporation-ről és a Netscape Navigatorról van szó.)

Az "egy nap talán a MIME" a tartalomegyeztetésre utal: a HTTP-nek arra a szolgáltatására, amelynek az a lényege, hogy az ügyfél (például egy webböngésző) elárulja a kiszolgálónak (például egy webkiszolgálónak), hogy milyen típusú "erőforrásokat" támogat (például az image/jpeg típusú képeket), hogy a kiszolgáló az ügyfél által előnyben részesített formátumban adhasson vissza valamit. "Az eredeti HTTP, ahogy 1991-ben leínák" (1993 februárjában ez volt az egyetlen megvalósított változat) nem adott módot az ügyfélnek arra, hogy közölje a kiszolgálókkal, hogy milyen fajta képeket támogat - ez okozott fejtörést Marcnak a tervezés során. Néhány órával később Tony Johnson válaszolt:

Nekem van valamim a Midas 2.0-ban, ami nagyon hasonló (itt, az SLAC-n már használjuk, és elvileg heteken belül sor kerül a nyilvános közzétételre is), csak az elnevezése más, és van még egy argumentuma, a NAME="név". Majdnem pontosan úgy működik, mint a javasolt IMG

címke. Itt egy példa:

<ICON name= "NoEntry" href= "http: //note/foo/bar/NoEntry .xbm ">

A name paramétert azért találtuk ki, mert így a böngésző rendelkezhet egy "beépített" képkészletteL Ha a megadott név megegyezik egy "beépített" képével, a böngésző ezt a beépített képet használhatja, és nem kell lekérnie a képet. A név ezen kívül a "szöveges" böngészőknek is segít, hogy tudják, milyen jelet kell helyőrzőként betenniük a kép helyére.

16 l Hogyan jutottunk el idáig? 1. fejezet

Nekem nem számítanak különösebben a paraméter- vagy címkenevek, de ésszerű lenne ugyanazokat az elnevezéseket használni. A rövidítéseket nem szecetern- miért ne lehetne például IMAGE= és SOURCE=? Az ICON-t azért részesíteném előnyben, mert utal arra, hogy az IMAGE-nek kicsinek kell lennie - vagy már túl sok dolgot akarunk rátukmálni az ICON-ra?

AMidas szintén a korai webböngészők egyike- az X Mosaic kortársa- volt. Rendszerfüggetlen böngészőkém Unix és VMS rendszeren egyaránt futott. Az

"SLAC" a Stanford Linear Accelerator Center-re utal (ma SLAC National

Accelerator Laboratory-nak hívják), ahol az Egyesült Államok első webkiszolgálóját (Európán kívül a legelső webkiszolgálót) üzemeltették. Amikor Tony a fenti üzenetet írta, az SLAC már régi rootorosnak számított a WWW

területén, mivel öt oldalt működtetett a webkiszolgálóján, méghozzá példátlanul hosszú ideig- 441 napig.

Tony így folytatta:

H a már új címkékről esik szó, van egy másik, némileg hasonló címkém, amit támogatni szecetnék aMidas 2.0-ban. Elvileg így néz ki:

<INCLUDE HREF= " ... ">

A célja az lenne, hogy egy második dokumentumot lehessen beágyazni az első be ott, ahol a címke szerepel. A hivatkozott dokumentum elvileg bármi lehet, de elsősorban képeket szecetnék beágyazni (ez esetben tetszőleges méretben) szöveges dokumentumokba. Amikor aztán megérkezik a HTTP2, a beágyazott dokumentum formárumát külön meg lehetne vitatni.

A "HTTP2" a Basic HTTP 1992-es változatára utal, amit ekkor - 1993

elején- még nagyrészt nem valósítottak meg. A "HTTP2"-ként isrne.llt vázlatot aztán továbbfejlesztették, és végül

"HTTP 1.0" néven vált belőle szab

vány. A HTTP 1.0-ba valóban belefoglalták a tattalomegyeztetésre szolgáló kérelemfejléceket, vagyis eljött "a MIME napja".

T o ny ugyanakkor még tovább ment:

Egy másik megoldás, amin töprengtem, ez volt:

<A HREF= • ... " INCLUDE>See photo</A>


Nem igazán szeretnék további feladatokat róni az <A> címkére, de így meg lehetne őrizni az együttműködést az INCLUDE paramétert figyelembe venni nem képes böngészőkkeL A cél az lenne, hogy az INCLUDE-ot értő böngészők a horgonyszöveget (ami itt a See photo - Lásd a képet) a beágyazott dokumemumea (képre) cseréljék, míg a régebbi vagy butább böngészők teljesen figyelmen kívül hagyják az INCLUDE címkét.

Ezt a javaslatot soha nem valósították meg, bár az az ötlet, hogy a böngésző szöveget jelenítsen meg a hiányzó képek helyén, igen fontosnak bizonyult az akadálymemesítés szempomjából, és ezt a megoldást Marc eredeti javaslata az <IMG> címkére nem tartalmazta. Évekkel később ebből lett az <img

alt> jellemző, amelyet a Netscape rögtön el is szúrt, mert tévesen súgószövegkém kezelte.

Néhány órával azt követően, hogy Tony közzétette a levelét, Tim BernersLee válaszolt rá:

Én úgy képzeltem, hogy az ábrákat így írnánk le:

<a name=figl href= "fghj kdfghj • REL= "EMBED, PRESENT ''>Ábra </a>

A fenti viszonyértékek jelentése pedig ez lenne:

EMBE D

PRESENT Eztágyazd be ide, am ikor m egjeleníted Jelenítsct meg a forrásdokumentum megjelenítésekor

Észrevehető, hogy a fentieknek különböző kombinációi lehetnek, és akkor sincs gond, ha a böngésző nem támogatja valamelyiket. Belátom ugyanakkor, hogy a kiválasztható ikonok megvalósításának ez a módszere horgonyok beágyazását jelentené-hmmm ... -de nem akartam külön címkét erre a célra.

Ezt a javaslatot sem valósították meg, de a rel jellemző még ma is létezik (lásd a "Viszonyleíró elemek" című részt a 3. fejezetben).

Jim Davis a következőket f űzte hozzá a témához:

Klassz lenne, ha lenne rá valamilyen mód, hogy megadjuk a tartalom típusát. Például: <IMGHREF="http://nsa.gov/pub /sounds/gorby.au"CONTENT-TYPE=audio/basic>


Persze én teljesen jól elvagyok azzal a követelménnyel, hogy a tartalomtípust a fájlkiterjesztés határozza meg.

Ezt a javaslatot sem valósították meg, de a Netscape később beépítette a tetszőleges médiaobjektumok beágyazásának lehetőségét az <embe d> elemmel.

Jay C. Webber ezt a kérdést tette fel:

A képek nálam az első helyen állnak a WWW-böngészőkben támogatandó médiatípusok kívánságlistáján, de nem gondolom, hogy külön horgokat kellene megadnunk minden egyes kép beágyazásakor. Hová lett a MIME-típusok iránt érzett lelkesedés?

Marc Andreessen ezt válaszolta:

Ez nem helyettesítené a jövőbeli MIME-ot, mint szabványos dokumentumleíró módszert, csupán egyszerű megvalósitását nyújtaná egy a MIME-tól függetlenül szükséges szolgáltatásnak.

Jay C. Webber erre ezt írta vissza:

Akkor egy időre feledkezzünk meg a MIME-ról, ha elfedi a lényeget. Én azt kifogásoltam, hogy azon töprengünk, hogy "miként támogassuk a képek beágyazását", ahelyett, hogy arról beszélnénk, hogy "miként támogathatnánk a különféle hordozókba beágyazott objektumokat". Ha ebben az irányban tapogatózunk, a jövő héten valaki majd azzal áll elő, hogy vegyünk fel egy <AUD SRC=">file://foobar.com/foo/bar/

blargh. snd "> alakú új címkét a hangfájlok számára. Szeriotem jobb lenne valamilyen általánosabb megoldást alkalmazni.

Visszatekintve úgy tűnik, hogy Jay teljesen jogosan aggódott. Valamivel tovább tartott egy hétnél, de a HTMLS végül csak bevezetett új <video> és <audio> elemeket.

J a y eredeti üzenetére válaszolva Dave Ragget t a következőket Írta:

Milyen igaz! Én is sok-sok kép- és vonalrajztípust szeretnék használni, és lehetőséget szeretnék a formátum egyeztetésére. Ezen felül Tim


megjegyzése a képeken belüli kattintható területek támogatásáról ugyan

csak fontos. 1993 folyamán később Dave felvetette a HTML+, mint a HTML-szabvány

továbbfejlesztése ötletét. A javaslatát soha nem valósították meg, végül pedig

túllépett rajta a HTML 2.0. A HTML 2.0 "retrospektív szabványnak" ké

szült, vagyis olyan szolgáltatásokat szabványosított, amelyeket már régóta

széles körben használtak. "Ez a szabvány azokat a lehetőségeket gyűjti össze,

tisztázza és írja le formálisan, amelyek nagyjából megfelelnek a HTML 1994

júniusa előtt általánosan használt szolgáltásainak."

Dave később a HTML+ régi vázlata alapján megírta a HTML 3.0-t, de

a W3C saját referencia-megvalósításától, azArenától eltekintve ezt sem való

sították meg. A helyébe a szintén "retrospektív szabvány" HTML 3.2 lépett:

"A HTML 3.2 széles körben használt elemekkel- táblázatokkal, kisalkalma

zásokkal és képek köré folyatott szöveggel - bővíti a nyelvet, miközben teljes

körű visszamenőleges együttműködést biztosít a meglevő HTML 2.0 szabvánnyal."

Dave később társszerzőként közreműködött a HTML 4.0 elkészítésében,

megalkotta a HTML Tidy-t, és segített az XHTML, az XForms, a MathML

és más újabb W3C-szabványok kidolgozásában.

De térjünk vissza 1993-hoz. Marc ezt felelte Dave-nek:

Tulajdonképpen lehet, hogy egy általános célú, eljárásközpontú grafikai

nyelvet kellene kidolgoznunk, amelyen belül lehetőség lenne tetszőleges,

ikonokra, képekre, szövegre vagy bármi másra mutató hi perhivatkozások

beágyazására. Ismeri más is az Intermedia ilyen irányú képességeit?

Az Intermedia a Brown Egyetem hiperszöveges programja volt, amelyet

1985-től 1991-ig fejlesztettek, és azA/UX-en, a korai Macintosh-számítógépek

Unix-szerű operációs rendszerén futott. Az "általános célú, eljárásközpontú grafikai nyelv" ötlete végül teret is

nyert. A mai böngészők mind az SVG-t (deklaratÍv leírókód beágyazott pa

rancsokkal), mind a <canvas>-t (eljárásközpontú, közvetlen módú grafikai

API) támogatják, bár az utóbbi magánfejlesztésű bővítményként kezdte a pá

lyafutását, mielőtt a WHAT munkacsoport "retrospektív szabványosítással"

hivatalossá tette volna.

Bill Janssen az alábbiakat válaszolta:


Vannak más figyelemre méltó rendszerek is, amelyek rendelkeznek az

említett ( meglehetősen hasznos) képességekkel: az Andrew és a Slate. Az

Andrew-t úgynevezett "betét"-ek (inset-ek) építik fel, amelyeknek kü

lönböző érdekes típusai vannak: szöveg, bitkép, rajz, animáció, üzenet,

táblázat, és így tovább. Az Andrew-ban adott a tetszőleges szimű be

ágyazás lehetősége, vagyis bármilyen betét beágyazható bármilyen más

betétbe, amely támogatja a beágyazást. Egy betét például beágyazható

egy szövegvezérlő szövegének bármely pontján, vagy egy rajzvezérlő tet

szőleges téglalap alakú területébe, vagy egy táblázat bármely cellájába.

Az "Andrew" az Andrew User Interface System-re utal, bár akkor még csak

egyszerűen Andrew Project-kém ismerték.

Közben Thomas Fine egy másik ötlettel állt elő:

Az én véleményem a következő. A WWW-ben a képek beágyazására a legjobb megoldás a MIME használata. Biztos vagyok benne, hogy a

pastscript már támogatott altípus a MIME-ban, és a pastscript nagyon

ügyesen kezeli a képekkel kevert szövegeket.

Csak éppen nem kattimható, ugye? Igen, így igaz- de gyanítom, hogy

erre már van megoldás a display postscriptben. De még ha nincs is,

a szabványos pastscript könnyen bővíthető vele. Csak meg kell hatá

rozni egy horgonyparancsot, amely megadja az URL-t, és az aktuális

elérési utat a gomb zárt területekém használja. Mivel a pastscript na

gyon jól kezeli az elérési utakat, tetszőleges gombalakot lehet létrehozni

pofonegyszerűen.

A Display Postscript egy képernyős megjelenítési technológia volt, amelyet

közösen fejlesztett ki az Adobe és a NeXT.

Ezt a javaslatot sem valósították meg, de az ötlet, miszerint a HTML hibáit úgy lehet a legjobban kijavítani, hogy valami teljesen másra cseréljük, ma

is időről időre felbukkan.

1993. március 2-án Tim Berners-Lee az alábbi megjegyzést fűzte a témához:

A HTTP2 bármilyen típusú adatot megenged egy dokumentumban, amelyről a felhasználó azt állítja, hogy képes kezelni, nem csak a

bejegyzett MIME-típusokat. Tehát kísérletezhetünk. Azt hiszem, lenne


létjogosultsága a hiperszöveges postscriptnek, azt viszont nem tudom, hogy a display postscript elég érvet tud-e felsorakoztatni mellette. Azt

tudom, hogy az Adobe fejleszti a saját, postscript alapú "PDF"-jét, amelyben hivatkozások is lesznek, és az Adobe saját megjelenítőprog

ramjaival lehet majd olvasni. Arra gondoltam, hogy ha a horgonyokhoz lenne egy általános (HyTime

alap ú?) "ráfektető" nyelv, akkor a hi perszöveges és a grafika- vagy vicleoszabványok egymástól függetlenül fejlődhetnének, ami mindkettőn segítene.

Legyen az IMG címke INCLUDE, és mutasson tetszőleges dokumentumtÍpusra. Vagy legyen EMBED, ha az INCLUDE úgy hangzana, mintha cppbeágyazásról lenne szó, amitől az ember azt várja, hogy SGML-forrás

kódot ad, amit helyben kell feldolgozni - márpedig nem ez a cél.

A HyTime egy korai, SGML alapú hiperszöveges dokumentumrendszer volt,

és az árnyéka kezdetben jócskán ráverült a HTML-lel és később az XML-lel kapcsolatos eszmecserékre.

Timnek az <INCLUDE> címkére vonatkozó javaslatát soha nem valósították meg, bár az öröksége tetten érhető az <object>, az <embed> és az

<iframe> elemben. Végüll993. március 12-én Marc Andreessen is visszatért az üzenetszálhoz:

Ismét a beágyazott képekről: egyre közelebb kerülök a Mosaic vO.lO

kiadásához, amely - ahogy korábban említettem - támogaeni fogja a beágyazott GIF és XBM képeket/bitképeket. [ ... ] Jelenleg nem állunk készen az INCLUDE!EMBED támogatására, [ ... ] ezért

valószínűleg az <IMG SRC="url"> változatnál maradunk (nem az ICON

mellett döntöttünk, mert nem minden beágyazott képre igaz, hogy ikon

lenne). A beágyazott képek egyelőre nem kapnak kifejezetten tartalom

tÍpust, de később ezt is támogatn i tervezzük (a MIME általános megva

lósításával együtt). A képolvasó eljárások, amelyeket jelenleg használunk, valójában mener közben képesek felismerni a kép formátumát, ezért a fájlnév-kiterjesztésnek nem is lesz jelentősége.


Töretlen fejlődés

Engem minden szempontból lenyűgöz ez a 17 éves eszmecsere, amely végül egy olyan HTML-elem megalkotásához vezetett, amelyet szinte minden valaha létrehozott weboldalon felhasználtak. Gondoljuk csak végig:

• A HTTP még mindig létezik. Sikeresen eljutott a 0.9-estől az 1.0-s, majd később az 1.1-es változatig, és még mindig fejlődik (http:llwww.ieif.org/ dynlwglcharterlhttpbis-charter. h tm l}.

• A HTML még mindig létezik. Ez a kezdetleges adatformárum (még a szövegbe ágyazott képeket sem támogatta!) sikeresen elérte a 2.0, 3.2 és 4.0 változatszámoL A HTML fejlődésének vonala töretlen. Kanyargós, itt-ott csomókkal és vadhajtásokkal tarkított - evolúciós fája jócskán tartalmaz "halott ágakat", vagyis olyan helyeket, ahol a szabványok megszállottjai önmagukat (és persze a programozókat) is megelőzték -, de akkor is töretlen, és ma, 2010-ben az 1990-ből származó weboldalak még mindig megjeleníthetők a mai böngészőkben. Épp az imént töltörtem be egyet simán a csúcstechnikás Android mobiltelefonom böngészőjébe, és még olyan üzenetet sem kaptam, hogy "kérem, várjon, amíg a böngésző feldolgozza a régi formátumot ... ".

• A HTML mindig is népszerű társalgási téma volt a böngészőkészírők, a szakkönyvírók, a szabványokkal foglalkozók és más emberek körében, akik bármikor szívesen cserélnek eszmét a csúcsos zárójelekrőL A HTML legsikeresebb változatai "retrospektív" szabványok voltak, amelyek egyszerre igyekeztek lépést tartani a világgal és a helyes irányba terelni azt. Azok, akik azt mondják, hogy a HTML-nek "tisztának" kellene maradnia (feltehetően a böngészőgyártók, a programozók vagy mindkét csoport figyelmen kívül hagyásával), egyszerűen nincsenek tisztában a helyzetteL A HTML soha nem volt tiszta, és minden kísérlet, amely a megtisztírására irányult, látványosan elbukott, akárcsak a felváltására tett próbálkozások.

• Az 1993-ban használt böngészők egyike sem létezik semmilyen felismerhető formában. A Netscape Navigator fejlesztését 1998-ban abbahagyták, és az alapoktól újraírták a programot - ebből lett a Mozilla Suite, majd a projekt egyik elágazásából megszületett a Firefox. Az Internet Explorer szerény "kezdetei" a Microsoft Plus! for Windows 95-ig nyúlnak

1. fejezet Hogyan jutottunk el idáig? J 23

vissza, ahol a programot még asztaltémákkal és egy flipperjátékkal csomagolták össze. Persze, ha akarjuk, a böngésző eredetéhez mélyebbre is áshatunk.

• Az 1993-ban létező operációs rendszerek némelyike ma is megvan, de egyik sem játszik lényeges szerepet a Web szempontjábóL A V ilágháló élményét

"megtapasztaló" felhasználók többsége ma (2000 utáni) Windowst vagy valamilyen Linux rendszert futtató PC-t, Mac OS X rendszerű Mac-et, illetve az iPhone-hoz hasonló kézi eszközöket használ. 1993-ban a Windows még csak a 3.1-es változatnál tartott (és az OS/2-vel versenyzett a piacért), a Mac-ek a System 7-re épültek, a Linuxot pedig aUseneten keresztül terjesztették. (Szeretnénk egy jót nevetni? Keressünk egy ősz szakállú informatikust, és mondjuk neki, hogy "T rumpet Winsock" vagy azt, hogy "MacPPP".)

• Azoknak a kereteknek a kidolgozásában, amelyeket ma egyszerűen "webszabványoknak" nevezünk, a "régiek" közül is részt vesznek néhányan. Pedig azóta eltelt 20 év! Vannak, akik még a HTML előfutárain is dolgoztak, az 1980-as években vagy még régebben.

• Ha már az előfutárokról beszélünk . .. A HTML és a Web mai népszerűsége könnyen elfeledteti az emberrel azokat a velük egyidős formátumokat és rendszereket, amelyek nagy hatással voltak a fejlődésükre. Mielőtt elolvastuk ezt a fejezetet, hallottunk valaha az Andrew-ról? És az lntermediáról? Vagy a HyTime-ról? A HyTime ráadásul nem valamilyen ütött-kopott kutatóintézeti projekt volt, hanem katonai használatra elfogadott ISO-szabvány- Nagy Üzlet! Magunk is olvashatunk róla a http:/1

www.sgmlsource. comlhistorylhthist. h tm l címen.

Ez persze mind szép, de nem ad választ az eredeti kérdésünkre: miért létezik az <img> elem? Miért nem <icon>-nak hívják? Vagy <include>-nak? Miért nem hiperhivatkozás include jellemzővel, vagy rel értékek valamilyen kombinációja? Miért pont az <img> elemet fogadták el? Nos, egyszerűen azért, mert Marc Andreessen kidolgozta és közzétette, és mindig a kész kód nyer.

Ezzel persze nem azt akarom mondani, hogy minden kész kód nyer -végtére is, az Andrew, az Intermedia és a HyTime is kész kódokból álltak. A kész kód szükséges, de nem elégséges a sikerhez. És természetesen nem is úgy értem, hogy a szabvány elkészülte előtt leszállított kód a legjobb megoldás. Marc <img> eleme nem követelt meg egy adott grafikaformátumot;


nem szabta meg, hogyan folyja körül a szöveg a képet; és nem támogatta a helyettesítő szövegeket vagy a régebbi böngészőknek nyújtott alapértelmezett tartalmat. 17 évvel később még mindig küszködünk a tartalom kiszimatolásával, ami még mindig őrült biztonsági kockázatok forrása. Mindezt nyomon követhetjük a Nagy Böngészőháborún át egészen 1993. február 25-ig, amikor Marc Andreessen mellékesen odavetette, hogy "egy nap talán a MIME

", aztán

ettől függetlenül közreadta a kódját.

A HTML fejlődésének története 1997 és 2004 között

1997 decemberében a World Wide Web Consortium (W3C) közzétette a HTML 4.0-t, és nyomban le is állította a HTML-munkacsoport (HTML Warking Group) munkáját. Kevesebb mint két hónappal később a W3C egy másik munkacsoportja közreadta az XML 1.0-t. Mindössze három hónappal ezt követően a W3C "Shaping the Future of HTML" (A HTML jövőjének alakítása) címmel műhelyt szervezett, hogy választ adjon a kérdésre: "A W3C feladta a HTML fejlesztését?

". A válaszuk ez volt:

A megbeszélések során egyetértettünk abban, hogy a HTML 4.0 további

bövítése körülményes lenne, akárcsak a 4.0 átalakítása XML-alkalmazássá. A korlátok közül úgy kívánunk kitörni, hogy a HTML következő nemzedékét új alapokra helyezzük, és XML-elemhalmazokra építjük.

A W3C újjászervezte a HTML-munkacsoportot, és azt a feladatot adta neki, hogy alkossa meg ezeket az "XML-elemhalmazokat

". A munkacsoport ragjai

első lépésként 1998 decemberében elkészítettek egy ideiglenes szabványváz

latot, amely egyszerűen XML-ben fogalmazta újra a HTML-t, anélkül, hogy bármilyen új elemet vagy jellemzőt adott volna hozzá. Ez a szabványleírás vált később XHTML 1.0 néven ismertté. A vázlat az XHTML-dokumentumok számára egy új MIME-típust határozott meg, az application/xhtml+

xml-r. Ugyanakkor a meglevő HTML 4 szabványú oldalak átalakírásának

megkönnyítése érdekében hozzábiggyesztették a C függeléket, amely "öszszefoglalja a tervezési irányelveket azoknak az oldalfejlesztöknek a számára, akik az XHTML-dokumentumaik megfelelő megjelenítését a meglevő HTML-megjelenítő programokban is biztosítani szeretnék

". A C függelék


kimondta, hogy megengedett olyan "XHTML-oldalak" készítése, amelyeket

a kiszolgáló továbbra is a text/html MIME-típussal ad át. A következő célpontot a webes űrlapok jelentették. 1999 augusztusában

ugyanez a HTML-munkacsoport közzétette az XHTML Extended Forms

(XHTML bővített űrlapok) leírásának első vázlatát. A munkacsoport tagjai

már a vázlat első néhány mondatában (http:llwww.w3.org/TR/1999/WD

xhtmljorms-req-19990830#intro) megfogalmazták az elvárásaikat:

Gondos médegelés után a HTML Warking Group arra a megállapításra

jutott, hogy az űrlapok következő nemzedékére háruló feladatok nem

egyeztethetők össze a HTML korábbi változataihoz tervezett böngé

szöknek való visszamenőleges megfelelőséggeL A célunk az, hogy egy

tiszta, új űrlapmodellt ("XHTML Extended Forms") állítsunk fel, amely

jól meghatározott követelményeknek tesz eleget. Az ebben a dokumentumban leírt követelmények az űrlapalkalmazások igen széles körének

használata során szerzett tapasztalatokra épülnek.

Néhány hónappal később az "XHTML Extended Forms"-t átnevezték

"XForms"-ra, és külön munkacsoportot jelöltek ki a kidolgozására. Ez a cso

port párhuzamosan dolgozott a HTML-munkacsoporttal, és az XForms első

kiadását végül 2003 októberében tette közzé.

Közben, az XML-re történő átállás befejeztével, a HTML-munkacsoport

tagjai nekiláttak "a HTML következő nemzedékének" megalkotásához.

200 l májusában közzétették az XHTML 1.1 első kiadását, amely csak né

hány apróbb szolgáltatással bővítette az XHTML l. O-t, viszont kiküszöbölte a C függelékből eredő ellentmondást. Az 1.1-es változattól kezdve minden

XHTML-dokumentumot az application/xhtml+xml MIME -típussal

kell szolgáltatni.

Minden, amit az XHTML-ről tudunk, téves

Miért fontosak a MIME-típusok? Miért térek vissza hozzájuk újra meg újra?

Két szóban összefoglalhatom: a drákói hibakezelés miatt. A böngészők mindig

"elnézőek" voltak a HTML nyelvű dokumentumokkal szemben. Ha elkészí

tünk egy HTML-oldalt, de elfelejtünk címer adni neki a <title> elemmel,


a böngészők akkor is megjelenítik a lapot, annak ellenére, hogy a <title>

elem mindig is kötelező volt, a HTML minden változatában. Ezen kívül bizonyos címkék nem megengedettek más címkéken belül, de ha olyan oldalt készítünk, amely ilyen címkéket ágyaz egymásba, a böngészők (valamilyen módon) megbirkóznak vele, és még csak hibaüzenetet sem adnak.

Ahogy az várható is volt, az a tény, hogy a webböngészőkben a "hibás"

HTML-kódok is működnek, ahhoz vezetett, hogy a szerzők hibás HTMLoldalakat készítettek. Sok-sok hibás oldalt. Egyes becslések szerint a Weben ma található HTML-oldalak 99 százaléka tartalmaz legalább egy hibát. Mivel azonban ezek a hibák nem kényszerítik látható hibaüzenetek megjelenítésére a böngészőket, senki sem vesződik a kijavításukkal.

A W3C ezt alapvető problémaként értékelte a Webbel kapcsolatban, és elhatározta, hogy megoldást ad rá. Az 1997-ben közzétett XML szakított az elnéző ügyfélprogramok hagyományával, és minden XML-fogyasztó program számára kötelezővé tette, hogy az úgynevezett "jólformáltsági hibákat" végzetes hibának kell tekinteni. Az első hiba végzetességének ez az elve "drákói hibakezelés" néven vált ismertté, az i.e. VII. században élt görög törvényhozó, Drakón után, aki a viszonylag kisebb kihágásokat is halállal büntette. Amikor a W3C XML-szótárként újrafogalmazta a HTML-t, a feladattal megbízott szakemberek megkövetelték, hogy az új application/xhtml+xml MIME

típussal kiszolgált valamennyi dokumentum drákói elbírálás alá essen a hibák szempontjábóL Ha az XHTML-oldalunkon akár csak egyetlen hiba is van, a webböngészőknek nincs más választásuk, mint hogy leállítsák az oldal feldolgozását, és hibaüzenetet jelenítsenek meg a végfelhasználónak

Ez az elv nem örvendett általános népszerűségnek. Mivel a meglevő oldalak a becslések szerint 99 százalékban hibásak voltak, és így a végfelhasználóknak folyamatosan hibaüzeneteket kellett volna küldeni, az XHTML 1.0 és 1.1 új szolgáltatásainak szűkössége pedig nem ellensúlyozta ezt az árat, a weboldalak szerzői lényegében figyelmen kívül hagyták az application/

xhtml+xml-t. Ez persze nem azt jelenti, hogy teljesen levegőnek nézték az XHTML-t. A legkevésbé sem. Az XHTML 1.0 szabványleírás C függeléke biztosított egy kiskaput a világ webfejlesztői nek: "Használjunk valami olyas

mit, ami hasonlít az XHTML nyelvtanára, de adjuk át továbbra is a text/

html MIME-típussal." A webfejlesztök ezrei pontosan ezt tették: "frissítettek " az XHTML nyelvtanára, de a dokumentumokat továbbra is a text/

h tm l MIME-típussal szalgálták ki.


Még ma is, amikor számtalan weboldal állítja magáról, hogy XHTML nyelvű -az első sorban az XHTML dokumentumtípus-meghatározással kezdődik, kisbetűs címkeneveket használ, idézőjelek közé zár minden jellemzőértéket, és záró perjelet tesz az olyan üres elemek után, mint a <b r /> vagy a <hr /> -csupán az oldalak töredéke használja az application/

xhtml +xml MIME-típust, amely kiváltaná az XML drákói hibakezelését. A text/html MIME-típussal kiszolgált oldalakat azonban a dokumen

tumtípusuktól, a nyelvtanuktól és a kódolási stílusuktól függetlenül kivétel nélkül egy "elnéző" HTML-értelmező dolgozza fel, amely csendben figyelmen kívül hagyja a leírókód hibáit, és soha nem figyelmezteti a végfelhasználót (vagy bárki mást), még ha az oldal technikailag hibásnak minősül is.

Az XHTML 1.0-ban még megvolt ez a kiskapu, de az XHTML U lezárta,

a véglegesítésig soha el nem jutó XHTML 2.0 pedig folytatta a drákói hibakezelés hagyományát. Ezért léteznek oldalak milliárdjai, amelyek XHTML l. O

tÍpusúnak adják ki magukat, és ezért van csak egy maroknyi, amely azt állítja magáról, hogy az XHTML 1.1-et (vagy az XHTML 2.0-t) követi. Valóban

XHTML-t használunk hát? Nézzük meg a MIME-típust (valójában, ha nem tudjuk, milyen MIME-típust használunk, elég biztosra vehető, hogy még mindig a text/html lesz): hacsak nem az application/xhtml+xml

MIME-típussal szolgáltatjuk az oldalainkat, az állítólagos "XHTML-oldalaink" csak a nevükben követik az XML-t.

Egy versenyképes látomás

2004 júniusában a W3C Workshop on Web Applications and Compound Documents rendezvényén részt vettek a böngészőgyártók és a webfejlesztő cégek képviselői, valamint a W3C más tagjai. Az érdekelt felek -köztük

a Mozilla Foundation és az Opera Software -egy csoportja előadást tartott arról, hogy ők hogyan képzelik el a Web jövőjét: a meglevő HTML 4 szabvány továbbfejlesztésével, és a modern webalkalmazások fejlesztését segítő új szolgáltatások beépítésével (http://www. w 3. org/2004/04/webapps-cdfws/ paperslopera. h tm/):

A következő hét alapelv jelképezi, hogy mi mit tartunk a legfontosabb követelményeknek:


Visszirányú megfelelöség, világos átállási útvonal

A webalkalmazások technológiáinak olyan szabványokon kell alapulniuk,

amelyeket a webfejlesztök jól ismernek, beleértve a HTML-t, a CSS-t,

a DOM-ot és a JavaScriptet.

A webalkalmazások alapszolgáltatásainak megvalósíthatónak kell len

niük a ma az IE6-ban rendelkezésre álló műveletek, parancskóclak és

stíluslapok segítségéve!, hogy a fejlesztök világos átállási útvonalat kö

vethessenek. Igen valószínűtlen, hogy bármely olyan megoldás sikeres

nek bizonyulna, amely nem alkalmazható bináris bővítmények nélkül

a jelenleg a legnagyobb piaci részesedéssei bíró böngőszőben.

jól körülírt hibakezelés

A hibakezelést a webalkalmazásokban olyan részletességgel kell megha

tározni, hogy a böngészőknek (felhasználói ügynököknek-User Agent,

UA) ne kelljen saját hibakezelő eljárásokat kidolgozniuk, vagy más fel

használói ügynökök kódját visszafejteniük

A felhasználónak nem szabad találkoznia a szerzöi hibákkal

A szabványoknak pontosan le kell írniuk a hiba utáni helyreállítás mód

ját minden lehetséges hibaforgatókönyvre. A hibakezelést, amikor csak

lehet, elegáns helyreállásként kell megvalósítani (mint a CSS-ben), nem

pedig nyilvánvaló és katasztrofális vészhelyzetként (mint az XML-ben).

Gyakorlati haszon

A webalkalmazások szabványaiba bekerülő minden szolgáltatásnak iga

zolható gyakorlati haszna kell legyen. Ennek fordítottja nem feltétlenül

igaz: nem minden gyakorlati haszon igazolja egy új szolgáltatás szüksé

gességét.

A gyakorlati hasznot igazoló használati eseteket lehetőleg olyan valós

webhelyekről kell venni, ahol a szerzők korábban más, sikertelen meg

oldással próbáltak túllépni a korlátokon.

A parancskódok velünk maradnak ...

. . . ugyanakkor kerülendők, amennyiben kényelmesebb, deklaratív leíró

kód is használható helyettük. A parancskódoknak eszköz- és megjelenítő

függetleneknek kell lenniük, kivéve ha a hatókörüket eszközfüggő mó

don határozzák meg (vagyis XBL-be foglalják).

Az eszközfüggö profilokat célszerű elkerülni

A szerzőknek képesnek kell lenniük ugyanazokra a szolgáltatásokra tá

maszkodni a felhasználói ügynökök asztali és mobilválrozataiban.


Nyílt folyamat A Web nyer azzal, hogy a fejlesztése nyílt környezetben folyik. A Web középpontj ában a webalkalmazások fognak állni, ezért ezek fejlesztésének

is nyíltan kell történnie. A levelezőlistákat, archívumokat és szabványtervezeteket folyamatosan elérhetővé kell tenni a nagyközönség számára.

A műhely résztvevőit megszavaztatták, hogy "a W3C deklaratív bővítéseket dolgozzon ki a HTML-hez és a CSS-hez, valamint imperatív bővítéseket a DOM-hoz, hogy eleget tegyen a középszintű webalkalmazások követelményeinek" vagy "kifinomult, teljes értékű, operációs rendszer szintű alkalmazásprogramozási felületeket

"? Az első megoldásra 8-an, a másodikra ll-en

szavaztak. A műhely összefoglalójában (http:llwww.w3.org/2004104/webappscdfwslsummary) a W3C tagjai ezt írták: " A W3C jelenleg nem kíván semmilyen erőforrást áldozni a harmadik szavazás kérdésében érintett területre -a HTML és a CSS bővítésére a webalkalmazásokat illetően -, eltekintve

a W3C munkacsoportjai által jelenleg is fejlesztett technológiáktól." Ezzel a döntéssel szembesülve azoknak, akik a HTML és a HTML

űrlapok továbbfejlesztését javasolták, két lehetőségük maradt: feladják, vagy a W3C keretein kívül folytatják a munkájukat. Az utóbbi mellett döntöttek: bejegyeztették a whatwg.org tartománynevet, és 2004 júniusában megszületett a WHAT Warking Group.

Milyen munkacsoport?

Mi a túró az a WHAT Warking Group? Mondják el ők a saját szavaikkal

(http://www. whatwg. orginewsis tart):

A Web Hypertext Applications Technology Warking Group webböngésző-gyártók és webfejlesztésben érdekelt felek laza, nem hivatalos, nyílt társulása. A csoport célja szabványok kidolgozása a HTML és a hozzá kapcsolódó technológiák alapján, hogy megkönnyítse az együttműködni képes webalkalmazások készítését, és eredményeit szándéká

ban áll benyújtani egy szabványügyi szervezetnek. Ezek a benyújtott tervezetek képeznék a HTML szabványos, hivatalos bővítésének alapját.


Fórumunkat több hó napnyi, az említett technológiák szabványairól foly

tatott privát elektronikus levelezés után nyitottuk meg. Eddig a HTML4

Forms bővítésére összpomosítottunk, azzal a céllal, hogy úgy támogassuk a webfejlesztök által igényelt új szolgáltatásokat, hogy közben visszame

nőlegesen megőrizzük az együttműködést a meglevő tartalmakkal. A cso

portot azzal a szándékkal hoztuk létre, hogy biztosítsuk az említett szabványok jövőbeli fejlesztésének teljes nyilvánosságát egy a nagyközönség számára hozzáférhető, nyílt levelezőlistán keresztül.

A kulcsmondat itt a "visszamenőlegesen megőrizzük az együttműködést a meglevő tartalmakkal". Az XHTML (leszámítva a C függelék nyújtotta kiskaput) visszamenőlegesen nem egyeztethető össze a HTML-lel: teljesen új MIME-típust igényel, és drákói hibakezelést követel meg minden ilyen MIMEtípussal szolgáltatott tartalom esetében. Az XForms sem képes a visszirányú

együttműködésre a HTML-űrlapokkal, mert csak olyan dokumentumokba építhető be, amelyek az XHTML új MIME-típusát használják, ami azt je

lenti, hogy az XForms is kötelezővé teszi a drákói hibakezelést. Minden út a MIME-hoz vezet.

Ahelyett, hogy sutba dobott volna egy évtizednyi, a HTML-be fektetett

erőfeszítést, és használhatatlanná tette volna a meglevő weboldalak 99 százalékát, a WHAT munkacsoport úgy döntött, hogy más megközelítést

követ: dokumentálja a böngészők által ténylegesen alkalmazott "elnéző"

hibakezelő algoritmusokat. A webböngészők mindig is elnézőek voltak

a HTML-hibákkal szemben, de senki sem vette a fáradságot, hogy pontosan leírja a viselkedésüket. Az NCSA Mosaic-nak saját algaritmusai voltak a hibás oldalak kezelésére, és a Netscape ezekhez próbált igazodni. Aztán az

Internet Explorer követte a Netscape-et, az Opera és a Firefox megpróbálta

utánozni az Internet Explorert, aSafari pedig a Firefox nyomába eredt, és így tovább, egészen a mai napig. Közben pedig a fejlesztök ezer meg ezer munkaórát öltek abba, hogy a termékeiket egyenértékűvé tegyék a versenytársak programjaivaL

Ha ez eszetlen mennyiségű munkának tűnik, az azért van, mert tényleg

az. Vagy legalábbis az volt. Sok évbe telt, de a WHAT munkacsoport (néhány homályos esetet leszámítva) sikeresen dokumentálta, hogyan kell a HTML-t a meglevő webes tartalmakkal összeegyeztethető módon értelmezni. A végső


algoritmusban egyetlen olyan lépés sincs, amely megkövetelné a HTML

értelmező programtól, hogy állítsa le a feldolgozást, és jelenítsen meg hiba

üzenetet a végfelhasználónak

Miközben ez a visszafejtés folyt, a WHAT munkacsoport csendben más

dolgokon is ügyködött. Az egyik egy szabvány volt, amelynek kezdetben a Web Forms 2.0 nevet adták, és új fajta vezérlőkkel bővítette a HTML

űrlapokat (a webes űrlapokról a 9. fejezetben bővebben is szó lesz), a másik

pedig egy szabványtervezet "Web Applications 1.0" címen, amely olyan jelentősebb új szolgáltatásokat tartalmazott, mint a közvetlenül festhető rajzvá

szon (lásd a 4. fejezetet) vagy a videók és hangfájlok bővítmények nélküli,

beépített támogatása (lásd az 5. fejezetet).

Vissza a W3C-hez

A W3C és a WHAT Warking Group lényegében évekig levegőnek nézte

egymást. Miközben a WHAT munkacsoport a webes űrlapokra és az új

HTML-szolgáltatásokra összpontosított, a W3C HTML-munkacsoportja az XHTML 2.0-s változatán szorgoskodott. 2006 októberére azonban világossá

vált, hogy a WHAT munkacsoport jelentős előnyre tett szert, míg az X HTML

2 még mindig csak vázlatszinten létezett, és egyetlen komolyabb böngésző

sem valósította meg. 2006 októberében Tim Berners-Lee - személyesen

a W3C alapítója- bejelentette, hogy a W3C a jövőben a WHAT munkacso

porttal közösen fog dolgozni a HTML rovábbfejlesztésén (http://dig.esail. mit. edu!breadcrumbs/node/166):

Bizonyos dolgok évekkel későbbről visszatekintve világosabbá válnak.

A HTML-t fokozarosan tovább kell fejleszteni. A kísérlet, hogy a világot

rá vegyük arra, hogy egyszerre álljon át az XML-re, zárja idézőjelek közé

a jellemzőértékeket, zárja le perjellel az üres címkéket, és használjon

névtereket, megbukott. A HTML-oldalakat készítő nagyközönség nem

mozdult, nagyrészt azért, mert a böngészők nem panaszkodtak. Egyes

nagyobb közösségek megvalósították ugyan az átállást, és élvezik

a jólformált rendszerek előnyeit, de nem mindenki. Fontos, hogy folya

matosan továbbfejlesszük a HTML-t, miközben nem mondunk le


a jólformált világ felé vezető átmenetről sem, és egyre hatékonyabbá tesszük ezt a világot. Tervünk egy teljesen új HTML-csoport felállítása. Az előzőtől eltérően

ennek az lesz a feladata, hogy fokozatosan továbbfejlessze a HTML-t és vele

párhuzamosan az XHTML-t. A csoport vezetősége és tagjai kicserélődnek,

és együtt fognak munkálkodni a HTML-en és az XHTML-en. Az új

csoport erős támogatással bír, többek között a böngészőgyártók részéről.

Az űrlapok fejlesztésén is dolgozni kívánunk. Ez bonyolult terület, mivel

mind a meglevő HTML Forms, mind az XForms űrlapnyel v. A HTML

űrlapokat mindenütt használják, de az X-űrlapoknak is számos megvalósí

tása és felhasználója létezik. Ezenkivül a Webforms-csapat benyújtott tervei is ésszerű bővítéseket javasolnak a HTML-űrlapokhoz. A Webformscsapat terve- elmondásuk szerint- a HTML-űrlapok bövítése.

A W3C újonnan felállított HTML-munkacsoportjának egyik legelső döntése az volt, hogy a "Web Applications l. O" nevet "HTML5"-re változtattákés ezzel el is érkeztünk a HTML5-höz.

Utószó

2009 októberében a W3C leállította az XHTML 2 Working Group munká

ját, és a döntés indoklásaként a következő nyilatkozatot bocsátotta ki (http:/1 www. w 3. org/2009/06/xhtml-faq. h tm/):

Amikor a W3C 2007 márciusában bejelentette a HTML- és XHTML

2-munkacsoporrok megalakítását, jelezte, hogy folyamatosan figyelni

fogja az XHTML 2 piacának alakulását. A W3C fontosnak tartja, hogy világossá tegye az álláspontját a közösségnek a HTML jövőjéről.

Miközben értékeljük az XHTML 2-munkacsoportnak az évek során

tett erőfeszítéseit, a résztvevőkkel folytatott megbeszélés után a W3C vezetősége úgy döntött, hogy a munkacsoport 2009 végén lejáró meg

bízatását nem kívánja megújítani.

Mindig a kész kód nyer.



• The History of the Web (http:llhixie.chlcommentarylweblhistory)- lan Hickson régi vázlata

• Michael Smith, Henri Sivonen és mások: HTML/History (http:llesw. w3.orgltopic!HTML/history)

• Scott Reynen: A Brief History of HTML (http://www.atendesigngroup. comlbloglbriefhistory-ofhtml}

2. fejezet

A HTML5-képességek észlelése

Ugorjunk fejest!

Joggal tehetjük fel a kérdést: "Hogyan kezdhetnék el átállni a HTML5 használatára, ha a régebbi böngészők nem támogatják?". A kérdés azonban félrevezető, ugyanis a HTML5 nem egyetlen nagy egység, hanem önálló szolgáltatások gyűjteménye. A "HTML5-támogatás

" tehát nem deríthető fel, mert

ilyesmi nem létezik. Az egyes szolgáltatások- a rajzvászon, a vicleobeágyazás vagy a helymeghatározás - meglétét azonban igenis észlelhetjük.

Észlelési módszerek

Amikor a böngészőnk megjelenít egy weboldalt, egy dokumentumobjektum

modellt (Document Object Model, DOM) épít fel, ami nem más, mint az oldalon található HTML-elemeket ábrázoló objektumok gyűjteménye. Minden elemet- minden <p>-t, minden <d i v>-et és minden <span>-t- önálló objektumok képviselnek a DOM-ban. (Ugyanakkor léteznek globális objektumok is, mint a window vagy a document, amelyek nem kötődnek konkrét elemekhez.)

Minden DOM-objektum rendelkezik bizonyos közös tulajdonságokkal, de egyes objektumoknak több tulajdonsága van, mint másoknak. A HTML5 szolgáltatásait támogató böngészőkben egyes objektumok egyedi tulajdonságokkal bírnak, így egy gyors pillantás a DOM-ra elárulja, hogy a böngésző milyen szolgáltatásokat támogat.

Négy egyszerű módszer létezik arra, hogy felderítsük, hogy egy adott böngésző rendelkezik-e egy bizonyos képességgel. Ezek a legegyszerűbbtől a legösszetettebb felé haladva a következők:

l. Megvizsgáljuk, hogy egy globális objektum (például a window vagy a navigator) rendelkezik-e egy adott tulajdonsággal. A helymeghatározó

2. fejezet A HTML5-képességek észlelése l 35

API támogatásának vizsgálatára pár oldallal később, a fejezet "Helymeghatározás" című részében láthatunk példát.

2. Létrehozunk egy elemet, majd megvizsgáljuk, hogy rendelkezik-e egy adott tulajdonsággaL A rajzvászon támogatásának vizsgálatát bemutató

példa úgy egy oldallal később szerepel. 3. Létrehozunk egy elemet, megvizsgáljuk, hogy rendelkezik-e egy adott

tagfüggvénnyel, majd meghívjuk ezt a tagfüggvényt, és megvizsgáljuk a függvénytől visszakapott értéket. A támogatott videoformátumok kiderítésére a "Videoformátumok" című részben láthatunk példát.

4. Létrehozunk egy elemet, egy adott tulajdonságát egy bizonyos értékre állítjuk, majd megvizsgáljuk, hogy a tulajdonság megtartotta-e az értékér. A támogatott <input>-úpusok kiderítésére a "Bevitelielem-típusok" című

rész mutat egy példát.

Modernizr: egy HTML5-észlelő könyvtár

A Modernizr (http://www.modernizr.com) egy nyílt forrású, MIT felhasználási engedéllyel terjesztett JavaScript-könyvtár, amely számos HTML5- és CSS3-szolgáltatás támogatásának észlelésére képes. E könyv írásának idején a legújabb változata az 1.1-es számot viselte, de mindig a legfrissebb változatot célszerű használni. Ehhez az alábbi <script> elemet kell feltüntetnünk az oldal elején:

<! DOCTYPE html>

<html>

<head>

<me ta char set= •utf-8 ">

<title>Dive into HTMLS</title>

<script src="modernizr .min. js"X/script> </head>

<body>

</body>

</html>

AModernizr önműködően indul el, tehát nincs modernizr _init() függvény, amelyet meg kellene hívnunk. Amikor a könyvtár betöltődött, létrehoz egy Modernizr nevű globális obejktumot, amely minden általa észlelhető szolgáltatás számára tartalmaz egy-egy logikai tulajdonságot. Ha a böngé-

36 l A HTML5-képességek észlelése 2. fejezet

szőnk például ismeri a Canvas API-t (lásd a 4. fejezetben), a Modernizr.

canvas tulajdonság értéke true lesz. Ha viszont a böngésző nem támogatja ezt a programozási felületet, az említett tulajdonság a false értéket kapja:

if (Modernizr. canvas) { l l Rajzoljunk alakzatokat!

l else { l l nincs elérhető beépített rajzvászon-támogatás : ( l

A rajzvászon

A HTML5 a <canvas>, vagyis "

rajzvászon" elemet (http://bit.ly/9]Hz0j) így határozza meg:

"egy a felbontástól függő bitképes rajzvászon, amelyet grafiko

nok, játékgrafikák, illetve más képi elemek futás közbeni megjelenítésére használhatunk". A rajzvászon egy téglalap alakú terület az oldalon, amire JavaScriptkódok segítségével bármit rajzolhatunk. A HTML5 különféle függvényeket ("

Canvas API") határoz meg alakzatok rajzolásához, útvonalak meghatározásához, színátmenetek létrehozásához és transzformációk alkalmazásához.

A rajzvászon-API támogatásának felderítése a 2. észlelési módszerrel (lásd az

"Észlelési módszerek" című részt a fejezet elején) történik. Ha a böngé

szőnk támogatja a Canvas API-t, az általa létrehozott, a <canvas> elemet jelképező DOM-objektum rendelkezni fog egy getContext ( ) nevű tagfüggvénnyel (lásd a 4. fejezet "Egyszerű alakzatok" című részét). Amennyiben a böngészőnk nem támogatja a rajzvászon-API-t, a <canvas> elem számára létrehozott DOM-objektum csak általános tulajdonságokkal fog bírni, amelyek között nem találunk olyanokat, amelyek kifejezetten a rajzvászonhoz kapcsolódnak. A rajzvászon támogatását ezzel a függvénnyel vizsgálhatjuk:

function supports _ canvas ( ) { return! !docurnent.createElernent('canvas') .getContext;

l

Ez a függvény először egy <canvas> nevű áldemet hoz létre:

return 1 1docurnent.createElement('canvas') .getContext;

Ez az elem soha nem kapcsolódik az oldalhoz, tehát soha senki nem fogja látni. Csupán ott lebeg a memóriában tétlenül és céltalanul, mint egy kenu a lustán hömpölygő folyón.


Amint létrehozzuk a <canvas> álelemet, megvizsgáljuk, hogy létezik-e a getContext ( ) tagfüggvény. Ez a tagfüggvény csak akkor lesz jelen, ha a böngésző támogatja a Canvas API-t:

return 1 !document.createElement('canvas') .getContext;

Végül, a kettős tagadás trükkjének segítségével az eredményt logikai alakba (true vagy false) kényszerítjük:

return 1 !document.createElement('canvas') .getContext;

Ez a függvény a rajzvászon-API lehetőségeinek nagy részét képes észlelni, beleértve az alakzatrajzolás képességét (lásd az "Egyszerű alakzatok" című részt a 4. fejezetben), az útvonalakat ("Útvonalak", 4. fejezet), a színátmeneteket ("Színátmenetek", 4. fejezet) és a mintázatokat. A külső fejlesztéső explorercanvas könyvtárat ( lásd a "Mi a helyzet az Internet Explorerrel?"

dmű részt a 4. fejezetben), amely a Canvas API-t a Microsoft Internet Explorerben valósítja meg, nem tudja észlelni.

Ahelyett, hogy magunk írnánk meg a fenti függvényt, használhatjuk a Modernizr könyvtárat is (amelyet az előző részben mutattunk be) a rajzvászon-API támogatásának észlelésére:

if (Modernizr.canvas) { l l Rajzoljunk alakzatokat!

} else { l l nincs elérhető beépített rajzvászon-támogatás : ( }

A rajzvászonra írt szövegek API -jának észlelésére külön vizsgálatot kell végeznünk, amelyet az alábbiakban mutatok be.

Rajzvászonra írt szöveg

Még ha a böngészőnk támogatja is a rajzvászon-API-t, nem biztos, hogy a rajzvászonra Írt szövegek API-ját ( Canvas text API) is ismeri. A Canvas API idővel egyre bővült, és szövegíró függvényeket adtak hozzá, a rajzvászont támogató böngészők közül azonban némelyiket már az előtt piacra dobták, hogy a szöveg-API elkészült volna.


A Canvas text API felderítése szintén a 2. észlelési módszerrel (lásd az "Észlelési módszerek

" című részt a fejezet elején) történik. Ha a böngészőnk

támogatja a Canvas API-t, az általa létrehozott, a <canvas> elemet jelképező DOM-objektum rendelkezni fog a getContext ( ) tagfüggvénnyel (lásd a 4. fejezet "Egyszerű alakzatok" című részét). Amennyiben a böngészőnk nem támogatja a rajzvászon-API-t, a <canvas> elem számára létrehozott DOM-objektum csak általános tulajdonságokkal fog bírni, amelyek között nem találunk olyanokat, amelyek kifejezetten a rajzvászonhoz kapcsolódnak. A rajzvászonra írható szövegek támogatását ezzel a függvénnyel vizsgálhatj uk:

function supports _ canvas _text () {

}

if (! supports _ canvas ()) { return false; }

var dummy_canvas = document. createElement (' canvas');

var context =dummy_ canvas. getContext ('2 d' ) ;

return typeof context. fillText == 'function';

A függvény először a rajzvászon támogatását vizsgálja az előző részben megismert supports canvas ( ) függvény segítségéve!:

if (!supports_canvas()) { return false;}

Ha a böngésző nem támogatja a Canvas API-t, természetesen nem fogja támogatni a Canvas text API-t sem!

Következő lépésként létrehozunk egy <canvas> álelemet, és lekérdezzük a rajzolókörnyezetét (context). Ez biztosan működik, mert a supports _

canvas ( ) függvény már kiderítette, hogy a getContext (l tagfüggvény minden rajzvászon-objektum esetében létezik:

var dummy_ canvas = document. createElement {' canvas');

var context = dUJIIIIY_ canvas. getContext (' 2d') ;

Végül, megvizsgáljuk, hogy a rajzolókörnyezet rendelkezik-e fillText ( )

nevű függvénnyeL Ha igen, akkor a Canvas text API elérhető:

return typeof con text. fillText = 'function' ;

Ezt a függvényt sem kell magunknak megírnunk, hanem használhatjuk helyette a Modernizr könyvtárat is (lásd a "Modernizr: egy HTML5-észlelő


könyvtár" című részt a fejezet elején) a rajzvászonra írt szövegek API-támogatásának észlelésére:

if (Modernizr.canvastext) l l Írjunk szöveget! l else ( l l nincs elérhetőbeépített szövegtámogatás a rajzvászonhoz : (

l

Videó

A HTML5 egy új, <v ideo> nevű elemet határoz meg a weboldalakba ágyazható videók részére. A videók beágyazása korábban nem volt lehetséges olyan külső fejlesztésű bővítmények (plug-in) nélkül, mint az Apple QuickTime vagy az Adobe Flash.

A <video> elemet úgy tervezték, hogy mindenféle észlelő parancskód nélkül használható legyen. Több vicleofájlt is megadhatunk, és a HTML5 videotámogatásával rendelkező böngészők aszerint választhatnak közülük, hogy mely vicleoformá tumokat ismerik.*

A HTML5-vicleót nem támogató böngészők teljesen figyelmen kívül hagyják a <video> elemet, de ezt az előnyünkre fordíthatjuk, és ilyenkor utasíthatjuk a böngészőt, hogy egy külső bővítmény segítségével játssza le a videót. Kroc Camen tervezett egy Vicleo for Everybody! nevű megoldást {http:!lcamendesign.com!code!video_for_everbody), amely a HTML5-videóra támaszkodik, amennyiben az rendelkezésre áll, a régebbi böngészőkben viszont képes helyette a QuickTime-ra vagy a Flash-re szorítkozni. Ez a megoldás egyáltalán nem használ JavaScriptet, és lényegében minden böngészőben működik, beleértve a mobileszközök böngészőit is.

Ha többet szeretnénk annál, hogy a videó csak felbukkan az oldalon, és a böngésző lejátssza, JavaScript-kódot kell használnunk. A vicleotámogatás fel- ·

derítése a 2. észlelési módszerrel (lásd az "Észlelési módszerek" című részt a fejezet elején) történik. Ha a böngészőnk támogatja a HTML5-videókat, az általa létrehozott, a <v ideo> elemet jelképező DOM-objektum rendelkezni

• A különböző videoformárumokkal kapcsolarban lásd: "A gentie inrroducrion ro vicleo encoding, part l: conrainer formars" (http:lldiveintomark.orglarchivesl20081121181give-part-1-container

Jormats) és "par r 2: lossy vicleo codecs" {http:lldiveintomark.orglarchivesl2008112118lgivepart-2-lossy-video-codecs).


fog egy canPlayType ( ) nevű tagfüggvénnyeL Amennyiben a böngésző nem támogatja a HTML5-videót, a <video> elem számára létrehozott DOM-objektum csak az összes elemnél rendelkezésre álló általános tulajdonságokkal fog bírni. A vicleotámogatást ezzel a függvénnyel vizsgálhatjuk:

function supports _ victea () { return ! ! ctocurnent. createElement (' victeo' ) . canPlayType;

}

Ezt a függvényt sem kell magunknak megírnunk: a HTML5-videók támogatásának észlelésére is használhatjuk a Modernizr könyvtárat (lásd a "Modernizr: egy HTML5-észlelő könyvtár" című részt a fejezet elején):

if (Modernizr.video) { l l Játsszunk le egy victeát!

} else { l l nincs elérhető beépített victeatámogatás : ( l l próbáljuk meg helyette esetleg a QuickTime-ot vagy a Flash-t

}

A böngészőben lejátszható videoformátumok észlelésére külön vizsgálatot kell végeznünk; ennek bemutatása következik most.

Videoformátu mok

A videoformátumok olyanok, mint az írott nyelvek. Egy angol nyelv ű újság tartalmazhatja ugyanazokat a híreket, mint egy spanyol, de ha csak angolul tudunk, csak az egyiknek vehetjük hasznát. Ahhoz, hogy le tudjon játszani egy videót, a böngészőnknek értenie kell a "nyelvet", amelyen a videót "írták".

A videók nyelvét "kodeknek" hívják- ez az az algoritmus, amelyet a videó bitfolyammá alakítására használtak. A világon kodekek tucatjai léteznek -melyiket használjuk? A HTML5-videó sajnálatos valósága az, hogy a böngészők nem tudnak megegyezni egyeden kodekben, de szerencsére úgy tűnik, sikerült leszűkíteniük a kört kettőre. Az egyik kodekért fizetni kell (mert szabadalmaztatott), viszont működik aSafariban és az iPhone készülékeken (sőt az Adobe Flash-ben is, ha egy olyan megoldást alkalmazunk, mint a Vicleo for Everybody!). A másik kodek ingyenes, és az olyan nyílt forrású böngészők is ismerik, mint a Chrome vagy a Mozilla Firefox.


A videoformátumok támogatásának felderítése a 3. észlelési módszerrel (lásd az "Észlelési módszerek" című részt a fejezet elején) történik. Ha a böngészőnk támogatja a HTML5-videókat, az általa létrehozott, a <video>

elemet jelképező DOM-objektum rendelkezni fog a canPlayType () nevű tagfüggvénnyeL Ez a tagfüggvény árulja el, hogy a böngésző támogat-e egy adott videoformátumot.

Az említett függvény itt a Mac-ek és iPhone-ok által támogatott, szabadalommal sújtott formátumot vizsgálja:

function supports _h 2 64_ baseline _v ideo () if ( ! supports _vide o{) ) { return false; ) var v= document. createElement ( "v ideo") ; return v. canPlayType ( 'video/mp4; codecs= "avcl. 42E01E, mp4a. 40.2 "');

)

A függvény először a HTML5-videók támogatását vizsgálja az előző részben bemutatott supports _vide o() függvény segítségéve!:

if (!supports_video()) { returnfalse;)

Ha a böngésző nem támogatja a HTMLS-videókat, természetesen nem fog támogatni egyetlen vicleoformátumot sem!

Következő lépésként a függvény létrehoz egy <video> nevű áldemet (de nem kapcsolja azt az oldalhoz, tehát nem lesz látható), és meghívja a canPlayType () tagfüggvényt. Ez a tagfüggvény biztosan létezik, mert a supports _vide o() függvény éppen az imént vizsgálta ezt:

var v= document.createElement ("v ideo"); return v. canPlayType ( 'video/mp4; codecs="avcl. 42E01E, mp4a.40. 2"');

A "videoformátumok" valójában különféle dolgok kombinációi. A böngészőtől konkrétan azt kell megkérdeznünk, hogy le tudja-e játszani a MPEG-4 tárolóha csomagolt H.264 Baseline kódolású video- és AAC LC kódolású hangsávo kat.*

A canPlayType () függvény nem true vagy false értéket ad vissza, hanem a vicleoformátum ok összetettségét szem előtt tartva egy karakterlánco t:

* Azr, hogy ez ponrosa n mir jelenr, az 5. fejezerben magyarázom el, de érdemes teher elolvasni az

"A genrle inrroducrion ro vicleo encoding" (http://diveintomark.orgltaglgive) cím ü írásr is.


"probably"

A böngésző meglehetősen biztos benne, hogy le tudja játszani az adott formátumot ( "valószínűleg" ).

"maybe"

A böngésző úgy véli, hogy talán le tudja játszani az adott formátumot

("talán").

" " (üres karakterlánc)

A böngésző biztos benne, hogy nem tudja lejátszani az adott formátumot. Az alábbi második függvény a Mozilla Firefox és más nyílt forrású böngészők által támogatott nyílt vicleoformátumot vizsgálja. Az eljárás pontosan ugyanaz, az egyeden különbséget a canPlayType ( ) függvénynek átadon karakterlánc jelenti. Itt technikailag azt kérdezzük a böngészőtől, hogy le tudja-e játszani az Ogg tároló ba csomagolt Theora kódolás ú videoés Yorbis kódolású hangsávokat.

function supports _ ogg_ theora _v ideo ()

if (! supports _v ideo () ) { return false; } var v = document. createElement ( "v ideo") ;

return v. canPlayType ( 'video/ogg; codecs="theora, vorbis'"};

}

Végül jöjjön a WebM (http://www.webmproject.org), az a nemrég nyílt forrásúvá vált (és szabadalmakkal nem sújtott) videokodek, amelyet beépítenek majd az olyan fontosabb böngészők következő változatába, mint a Chrome, a Firefox és az Opera. A nyílt WebM-videók támogatását ugyanazzal a mód

szerrel észlelhetjük:

function supports _ webm _v ideo (}

if ( ! supports _v ideo () ) { return false; } var v= document. createElement ("v ideo");

return v. canPlayType ('video/wel::m; codecs="vp8, vorbis"');

}

Ezt a függvényt sem kell magunknak megírnunk: a különböző HTML5-videoformátumok támogatásának észlelésére is használhatjuk a Modernizr könyvtárat (megjegyzendő, hogy a Modernizr még nem képes észlelni a nyílt WebM vicleoformátum támogatását):


if (Modernizr. v ideo) (

l l Játsszunk le egy videó t! De milyet?

if (Modernizr.video.ogg) (

l l megpróbáljuk az Ogg tároléba csomagolt

l l Ogg Theora + Verbis formátumot

l else if (Modernizr.video.h264) ( l l megpróbáljuk az MP4 tároléba csomagolt

l l H. 264 videó+ MC hang formátumot

l l

Helyi tárolás

A HTML5-tároló (http:lldev. w 3. orglhtm/5/webstorage/) arra ad módot a webhelyeknek, hogy információkat tároljanak a felhasználó számítógépén, amelyeket később kinyerhetnek. A HTML5-tároló működési elve hasonló a sütikéhez (cookie), de nagyobb mennyiségű információhoz tervezték. A sütik mérete korlátozott, és a böngésző minden alkalommal elküldi őket a webkiszolgálónak, amikor új oldalt kér (ami további időbe telik, és értékes sávszélességet emészt fel). A HTML5-tároló a felhasználó számítágépén marad, és a webhelyek JavaScript-kód segítségével érhetik el, miután az oldal betöltődött.

Kérdezzük meg Leírókód professzort!

Kérdés: A helyi tárolás valóban része a HTML5-nek? Miért kapott helyet külön szabványleírásban?

Válasz: Az első kérdésre a rövid válasz: igen, a helyi tárolás a HTML5 része. Kicsir bővebben kifejtve: a helyi tárolás régebben a HTML5 fő szabványleírásának része volt, de végül külön leírásban kapott helyet, men a HTMLS-munkacsoport egyes tagjai panaszkodtak, hogy a HTMLS túl nagy. Ha ez úgy hangzik, mimha a kalóriák számár csökkenrendő több szelerre vágnánk egy tortát ... , nos, nem tévedünk. Üdv a szabványok bizarr világában!

A HTML5-tároló támogatásának felderítése az l. észlelési módszerrel (lásd az "Észlelési módszerek" című részt a fejezet elején) történik. Ha a böngészőnk


támogatja a helyi tárolást, a globális window objektum rendelkezni fog egy localStarage nevű tulajdonsággaL Amennyiben a böngésző nem támogatja a helyi tárolást, a localStarage tulajdonság undefined (nem meghatározott) lesz. A HTML5-tároló támogatását ezzel a függvénnyel vizsgálhatjuk

function supports _local_ storage () { return (' localStorage' in window) && window [' localStorage' J ! =null;

}

Ezt a függvényt sem kell magunknak megírnunk: a HTML5-féle helyi tárolás támogatásának észlelésére is használhatjuk a Modernizr könyvtárat (lásd a "Modernizr: egy HTML5-észlelő könyvtár

" című részt a fejezet elején):

if (Modernizr .localstorage) ( l l A window .localStorage elérhető! j else { l l nincs elérhető beépített támogatás a helyi tároláshoz : ( l l próbáljuk meg esetleg aGears-t vagy egy másik külső megoldást

j

Megjegyzendő, hogy a JavaScript megkülönbözteti a kis- és nagybetűket. AModernizr jellemzőjét localstarage-nek hívják (csupa kisbetűvel), a DOMtulajdonság neve azonban window.localStorage (nagy S-sel).


Kérdés: Mennyire biztonságos a HTML5-tárolóadatbázisom? Bárki elolvashatja? Válasz: Bárki, aki fizikailag hozzáfér a számítógépünkhöz, valószínűleg beletekinthet a HTML5-tárolóadatbázisba (sőt meg is változtathatja azt). A böngészőn belül minden webhely olvashatja és módosíthatja a saját értékeit, de a más webhelyek által tárolt értékekhez nem férhet hozzá. Ezt a korlátozást hívják az " azonos eredet elvének" (http://bit.lyi9YyPpj).

Webmunkások

A webmunkások (Web Worker API, http://bit.ly/9jheoj) szabványos módot adnak a böngészőknek arra, hogy JavaScript-kódokat futtassanak a háttérben.


A webmunkások segítségével több "szálat" indíthatunk, amelyek többé-kevésbé mind egyszerre futnak. (Gondoljunk arra, hogyan futtat a számítógép párhuzamosan több alkalmazást, és nagyjából megértettük a lényeget.) Ezek a "háttérszálak" bonyolult matematikai számításokat végezhetnek, hálózati kérelmeket adhatnak ki, vagy műveleteket végezhetnek a helyi tárolón, miközben a fő weboldal arra reagál, ahogy a felhasználó görget, kattint vagy szöveget gépel be.

A webmunkások támogatásának felderítése az l. észlelési módszerrel (lásd az "Észlelési módszerek" című részt a fejezet elején) történik. Ha a böngészőnk támogatja a Web Warker API-t, a globális window objektum rendelkezni fog egy Warker nevű tulajdonsággaL Amennyiben a böngésző nem támogatja a webmunkások programozási felületét, a Warker tulajdonság undefined (nem meghatározott) lesz. A webmunkások támogatását ezzel a függvénnyel vizsgálhatjuk:

function supports _web_ workers ( ) { return ! 1 window. Worker;

Ezt a függvényt sem kell magunknak megírnunk: a webmunkások támogatásának észlelésére is használhatjuk a Modernizr könyvtárat (lásd a "Modernizr: egy HTML5-észlelő könyvtár" című részt a fejezet elején):

if (Modernizr. webworkers) {

l l A window. Wo r ker elérhető! J else {

l l nincs elérhetőbeépített támogatás a webmunkások számára : ( l l próbáljuk meg esetleg aGears-t vagy egy másik külső megoldást

)

Megjegyzendő, hogy a JavaScript megkülönbözteti a kis- és nagybetűket. A Modernizr jellemzőjét webworkers-nek hívják (csupa kisbetűvel), a DOMtulajdonság neve azonban window. Warker (a "Worker" szóban nagy W-vel).

Kapcsolat nélküli webalkalmazások

Statikus weboldalakat olvasni kapcsolat nélküli módban könnyű: csatlakozunk az Internetre, letöltünk egy weboldalt, megszakítjuk az internetkapcsolatot, bezárkózunk egy szobába, és addig olvasgatjuk az oldalt, amíg csak


akarjuk. (Bezárkózni persze nem feltétlenül kell.) De mi a helyzet az olyan webalkalmazások kapcsolat nélküli használatával, mint a Gmail vagy a Google Docs? A HTML5-nek köszönhetően bárki (nem csak a Google!) készíthet kapcsolat nélkül is működő webalkalmazásokat.

A kapcsolat nélküli (ofHine) webalkalmazások természetesen kezdetben online webalkalmazáském működnek. Amikor először látogatunk el egy kapcsolat nélkül is működő webhely re, a webkiszolgáló elárulja a böngésző nknek, hogy mely fájlokra van szüksége ahhoz, hogy a webhely kapcsolat nélkül is működjön. Ezek a fájlok bármilyen típusú állományok lehetnek: HTML, JavaScript, képek, sőt akár videók is (lásd a "Videó" című részt a fejezet első felében). Ha a böngésző egyszer minden szükséges fájlt letöltött, az adott webhelyre akkor is ellátogathatunk, ha éppen nem kapcsolódunk az Internetre. A böngészőnk észre fogja venni, hogy kapcsolat nélkül dolgozunk, és a korábban letöltött fájlokat fogja betölteni. Amikor aztán ismét csatlakozunk a Világhálóhoz, minden végrehajtott változtatást feltölthetünk a távoli webkiszolgálóra.

A kapcsolat nélküli munka támogatásának felderítése az l. észlelési módszerrel (lásd az "Észlelési módszerek" című részt a fejezet elején) történik. Ha a böngészőnk támogatja a kapcsolat nélküli webalkalmazásokat, a globális window objektum rendelkezni fog egy applicationCache nevű tulajdonsággaL Amennyiben a böngésző nem támogatja a kapcsolat nélküli webalkalmazásoka t, az applicationCache tulajdonság undefined (nem meghatározott) lesz. A kapcsolat nélküli webalkalmazások támogatását ezzel a függvénnyel vizsgálhatjuk:

function supports_offline () { return! !window.applicationCache;

)

Ezt a függvényt sem kell magunknak megírnunk: a kapcsolat nélküli webalkalmazások támogatásának észlelésére is használhatjuk a Modernizr könyvtárat (lásd a "Modernizr: egy HTML5-észlelő könyvtár" című részt a fejezet elején):

if (Modernizr.applicationcache) { l l A window. applicationCache elérhető! ) else { l l nincs elérhető beépített támogatás a kapcsolat nélküli munkához : ( l l próbáljuk meg esetleg aGears-t vagy egy másik külső megoldást )


Megjegyzendő, hogy a JavaScript megkülönbözteti a kis- és nagybetűket. A Modernizr jellemzőjét applicationcache-nek hívják (csupa kisbetűvel), a DOM-tulajdonság neve azonban window. applicationCache (nagy C-vel a "Cache" szó elején).

Helymeghatározás

A helymeghatározás (geolokáció) annak a művészete, hogy kiderítsük, hol tartózkodunk a Földön, és (ha kívánjuk) megoszthassuk ezt az információt azokkal, akikben megbízunk. A tartózkodási helyünket sokféleképpen ki lehet deríteni - az IP-címünkből; a drót nélküli hálózati kapcsolatunkból; abból, hogy a mobiltelefonunk melyik adótoronnyal áll éppen kapcsolatban; vagy egy GPS-eszköz segítségéve!, amely a Föld körül keringő műholdaktól kapott információk alapján állapítja meg a szélességi és hosszúsági fokot.


Kérdés: A helymeghatározás része a HTML5-nek? Miért beszélünk róla?

Válasz: A helymeghatározás támogatásának beépítése a böngészökbe éppen most zajlik, akárcsak más HTML5-képességeké. Szigorúan véve a helymeghatározást a HTML5-munkacsoporttól független Geolocation Working Group (http:!lwww.w3.org/2008/geolocation) szabványosítja. Én ennek ellenére szót ejtek a helymeghatározásról ebben a könyvben, merr része a Web jelenleg is zajló evolúciójának.

A helymeghatározás támogatásának felderítése az l. észlelési módszerrel (lásd az "Észlelési módszerek" cím ű részt a fejezet elején) történik. Ha a böngészőnk támogatja a Geolocation API-t, a globális navigator objektum rendelkezni fog egy geolocation nevű tulajdonsággaL Arnennyiben a böngésző nem támogatja a helymeghatározás programozási felületét, a geolocation tulajdonság undefined (nem meghatározott) lesz. A helymeghatározás támogatását ezzel a függvénnyel vizsgálhatjuk

function supports _geolocation ( ) { return ! ! navigator .geolocation;


Ezt a függvényt sem kell magunknak megírnunk: a Geolocation API támogatásának észlelésére is használhatjuk a Modernizr könyvtárat (lásd a "Modernizr: egy HTML5-észlelő könyvtár" című részt a fejezet elején):

if (Modernizr.geolocation) { l l Derítsük ki, hol vagyunk!

) else { l l nincs elérhető beépített támogatás a helymeghatározáshoz : (

l l próbáljuk meg esetleg aGears-t vagy egy másik külső megoldást

)

Akkor sincs minden veszve, ha a böngészőnk nem támogatja beépítve a helymeghatározó API-t. A Gears (http:lltools.google.comlgearsl) egy nyílt forrású böngészőbővítmény a Google-tól, amely Windows, Mac, Linux, Windows Mobile és Android rendszeren is működik, és számos szolgáltatást kínál azoknak a régebbi böngészőknek, amelyek nem támogatnak minden csillogóvillogó újdonságot, amelyről ebben a fejezetben szót ejtettünk. AGears kínálatának része egy helymeghatározó API is- igaz, nem a navigator.geo

location API, de ugyanazt a célt szolgálja.

Léteznek konkrét eszközökre Írt helymeghatározó API-k is, az olyan mobiltelefon-rendszerek számára, mint a BlackBerry, a Nokia, a Palm vagy az OMTP BONDI.

A 6. fejezetben kimerítő részletességgel fogjuk tárgyalni ezeknek a külön

féle API-knak a használatár.

Bevitelielem-típusok

Ismerjük a webes űrlapokat, igaz? Létrehozunk egy <form> elemet, hozzá

adunk néhány <input type= "text"> elemet, esetleg egy <input type=

"password"> mezőt, és egy <input type="submit"> gombbal tesszük teljessé a művünket.

Nos, ez szánalmasan kevés. A HTMLS a beviteli elemeknek több mint egy tucat új típusát határozza meg, amelyeket felhasználhatunk az űrlap

jainkon:

<input type= "search''>

A keresőmezőket lásd: http:llbit.fyl9mQt5C.


<input type= "number">

A léptetőmezőket lásd: http://bit.lylaPZHjD. <input type= "range">

A csúszkákat lásd: http://bit.fyldmLiRr. <input type= "color">

A színválasztókat lásd: http://bit.fylbwRcMO. <input type= "tel">

A telefonszámokat lásd: http://bit.fylamkWLq. <input type= "url">

A webcímeket lásd: http://bit. fylcjKb3a. <input type= "email">

Az e-mail címeket lásd: http://bit.fylaaDrgS. <input type= "date">

A dátumválasztó naptárakat lásd: http:!lbit.fylc8hL58. <input type= "month ">

A hónapválasztókat lásd: http://bit.fylcDgHRI <input type= "week">

A hétválasztókat lásd: http:llbit.fylbR3r58. <input type= "time">

Az időbélyegeket lásd: http:llbit.fy!bjMCMn. <input type= "da tetime ">

A precíz, abszolút dátum/időbélyegeket lásd: http://bit.fylc46zVW. <input type= "datetime-local ">

A helyi dátumokat és időpontokat lásd: http:llbit.fylaziNkE.

A HTML5 bevitelielem-típusainak felderítése a 4. észlelési módszerrel (lásd az "Észlelési módszerek" című részt a fejezet elején) történik. Először létrehozunk egy <input> áldemet a memóriában:

var i= document. createElement ("input");

Minden <input> elemnek a "t ext" az alapértelmezett típusa. Ez létfontosságú, ezért jól jegyezzük meg.

A következő lépés, hogy az <input> áldern type jellemzőjét arra a bevitelielem-típusra állítjuk, amelynek a létezését ki szeretnénk deríteni:

i. setAttribute ("type", "color'');


Ha a böngészőnk támogatja az adott bevitelielem-típust, a type tulajdonság megőrzi az általunk beállított értéket, ha azonban nem, a böngésző figyelmen kívül hagyja azt, és a type tulajdonság értéke továbbra is "text" lesz:

return i. type ! == "text";

Ahelyett, hogy magunk írnánk meg 13 különböző függvényt, a HTML5-ben meghatározott összes új bevitelielem-típus észlelésére használhatjuk a Modernizr könyvtárat is (lásd a "Modernizr: egy HTML5-észlelő könyvtár"

című részt a fejezet elején). A Modernizr egyetlen <input> elemet hasznosít újra mind a 13 bevitelielem-típus támogatásának észlelésére, majd felépít egy Modernizr.inputtypes nevű hasítótáblát, amely 13 kulcsot tartalmaz (a HTML5 type jellemzőit), valamint 13logikai értéket (true, ha a beviteli elem támogatott, és false, ha nem):

if (!Modernizr.inputtypes.date) ( l l nincs elérhető beépített támogatás az <input type= "date ">-hez : (

l l esetleg írjuk meg magunk

llaDojo

l l vagy a j Query segítségével

)

Helyőrző szöveg

Az új típusú beviteli elemek mellett a HTML5 több apró újítást is tartalmaz a meglevő űrlapokhoz. Az egyik ilyen új szolgáltatás, hogy helyőrző szöveget tehetünk egy beviteli mezőbe. A helyőrző szöveg addig lesz látható a beviteli mezőben, amíg a mező üres, és nincs rajta a fókusz. Amint azonban a beviteli mezőre kattintunk (vagy a tabulátorbillentyűvel állítjuk rá a fókuszt), a helyőrző szöveg eltűnik. Ha nehezen tudjuk magunk elé képzelni a dolgot, a 9.

fejezet elején, a "Helyőrző szöveg" című részben találunk hozzá képernyőfelvételeket.

A helyőrző szövegek támogatásának felderítése a 2. észlelési módszerrel (lásd az "Észlelési módszerek" című részt a fejezet elején) történik. Ha a böngészőnk támogatja a helyőrző szövegeket a beviteli mezőkben, az általa létrehozott, az <input> elemet jelképező DOM-objektum rendelkezni fog egy placeholder (helyőrző) nevű tulajdonsággal (még akkor is, ha a HTMLkódban nem szerepeltetünkplaceholder jellemzőt). Amennyiben a böngésző


nem támogatja a helyőrző szövegeket, az <input> elem számára létrehozott DOM-objektumnak nem lesz placeholder tulajdonsága. A helyőrzők támogatását az alábbi módon vizsgálhatjuk

function supports _input _placeholder () { var i= document. createElement ('input'); return 'placeholder' in i;

)

Ezt a függvényt sem kell magunknak megírnunk: a helyőrző szövegek támogatásának észlelésére is használhatjuk a Modernizr könyvtárat (lásd a "Modernizr: egy HTML5-észlelő könyvtár" című részt a fejezet elején):

if (Modernizr.input.placeholder) { l l A helyőrzö sz övegnek már láthatónak kell lennie! ) else { l l a helyőrzö szövegek nem támogatottak : ( l l parancskódot alkalmazó megoldásra kell szorí tkoznunk

)

Automatikus űrlapfókusz

Sok webhely JavaScript-kódot használ arra, hogy a fókuszt automatikusan a webes űrlapok első beviteli mezőjére állítsa. A Google.com nyitóoldala például automatikusan a keresőmezőre állítja a fókuszt, hogy a keresett kifejezést azonnal beírhassuk, anélkül, hogy előbb a mezőbe kellene kattintanunk Ez a legtöbb ember számára kényelmes, de a gyakorlott felhasználóknak vagy a különleges igényekkel bíró felhasználóknak idegesítő lehet: ha lenyomjuk a szóköz billentyűt, arra számítva, hogy ezzel görgetjük az oldalt, csalódni fogunk, mert a fókusz már egy űrlapmezőben található, ezért az oldal nem fog

lejjebb gördülni. (Helyette egy szóközt írunk a beviteli mezőbe.) Ha egy másik beviteli mezőre állítjuk a fókuszt, miközben az oldal még töltődik, a webhely amofókusz-kezelő parancskódja "segít", és visszateszi a fókuszt az eredeti beviteli mezőbe, amint az oldal teljesen betöltődött, így megszakítja a munkánkat, és rossz helyre fogunk gépelni.

Mivel az automatikus fókuszállítás JavaScript-kód segítségével történik, nehéz lehet minden szélsőséges esetet kezelni, és nem sok lehetősége marad azoknak, akik nem akarják, hogy a weboldal "ellopja" a fókuszt.

A probléma megoldására a HTML5 egy autofocus nevű jellemzőt vezet be a webes űrlapok minden vezérlője számára. Az autofocus jellemző pon-


tosan azt teszi, amire a neve utal: a fókuszt egy adott beviteli mezőre állítja. Mivel azonban ez csak leírókód, és nem parancskód, a viselkedése minden webhelyen azonos. Ezen kívül a böngészőgyártók (illetve a bővítmények készítői) módot adhatnak a felhasználóknak az automatikus fókuszálás kikapcsolására.

Az autofókusz támogatásának felderítése a 2. észlelési módszerrel (lásd az

"Észlelési módszerek" című részt a fejezet elején) történik. Ha a böngészőnk támogatja a webes űrlapok vezérlőinek automatikus fókuszállítását, az általa létrehozott, az <input> elemet jelképező DOM-objektum rendelkezni fog egy autofocus nevű tulajdonsággal (még akkor is, ha a HTML-kódban nem szerepeltetünk autofocus jellemzőt). Amennyiben a böngésző nem támogatja a webes űrlapvezérlők autofókusz szolgáltatását, az <input> elem számára létrehozott DOM-objektumnak nem lesz autofocus tulajdonsága. Az automatikus fókuszállítás támogatását az alábbi függvénnyel vizsgálhatjuk:

function supports input_autofocus () { var i = document. createElement ('input' ) ; return 'autofocus' in i;

Ezt a függvényt sem kell magunknak megírnunk: az űrlapmezők aurafókusztámogatásának észlelésére is használhatjuk a Modernizr könyvtárat (lásd a

"Modernizr: egy HTML5-észlelő könyvtár" című részt a fejezet elején):

if (Moderni.zr. input. autofocus) { l l Az automatikus fókusz működik! ) else { l l nincs autofókusz-támogatás : ( l l parancskódot alkalmazó megoldásra kell szorítkoznunk

)

Mikroadatok

A mikroadatok (http://bit.lylckt9Rj) szabványos módot adnak arra, hogy további, jelentéssei bíró elemekkel bővítsük a weboldalainkat. Mikroadatok segítségével például bejelenthetjük, hogy egy bizonyos fénykép egy adott Creative Commons felhasználási engedély hatálya alá tartozik. Ahogy a 10. fejezetben látni fogjuk, mikroadatokat használva "Névjegy" oldalt is létrehozhatunk,


a böngészők, böngészőbővítmények és keresőprogramok pedig a HTML5-ös mikroadatkódot egy vCard-dá alakíthatják, ami az elektronikus névjegykártyák szabványos formátuma. Ezenkívül saját mikroadat-szótárakat is meghatározhatunk

A HTML5-mikroadatok szabványa HTML-kódot (elsősorban a keresőmatorok számára) és DOM-függvényeket (főként a böngészők számára) is tartalmaz. Mikroadatkódot nyugodtan beilleszthetünk a weboldalainkba, kárt nem okozunk vele - csupán néhány jól elhelyezett jellemzőről van szó, és azok a keresők, amelyek nem ismerik a mikroadat-jellemzőket, egyszerűen figyelmen kívül hagyják őket. Ha viszont a DOM-on keresztül kell elérnünk vagy módosítanunk mikroadarokat, ellenőriznünk kell, hogy a böngésző támogatja-e a mikroadatok DOM API-ját.

A HTML5-mikroadatok API-támogatásának felderítése az l. észlelési módszerrel (lásd az "Észlelési módszerek" című részt a fejezet elején) történik. Ha a böngészőnk támogatja a HTML5 MicrodataAPI-t, a globális document

objektum rendelkezni fog egy get Items ( ) nev ű függvénnyeL Amennyiben a böngésző nem támogatja a mikroadatokat, agetitems () függvény nem meghatározott lesz. A támogatást az alábbi módon vizsgálhatjuk:

function supports _ microdata _api ( ) { return! !document.getitems; )

A Modernizr könyvtár egyelőre nem képes a Microdata API észlelésére, ezért mindenképpen egy a fentihez hasonló függvényt kell használnunk.


Szabványok és egyéb leírások: • A <canvas> elem (http:llbit.lyi9]Hz0j) • A <v ideo> elem (http://bit.ly/a3kpiq) • <input>-típusok (http://bit.ly/akweH4) • Az <input placeholder> jellemző (http:llbit.lylcaGLBN) • Az <input autofocus> jellemző (http:llbit.lyldbJFj4) • HTML5-tároló (http:lldev.w3.orglhtml5/webstoragel) • Webmunkások (http://bit.ly/9jheoj) • Kapcsolat nélküli webalkalmazások (http://bit.lyldBZgzX)


• A Geolocation helymeghatározó API (http:llwww.w3.org/TR!geolocationAPII)

J avaScript-könyvtárak:

• A Moclernizr HTML5-észlelő könyvtár (http://www.modernizr.com/) • A geo.js helymeghatározó API-burkoló (http:llcode.google.comlplgeo-location

javascript)

Egyéb cikkek és oktatóanyagok

• Vicleo for Everybocly! (http:llcamendesign.comlcode/video_for_everybody) • "A gentie introcluction to vicleo encocling" (http:lldiveintomark.orgltagl

giv e) • "Vicleo type parameters" (http://wiki.whatwgorglwiki/Video_type_parameters) • Jelen kötet Függeléke

3. fejezet

Mit jelent mindez?

Ugorjunk fejest!

Ebben a fejezetben fogunk egy HTML-oldalt, amellyel az égvilágon semmi gond nincs, és javítunk rajta. Egyes részei rövidebbek, mások hosszabbak lesznek - de az egész sokkal olvashatóbbá fog válni. Lenyűgöző lesz!

A kérdéses oldal ezen a címen található: http:lldiveintohtml5.orglexamples/ blog-original.html. Olvassuk át tüzetesen. Éljük át. Szeressük. Nyissuk meg egy új böngészőlapon, és vissza se jöjjünk, amíg legalább egyszer ki nem adtuk a "Forrás megtekintése" parancsot.

A dokumentumtípus

Az oldal forrása így kezdődik:

<! DOCTYPE html

PUBLIC •- / /W3C/ /DTD XHTML l. O Strict/ /EN •

"http://www.w3.org/TR/xhtmll/DTD/xhtmll-strict.dtd">

Ezt hívják dokumentumtípusnak (doctype). A dokumentumtípusnak hosszú -fekete mágiától sem mentes-története van. Az Internet Explorer 5 for Mac fejlesztése közben a Microsoft meglepő problémával találta magát szemben. A böngésző készülő változata annyit fejlődött a szabványok támogatása terén, hogy a régebbi oldalakat többé nem tudta megfelelően megjeleníteni. Pontosabban, az oldalak (a szabványok szerint) helyesen jelentek meg, a felhasználók viszont éppen hogy azt várták, hogy a böngésző helytelenül képezze le azokat. A weboldalakat ugyanis az akkori piacvezető böngészők-elsősorban a Netscape 4 és az Internet Explorer 4 - trükkjeihez igazodva Írták. Az lES/ Mac viszont annyira fejlett volt, hogy tulajdonképpen tönkretette a Webet.

3. fejezet Mitjelent mindez? l 57

A Microsoft újszerű megoldással állt elő. Az lES/Mac egy oldal leképezése előtt megvizsgálta a "dokumenrumtípust

", ami jellemzően a HTML-forrás

első sorában szerepel (még a <h tm l> elem előtt). A régebbi oldalak (amelyek a régi böngészők leképezési trükkjeire támaszkodtak) általában egyáltalán nem határozták meg a dokumentum típusát- ezeket az oldalakat az lES/Mac úgy jelenítette meg, minr a régebbi b öngészők. Ahhoz, hogy az új szabványtámogatás "életbe lépjen

", a weboldalak szerzőinek kifejezetten meg kellett

adniuk a megfelelő dokumenrumtípust a <html> elem előtt. Az ötlet futótűzként terjedt, és hamarosan minden fonrosabb b öngésző

két leképezési móddal rendelkezett: a "trükköző móddal"

(quirks mode) és a "szabványkövető móddal

" (standards mode). A dolgok azonban természe

tesen - hiszen a Webről van szó - hamarosan kicsúsztak az érintettek kezéből. Közvetlenül a Mozilla böngésző 1.1-es változatának megjelenése előtt a Mozilla fejlesztői észrevették, hogy a böngésző olyan oldalakat is szabványkövető módban jelenít meg, amelyek valójában egy bizonyos trükkre támaszkodnak. A Mozilla leképezőmotorját nem sokkal korábban javították ki, hogy kiküszöböljék ezt a trükköt, és oldalak ezrei váltak egyszerre működésképtelenné. Így született meg- és ez nem vicc- a "majdnem szabványkövető mód

"

(almost standards mode). "Activating Browser Modes with Doctype

" (http:llhsivonen.iki.fi/doctypel)

című korszakalkotó művében Henri Sivonen így foglalja össze a különböző leképezési módokat:

Trükköző mód

A trükköző módban a böngészők megsértik a mai webformátum-szabványok elöírásait, hogy elkerüljék azoknak az oldalaknak a működésképtelenné válását, amelyeket az 1990-es évek végén uralkodó gyakorlatot követve írtak.

Szabványkövető mód

A szabványkövető módban a böngészők a jólformált dokumentumokat igyekeznek a szabványokban leírtaknak megfelelően megjeleníteni, amenynyire ezt az adott böngésző megvalósítása megengedi. A HTMLS ezt a módot "nem trükköző módnak

" (no quirks mode) hívja.

Majdnem szabványkövető mód

A Firefox, a Safari, a Chrome, a (7.5-ös vagy újabb) Opera és az lES rendelkezik az úgynevezett "majdnem szabványkövető móddal" is, amely

58 l Mitjelent mindez? 3. fejezet

a táblázatcellák függőleges méretezését nem szigorúan a CSS2-szabvány

szerint, hanem hagyományos módon valósítja meg. A HTML5 ezt

a módot "korlátozott trükköző módnak"

(limited quirks mode) hívja.

,, ,, Henri cikkének a többi részét is érdemes elolvasni, mert én itt

jelentősen leegyszerűsítettem. Például egyes régebbi dokumentumtípusok

még az IE5/MAC-ben sem kapcsolták be a szabványok támogatását. Ezen

kívül a trükkök száma idővel nőtt, akárcsak azoké a dokumentumtípu

soké, amelyek trükköző módra kényszerítették a böngészőket. Amikor

legutóbb megpróbáltam megszámolni, 5 dokumentumtípust találtam,

amely "majdnem szabványkövető" módot váltott ki, és 73-at, amely trük

közőt. Biztosan kihagytam persze néhányat, és akkor még nem is beszél

tem arról, hogy mit csinál az Internet Explorer 8, hogy váltani tudjon

a négy- igen, négy! - különböző leképezési módja között. Van róla egy

folyamatábra a http:llhsivonen.iki.fi!doctypelie8-mode.png címen. Pusztít

suk el. Vessük máglyára.

Hol is tartottunk? Ja, persze, a dokumentumtípusnál:

<' DOCTYPE html

PUBLIC "-/ /W3C/ /DTD XHTML l. 0 Strict/ /EN"

"http: l /www. w 3 .org/TR/xhtmll/DTD/xhtmll-strict.dtd ">

Ez történetesen egyike annak a 15 dokumenrumtípusnak, amely szabványkö

vető módot vált ki minden modern böngészőben. Nincs vele semmi gond.

Ha tetszik, tartsuk meg. Vagy változtassuk a HTML5 dokumentumtÍpusra,

ami rövidebb és barátságosabb, és szintén szabványkövető módban kezeli

minden mai böngésző.

A HTML5 dokumentumtípus így fest:

<! DOCTYPE html>

Ennyi az egész. Mindössze 15 karakter. Annyira egyszerű, hogy saját kezűleg

is begépelhetjük, és nem fogjuk elrontani.


Leírókód professzor azt mondja

A dokumentumtípusnak a HTML-fájl legelső sorában kell szerepelnie.

Ha bármi más van előtte -akár egyetlen üres sor -, egyes böngészők úgy fogják kezelni az oldalt, mintha egyáltalán nem határozta volna

meg a dokumentumtípust. Dokumentumtípus nélkül pedig a böngésző

trükköző módban jeleníti meg az oldalt. Ezt a hibát nagyon nehéz észrevenni, mert a fölös térközök általában nem számítanak a HTML-ben, így a szemünk hajlamos átsiklani felette - ebben az esetben viszont

nagyon fontos!

A gyökérelem

A HTML-oldalak egymásba ágyazott elemek sorából állnak, tehát egy oldal szerkezete olyan, mint egy fa. Egyes elemek "testvérek", mint két ág, amely

ugyanannak a fának a törzséből ered. Olyan elemek is vannak, amelyek más

elemek "gyermekei", mint amikor egy vékonyabb ág hajt ki egy vastagabbóL

(Ez a másik irányban is érvényes: azokat az elemeket, amelyek más elemeket tartalmaznak, a közvetlen gyermekelemeik "szülőcsomópontjának", illetve az

"unokáik" "őseinek" hívjuk.) A gyermektelen elemek a "levélcsomópontok".

A legkülső elem, amely az oldalon található összes többi elem őse, a "gyökér

elem". A HTML-oldalak gyökéreleme mindig a <html>.

A mintaoldalunkon (http:l!diveintohtm/5. orglexampleslblog-original. h tm/) a gyökérelem így fest:

<html xmlns= "http: l /www. w 3 .org/1999/xhtml •

lang="en •

xml:lang=•en">

Ezzel a kóddal nincs semmi gond. Megint csak azt mondhatom, ha tetszik, tartsuk meg, hiszen érvényes HTML5-kód. Egyes részei ugyanakkor már nem

szükségesek a HTML5-ben-ha ezeket eltávolítjuk, nyerhetünk néhány báj tot.

Az első dolog, amiről szót kell ejtenünk, az xmlns jellemző. Ez még az XHTML l. O öröksége. Azt mondja a böngészőnek, hogy az oldalon ralálható

elemek az XHTML névtér (http://www.w3.org/1999/xhtml) részei. A HTML5-ben azonban az elemek mindig ebben a névtérben találhatók,


ezért ezt nem kell kifejezetten bejelentenünk. A HTML5-oldalaink pontosan ugyanúgy fognak működni minden modern böngészőben, akár jelen van ez a jellemző, akár nincs.

Ha az xmlns jellemzőt elhagyjuk, ezt a gyökérelemet kapjuk:

<html lang= "en" xml: lang= "en">

Mindkét jellemző- a lang és az xml: lang- amelyet itt látunk, a HTMLoldal nyelvét határozza meg. (Az en az "English

", vagyis "angol

" rövidítése.*)

Miért kell két jellemző ugyanarra a célra? Ez megint csak az XHTML öröksége, a HTML5-ben viszont csak a lang jellemzőnek van hatása. Az xml: lang

jellemzőt is megtarthatjuk, ha akarjuk, de ha így teszünk, ügyelnünk kell rá, hogy ugyanaz legyen az értéke, mint a lang jellemzőnek

Az XHTML-re, illetve onnan való átállás megkönnyítése érdekében a szerzök megadhatnak egy névtér és előtag nélküli jellemzőt az "xml:lang" környezeti névvel a HTML-dokumentumok HTML-elemeire, de ilyen jellemzőt csak akkor szabad megadni, ha egy névtér nélküli lang jellemző szintén szerepel, és mindkét jellemzőnek ugyanaz az értéke, ha a kis- és nagybetűket nem megkülönböztetve, ASCII-karakterekként hasonlítjuk össze őket. A névtér és előtag nélküli, az "xml:lang" környezeti névvel szereplő jellemzőnek nincs hatása a nyelvi feldolgozásra.

Készen állunk hát, hogy ejtsük a második jellemzőt? Semmi baj, csak engedjük el. Egyik kéz, másik kéz ... mehet! Így ez a gyökérelem marad:

<html lang= "en">

Erről nincs is több mondanivalóm.

A <head> elem

A gyökérelem első gyermeke általában a <head> elem. A <head> elem metaadatokat tartalmaz - információkat az oldalról, nem pedig az oldal

• Nem angolul írunk? Keressük meg az álralunk használc nyelv kódjár a http:llwww.w3.org/ lnternationallquestionslqa-choosing-langrtage-tags címen.

3. fejezet Mitjelent mindez? J 61

szövegtörzséről. (Az oldal törzse- nem meglepő módon- a <body> elemben található.) Maga a <head> elem elég unalmas, és a HTML5-ben sem esett át semmilyen érdekes változáson. Ami izgalmas, azt a <head> elemen belül

találjuk Ehhez ismét a mintaoldalunkhoz fordulunk:

<head>

<me ta http-equi v� "Content-Type" content� "text/html; charset�utf-8" />

<ti tle>My Weblog</ ti tle>

<link rel� "stylesheet" type� "text/ess" href� "style-original. ess" />

<link rel� "al terna te" type� "application/atom+xml"

ti tle� "My Weblog feed"

href�"/feed/" />

<link rel� "search" type� "application/opensearchdescription+xml"

ti tle� "My Weblog search"

href�"opensearch.xml" />

<link rel� "shortcut icon" href� "l favicon. i co" />

</head>

Először is lássuk a <meta> elemet!

Karakterkódolás

Amikor azt látjuk, hogy "szöveg", valószínűleg azokra a "karakterekre és je

lekre" gondolunk, amelyeket "a számítógép képernyőjén látunk". A számítógé

pek azonban nem foglalkoznak karakterekkel és jelekkel, csak bitekkel és bájtokkal. Minden szöveg, amir a számítógép képernyőjén látunk, valójában egy

adott karakterkódolással tárolódik. Sokféle különböző karakterkódolás létezik: vannak, amelyeket bizonyos nyelvekhez igazítottak, például az oroszhoz, a kínaihoz vagy az angolhoz, míg másokat többféle nyelvhez is használhatunk.

Nagy vonalakban: a karakterkódolás bizrosírja a megfelelterést a képernyőn

látott szöveg és a számítógép memóriájában, illetve lemezén tárolt dolog között. A valóságban ez persze bonyolultabb. Sok karaktert több kódtáblában is

megralálunk, de az egyes kódolások más-más bájtsorozatot használharnak ahhoz, hogy ezeker a karaktereket a memóriában vagy a lemezen tárolják. A karakterkódolásra tehát a szöveg egyfajta visszafejtő kulcsaként gondolha

runk. Amikor valaki egy bájtsorozatot ad át nekünk, és azt állírja róla, hogy

"szöveg", tudnunk kell, hogy milyen karakterkódolást használt, hogy a báj

rokat visszafordírhassuk karakterekre, és megjeleníthessük (vagy feldolgozhassuk stb.) azokat.


Hogyan állapítja meg a böngésző egy webkiszolgálótól kapott bájtfolyam karakterkódolását? Örülök a kérdésnek. Ha ismerjük a HTTP-fejléceket, talán már láttunk ilyen fejlécet:

Content-Type: text/html; char set; "utf-8"

Ez röviden annyit tesz, hogy a webkiszolgáló úgy véli, hogy egy HTMLdokumentumot küld nekünk, és hogy a dokumentum az UTF-8 karakterkódolást használja. Sajnos a Világháló szövevényében nagyon kevés weboldal szerzője tartja ténylegesen az irányítása alatt a HTTP-kiszolgálót. Gondoljunk például a Bloggerre (http://www.blogger.com}: a tartalmat önálló szerzők szolgáltatják, de a kiszolgálókat a Google üzemelteti. A HTML 4 ezért módot adott rá, hogy magában a HTML-dokumentumban megadhassuk a karakterkódolást. Valószínűleg ilyesmit is láttunk már:

<meta http-equiv; "Content-Type" content; "text/html; charset;utf-8 ">

Ez röviden azt jelenti, hogy a a weboldal szerzője úgy véli, hogy egy HTMLdokumentumot készített, és ehhez az UTF-8 karakterkódolást használta.

Mindkét említett módszer működik a HTML5-ben is, a HTTP-fejlécben megadott karakterkódolás viszont előnyt élvez, és - ha szerepel az oldalon -felülbírálja a <meta> elemet. HTTP-fejlécet azonban nem mindenki állíthat be, ezért a <meta> címke még mindig létezik- sőt, a HTML5-ben valójában kicsit egyszerűsödött is. Most így néz ki:

<me ta char set; "utf-8" />

Ez minden böngészőben működik. De hogyan született meg ez a rövid forma? Íme a legjobb magyarázat, amit találtam (http:lllists.w3.org/Archives/Publicl public-html/2007]ul/0550.html}:

A <me ta char set=""> jellemzőkombináció mellett az az érv szól, hogy a felhasználói prograrnak (a böngészők) már megvalósították, mert a felhasznáJók hajlamosak lehagyni az idézőjeleket. Például:

<META HTTP-EQUIV;Content-Type CONTENT;text/html; charset;IS0-8859-1>

Ha nem hisszük el, hogy a böngészők már alkalmazzák ezt a megoldást, találunk néhány <meta charset>-tesztesetet is (http://simon.html5.orgltestl htmllparsinglencoding).



Kérdés: Én soha nem használok furcsa karaktereket. Akkor is be kell jelentenem az általam használt karakterkódolást? Válasz: Igen! Mindig, minden HTML-oldalunkon célszerű megadni egy karakterkódolást, mert ennek elmulasztása biztonsági rést üthet az oldalon (http://code.google. comlpldoctypelwiki!ArticleUtj7).

Összefoglalva: a karakterkódolás bonyolult, és a helyzeten nem könnyített az a sok-sok rosszul megírt szoftver sem, amit az évtizedek során a "másolás és beillesztés

" módszerrel dolgozó fejlesztök használtak. Mindig, minden HTML

dokumentumban adjuk meg a karakterkódolást, különben pórul járunk. Mindegy, hogy a Content-Type HTTP-fejléc, a <meta http-equiv> vagy a rövidebb <meta char set> címke segítségéve!, de mindenképpen tegyük meg. A Web előre is köszöni.

Viszonyleíró elemek

A szokványos hivatkozások (<a href>) egyszerűen egy másik oldalra mutatnak. A viszonyleíró elemek magyarázzák meg, hogy miért mutatunk egy másik oldalra. Lényegében befejezik a mondatot: "Azért mutatok erre a másik oldalra, mert ... "

• ... az egy stíluslap, amely azokat a CSS-szabályokat tartalmazza, amelyeket a böngészőnek erre az oldalra alkalmaznia kell.

• ... az egy hírfolyam, amely ugyanazt tartalmazza, mint ez az oldal, de szabványos előfizethető formátumban.

• ... az ennek az oldalnak egy másik nyelvre fordított változata. • ... az ugyanazt tartalmazza, mint ez az oldal, de PDF formátumban. • ... az a következő fejezete egy elektronikus könyvnek, amelynek ez is egy

oldala.

És így tovább. A HTML5 a viszonyleíró elemeket két csoportba sorolja (http:/1 bit.ly!d2cbiR):


A viszonyleíró elemekkel kétféle hivatkozás hozható létre. A külső erő

forrásra mutató hivatkozások olyan erőforrásokra mutatnak, amelyek az adott dokukentumot egészítik ki, míg ahiperhivatkozások más dokumentumokra mutató kapcsok. [ ... ] A külső erőforrásra mutató hivatkozások pontos viselkedése a konkrét kapcsolattól függ, amelyet az adott hivatkozástípusra meghatároztak.

Az iménti példák közül csak az első (rel= "stylesheet ") külső erőforrásra mutató hivatkozás, a többi más dokumentumokhoz kapcsolódó hiperhivatkozás. Ez utóbbi hivatkozásokat tetszés szerint követhetjük, vagy nem követhetjük, de az aktuális oldal megtekintéséhez nincs szükség rájuk.

A viszonyokat a leggyakrabban az oldal <he ad> részében szereplő <link>

elemek adják meg. Egyes viszonyok az <a> elemekben is megadhatók, de ez még a megengedett esetekben is ritka. A HTML5 az <area> elemekben is megenged bizonyos viszonyleíró elemeket- amit még ritkábban szoktak kihasználni. (A HTML 4 nem engedélyezte a rel jellemzőket az <area> elemekben.) A viszonyleíró elemek teljes táblázata megtekinthető a http://bit.ly/a3nsqi címen. Itt ellenőrizhetjük, hogy hol használhatjuk az egyes rel-értékeket.


Kérdés: Egyéni viszonyleíró elemeket is létre lehet hozni? Válasz: Új viszonyleíró elemekre - úgy tűnik - vég nélkül születnek ötletek. Megakadályozandó, hogy a felhasználók a saját fejük után menjenek, a WHAT munkacsoport jegyzéket tart fenn az elfogadásra benyújtott új rel-értékekről (http://wiki.whatwg.orglwiki/RelExtensions), és meghatározta az engedélyezési eljárás pontos menetét.

rel= stylesheet

Nézzük meg az első viszonyleíró elemet a mintaoldalunkon:

<link rel; "stylesheet" href; "style-original. ess" type; "text/ess" />

Ez a leggyakrabban használt viszonyleíró elem a világon (szó szerint). A <link rel= "stylesheet ">önálló fájlban tárolt CSS-szabályokra mutat. A HTML5-ben ezen egy olyan apró finomírást végezhetünk, hogy elhagyjuk


a type jellemzőt. A Weben csak egy stíluslapnyelv létezik, a CSS, ezért

a type jellemzőnek ez az alapértelmezett értéke:

<link rel= "stylesheet" href= "style-original. ess" l>

Ez minden böngészőben működik. (Egy nap persze valaki feltalálhat egy új stíluslapnyelvet, de ha ez bekövetkezik, csak annyit kell majd tennünk, hogy visszatesszük a type jellemzőt.)

rel= alternate

Folytassuk a mintaoldalunkat:

<link rel= "al terna te"

type="application/atorn+xrnl"

ti tle= "My Weblog feed"

href= "l feed/ " l>

Ez a viszonyleíró elem ugyancsak meglehetősen gyakori. A <link rel=

"alternate ">a type jellemzőben az RSS vagy Atom médiatípussal kombinálva az úgynevezett "automatikus hírfolyam-felderítést" teszi lehetövé, va

gyis a segítségével az olyan hírfolyamolvasók, mint a Google Reader, észlel

hetik, ha egy webhely hírfolyamot nyújt a legfrissebb cikkeibőL A legtöbb

böngésző azzal is támogatja az automatikus hírfolyam-felderítést, hogy egy különleges ikont jelenít meg az URL mellett. (A rel= "stylesheet" típus

tól eltérően itt számít a type jellemző, ezért ne hagyjuk el!) A rel="alternate" viszonyleíró elemet mindig furcsa módon keverve

használták, még a HTML 4-ben is. A HTML5-ben egyértelműbbé tették és kibővítették a meghatározását, hogy pontosabban írja le a meglevő webes tartalmakat. Ahogy az imént említettem, a rel="alternate" és a type=

application/atom+xml használata azt jelzi, hogy az adott oldahoz Atomhírfolyam tartozik. A rel="alternate" viszonyleíró elemet azonban más type jellemzőkkel is párosíthatjuk, hogy jelezzük: a tartalom más formátumban, például PDF-ként is elérhető.

A HTML5 annak a régi vitának is véget vet, hogy pontosan hogyan kell

hivatkozni a dokumentumok más nyelvre lefordított változataira. A HTML 4 azt mondja, hogy a lang jellemzőt kell használni a rel="alternate"

viszonyleíró elemmel párban, hogy megadjuk a hivatkozott dokumentum

nyelvét, de ez tévedés. A HTML 4 hibajegyzéke négy egyértelmű hibát sorol fel a HTML 4 szabványleírásából (számos "nyomdahiba" mellett), és ezek


egyike éppen az, hogy miként kell egy a rel= "alte rnate" elemmel hivat

kozott dokumentum nyelvét meghatározni. (A helyes megoldás - ahogy

a HTML 4 hibajegyzékében és most már a HTML5-ben is áll- a h reflang

jellemző használata.) Sajnos ezeket a hibajavításokat soha nem építették be

a HTML 4 szabványba - mivel a W3C HTML-munkacsoportjából már

senki nem dolgozott többé a HTML-en.

Egyéb viszonyleíró elemek a HTML5-ben

rel = "archives"

(http://bit.lylclzlyG) "Azt jelzi, hogy a hivatkozott dokumentum jegyze

tek, dokumentumok vagy más történeti érdekességű anyagok gyűjtemé

nyét írja le. Egywebnapló (blog) nyitóoldala például a rel= "archives"

segítségével hivatkozhat a korábbi naplóbejegyzések tárgymutatójára."

rel = "author"

Ez az elem az oldal szerzőjére vonatkozó információkra mutar. Az infor

máció lehet például egy ma i l to: cím, bár nem muszáj annak lennie

- a hivatkozás mutathat egyszerűen egy kapcsolati űrlapra vagy egy a

szerzőt bemutató oldalra ("about the author") is.

rel = "external"

(http://bit.ly/dBV009) "Azt jelzi, hogy a hivatkozás egy olyan dokumen

tumhoz vezet, amely nem része annak a webhely nek, amelyen az aktuális

dokumentum található." Azt hiszem, ezt a viszonyleíró elemet a Word

Press tette először népszerűvé, ahol a hozzászólók által beszúrt hivatko

zásokra alkalmazzák

rel = "start", rel= "p rev " és rel= "next "

(http:llwww.w3.org/TR!html40Jitypes.html#type-links) Ezekkel olyan ol

dalak között határozunk meg kapcsolatokat, amelyek egy sorozat részét

(például egy könyv fejezeteit vagy akár egy webnapló bejegyzéseit) képezik.

Az egyetlen, amelyet valaha is helyesen használtak, a rel= "next";

rel= "p rev" helyett viszont már rel= "previ ous "-t szaktak írni,

rel= "start" helyett a helytelen rel= "begi n" vagy rel= "first"

alakot használják, rel= "last" helyett pedig a rel= "end "-et. Ja, és

a saját ujjukból szopott rel= " up" hivatkozással mutatnak a "szülő

oldalakra".

3. fejezet Mit jelent mindez? J 67

A HTML5 ugyanakkor tartalmazza a rel="first" alakot, amelyet a leggyakrabban használtak arra, hogy azt mondják, hogy "egy sorozat első oldala

" (a visszamenőleges megfelelőség kedvéért a rel= "start"

is megmaradt), a HTML 4-hez hasonlóan a re l= "p rev" és re l=

"next" viszonyleíró elemeket (ezenkívül a visszamenőleges megfelelőség kedvéért támogatja a rel= "previo us "-t), valamint a sorozat utolsó tagjára mutató rel= "las t "-ot (a re l= "first" párját) és a rel="up" viszonyt is.

A re l= "u p" leginkább a "morzsaútvonalra"

( breadcrumb navigation) hasonlít, amelyen valószínűleg a nyitóoldalunk az első oldal, az aktuális oldal pedig az útvonal utolsó eleme. A rel= "up" a morzsaútvonal utolsó előtti elemeként szereplő oldalra mutat.

rel= "icon"

(http://bit.ly/diA]UP) Ez a második legnépszerűbb viszonyleíró elem (http:/1

code.google. com/webstats/2005-12/linkrels. h tm l) a r e l=" st y le sh e et"

után. Általában a shortcut-tal együtt szerepel, valahogy így:

<link rel= "shortcut icon" href= "/favicon. i co">

Minden jelentősebb böngésző támogatja, hogy így társírsunk egy apró ikont az oldalhoz, ami általában a böngésző címsávjában az URL mellett jelenik meg, vagy az oldalhoz tartozó böngészőfülön, vagy mindkét helyen.

Szintén újdonság a HTML5-ben, hogy a sizes jellemzőt az icon

elemmel együtt használva a hivatkozott ikon méretét is jelezhetjük (http://bit.ly/diA]UP).

rel= "license"

(http:llbit.lyl9n9Xjv) Ezt a viszonyleíró elemet a mikroformátumok közössége találta ki. Azt jelzi, hogy "a hivatkozott dokumentum adja meg, hogy milyen szerzői és felhasználási feltételek hatálya alá tartozik az aktuális dokumentum.

"

rel = "nofollow"

(http://bit.lylcGjSPi) "Azt jelzi, hogy az eredeti szerző vagy az oldal üzemeltetője nem vállal felelősséget a hivatkozott dokumentumért, vagy hogy a hivatkozás elsősorban azért került a dokumentumba, mert a két oldalhoz társítható személyek üzleti kapcsolatban állnak egymással.

"

Ezt az elemet a Google találta ki, és a mikroformátumok közössége szabványosította. Az elgondolás az volt, hogy ha a "nofollow

" ( "nem köve-


tendő") hivatkozások nem számítanak a keresők oldalrangsorában (Page

Rank), akkor a levélszemetelők feladják, hogy kéretlen leveleket küldöz

gessenek a blogokra. Ez hiú ábrándnak bizonyult, de a rel= "nofollow"

megmaradt, és sok népszerű webnaplórendszer alapértelmezés szerím

a rel= "nofollow" viszonyt rendeli a hozzászólók által beszúrt hivat

kozásokhoz.

rel = "noreferrer"

(http:llbit.lylcQMS]g) "Azt jelzi, hogy a hivatkozás követésekor nem sza

bad információt kiszivárogtatni a hivatkozóról (referrer)". Ezt jelenleg

egyetlen forgalomban levő böngésző sem támogatja, de nemrég bekerült

a WebKit-be, így végül meg fog jelenni a Safariban, a Google Chrame

ban és más WebKit alapú böngészőkben. A rel= "noreferrer "-hez

a http:llwearehugh. comlpublic/2009104/rel-noreferrer. h tm! címen találha

tunk egy tesztesetet.

rel = "pingback"

(http:l!bit.lylc!AGXB) Egy "

pingback" kiszolgáló címét adja meg. Ahogy

a Pingback leírásában (http://hixie. chlspecslpingbacklpingback-1. O) szere

pel, a "

pingback rendszer arra szolgál, hogy egy webnapló automatikus

értesítést kaphasson, amikor más webhelyek rá mutató hivatkozást tesz

nek közzé. [ ... ], vagyis fordított hivatkozást tesz lehetövé, a hivatkozási

láncon felfelé haladva, és nem egyszerűen mélyebbre ásva." A webnapló

rendszerek-elsősorban a WordPress-a pingback ("visszhangértesítés")

megvalósításával értesítik a szerzőket a rájuk mutató új hivatkozásokról,

amikor új webnapló-bejegyzést hoznak létre.

rel = "prefetch"

(http:!lbit.ly/9oOnMS) "Azt jelzi, hogy a megadott erőforrás előzetes le

kérése és gyorstárazása jótékony hatású lehet, mivel igen valószínű, hogy

a felhasználónak szüksége lesz rá." A keresőprogramok néha hozzáadják

a <link rel="prefetch" h ref ="<emphasis>Az első

helyre rangsorolt oldal URL-je</emphasis>"> kódot

a találari oldalhoz, ha úgy érzik, hogy az első helyre rangsorolt oldal

lényegesen népszerűbb a többiné!. Próbáljuk ki például a Firefoxban,

hogy a Google-ben végrehajtunk egy keresést a CNN kifejezésre: ha

megnézzük a találari oldal forrását, megtalálhatjuk benne a prefetch

kulcsszót. Jelenleg a Mozilla Firefax az egyetlen böngésző, amelyik tá

mogatja a rel="prefetch" viszonyleíró elemet.

3. fejezet Mit jelent mindez? l 69

rel= "search"

(http:!lbit.ly!aApkaP) "Azt jelzi, hogy a hivatkozott dokumentum ren

delkezik kifejezetten a dokumentumban és a hozzá kapcsolódó erő

forrásokban való keresésre szolgáló felülettel." Ha azt szeretnénk, hogy

a rel= "search" valóban hasznos legyen, a hivatkozásnak egy Open

Search-dokumentumra kell mutatnia, amely leírja, hogy a böngészők

hogyan építhetnek fel egy olyan URL-t, amellyel egy adott kulcsszó

előfordulásait megkereshetik az aktuális webhelyen. Az OpenSearch

dokumentumokat (illetve a rel= "search" hivatkozásokat, amelyek

ilyen leíró OpenSearch-dokumentumokra mutatnak) a Microsoft Inter

net Explorer a 7-es, a Mozilla Firefox pedig a 2-es változat óta támo

gatja.

rel= "sidebar"

(http:!!bit.lylazTA9D) "Azt jelzi, hogy a hivatkozott dokumentumot

amennyiben lekérik- (lehetőség szerint) egy másodiagos böngészőkör

nyezetben, és nem az aktuális böngészőkörnyezetben kell megjelení

teni." Mit jelent mindez? Az Operában és a Mozilla Firefaxban azt, hogy

"amikor erre a hivatkozásra kattintok, kérdezd meg a felhasználót, hogy

létre kíván-e hozni egy könyvjelzőt, amely a Boomarks (Könyvjelzők)

menüből kiválasztva egy oldalsávban nyitja meg a hivatkozott doku

mentumot." (Az Opera valójában "panelnek" hívja az "oldalsávot".) Az

Internet Explorer, a Safari és a Chromc figyelmen kívül hagyja a rel =

"sidebar "-t, és a hivatkozást normál hivatkozásként kezeli. A rel=

"s idebar "-hoz a http://wearehugh. comlpublic/2009/04/rel-sidebar. html

címen találhatunk egy tesztesetet.

rel= "tag"

(http:!lbit.lyl9bYlfo) "Azt jelzi, hogy a címke, amelyet a hivatkozott do

kumentum jelképez, alkalmazható az aktuális dokumentumra." A "cím

kék" (kategória-kulcsszavak) megjelölését a rel jellemzővel a Technorati

találta ki, hogy segítsen a webnapló-bejegyzések csoportosításában, ezért

a régebbi webnaplók és oktatóanyagok "Technorati-címkék" néven hi

vatkoztak rájuk. (Igen, jól értettük: egy üzleti vállalkozás rábeszélte az

egész világot, hogy használjanak metaadatokat, hogy megkönnyítsék

a cég dolgát. Szép teljesítmény!) Az utasításformát később a mikroformá

tumok közössége szabványosította; itt kapta az egyszerű rel= "t ag"

nevet. A legtöbb webnaplórendszer, amely megengedi, hogy az egyes


bejegyzéseket kategóriákba soroljuk, illetve kulcsszavakat vagy címkéket

rendeljünk hozzájuk, re l= "tag" hivatkozásokkal látja el a bejegyzése

ket. A böngészők ezekkel nem csinálnak semmi különöset, hiszen csupán

arra valók, hogy a keresőknek jelezzék, hogy miről szól az adott oldal.

Új jelentéstükröző elemek a HTML5-ben

A HTML5-nek nem csak az a célja, hogy a meglevő kódokat lerövidíthessük

( bár jelentősen segít ebben), hanem több új jelentéstükröző (szemantikus)

elemet is meghatároz. A HTML5 szabvány a következő elemeket írja le:

<section>

A s ection (szakasz) elem egy dokumentum vagy alkalmazás egy ál

talános értelemben vett szakaszát jelképezi. Ebben az összefüggésben

a szakasz egy adott téma köré csoportosított tartalom, amelynek jellem

zően van egy címsora. Szakaszok például a fejezetek, a füles párbeszéd

ablakok különféle lapjai, vagy egy szakdolgozat számozott részei. Egy

webhely nyitóoldalát különböző szakaszokra- bevezetés, hírek, kapcso

lati információk- lehet osztani.

<na v>

A nav elem egy oldal egy olyan szakaszát jelképezi, amely más olda

lakra vagy az adott oldal más részeire hivatkozik, tehát egy navigációs

hivatkozásokkal ellátott szakaszt. Egy oldalon nem minden hivatkozás

csoportnak kell nav elemen belül szerepelnie, hanem csak azoknak

a szakaszoknak, amelyek fontosabb navigációs blokkokból állnak. A láb

lécben például a webhely különböző oldalaira murató hivatkozások- szol

gáltatási feltételek, nyitóoldal, szerzői jogok stb. - rövid listáját szakták

elhelyezni, de ilyenkor a footer (lábléc) elem önmagában elég, nincs

szükség nav elemre.

<art i ele>

Az a rticle (cikk) elem egy önálló, független közzétételre vagy újra

hasznosításra (például hírsugárzásra) alkalmas egységet jelképez egy do

kumentumon, oldalon, alkalmazáson vagy webhelyen belül. Ez az egység

lehet fórum- vagy webnaplóbejegyzés, újságcikk, felhasználói hozzászó

lás, interaktív vezérlő, illetve bármilyen más önálló tartalomegység.

3. fejezet Mit jelent mindez? J 71

<a side>

Az aside ("mellesleg") elem egy oldal egy olyan szakaszát jelképezi, amely a körülötte levő tartalomhoz csupán érintőlegesen kapcsolódik, de attól függetlennek tekinthető. Az ilyen szakaszokat nyomtatásban általában külön dobozba (oldalsávba) rakják. Az aside elemet olyan tipográfiai hatásokhoz használhatjuk, mint a behúzott idézetek vagy az oldalsávok, illetve reklámokat, na v elemcsoportokat, valamint az oldal fő tartalmához szorosan nem kötődö más tartalmakat helyezhetünk el bennük.

<hgroup>

A hgroup (címsorcsoport) elem egy szakasz címsorait jelképezi. Ezzel az elemmel csoportosíthatjuk a hl-h6 elemeket, amikor a címsoroknak több szintje van, például alcímeket vagy mottókat is használunk.

<header>

A header (címsor/fejléc) elem bevezető elemek vagy navigációs segédek egy csoportját jelképezi. Általában egy szakaszcímsort (egy hl-h6

vagy egy hgroup elemet) helyeznek el benne, de ez nem kötelező. A header elem egy szakasz tartalomjegyzékének, egy keresőűrlapnak vagy egy kapcsolódó emblémának a beburkolására is használható.

<footer>

A footer (lábléc) elem a legközelebbi szakaszképző szülőtartalom vagy gyökérelem láblécét jelképezi. A láblécben jellemzően olyan információk szerepeinek a vonatkozó szakaszról, mint a szakasz szerzője, a kapcsolódó dokumentumokra mutató hivatkozások, a szerzői jogi információk és hasonlók. A lábléceknek nem feltétlenül kell egy szakasz végén szerepelniük bár általában ott szokták elhelyezni őket. Ha a footer elem teljes szakaszokat tartalmaz, függeléket, tárgymutatót, hosszú kolofont, részletes felhasználási engedélyt vagy más hasonló tartalmat jelöl.

<time>

A time (idő) elem vagy egy (24 órás időbeosztású) időpontot, vagy egy konkrét dátumot jelöl a Gergely-naptárban (nem kötelezően kiegészítve egy időponttal és egy időzóna-eltéréssel).

<mark>

A mark (megjelölés/kiemelés) elem egy olyan szövegrészt jelképez egy dokumentumon belül, amelyet hivatkozás céljából megjelöltek vagy kiemeltek.


Tudom, hogy az Olvasó már alig várja, hogy használatba vegye ezeket az új

elemeket - különben nem olvasná ezt a fejezetet. Először azonban még tennünk kell egy kis kitérőt.

Hosszú kitérő arról, hogy miként

kezelik a böngészők az ismeretlen elemeket

Minden böngészőnek van egy "mesterlistája" azokról a HTML-elemekről,

amelyeket támogat. A Mozilla Firefox listáját például az nsElementTable.cpp

fájl tárolja (http:llmxr.mozilla.orglseamonkeylsourcelparserlhtmfparserlsrclmElement Tabfe.cpp). Az ebben a listában nem szereplő elemek "ismeretlen elemeknek" mi

nősülnek. Az ismereden elemekkel kapcsolatban két alapvető kérdés merül fel:

Hogyan formázandó az elem? Alapértelmezés szerint a <p> elemek felett és alatt térköz található, a <blockquote> elemek balról behúzottak, a <hl> elemek pedig

nagyobb betűvel jelennek meg. Hogyan kell kinéznie az elem DOM-jának?

A Mozilla nsElementTable.cpp fájlja arról is tartalmaz információt, hogy

az egyes elemek milyen más elemeket tartalmazharnak. Ha azt írjuk

például, hogy <p><p>, akkor a második bekezdéselem közvetetten be

zárja az elsőt, így a két elem testvér lesz, nem pedig szülő és gyermek. Ha viszont azt írjuk, hogy <p><span>, akkor a span nem zárja be

a bekezdést, mert a Firefox tudja, hogy a <p> tömbelem (blokkelem), amely tartalmazhat belső <span> elemet. A <span> tehát a <p>

gyermeke lesz a DOM-ban.

A különböző böngészők más-más választ adnak ezekre a kérdésekre. ( Tudom, megdöbbentő.) A fontosabb böngészők közül a Microsoft Internet Explorer

válaszaival van a legtöbb gond.

Az első kérdésre adott válasznak viszonylag egyszerűnek kellene lennie: az ismereden elemek ne kapjanak semmilyen különleges formázás t, csak örököljék azokat a CSS-tulajdonságokat, amelyek a megjelenésük helyén érvényben

vannak az oldalon, és minden formázást az oldal szerzője határozzon meg

CSS segítségéveL Sajnos az Internet Explorer (a 9-es változat előtt) egyáltalán


nem engedi meg az ismereden elemek formázását. Tegyük fel például, hogy a következő leírókódunk van:

<st y le type= "text/ ess">

article { display: black; border: lpx solid red l </style>

<article>

<hl>Welcome to Initech</hl>

<p>This is you r <span>first da y</ span>. </p>

</article>

Az Internet Explorer (az IE8-cal bezárólag) nem tesz vörös keretet a cikk köré. E könyv írásának idején az Internet Explorer 9 még csak bétaváltozatban létezett, de a Microsoft bejelentette (és a fejlesztök megerősítették), hogy az Internet Explorer 9-ben már nem lesz jelen ez a probléma.

A másik gondot a DOM okozza, amelyet a böngészők akkor építenek fel, amikor ismereden elemekkel találkoznak. Ebben a tekintetben is az Internet Explorer a fekete bárány. Ha az IE nem ismeri fel egyértelműen az elem nevét, akkor az elemet üres, gyermektelen csomópontként szúrja be a DOM-ba. Így minden elem, amelyről azt feltételeznénk, hogy az ismereden elemnek közveden gyermeke lesz, ehelyett testvérként kerül a DOM-ba.

Lássuk a különbséget egy ASCII-ábrán! Ez a DOM következne a HTMLSből:

article

+--hl (az article gyermeke)

l l l +--szövegcsomópont "Welcome to Initech"

l +--p (az article gyermeke, a hl testvére}

l +--szövegcsomópont "This is your "

l +--span

l l l +--szövegcsomópont "first da y"

l +--szövegcsomópont ". "


Az Internet Explorer azonban valójában ezt a DOM-ot hozza létre:

article (nincsenek gyermekek)

hl (az article testvére)

l +--szövegcsomópont "Welcome to Initech •

p (a hl testvére)

l +--szövegcsomópont "This is your •

l +--span

l l l +--szövegcsomópont "first da y • l +--szövegcsomópont "."

Van azonban egy csodálatos kerülő megoldás erre a problémára. Ha JavaScript segítségével létrehozunk egy <article> álelemet, mielőtt ezt az elemet használnánk az oldalon, az Internet Explorer varázsütésre felismeri, és hagyja, hogy CSS-sel formázzuk Az áldemet egyáltalán nem szükséges beszúrni a DOM-ba. Elég (oldalanként) egyszer létrehozni az elemet, hogy megtanítsuk az IE-nek, hogy formáznia kell az ismeretlent. Például:

<html>

<head>

<st y le>

art i ele { display: block; border: lpx solid red } </st y le>

<script>document.createElement("article");</script> </head>

<body>

<article>

<hl>Welcome to Initech</hl>

<p>This is you r <span>first da y</ span>. </p>

</article>

</body>

</html>

Ez a megoldás az Internet Explorer valamennyi változatában működik, egészen az IE 6-ig visszamenőleg! A módszert kiterjeszthetjük, és egyszerre minden új HTML5-elemből létrehozhatunk álpéldányokat - amelyek soha nem kerülnek be a DOM-ba, így nem is fogjuk látni őket-, és rögtön használatba is vehetjük őket, anélkül, hogy túlságosan aggódnunk kellene a HTML5-öt nem ismerő böngészők miatt.


Remy Sharp éppen ezt tette a találóan "HTML5 enabling script"-nek elnevezett parancskódjával (http:llremysharp.com/2009/0I/07/html5-enablingscript). A parancskód számos átdolgozáson esett át, de az alapödet ez:

<1--[if lt IE 9]>

<script>

var e: ("abb r, article, a side, audio, canvas, datalist, details, "+

"figure,footer,header,hgroup,mark,menu,meter,nav,output, " +

"progress,section,time,video") .split(' ,');

for (var i: O; i< e.length; i++) { document.createElement(e[i]);

) </script>

<! [endif]-->

Az részek feltételes megjegyzések, amelyeket az Internet Explorer úgy értelmez, mint egy if ("ha") utasítást:

"ha az aktuális böngésző az Internet Explorer 9-esnél régebbi változata, hajtsd végre ezt a kódblokkot". Minden más böngésző HTML-megjegyzésként kezeli a teljes blokkot. Az eredmény: az Internet Explorer (a 8-as változattal bezárólag) végrehajtja a fenti parancskódot, a többi böngésző azonban teljesen figyelmen kívül hagyja, így az oldal gyorsabban töltődik be azokban a böngészőkben, amelyekben nincs szükség erre a trükkre.

Maga a JavaScript-kód viszonylag egyszerű. Az e változóból egy olyan karakterláncokból álló tömb lesz, mint az "abbr ",az "article ",az "a side",

és így tovább. Ezt követően egy ciklussal végigjárjuk ezt a tömböt, és a document. createElement ( ) meghívásával létrehozzuk a nevesített elemeket. Mivel azonban a visszakapott értéket figyelmen kívül hagyjuk, az elemek nem szúródnak be a DOM-ba. Mindazonáltal, ez elég ahhoz, hogy az Internet Explorer úgy kezelje ezeket az elemeket, ahogy szeretnénk, amikor az oldal későbbi részében ténylegesen használatba vesszük öket.

A "később" lényeges: ennek a parancskódnak az oldal elején kell szerepelnie - lehetőleg a <head> elemben -, nem pedig a végén. Így az Internet Explorer még az előtt végrehajtja a parancskódo t, hogy feldolgozná a címkéket és a jellemzőket. Ha a parancskódot az oldal végére tesszük, túl késő lesz: az Internet Explorer ekkorra már félreértelmezi a leírókódot, és hibás DOM-ot hoz létre - emiatt a parancskód miatt pedig nem fog visszamenni, és kijavítani a hibát.

Remy Sharp "összesűrítette" ezt a parancskódot, és elhelyezte a Google Project Hosting (http:llcode.google.comlplhtml5shivl) oldalán. (Ha esetleg

76 l Mit jelent mindez? 3. fejezet

érdekelne minket, maga a parancskód nyílt forrású, és MIT-engedéllyel rendelkezik, így tetszőleges projektben felhasználhatjuk.) Ha szeretnénk, még

"forró hivatkozással" is kapcsolódhatunk a parancskódhoz, tehát közvetlen ül mutathatunk a fenti címen elhelyezett változatra - valahogy így:

<he ad>

<me ta charset= •utf-8" />

<title>My Weblog</title>



</head>

Ezzel készen is állunk a HTML5 új jelentéstükröző elemeinek használatára.

Címsarok

Térjünk vissza a mintaoldalunkhoz- egészen pontosan a címsorokhoz:

<d i v id= "header">

<hl>My Weblog</hl>

<p class= "tagline ">A lot of effort wen t in to ma king this effortless. </p>

</div>

<d i v class= "en try">

<h2>Travel day</h2>

</div>

<div class= •en try">

<h 2> I'm going to Prague 1 </h2>

Ezzel a résszel nincs semmi gond. Ha tetszik, megtarthatjuk, mert érvényes HTML5-kód. A HTML5 azonban további elemeket is biztosít a címsorok és szakaszok számára.

Először is, szabaduljunk meg a <d i v id= "header"> rész től. Ez nagyon gyakori címke, de semmit nem jelent. Adivelemnek nincs meghatározott jelentése, ahogy az id jellemzőnek sem. (A böngészőknek nem szabad semmilyen jelentésre következtetniük az id jellemző értékéből.) Ha az említett

címkét mondjuk <div id="shazbot">-ra változtatnánk, ugyanannyi jelentéssel bírna - semennyiveL

A HTML5 azonban erre a célra meghatároz egy <header> elemet. A HTML5 szabványleírása több, a valós életből vett példát is bemutat a <header>

elem használatára. A mintaoldalunkon így festene:

<header>

<hl>My Weblog</hl>

<p class� "tagline ">A lot of effort wen t in to ma king this effortless. </p>

</header>

Ez jó, mert bárkinek, akit érdekel, elárulja, hogy egy címsorról van szó. De mi a helyzet a roottóval (tagline)? Ilyet is gyakran szoktak használni, de eddig nem volt rá szabványos leírókód, mert nem könnyű jelölni. A mottó olyan, mint egy alcím, de az elsődleges címhez "kapcsolódik"- vagyis olyan alcím, amely nem hoz létre saját szakaszt.

Az oldal szerkezetét olyan címsorelemek hozzák létre, mint a <hl> és a <h2>. Együtt egy olyan vázlatot alakítanak ki, amely segít magunk elé képzelni az oldalt, illetve megkönnyíti a mozgást az oldalon belül. A képernyőolvasó prograrnak a dokumentumvázlatra támaszkodva segítik a vak felhasználókat, hogy eligazadjanak az oldalon. A dokumentumvázlat képi megjelenítésére internetes eszközöket (http:llgsnedders.html5.orgloutlinerl) és böngészőbővítményeket (http:llchrispederick. comlworklweb-developerl) is használhatunk.

A HTML 4-ben kizárólag <hl>-<h6> elemekkel lehetett dokumentumvázlatot létrehozni. A mintaoldalunk vázlata így fest:

MyWeblog (hl)

l

+--Travel day (h2)

l

+--I'm going to Prague! (h 2)

Ez mind szép, de azt jelenti, hogy nincs mód az "A lot of effort went into making this effortless" ("Egy csomó problémát oldottunk meg, hogy a megoldás problémamentes legyen") mottó felcímkézésére. Ha <h2> címsorként próbáljuk megjelölni, egy fanromcsomópont jelenik meg a dokumentumvázlatban:


My Weblog (hl)

l +--A lot of effort wen t into making this effortless. (h2)

l +--Travel day (h2)

l +--I'm going to Prague' (h2)

Ez azonban nem a dokumentum tényleges szerkezete, hiszen a mottó csupán egy alcím; szakaszt nem jelképez.

És mi lenne, ha a mottót <h 2> címsorként jelölnénk meg, az egyes cikkek címei viszont <h3> címkét kapnának? Nem, ez még rosszabb:

My Weblog (hl)

l +--A lot of effort went in to making this effortless. (h2)


l +--I'm going to Prague! (h3)

A fantomcsomópont továbbra is ott van a dokumentumvázlatban, ráadásul

"ellopja" a gyökércsomóponthoz tartozó gyermekeket. Pontosan ebben rejlik

a probléma: a HTML 4 nem ad módot arra, hogy anélkül adjunk meg egy alcímet, hogy hozzáadnánk a dokumentumvázlathoz. Nem számít, hogyan keverjük a kártyákat, az "A lot of effort wem into making this effortless" mottó mindenképpen fel fog bukkanni a vázlatban - ezért használtunk egy olyan jelentéssei nem bíró kódot, mint a <p class= "tagline">.

A HTML5 azonban kínál erre egy megoldást: a <hgroup> elem használatár. A <hgroup> elem két vagy több kapcsolódó címsorelem burkolójaként működik- de mit jelent az, hogy

"kapcsolódó"? Nos, azt jelenti, hogy a kap

csolódó elemek együtt egyeden csomópontot hoznak létre a dokumentumvázlatban.

Vegyük ezt a leírókódot:

<header>

<hgroup> <hl>My Weblog</hl>

<h2>A lot of effort wen t in to ma king this effortless. </h2> </hgroup>

</header>


<di v class= "en try">

<h2>Travel day</h2>

</div>

<d i v class= "en try">

<h2> I'm going to Prague! </h2>

</div>

A fenti kód ezt a dokumentumvázlatot hozza létre:

My Weblog (a hgroup hl eleme)


l +--I'm going to Prague! (h2)

A saját oldalainkat a HTML5 Outliner segítségével megvizsgálva győződhetünk meg arról, hogy helyesen használjuk-e a címsorelemeket.

Cikkek

A mintaoldalunkat folytatva, lássuk, mit tehetünk ezzel a kóddal:

<di v class= "en try">

<p class= "post-date ">October 22, 2009</p>

<h 2>

<a href="# •

rel= "bookmark •

ti tle= "link to this post"> Travel day

<la> </h2>

</div>

Ez ismét csak érvényes HTML5-kód, de a HTML5-ben van egy konkrétabb elem is arra, hogy egy oldalon megjelöljünk egy cikket - a találó nevű <article> ("cikk") elem:

<article>



<h 2>

<a href="# •

rel= "bookmark •

title= "link to this post">

Travel day

</a>

</h2>

</article>

Na persze ez nem ilyen egyszerű. Még egy módosítást végre kell hajtanunk. Először megmutatom, aztán elmagyarázom:

<article>

<header>


<hl>

<a href= "#"

rel="bookrnark"


Travel day

</a>

</hl>

</header>

</article>

Észrevettük? A <h2> elemet <hl>-re változtattam, és egy <header> elembe burkoltam. A <header> elemet már láttuk működés közben. A célja az, hogy beburkolja a cikk fejlécét alkotó összes elemet (vagyis ebben az esetben a cikk közzétételének dátumát és a cikk címét). De ... de ... de <hl> elemből nem csak egy lehet egy dokumentumban? Nem fogja ez tönkretenni a dokumentumvázlatot? Nem, de ahhoz, hogy megérthessük, miért nem, vissza kell lépnünk egy kicsit.

A HTML 4-ben kizárólag <hl>-<h6> elemekkeliehetett dokumentumvázlatot létrehozni. Ha a vázlatban csak egyetlen gyökércsomópontot akartunk, a leírókódban egyetlen <hl> elemre kellett szorítkoznunk. A HTML5 szabvány azonban egy olyan algoritmust határoz meg a dokumentumvázlatok előállítására, amely a HTML5 új jelentéstükröző elemeire támaszkodik. A HTML5 algoritmusa azt mondja, hogy az <article> elemek új szakaszt hoznak létre, vagyis új csomópontot a dokumentumvázlatban- a HTML5-ben viszont minden szakasznak saját <hl> eleme lehet.


Ez drasztikus és előnyös változás a HTML 4-hez képest. Hogy miért előnyös? Nos, sok weboldalt valójában sablonok alapján állítanak elő. A tartalom egy részét az egyik forrásból nyerik ki és szúrják be az oldalba, a másik része pedig egy másik forrásból származik, és az oldal egy másik részén helyezik el. Sok oktatóanyagat ugyanígy építenek fel: "Itt egy HTML-részlet- csak másolj uk le, és illesszük be az oldalunkba.". Ez kis mennyiségű tartalomnál megfelel, de mi a helyzet, ha a heilleszrendő kód egy reljes szakaszt felölel? Ebben az esetben az oktatóanyag valami ilyesmit fog mondani: ",tt egy HTMLrészlet - csak másoljuk le, illesszük be egy szövegszerkesztőbe, és igazítsuk a címsorelemeket úgy, hogy megfeleljenek a céloldal címsorelemei beágyazási szintjének.".

Hadd fogalmazzam meg másként. A HTML 4-ben nincs általános címsorelem, csak hat szigorúan számozott címsor (<hl>-<h6>), amelyeket pontosan a számozásnak megfelelő sorrendben kell egymásba ágyazni. Ez elég kényelmetlen, különösen ha az oldalunkat "összeszereljük", nem pedig "megírjuk". Ezt a problémát oldja meg a HTML5 az új szakaszaló elemekkel és a meglevő címsorelemekre vonatkozó új szabályokkaL Ha az új szakaszaló elemeket használjuk, ezt a kódot ajánihatom fel:

<article>

<header>

<hl>A syndicated post</hl>

</header>

<p> Lorern ips um blah blah ... </p>

</article>

Ezt a kódot lemásolhatjuk, és az oldalunkon bárhová beilleszthetjük módosítás nélkül. Az, hogy tartalmaz egy <hl> elemet, nem jelent gondot, mert az egészet egy <article> elem zárja magába. Az <article> elem egy önálló csomópontot határoz meg a dokumenrumvázlarban, a <hl> elem ennek a csomópontnak a címét adja meg, az oldal összes többi szakaszaló eleme pedig azon a beágyazási szinten marad, mint korábban.



Mint mindenre, ami a Weben található, a fentiekre is igaz, hogy a va

lóság kissé bonyolultabb annál, mint ahogy én lefestem. Az új "kifeje

zett" szakaszoló elemek (mint az <article> elembe burkolt <hl>)

kiszámíthatatlan kölcsönhatásba kerülhetnek a régi, "beleértett" szakaszoló elemekkel (az önmagukban álló <hl>-<h6> elemekkel). Az éle

tünk egyszerűbb lesz, ha csak az egyiket vagy a másikat használjuk, de nem mindkettőt. Ha mindkettőt használnunk kell egy oldalon belül, mindenképpen ellenőrizzük az eredményt a HTML5 Outlinerben, és győződjünk meg róla, hogy értelmes dokumentumvázlatot kapunk.

Dátumokés időpontok

Izgalmas, nem? Persze nem annyira izgalmas, mint meztelenül lesikJani a Mount Everestről, miközben visszafelé énekeljük az amerikai himnuszt, de egy jelentéstükröző leírókódtól nem rossz. De folytassuk a minraoldalunk elemzését. A következő sor, amire fel szeretném hívni a figyelmet, ez:

<div class= "entry ">

<p class="post-date">October 22, 2009</p> <h2>Travel day</h2>

</div>

Már megint a régi nóta, igaz? Egy szokványos információközlés - egy cikk közzétételi dátumának jelzése -, amelyhez nem áll rendelkezésre megfelelő jelentéstükröző elem, ezért a szerzőknek egyéni class jellemzőkkel ellátott általános leírókódokra kell szorítkozniuk. Itt is igaz persze, hogy ez érvényes

HTML5-kód, tehát nem kötelező megváltoztatnunk. A HTML5 azonban konkrét megoldást is kínál az ilyen esetekre: a <time> elemet:

<time date time= "2009-10-22" pubdate>October 22, 2009</time>

A <time> elemek három részből állnak: • A számítógép által olvasható időbélyegből

• Az ember által értelmezhető szöveges tartalomból • Az elhagyható pubdate jelzőből


Ebben a példában a datetime jellemző csak egy dátumot határoz meg, időpontot nem. A formátum: négy számjegyű év, két számjegyű hónap és két számjegyű nap, kötőjelekkel elválasztva:

<time datetime="2009-10-22" pubdate>October 22, 2009</time>

Ha időpontot is meg akarunk adni, írjuk a T betűt a dátum után, majd az időpontot 24 órás formában, végül pedig egy időzóna-eltérést:

<time da tet ime� "2009-10-22T13: 59:47-04:00" pubdate>

October 22, 200 9 l: 59pm EDT

</time>

A dátum- és időformátum elég rugalmas. A HTMLS szabványleírása több példát is tartalmaz az érvényes dátum- és idő-karakterláncokra.

Figyeljük meg, hogy megváltoztattam a szövegtartalmat-a <time> és </time> címkék közötti részt-, hogy illeszkedjen a számítógép által olvasható időbélyeghez. Ez nem kötelező; a szövegtartalom tetszőleges lehet, amíg a datetime jellemzőben egy számítógép által olvasható dátum- és időbélyeget adunk meg. Ez tehát érvényes HTMLS-kód:

<time da tet ime� "2009-10-22 ">múlt csütörtök</ time>

És ez is:

<time datetime� "2009-10-22 "></time>

A kirakósjáték utolsó darabja itt a pubdate jellemző. Ez egy logikai jellemző, ezért csak annyit kell tennünk, hogy beírjuk, ha szükségünk van rá, valahogy így:

<time datetime� "2009-10-22 "pubdate>October 22, 2009</time>

Ha nem szeretjük a "csupasz" jellemzőket, írhatjuk az alábbit is, ami egyenértékű a fenti kóddal:

<time date time� "2009-10-22 "pubdate="pubdate">October 22, 2009</time>

Mi a jelentése pubdate jellemzőnek? Nos, két dolgot jelenthet. Ha a <time>

elem egy <article> elemben található, akkor azt jelenti, hogy ez az időbélyeg a cikk közzétételi dátuma (publication date). Ha viszont a <time> elem nem egy <art ic le> elem belsejében található, akkor a jelentése az, hogy az időbélyeg a teljes dokumentum közzétételének dátumát adja meg.


Íme a teljes cikk átdolgozott, a HT ML5 előnyeit teljes mértékben kihasználó változata:

<article>

<header>

<time datetirne= "2009-10-22 " pubdate>

October 22, 200 9

</time>

<hl>

<a href= •J "

rel="bookrnark"


Travel da y

</a>

</hl>

</header>

<p> Lorern ip sum dolo r si t ame t ... </p>

</article>

Navigáció

Minden webhelynek a navigációs sáv az egyik legfontosabb része. A CNN.

com webhely minden oldalának tetején "fülek" találhatók, amelyek a különböző híresokrokra- "T ech" (Tudomány), "Health" (Egészség), "Spons" (Sport) stb. - hivatkoznak. A Google kereső találari oldalai hasonló sávot jelenítenek meg az oldal tetején, ami lehetövé teszi, hogy a keresést a Google különféle szolgáltatásaival- "Images" (Képek), "Video" ( Videók), "Maps" (Térkép) stb. - hajtsuk végre. A mintaoldalunk fejlécében is van egy navigációs sáv, amely hivatkozásokat tartalmaz a képzeletbeli webhelyünk különböző - "home"

(nyitóoldal), "blog" (webnapló), "gallery" (képgaléria) és "abour" (névjegy) -szakaszaira.

A navigációs sáv leírókódja erederileg így nézett ki:

<di v id= "na v">

<ul>

<li><a href= "#">home</ a></ li>

<li><a href="l'>blog</a></li>

<li><a href= •t '>gallery</ a></ li>

<li><a href="l">about</a></li>

</ul>

</div>


Ez megint csak érvényes kód a HTMLS-ben, csak éppen egy négy elemből álló listát jelöl, és semmi sem utal arra, hogy ez a lista a webhely navigációs rendszerének része. A látványból persze kitalálhatjuk, mivel a lista az oldal fejlécében szerepel, és a hivatkozások szövege is elárulja, de szemantikailag semmi nem különbözteti meg ezt a hivatkozáslistát a többi, nem navigációs hivatkozástóL

De kinek számít, hogy egy webhely navigációs rendszerének jelentéstük

röző leírása legyen? Nos, például a fogyatékkal élőknek (http://diveintoaccessibility.org). Miért? Vegyük a következő forgatókönyvet: mozgáskorlátozottak vagyunk, így csak nehezen vagy egyáltalán nem tudjuk használni az egeret. Ennek ellensúlyozására egy böngészőbővítményt használunk, amely lehetövé teszi, hogy a kívánt fő navigációs hivatkozásra ugorjunk (vagy éppen átugorjuk azt). Vagy nézzünk egy másik esetet: a látásunk korlátozott, ezért egy úgynevezett "képernyőolvasó" programot használunk, amely hangosan felolvassa és összefoglalja a weboldalak szövegét. Az oldal címe után minden oldalon a fő navigációs hivatkozások jelentik a következő fontos információkat. Ha az adott webhelyen belüli mozgást szeretnénk felgyorsítani, arra utasítjuk a képernyőolvasót, hogy ugorjon a navigációs sávra, és olvassa fel azt.

Ha viszont az oldal tartalma érdekel minket, azt mondjuk a képernyőolvasónak, hogy ugorja át a navigációs sávot, és az oldal szövegét kezdje felolvasni. Mindkét esetben fontos azonban, hogy képesek legyünk programozott mó

don meghatározni a navigációs hivatkozásokat. Tehát nincs ugyan semmi baj azzal, ha a <div id="nav"> kóddal jelöl

jük meg a webhely navigációs elemeit, de nem is különösebben hasznos, mert azokat, akiknek tényleg szükségük van rá, nemigen segíti. A HTML5-ben viszont már lehetőségünk van jelentéstükröző módon megadni a navigációs szakaszokat- a <na v> elemmel.

<na v> <ul>

<li><a href= "#">home</ a></ li> <li><a href= "# ">blog</ a></ li>

<li><a href= "# ">gallery</ a></ l i> <li><a href= "# ">about</a></li>

</ul> </nav>



Kérdés: Az ugróhivatkozások (skip link) összeegyeztethetők a <nav> elem

mel? Szükség van egydita/án a HTML5-ben is ugróhivatkozdsokra?

Válasz: Az ugróhivatkozások lehetövé teszik a képernyőolvasóknak, hogy átugorják a navigációs szakaszokat, ami hasznos azoknak a fogya

tékkal élő felhasználóknak, akik valamilyen külső programmal olvastatják fel a weboldalakat, és egér nélkül mozognak a webhelyeken belül. Arról, hogy hogyan és mikor használhatunk ugróhivatkozásokat, a http:/1

www.webaim.org/techniqueslskipnav címen olvashatunk részletesebben.

Amint frissítik a képernyőolvasókat, hogy felismerjék a <n av> elemet,

az ugróhivatkozások feleslegessé válnak, mivel a képernyőolvasó progra

mok képesek lesznek kívánságra automatikusan átugrani a <n av> kód

dal megjelölt navigációs szakaszokat. Mindazonáltal időbe telik, mire a Weben minden fogyatékkal élő felhasználó HTML5-képes képernyőolvasóra vált, ezért továbbra is célszerű ugróhivatkozásokat biztosítani a <n av> szakaszok átlépéséhez.

Láblécek

Végre-valahára elérkeztünk a mintaoldalunk végéhez. Az utolsó, amiről beszélni szeretnék, az oldal utolsó eleme: a lábléc. A lábléc eredeti kódja így

nézett ki:

<di v id= • faoter ">

<p>&U67;</p>

<p>&#l69; 2001– 9 <a href= "#">Mark Pilgrim</ a></ p>

</div>

Ez ismét csak érvényes HTML5-kód, de a HTML5-ben van egy megfelelőbb

elem is erre a célra-a <footer> ("lábléc") elem:

<footer>

<p>§</p>

<p>© 2001– 9 <a href= "#''>Mark Pilgrim</a></p>

</footer>

Mit helyénvaló egy <footer> elembe tenni? Valószínűleg minden olyasmit, amit most egy <d i v id= "footer "> elemben helyezünk el. Na jó, ez a válasz

3. fejezet Mitjelent mindez? J 87

egy önnön farkába harapó kígyó volt, de tényleg ennyi az egész. A HTMLS szabványleírása ezt mondja: "A lábléc jellemzően olyan információkat tartalmaz a szakaszról, amelyhez tartozik, mint a szakasz szerzője, hivatkozások kapcsolódó dokumentumokra, szerzői jogi információk és hasonlók.". Ilyen a mintaoldalunk lábléce is: egy rövid copyright-szöveg szerepel benne, valamint egy hivatkozás a szerzőről szóló oldalra. Ha körülnézünk néhány népszerű webhelyen, más elemeket is láthatunk, amelyek alkalmasak arra, hogy egy láblécben helyezzük el őket:

• A CNN oldalának lábléce a szerzői jogi információkat tartalmazza, valamint hivatkozásokat az oldal más nyelvre fordított változataira, a szolgáltatási feltételekre, az adatvédelmi nyilatkozatra, illetve az "about us"

("rólunk"), "contact us" ("elérhetőségeink") és "help" ("súgó") oldalakra. A lábléc mindegyiknek tökéletes hely.

• A Google nyitóoldala híresen spártai, de az alján találunk néhány hivatkozást- "Advertising Programs" (Hirdetési programok), "Business Solutions" (Üzleti megoldások), "About Google" (Rólunk)-, valamint a szerzői jogi információkat és egy hivatkozást a Google adatvédelmi irányelveire. Ezek mind olyan dolgok, amiket be lehet csomagolni egy <footer> elembe.

• Az én webnaplám (http://diveintomark.org) lábléce az egyéb webhelyeimre mutató hivatkozásokar, valamint a szerzői jogi információkat tartalmazza- ezek egyértelműen egy <footer> elembe valók. (Megjegyzendő, hogy magukat a hivatkozásokat nem szabad egy <nav> elembe burkolni, mert nem a webhely navigációs hivatkozásairól van szó, csupán más webhelyeken folyó projektekre mutató hivatkozásokról.)

Manapság a kövér láblécek (http:llui-patterns.comlpattern/FatFooter) nagy slágernek számítanak. Vessünk egy pillantást a W3C webhelyén (http://www. w3.org) található láblécre: ez a lábléc három oszlopból- "Navigation" (Navigáció), "Contact W3C" (A W3C elérhetőségei) és "W3C Updates" (Frissítések) - áll. A leírókódja pedig többé-kevésbé így fest:

<div id= "w 3 c faoter ">

<di v class= "w 3 c footer-nav ">

<h3>Navigation</h3>

<ul>

<li><a href= • l ">Home< la></ li>

<li><a href="/standards/">Standards</a></li>


<li><ahref="/participate/">Participate</a></li>

<li><ahref="/Consortium/membership">Membership</a></li>

<li><a href= "/Consortium/ ">About W3C</a></li>

</ul>

</div>

<div class= "w 3 c footer-nav ">

<h3>Contact W3C</h3>

<ul>

<li><ahref="/Consortium/contact">Contact</a></li>

<li><a href= "/Help/ ">Help and FAQ</ a></ li>

<li><ahref="/Consortium/sup">Donate</a></li>

<li><a href= "/Consortium/ siteindex ">Site Map</ a></ li>

</ul>

</div>

<di v class= "w 3 c footer-nav ">

<h3>W3C Updates</h3>

<ul>

<li><a href= "http: l /twitter. com/W3C ">Twitter</a></li>

<li><ahref="http://identi.ca/w3c">Identi.ca</a></li>

</ul>

</div>

<p class= "copyright ">Copyright© 200 9 W3C</p>

</div>

Ahhoz, hogy ezt jelentéstükröző HTML5-kóddá alakítsuk, én a következő módosításokat hajtanám végre:

• Alakítsuk a külső <div id= "w 3 c footer "> derner <footer>

elemmé.

• Alakítsuk a <div class="w3c _ footer-nav"> első két példányát <nav> elemekké, a harmadik példányt pedig egy <section> elemmé.

• Alakítsuk a <h3> címsorokat <hl> címsorokká, mivel mindegyik egy

szakaszaló elembe fog kerülni. A <n av> elem egy szakaszt hoz létre a dokumentumvázlatban, akárcsak az <article> elem (lásd a "Cikkek"

című részt egy kicsir korábban).

A végső leírókód valahogy így nézne ki:

<footer>

<na v>

<hl>Navig ation</hl>

<ul>

<li><a href= "l ">Home</ a>< /li>

<li><a href= "/standards/ ">Standards</ a></ li>

<li><ahref="/participate/">Participate</a></li>

<li><a href= • /Consortium/membership ">Membership</a></li>

<li><a href= "/Consortium/ ">About W3C</a></ li>

</ul>


</nav>

<na v>

<hl>Contact W3C </hl> <ul>

<li><ahref="/Consortium/contact">Contact</a></li>

<li><a href= "/Help/ ">Help and FAQ</ a></ li>

<li><ahref="/Consortium/sup">Donate</a></li>

<li><a href= • /Consortium/ siteindex ">Site Map</ a></ li>

</ul>

</nav>

<section>

<hl>W3C Updates </hl>

<ul>

<li><ahref="http://twitter.com/W3C">Twitter</a></li>

<li><ahref="http://identi.ca/w3c">Identi.ca</a></li>

</ul>

</section>

<p class= "copyright ">Copyright© 200 9 W3C</p>

</footer>


A fejezetben szereplő mintaoldalak:

• Az eredeti (HTML 4) (http://diveintohtml5.orglexamples/blog-original.html) • A módosított (HTML5) (http://diveintohtml5.orglexampleslblog-html5.

html)

A karakterkódolásról:

• Joel Spolsky: "The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)" (h ttp:llwwwjoelonsoftware. com/ articiesi Unicode. html)

• Tim Bray: "On the Goodness ofUnicode" (http:l!www.tbray.org/ongoingl When/200x/2003/04/06/Unicode), "On Character Strings" (http://www.tbray.org/ ongoing!When/200x/2003!04113/Strings) és "Characters vs.Bytes" (http:/1 www.tbray.org/ongoing/When/200x/2003/04126/UTF)

A HTML5 engedélyezéséről az Internet Explorerben: • Sjoerd Visscher: "How to style unknown elements in IE " (http:llxopus.

com/devblog/2008/style-unknown-elements.html) • John Resig: HTML5 shiv (http:!lejohn.org!bloglhtml5-shivl)


• Remy Sharp: HTMLS enabling script (http:llremysharp.com/2009/01/07/ html5-enabling-scriptl)

A szabványkövető módról és a dokumentumtípus-kiszimatolásról:

• Henri Sivonen: "Activating Browser Modes with Doctype" (http://hsivonen. iki.Ji!doctypel)- ez az egyetlen cikk, amelyet muszáj elolvasnunk a témáról.

Sok más cikket Írtak róla, de azok elavultak, hiányosak vagy tévedéseket tartalmaznak.

A HTML5-öt ismerő ellenőrző rendszer:

• Validator.nu (X)HTMLS Validator (http://html5.validator.nu)

4. fejezet

A rajzvászon ördöge (ne fessük a falra!)

Ugorjunk fejest!

A HTMLS így határozza meg a <canvas> ("rajzvászon") elemet (http:!lbit. ly/9]Hz0j): "felbontástól függeden bitképes rajzvászon, amelyet grafikonok, játékgrafikák és más képi elemek menet közbeni megjelenítésére használhatunk

".

A rajzvászon egy téglalap alakú terület az oldalon, amelyre JavaScript-kód segítségével tetszőleges dolgot rajzolharunk Az alábbi táblázat megmutatja, hogy e könyv írásának idején mely böngészők kínálnak alapszintű támogatást a rajzvászonhoz:

.Chmm.«

7.0+ 3.0+ 3.0+ 3.0+ 10.0+ 1.0+ 1.0+

'Az Internet Explorerben a támogatáshoz a külső explorercanvas könyvtár szükséges

Hogyan néz ki egy rajzvászon? Tulajdonképpen sehogy. A <canvas> elemnek nincs tartalma, és nincs saját szegélye. A leírókódja így fest:

<canvas wid th= "300" height= "225"></ canvas>

A 4.1. ábra pontozott körvonallal mutatja a rajzvásznat, hogy lássuk, mivel is van dolgunk.

Egy oldalon több <canvas> elem is lehet. Mindegyik rajzvászon megjelenik a DOM-ban, és mindegyiknek saját állapota van. Ha az egyes rajzvásznakhoz id jellemzőket rendelünk, ugyanúgy érhetjük el őket, mint bármely más elemet.

Bővítsük ki hát a fenti kódot, hogy id jellemző is legyen benne:

< canvas id= "a" width= "300 • height= "225 "></canvas>

Most már egyszerűen megtalálhatjuk ezt a <canvas> elemet a DOM-ban:

var a_ canvas = document. getElementByid ( "a") ;

4. fejezet A rajzvászon ördöge ... l 93

4. l. ábra Rajzvászon szegéllyel

Egyszerű alakzatok

IP Arefox Sa fari 7.0+ 3.0+ 3.0+

Chrome ra 3.0+ 10.0+

!Phone Androld 1.0+ 1.0+

• Az Internet Explorerben a támogatáshoz a külső explorercanvas könyvtár szükséges

Kezdetben minden rajzvászon üres. Ez nagyon unalmas, úgyhogy rajzoljunk

valamir! Az onclick eseménykezelő segítségével meghívhatunk egy függvényt, amely egy négyszöget rajzol (egy interaktív példát a http:lldiveintohtm/5. orglcanvas.html címen láthatunk):

function draw_ b () {

)

var b_ canvas = docurnent. getElementByid ( "b") ;

var b_context = b_canvas. getContext ( "2d ");

b_context.fil1Rect(50, 25,150, 100);

A függvény első sorában nincs semmi különleges: csak megkeresi a <canvas> elemet a DOM-ban. A második sorban kezd érdekessé válni a dolog. Minden rajzvászonnak van egy rajzkörnyezete (context), és itt történnek az izgalmas dolgok. Miurán megtaláltuk (akár a document.getElementByid(), akár egy kedvünkre való másik tagfüggvény segítségéve!) a kívánt <canvas> elemet, meghívhatjuk a getContext O tagfüggvényét. Ennek a tagfüggvénynek kötelező a "2 d" karakterláncot átadnunk:

94 l A rajzvászon ördöge ... 4. fejezet

function draw_b() {

l

var b_canvas = document. getElementByld ("b");

var h_context =b_canvas .getContext("2d"); b_context.fillRect(SO, 25, 150, 100);


Kérdés: Létezik háromdimenziós rajzvászon is? Válasz: Még nem. Egyes gyártók kísérleteznek saját háromdimenziós rajzvászon-API-val, de még egyik sem vált szabvánnyá. A HTML5

leírása csak annyit jegyez meg, hogy "e szabvány valamelyik jövőbeli változata valószínűleg meg fog határozni egy háromdimenziós környezetet is".

Van tehát egy <canvas> elemünk, és rendelkezünk a rajzkörnyezetéveL A rajzkörnyezet határozza meg az összes rajzolófüggvényt és rajztulajdonságot. A négyszögek rajzolásához tulajdonságok és tagfüggvények egész csoportja áll rendelkezésre:

• A fil1St y le (kitöltési stílus) tulajdonság értéke egy CSS-kóddal meghatározott szín, mintázat vagy színátmenet lehet. (A színátmenetekről hamarosan bővebben is szó lesz.) Az alapértelmezett fillStyle az egyszínű fekete, de ezt tetszés szerint módosíthatjuk. Minden rajzkörnye

zet emlékszik a saját tulajdonságaira, amíg az oldal nyitva van, hacsak nem teszünk valamit, hogy visszaállítsuk azokat az alapértelmezett értékeikre.

• A fillr ect(x, y, szélesség, magasság) egy négyszöget rajzol az érvényben levő kitöltési stílussaL

• A strokeStyle (körvonalstílus) tulajdonság olyan, mint a fillStyle:

az értéke egy CSS-szín, -mimázat vagy -színátmenet lehet. • A strokeRect(x, y, szélesség, magasság) egy négyszöget

rajzol az érvényben levő körvonalstílussal. A strokeRect nem tölti ki a négyszöget, csak az oldalait rajzolja meg.

• A clearRect(x, y, szélesség, magasság) törli a megadott négyszög képpontjait.

4. fejezet A rajzvászon ördöge ... \ 95


Kérdés: "Aiaphelyzetbe" lehet állítani egy rajzvásznat?

Válasz: Igen. Ha egy <canv as> elemnek módosítjuk a szélességét vagy a magasságát, a tartalma törlődik, és a rajzkörnyezetének minden tulaj

donsága visszaáll az alapértelmezett értékére. Sőt nem is kell módosítani

a szélességet- elég, ha "beállítj uk" az aktuális értékére, valahogy így:

var b_canvas = document .getElementByid ("b");

b_ canvas . width =b_ canvas . width;

Térjünk vissza az előző példában szereplő kódhoz:

var b_canvas = document. getElementByid ("b");

var b_ context =b_ canvas. getContext ( "2 d •) ;

b_context.fillRect(SO, 25, 150, 100);

A fill Re ct() tagfüggvény meghívása egy négyszöget rajzol a rajzvászonra, és az érvényben levő kitöltési stílussal- vagyis fekete színnel, ha nem módosítottuk az alapértelmezést- tölti ki azt. A négyszöget a bal felső sarka (50,

25), a szélessége (150) és a magassága (100) határozza meg. Hogy jobban el tudjuk képzelni, hogyan is működik ez az egész, nézzük meg a rajzvászon koordinátarendszerét.

Rajzvászon-koordináták

A rajzvászon egy kétdimenziós rács. A (O, O) koordináta a rajzvászon bal felső

sarkát jelöli. Az x-tengelyen az értékek a rajzvászon jobb széle felé nőnek, míg az y-tengelyen a rajzvászon alsó széle felé.

A 4.2. ábrán látható koordináta-diagramot egy <canvas> elem segítségével rajzoltam, és a következőkből áll:

• Piszkosfehér függőleges vonalakból • Piszkosfehér vízszintes vonalakból • Két fekete vízszintes vonalból

• Két apró fekete átlós vonalból, amelyek egy nyilat formáznak • Két fekete függőleges vonalból


• Két apró fekete átlós vonalból, amelyek egy újabb nyilat formáznak • Az "x

" betűből • Az "y" betűből • A "(O, O)" szövegből a bal felső sarok közelében • Az "(500, 375)" szövegből a jobb alsó sarok közelében • Egy pontból a bal felső és egy másik pontból a jobb alsó sarokban

(0,0)

x --------------7

y

(500 ,375}

4.2. ábra Rajzvászonkoordináta-diagram

A következőkben megvizsgáljuk, hogyan érhetjük el a képen látható hatást. Először is, meg kell határoznunk magát a <canvas> elemet. A <canvas>

elem adja meg a négyszög szélességét (wid th) és magasságát (height), valamint az azonosítóját (id), hogy később megtalálhassuk:

< canvas id; "c • width; "500" height; "375 "></canvas>

Ez után egy parancskódra van szükségünk, amely megkeresi a <canvas>

elemet a DOM-ban, és kiolvassa a rajzkörnyezetét:

4. fejezet A rajzvászon ördöge .. . J 97

var c_canvas = document .getElementByid ( •c ");

var context =c_ canvas. getContext ("2 d") ;

Most már nekiállhatunk megrajzolni a vonalakat.

útvonalak

7.0+ 3.0+ 3.0+ 3.0+ 10.0+ 1.0+ 1.0+

• Az Internet Explorerben a támogatáshoz a külsö explorercanvas könyvtár szükséges

Képzeljük el, hogy tollal rajzolunk egy képet. Nem akarunk csak úgy fejest ugrani a rajzolásba, mert ha esetleg hibázunk, nem tudjuk majd kijavítani. Ehelyett először ceruzával felvázoljuk a vonalakat, és ha elégedettek vagyunk

velük, kihúzzuk a vázlatot tollal. Minden rajzvászonhoz tartozik egy útvonal (path). Az útvonal meghatá

rozása olyan, mint ceruzával rajzolni. Azt rajzol unk, amit akarunk, de az nem lesz a végső alkotás része, amíg tollal ki nem húzzuk.

Ha egyenes vonalakat szeretnénk ceruzával rajzolni, az alábbi két mód

szert alkalmazhatjuk:

• moveTo (x, y) -A ceruzát a megadott kezdőpontba mozgatja. • lineTo (x, y) -A megadott végpontig húz vonalat.

Minél többször hívjuk meg a moveTo () és lineTo () függvényeket, annál

hosszabb lesz az útvonal. Ezek "ceruza-tagfüggvények" - annyiszor hívjuk meg őket, ahányszor csak akarjuk, de a rajzvásznon semmit sem fogunk látni, amíg meg nem hívjuk valamelyik "tolltagfüggvényt".

Kezdjük a piszkosfehér rács megrajzolásával:

for (varx=O.S; x< 500; x+=lO)

context.moveTo(x, 0); context.lineTo(x, 375);

} for (vary=O.S; y< 375; y+=lO)

context.moveTo(O, y);

context.lineTo(SOO, y); }


A fentiek mind "ceruza-tagfüggvények", tehát ténylegesen még semmit nem

rajzoltunk a rajzvászonra. Ahhoz, hogy a rajz maradandó legyen, egy "tolltagfüggvényre" van szükségünk:

context. strokeStyle; "!Ieee"; context.stroke();

A stroke() egyike a "tolltagfüggvényeknek": fogja amoveTo () és lineTo () hívásokkal meghatározott bonyolult útvonalat, és ténylegesen felrajzolja a rajzvászonra. A vonalak színét a strokeStyle szabályozza. Az eredményt

a 4.3. ábra mutatja.

4.3. ábra Rajzvászonra rajzolt rács

4. fejezet A rajzvászon ördöge . . . J 99


Kérdés: Miért indul az x és az y 0.5-töl? Miért nem O-tól?

Válasz: Minden képpontot úgy kell elképzeln ünk, mint egy nagy négy

zetet. A négyzet sarkait az egész számú koordináták (O, l, 2 ... ) jelképe

zik. Ha egész számú koordináták között rajzolunk egy egy egység széles

vonalat, az a képpontnégyzet mindkét szemben levő oldalát le fogja

fedni, így az eredményként kapott vonal két képpont szélességű lesz.

Ha olyan vonalat szecetnénk rajzolni, amelyik csak egy képpont széles,

a koordinátákat a vonaira merőlegesen el kell tolnunk 0,5-tel.

Most rajzoljuk meg a vízszintes nyilat. Az azonos útvonalon levő vonalak és

görbék rajzolása ugyanazzal a színnel (vagy színátmenettel - igen, mindjárt

odaérünk) történik, mi viszont más színnel - piszkosfehér helyett feketével

- szeretnénk megrajzolni a nyílhegyet, ezért új útvonalat kell kezdenünk:

context.beginPath(); context. moveTo (O, 4 O) ;

context.lineTo(240, 40);

context.moveTo(260, 40);


context.moveTo (495, 35);


context.lineTo (495, 45);

A függőleges nyíl ehhez igen hasonló, mivel azonban a színe megegyezik

a vízszintes nyíl színével, nem kell másik útvonalat kezdenünk. A két nyíl

hegy ugyanannak az útvonalnak lesz a része:


context .lineTo (60, 153) ;






Azt mondtam, hogy a nyilak feketék lesznek, de a strokeStyle még min

dig piszkosfehér. (A fil1St y le és strokeStyle tulajdonságok nem állnak

vissza az alapértelmezett értékre, amikor új útvonalat kezdünk.) Ezzel nincs

semmi gond, mert most csak "ceruzavonalakat" húztunk Mielőtt azonban


ténylegesen, "tollal" megrajzolnánk az ábrát, a strokeStyle-t feketére kell állítanunk, különben a két nyíl is piszkosfehér lesz, és nemigen fogjuk látni őket. A következő sarok állítják feketére a színt, és rajzolják ki a vonalakat a rajzvásznon:

context. strokeStyle = "#OOO •;

context.stroke();

Az eredményt a 4.4. ábra mutatja.

4.4. ábra Felcím kézetlen tengelyek egy rajzvásznon

Szöveg

7.0+ 3.0+ 3.0+ 3.0+ 10.0+ 1.0+ 1.0+

• Az Internet Explorerben a támogatáshoz a külső explorercanvas könyvtár szükséges

b A Mozilla Firefax 3.0-ban a támogatáshoz egy kiegészítő (.,shim") szükséges


A rajzvásznakra nem csak vonalakat, hanem szöveget is rajzolhatunk A képet

körülvevő weboldalon levő szöveggel ellentétben azonban itt nincs dobozmodell. Ez azt jelenti, hogy az ismerős CSS-eljárások egyike sem használható:

nincsenek úsztatott elemek, nincsenek külső és belső margók, és nincs szóhatáron automatikus sortörés. (Ezt talán nem is bánjuk.) Csak néhány betűjel

lemzőt állíthatunk be, majd kiválaszthatunk egy pontot a rajzvásznon, és

onnan indítva kiírhatjuk a szöveget. A rajzkörnyezetben a következő betűjellemzőket használhatjuk (lásd az

"Egyszerű alakzatok" című részt a fejezet elején):

• A font értéke bármi lehet, amit egy font CSS-szabályba tennénk: betűstí

lus, betűváltozat, betűvastagság, betűméret, vonalmagasság és betűcsalád.

• A textAlign a szöveg igazírását szabályozza. A text-align CSSszabályhoz hasonlóan működik (de nem azonos azzal). Lehetséges értékei: start, end, left, right és center.

• A textBaseline a szövegnek a kezdőponthoz viszonyított helyzetét

adja meg. Lehetséges értékei: top, hanging, middle, alphabetic,

ideographic és bot tom.

A textBas e l i ne (szöveg-alapvonal) használata bonyolult, mert maguk a szö

vegek is azok. (Na jó, nem mindegyik, de egy rajzvászonra bármilyen Unicode

karaktert rajzolhatunk, és az Unicode már nem olyan egyszerű.) A HTML5

szabványleírása így magyarázza el a különböző szöveg-alapvonalakat:*

Az em-négyzet felső vonala (top) egy betűtípus karakterjeleinek (gliféi

nek) nagyjából a tetején húzódik; a függő alapvonal (hanging) ott,

ahová az olyan gliféket horgonyozzák, mint a 3If karakter; a középvonal (middle) félúton található az em-négyzet teteje és alja között; az alfabe

tikus alapvonal (alphabetic) az olyan karakterek horgonyvonalát jelzi, mint az Á, az y-, az f és az O ; az ideografikus alapvonal (ideographic) az

olyan karakterek horgonyvonalát, mint a �b. és a li ; míg az em-négyzet alsó vonala nagyjából a betűtípusok gliféinek alját jelzi. A befoglaló do

boz alja és teteje távol is eshet ezektől az alapvonalaktól, mivel egyes ka

rakterjelek messze túlnyúlnak az em-négyzeten (lásd a 4.5. ábrát).

• http://bit.ly/aHCdDO


kfeografikus

em-néQvzet a

A befog la ló doboz alja

4.5. ábra Szöveg-alapvonalak

Az olyan egyszerű ábécék esetében, mint az angol, nyugodtan maradhatunk

a textBaseline tulajdonság top, middle vagy bottom értékénéL Rajzoljunk is egy kis szöveget! A rajzvászon belsejébe rajzolt szöveg magá

nak a <canvas> elemnek a betűméretét és betűstílusát örökli, de ezt felül

bírálhatjuk, ha módosítjuk a font tulajdonság értékét a rajzkörnyezetben:

context. font= "bold 12px sans-serif" ; context.fillText( "x", 248, 43);

context.fillText( "y", 58, 165);

A tényleges szöveget a fill Text ( ) tagfüggvény rajzolja ki:

con text. font= "bold 12px sans-serif"; context.fillText( "x", 248, 43);

context.fillText("y", 58, 165);


Kérdés: Megadhatok viszonyított betűrnéretet is, amikor rajzvászonra rajzo/ok szöveget? Válasz: Igen. Mint egy oldal minden más HTML-elemének, magának

a <canvas> elemnek is van egy számított betűmérete, amely az oldal CSS-szabályain alapul. Ha a context. font tulajdonságot egy olyan relatív betűmérettel adjuk meg, mint az l. Sem vagy a 150%, a böngé

sző ezt a <canvas> elem számított betűméretével fogja összeszorozni.

4. fejezet A rajzvászon ördöge . .. l 103

Tegyük fel, hogy a bal felső sarokba kerülő szöveg esetében azt szeretnénk, hogy a szöveg teteje y=S-nél húzódjon. Viszont lusták vagyunk, és nem akarjuk megmérni a szöveg magasságát, és kiszámítani az alapvonalat. Ehelyett beállíthatjuk a textBaseline tulajdonságot a top értékre, és átadhatjuk a szöveget befoglaló doboz bal felső sarkának koordinátáját:

context. textBaseline = "top";

context.fillText( "(O, O)", 8, 5);

Most pedig jöjjön a jobb alsó sarokba kerülő szöveg! Tegyük fel, hogy a szöveg jobb alsó sarkát a (492, 370) koordinátákra szeretnénk helyezni- csupán néhány képpontnyira a rajzvászon jobb alsó sarkától -, de megint csak nem akarjuk megmérni a szöveg magasságát vagy szélességét. Állítsuk a textAlign

tulajdonságot right ( jobbra), a textBaseli ne tulajdonságot pedig bottom

(alul) értékre, majd hívjuk meg a fillText ( ) tagfüggvényt a szöveget befoglaló doboz jobb alsó sarkának koordinátáival:

context. textAlign = "right ";

context. textBaseline = "bot tom";

context. fillText ( " ( 500, 375 ) ", 492, 370);


(0,0)

y

4.6. ábra Felcímkézett tengelyek egy rajzvásznon

104 l A rajzvászon ördöge ...

(500,375)

4. fejezet

Hoppá! Elfelejtettük a pontokat a sarkokban! Hamarosan megtudjuk, hogyan rajzolhatunk köröket, de most csalunk egy kicsit, és négyszögekként rajzoljuk meg a pomokat (lásd az "Egyszerű alakzatok" című részt a fejezet elején):

context.fillRect(O, O, 3, 3); context.fillRect(497, 372, 3, 3);

Ennyi az egész! A végeredményt a 4.7. ábrán láthatjuk.

(0,0)

----��---------------- ·----------------------�

y

4.7. ábra Rajzvászonkoordináta-diagram egy rajzvásznon

Sz í nátmenetek

Lineáris színátmenetek 7 .0+ 3.0+

Sug_aras színátmenetek . 3.0+

3.0+ 3.0+

3.0+ 3.0+

(500 ,375)

10.0+ 1.0+

10.0+ 1.0+


Andmid

1.0+

1.0+

A fejezet korábbi részében megtanulruk, hogyan rajzolharunk egyetlen színnel kiröltött négyszögeket (lásd az "Egyszerű alakzatok" című részt a fejezet elején), illetve egyszínű vonalakat ("Útvonalak", szintén ebben a fejezetben).

4. fejezet A rajzvászon ördöge ... J 105

A lehetőségeink azonban nem korlátozódnak egyszínű alakzatokra és vonalakra - színátmenetekkel (gradient) mindenféle dolgot varázsolhatunk. A 4.8. ábrán láthatunk egy példát.

A leírókód ugyanolyan, mint bármely más rajzvászon esetében:

<canvas id= •ct n width= " 300 . height= "225 "></canvas>

Először meg kell keresnünk a <canvas> elemet, és ki kell olvasnunk a rajzkörnyezetér:

var d_ canvas = document. getElementByid ( "d") ; var context = d_canvas. getContext ( "2d ");

4.8. ábra Balról jobbra haladó lineáris színátmenet

Ha megvan a rajzkörnyezet, nekiláthatunk meghatározni egy színátmenetet. A színátmenet egyenletes átmenetet jelent két vagy több szín között. A rajzvászon rajzkörnyezete kétféle színátmenetet támogat:

• A createLinearGradient(xO, yO, xl, yl) az (xO, yO) ponttól az (xl, yl) pontig tartó egyenes mentén fest.

• A createRadialGradient(xO, yO, rO, x l, yl, rl) egy két kör által meghatározott kúp mentén fest. Az első három paraméter adja meg a kezdőkört, amelynek a középpontja (xO, y O), a sugara pedig rO.

Az utolsó három paraméter a zárókört határozza meg, (x l, yl) középponttal és rl sugárral.

Készítsünk lineáris színátmenetet! A színátmenetek tetszőleges méretűek lehetnek, de ezt most a rajzvászonnal megegyezően 300 képpont szélesre vesszük:


var my_gradient = context.createLinearGradient(O, O, 300, 0);

Mivel mindkét y-érték (a második és a negyedik paraméter) O, a színátmenet balról jobbra egyenletes lesz.

Miután létrehoztunk egy színátmenet-objektumot, meghatározhatjuk a színátmenet színeit. A színátmenetek két vagy több színállomásból állnak, amelyek a színátmenet bármely pontján lehetnek. Színállomást úgy adhatunk a színátmenethez, hogy megadjuk a helyzetét (pozícióját) az átmenet mentén. A színátmenet-pozíciók O és l között tetszőleges értéket vehetnek fel.

Határozzunk meg egy olyan színátmenetet, amely feketéből (black) fehérbe (white) tart:

my_gradient. addColorStop (0, "black");

my_gradient.addColorStop (l, "white");

A színátmenet meghatározásával még semmit nem rajzolunk a rajzvászonra, csupán egy objektumot hozunk létre valahol a memóriában. A színátmenet megrajzolásához a fil1St y le értékéül kell adnunk a színátmenetet, és rajzolnunk kell egy alakzatot (például egy négyszöget) vagy egy vonalat:

context. fillStyle = my_gradient; context.fillRect(O, O, 300, 225);

4.9. ábra Balról jobbra tartó lineáris színátmenet

Tegyük fel, hogy egy olyan színátmenetet szeretnénk, amely felülről lefelé halványodik. Amikor létrehozzuk a színátmenet-objektumot, az x-értékek (az első és a harmadik paraméter) legyenek állandók, míg az y-értékek (a második és a negyedik paraméter) essenek O és a rajzvászon magassága közé:

4. fejezet A rajzvászon ördöge . . . J 107

var my _gradient � context. createLinearGradient (O, O, O, 225) ; my_gradient. addColorStop (0, "black");

my _gradient. addColorStop (l, "w hi te") ;

context. fillStyle � my _gradient;

context.fillRect(O, O, 300, 225);


4.1 O. ábra Felülrőllefelé haladó lineáris színátmenet

Átlós színátmeneteket is létrehozhatunk. Lássunk egy példát:

var my_gradient � context. createLinearGradient (0, O, 300, 225); my_gradient.addColorStop(O, "black");

my_gradient. addColorStop (l, "white");

context. fillStyle � my_gradient;

con text. fillRect (0, O, 300, 225);

Az eredményt a 4.11. ábrán láthatjuk.

4.11. ábra Átlós lineáris színátmenet


Képek

� Cbrome_Ooera iPhone Android 7.0+ 3.0+ 3.0+ 3.0+ 10.0+ 1.0+ 1.0+


A 4.12. ábrán egy macskáról készült rajzor láthatunk, amelyet az <img> elem

jelenít meg.

4.12. ábra Macska egy <img> elemben

� '· - ''

A 4.13. ábra ugyanezt a macskát mutatja, de egy rajzvászonra rajzolva .

4.13. ábra Macska egy <canvas> elemben

• ....,.._ J:

Több módja is van annak, hogy képeket rajzoljunk egy rajzvászonra:

• A drawimage (kép, dx, d y) fogja a paraméterkém áradott képet, és a rajzvászonra rajzolja. A megadott (dx, dy) koordináták a kép bal

felső sarkát jelölik. Ha a (0, 0) koordinátákat adjuk meg, a kép a rajz

vászon bal felső sarkába kerül.

4. fejezet A rajzvászon ördöge . .. J 109

• A drawimage (kép, dx, d y, d w, dh) fogja a paraméterként átadott képet, dw szélességűre és dh magasságúra állítja, és a rajzvászonra

rajzolja a megadott (dx, dy) koordinátákon.

• A drawimage (kép, sx, sy, sw, sh, dx, dy, dw, dh) fogja a paraméterként átadon képet, kivágja belőle az (sx, sy, sw, sh)

négyszöget, a kivágott részt d w szélességűre és dh magasságúra állítja, és

a rajzvászonra rajzolja a (dx, dy) koordinátákon.

A HTML5 szabvány leírása így magyarázza el a drawimage () paramétereit

(http://bit.ly/9WTZAp):

A forrásnégyszög az a négyszögletes terület [a forrásképen belül], amelynek a sarkait az (sx, sy), (sx+sw, sy), (sx+sw, sy+sh) és (sx, sy+sh) pontok adják meg.

A célnégyszög az a négyszögletes terület [a rajzvásznon belül], amelynek a sarkait a (dx, d y), (dx+dw, d y), (dx+dw, dy +dh) és (dx,

dy+dh) pontok adják meg.

A fenti paramétereket a 4.14. ábra szemlélteti.

Ha képet szeretnénk rajzolni egy rajzvászonra, akkor szükségünk van egy képre. A kép lehet egy már létező <img> elem, de létrehozhatunk egy Image

objektumot is JavaScript-kód segítségéveL Mindkét esetben gondoskodnunk kell azonban arról, hogy a kép teljesen betöltődjön, mielőtt a rajzvászonra

rajzolhatnánk. Ha egy meglevő <img> elemet használunk, biztonságosan a rajzvászonra

rajzolhatjuk a window.onload esemény során:

<img id= •ca t • src= "images/ca t .png • alt=" sleeping ca t • width= "177 •

height="ll3">

< canvas id= "e" width= "177 • height= "113 "></canvas>

<script>

window. on load = function () {

var canvas = document. getElementByid ( •e ") ;

var context = canvas. getContext ( "2d ");

var ca t= document. getElementByid ("ca t");

context.drawlmage(cat, O, 0);

}; </script>


Forráskép

sy

sx Rajzvászon

dx

4.14. ábra fgy képez le egy képet a drawlmage() egy rajzvászonra

dh

Ha a képet teljes egészében JavaScript-kóddal hozzuk létre, a képet az Image.

on load esemény során rajzolhatjuk biztonságosan a rajzvászonra:

<can vas id= •e" wid th= "l 77 • height= "113 "></can vas>

<script>

var canvas = document.getElementByid ("e");

var context = canvas. getContext ("2 d");

var ca t = new Image() ;

ca t. src = "images/cat .png ";

ca t. onload = function () (

context.drawlmage(cat, O, 0); };

</script>

A drawimage ( ) tagfüggvény elhagyható harmadik és negyedik paramétere

a kép méretét szabályozza. A 4.15. ábra ugyanezt a macskarajzor mutatja, de feleakkora szélességben és magasságban, és különböző koordinátákon többször kirajzolva egy rajzvásznon belül.

4. fejezet A rajzvászon ördöge... l lll

A "macskamintát"

ez a parancskód állítja elő:

ca t. onload = function ()

for (varx=O, y= O;

x< 500 && y< 375;

x+=50, y+= 37) l context.drawimage(cat, x, y, 88, 56);

) ) ;

4.15. ábra Macskamintal

Ez a sok erőfeszítés felvet egy jogos kérdést: miért akarnánk egyáltalán egy rajzvászonra rajzolni egy képet? Milyen előnyei vannak ennek a bonyolultabb megoldásnak egy <img> elemmel és néhány CSS-szabállyal szemben? Még a "macskamintát

" is elő tudnánk állítani 10 egymást átfedő <img> elemmel.

A válasz röviden annyi, hogy ugyanazért teszünk ilyesmit, amiért szöveget rajzolnánk egy rajzvászonra (lásd a fejezet korábbi, "Szöveg

" című részét).

A rajzvászonkoordináta-diagramunk (lásd a fejezet korábbi, "Rajzvászon-


koordináták" című részét) szöveget, vonalakat és alakzatokat is tartalmazott, a rajzvászonra rajzolt szöveg tehát csak egy része volt egy nagyobb alkotásnak. Egy még bonyolultabb diagramon a drawimage ( ) segítségével egyszerűen feltüntethetnénk ikonokat és más képelemeket is.

Mi a helyzet az Internet Explorerrel?

A Microsoft Internet Explorer (a 8-as változattal bezárólag, amely könyvünk írásának idején a legfrissebb kiadás volt) nem támogatja a Canvas API-t, viszont a Microsoft saját megoldását, a VML-t igen, amely sok szempontból hasonló dolgokra képes, mint a <canvas> elem. Így született meg az excanvas.js.

Az ExplorerCanvas (http:l!code.google.comlplexplorercanvasl)- excanvas.js -egy nyílt forrású, az Apache License hatálya alá tartozó JavaScript-könytár, amely megvalósítja a Canvas API-t az Internet Explorerben. A használatához az alábbi <script> elemet kell elhelyeznünk az oldalunk elején:

<' DOCTYPE html>

<html>

<he ad>

<me ta char set= "utf-8 ">

<title>Dive Into HTML 5</title>



</head>

<body>

</body>

</html>

A részek feltételes megjegyzések, amelyeket az Internet Explorer úgy értelmez, mint egy if ( " ha") utasítást: "ha az aktuális böngésző az Internet Explorer bármelyik változata, hajtsd végre ezt a kódblokkot". Minden más böngésző HTML-megjegyzésként kezeli a teljes blokkot. Az eredmény: az Internet Explorer letölti és végrehajtja az excanvas. js parancsfájlt, a többi böngésző azonban teljesen figyelmen kívül hagyja (nem tölti le, nem hajtja végre stb.), így az oldal gyorsabban töltődik be azokban a böngészőkben, amelyek belső támogatást nyújtanak a Canvas API-hoz.

Ha beemeltük az excanvas.js parancsfájlt az oldal <he ad> részében, mást már nem kell tennünk ahhoz, hogy képessé tegyük az Internet Explorert a rajzvászon kezelésére. Csak hozzá kell adnunk a <canvas> elemeket a leírókódhoz, vagy dinamikusan létrehozni azokat JavaScript segítségéveL A <canvas> elemek rajzkörnyezetét a fejezet utasításait követve olvashatjuk ki, és máris rajzolhatunk alakzatokat, szöveget és mintázatokat.

Illetve ... nem egészen. Van néhány korlátozás:

• A színátmenetek (lásd a fejezet korábbi, "Színátmenetek" című részét) csak lineárisak lehetnek, mert az excanvas.js nem támogatja a sugaras színátmeneteket.

• A mintázatoknak mindkét irányban ismétlődniük kell. • A kivágható területek nem támogatottak. • A körvonalak méretezése helytelen lesz, ha nem egységesen méretezünk. • Az excanvas.js lassú. Ez persze senkit nem érhet nagy meglepetésként,

hiszen az Internet Explorer JavaScript-feldolgozója eleve lassabb más böngészőkénéL Ha bonyolult alakzatokat kezdünk rajzolni egy olyan JavaScript-könyvtáron keresztül, amely az utasításokat egy teljesen más technológiára fordítja le, a feldolgozás lelassul. A sebességcsökkenést nem fogjuk észrevenni, ha olyan egyszerű műveleteket végzünk, mint néhány vonal rajzolása vagy egy kép transzformáció ja, de azonnal feltűnik majd, ha rajzvászon alapú animációba vagy más őrült dolgokba kezdünk.

Az excanvas.js használatának van még egy hátulütője, amibe akkor szaladtam bele, amikor elkészítettem ennek a fejezetnek a példáit. Az ExplorerCanvas automatikusan előkészíti a saját ál-rajzfelületét, amikor beemeljük az excanvas.js parancsfájlt egy HTML-oldalba, ez azonban nem jelenti azt, hogy az Internet Explorer is rögtön használatba tudja venni. Bizonyos esetekben megtörténhet, hogy az ál-rajzfelület majdnem használatra kész, de nem teljesen. Ennek az állapotnak az elsődleges jele az, hogy az Internet Explorer panaszkodik,

hogy "az objektum nem támogatja ezt a tulajdonságot vagy tagfüggvényt", amikor csinálni próbálunk valamit egy <canvas> elemmel, például megpróbáljuk kiolvasni a rajzkörnyezetét.

A legegyszerűbb megoldás erre a problémára az, ha minden rajzvászon

műveletet elhalasztunk az on load esemény utánra. A betöltés eltarthat egy ideig - például ha az oldalon sok kép vagy videó található, az késlelteti az


onload esemény bekövetkezését- de időt ad az ExplorerCanvasnak, hogy felkészüljön a varázslatra.

Egy teljes példa

A Halma egy több évszázados táblajáték, amelynek számos változata létezik. Ebben a példában a Halmának egy egyszemélyes változatát készítettem el,

kilenc "bábuval" egy 9 x 9-es táblán. A játék kezdetén a bábuk egy 3 x 3-as négyzetet formáznak a tábla bal alsó sarkában. A játék célja az, hogy addig mozgassuk a bábukat, amíg a tábla jobb felső sarkában nem alkotnak egy 3

x 3-as négyzetet, méghozzá a lehető legkevesebb lépéssel. A Halmában kétféle lépés megengedett:

• Fogunk egy bábut, és valamelyik üres szomszédos mezőre lépünk vele. Az "üres mező" azt jelenti, hogy a mezőben jelenleg nem tartózkodik bábu. A "szomszédos mező" olyan mező, amely közvetlenül a bábu jelenlegi helye felett vagy alatt, attól közvetlenül jobbra vagy balra, közvet

lenül átlósan balra felfelé vagy lefelé, illetve közvetlenül átlósan jobbra felfelé vagy lefelé található. (A tábla egyik oldala nem folytatódik a másik oldalon, tehát a bal szélső oszlopban levő bábuk nem mozoghatnak

balra, illetve átlósan balra felfelé vagy lefelé, a jobb szélső oszlopban levő

bábuk pedig nem mozoghatnak jobbra, illetve átlósan jobbra felfelé vagy lefelé.)

• Fogunk egy bábut, és átugrunk vele egy vagy- ha tehetjük- több szom

szédos bábut. Tehát ha átugrunk egy szomszédos bábut, majd egy másikat, amely az új pozícióval szomszédos mezőben áll, az egyetlen lépésnek

számít. Sőt, tetszőleges alkalommal ugorhatunk egymás után, az még mindig ugyanaz a lépés lesz. (Mivel a cél a lehető legkevesebb lépésből megoldani a feladatot, a Halmában akkor játszunk jól, ha egy-egy mezőt

kihagyva hosszú láncot építünk a bábukból, hogy a többi bábu minél többet átugorhasson közülük.)

A játékról a 4.16. ábrán láthatunk egy képernyőfelvételt. Az Interneten (http:/1 diveintohtml5.orglexampleslcanvas-halma.html) is játszhatunk vele, ha meg

szecetnénk vizsgálni a böngészőnk fejlesztőeszközeiveL


De hogyan működik a játék? Örülök a kérdésnek. Itt nem fogom az egész kódot bemutatni (de ha kíváncsiak vagyunk rá, megtalálhatjuk a http:/1 diveintohtml5.orglexampleslhalmajs címen). Magának a játékot vezérlő kódnak a nagyját kihagyom, de kiemelnék néhány olyan kódrészt, amely a rajzvászonra rajzolással kapcsolatos, illetve a <canvas> elemen végrehajtott egérkattintásokat kezeli.

o o o o o o o o o

Lépés: O l

4.16. ábra A Halmajáték kezdőállása

A játékot az oldal betöltése közben készítjük elő, a <canvas> elem méreteinek beállításával, illetve egy a rajzvászon rajzkörnyezetére mutató hivatkozás elraktározásával:

gCanvasElement. wid th= kPixelWidth;

gCanvasElement. height = kPixelHeight;

gDrawingContext = gCanvasElement. getContext ("2 d") ;


Ezt követően valami olyasmit csinálunk, amivel eddig még nem találkoztunk: hozzáadunk egy eseménykezelőt a <canvas> elemhez, amellyel a kattimási eseményeket (click) figyeljük:

gCanvasElement. addEventListener ( "click", halmaOnClick, false) ;

A halmaOnClick() függvény akkor hívódik meg, amikor a felhasználó valahol a rajzvászonra kattint. A függvény argumentuma egy MouseEvent

(egéresemény) objektum, amely megadja, hogy a felhasználó hol kattintott:

function halmaOnClick (e) { var cell= getCursorPosition (e);

l l a többi csak a játék vezérlőlogikája

for (var i=O; i<gNumPieces; i++) { if ( (gPieces [i]. row == cell. row) &&

(gPieces [i] . column== cell. column))

clickOnPiece(i);

return;

J

J clickOnEmptyCell(cell);

A következő lépés, hogy fogjuk a MouseEvent objektumot, és kiszámítjuk, hogy a felhasználó a Halma-tábla melyik mezőjére kattintott. A Halma-tábla elfoglalja az egész rajzvászont, tehát minden kattintás a tábla valamelyik részére történik - csak ki kell derítenünk, hogy melyikre. Ez nem egyszerű, mert az egéreseményeket szinte minden böngészőben másképp valósították meg:

function getCursorPosition (e)

var x;

var y;

if (e.pageX ll e.pageY)

x= e.pageX;

y= e.pageY;

) else { x= e. clientX + document .body. scrollLeft +

document.documentElement.scrollLeft;

y= e. clientY + document .body. scrollTop +

document.documentElement.scrollTop;


Itt még a dokumentumhoz (vagyis a teljes HTML-oldalhoz) viszonyított x

és y koordinátáink vannak, de mi a rajzvászonhoz viszonyított koordinátákat szeretnénk. Így juthatunk hozzájuk:

x-= gCanvasElement. offsetLeft;

y-= gCanvasElement. offsetTop;

Az x és y koordinátáink most már a rajzvászonhoz viszonyítottak (lásd a "Rajzvászon-koordináták" című részt a fejezet korábbi részében), vagyis ha most x = O és y = 0, akkor tudjuk, hogy a felhasználó a rajzvászon bal felső sarkában található képpontra kattintott.

Innen már kiszámíthatjuk, hogy a felhasználó melyik Halma-mezőre kattintott, majd ennek megfelelően cselekedhetünk:

var cell= new Cell (Ma th. floor (y/kPieceHeight),

Math.floor(x/kPieceWidth));

return cell;

Húha! Az egéreseményekkel nem könnyü bánni! Viszont ugyanezt a logikát (sőt akár pontosan ezt a kódot) alkalmazhatjuk minden rajzvászon alapú alkalmazásban. Jegyezzük meg: egérkattintás->dokumentumhoz viszonyított koordináták->rajzvászonhoz viszonyított koordináták->alkalmazásfüggő kód.

Oké, akkor most nézzük a fő rajzolóeljárást. Mivel a grafika nagyon egyszerű, úgy döntöttem, hogy minden lépés után törlöm és újrarajzolom az egész táblát, de ez nem feltétlenül szükséges. A rajzvászon rajzkörnyezete megőrzi, amit korábban a vászonra rajzoltunk, még akkor is, ha a felhasználó kigördíti a rajzvásznat az ablakból, vagy egy másik böngészőlapra vált, aztán később visszatér a játékhoz. Ha bonyolultabb grafikájú rajzvászon alapú játékot (például valamilyen ügyességi játékot) fejlesztünk, növelhetjük a sebességét, ha nyomon követjük a rajzvászon "piszkos" mezőit, és csak azokat rajzoljuk újra - ez azonban túlmutat ennek a könyvnek a keretein. Íme a táblát tisztára törlő kód:

gDrawingContext.clearRect(O, O, kPixelWidth, kPixelHeight);

A táblarajzoló eljárásnak már ismerősnek kell lennie: nagyon hasonlít ahhoz, ahogy a rajzvászonkoordináta-diagramot rajzoltuk meg (lásd a fejezet "Rajzvászon-koordináták" címü részét):


gDrawingContext.beginPath();

l* függőleges vonalak* l for (var x= 0; x<= kPixelWidth; x+= kPieceWidth)

gDrawingContext.moveTo (0.5 +x, 0);

gDrawingContext .lineTo (0. 5+ x, kPixelHeight);

l* vizszintes vonalak* l for (var y= 0; y<= kPixelHeight; y+= kPieceHeight)

gDrawingContext .moveTo (O, O. 5 + y) ;

gDrawingContext .lineTo ( kPixelWidth, O. 5 + y) ;

l* Raj zoljuk ki! *l

gDrawingContext. strokeStyle = "#ccc ";

gDrawingContext.stroke();

Az igazi móka akkor kezdődik, amikor nekilátunk megrajzolni az egyes bábukat. A bábukat egy-egy kör jelképezi - ilyesmit sem rajzoltunk még. Továbbá, ha a felhasználó kiválaszt egy bábut, amellyel lépni szeretne, ezt a bábut egy kitöltött körrel szeretnénk jelölni. Az alábbiakban a p argumen

tum jelképezi a bábut, a bábu jelenlegi helyét a táblán pedig ennek a row (sor) és column (oszlop) tulajdonságai. A (column, row) koordinátákat né

hány, csak ebben a játékban érvényes állandó segítségével lefordítjuk rajzvászonhoz viszonyított (x, y) koordinátákra, majd rajzolunk egy kört, és (ha

a felhasználó kiválasztotta a bábut) kitöltjük azt egy színnel:

function drawPiece (p, selected)

var column= p.column;

var row =p. row;

var x= (column* kPieceWidth) + (kPieceWidthl2);

var y= (row * kPieceHeight) + (kPieceHeightl2);

var ractius = (kPieceWidth/2) - (kPieceWidthllO);

Itt ér véget a játék programlogikája. Most már megvannak a rajzvászonhoz

viszonyított (x, y) koordinátáink, amelyek megadják a kirajzolni kívánt

kör középpontját. A Canvas API-ban nincs circle () tagfüggvény, de arc()

tagfüggvény igen- a kör (circle) pedig nem más, rnint egy önmagába záródó ív (arc), nem igaz? Mértan alapfokon. Az arc() tagfüggvénynek egy (x, y)

középpontot, egy sugarat, egy kezdő- és zárószöget (radiánban), valamint

egy irányjelzőt (false, ha az óramutató járásával egyező, és true, ha az


óramutató járásával ellentétes) kell átadnunk. A radiánszámításhoz a JavaScriptbe beépített Ma th modult használhatjuk:

gDrawingContext.beginPath();

gDrawingContext.arc(x, y, radius, O, Math.PI*2, false);

gDrawingContext.closePath();

Várjunk csak! Semmi nem rajzolódik ki! A moveTo () és l i ne To () tagfüggvényekhez hasonlóan az arc () is "ceruza-tagfüggvény" (lásd a fejezet "Útvonalak" című részét): ahhoz, hogy a kört valóban kirajzoljuk, be kell állítanunk a körvonalstílust (strokeStyle), és meg kell hívnunk a stroke() tagfüggvényt, hogy "tollal" kihúzzuk a ceruzavonalakat:

gDrawingContext. strokeStyle = "#OOO"; gDrawingContext.stroke();

Mi a helyzet akkor, ha kiválasztott báburól van szó? Nos, ekkor újrahasznosíthatjuk azt az útvonalat, amelyet a bábu körvonalának megrajzolására hoztunk létre, és kirölthetjük egy színnel:

if (selected) { gDrawingContext. fillStyle = "#OOO •;

gDrawingContext.fill();

l

Lényegében ennyi az egész. A program többi része a játékot vezérlő logika: a szabályos és szabálytalan lépések megkülönböztetése, a lépések számának nyomon követése, a játék végének megállapítása. Kilenc körrel, néhány egyenes vonallal és egy onclick eseménykezelővel megalkottunk egy teljes játékot egy <canvas> elemben! Éljen!


• Canvas-ranfolyam (https:lldeveloper. mozilla. orglen!Canvas_tutorial) a Mozilla Developer Center webhelyén

• Mihai Sucan: "HTML5 canvas - the basics" (http:!!dev.opera.com/ articles/view!html-5-canvas-the-basics/)

• Canvas Dernos (http:!!www.canvasdemos.com}: bemutatók, eszközök és oktatóanyagok a HTML <canvas> eleméhez

• "The canvas element" (http:llbit.lyi9]Hz0j) a HTML5 szabványtervezetében


5. fejezet

Videó a Weben

Ugorjunk fejest!

Bárki, aki ellátogatott a YouTube.com oldalára az elmúlt négy évben, tudja, hogy a weboldalakba videókat is beágyazhatunk A HTMLS előtt azonban

ennek nem volt szabványokon alapuló módja. Lényegében minden videó,

amit valaha láttunk "a Weben", egy külső bővítmény (plug-in) - esetleg

a QuickTime, a RealPlayer vagy a Flash - segítségével jutott el hozzánk. (A YouTube a Flash-t használja.) Ezek a bővítmények elég jól beépülnek a böngészőbe, ezért nem is nagyon vesszük észre, amikor használjuk őket -legalábbis amíg egy olyan rendszeren nem próbálunk megtekinteni egy videót, amelyik nem támogatja az adott bővítményt.

A HTMLS ezzel szemben szabványos módszert határoz meg a videók weboldalakba ágyazására: a <video> elem használatár. A <video> elem

támogatása még képlékeny - ami udvarias megfogalmazása annak, hogy egyelőre nem működik (legalábbis nem mindenhol). De ne essünk kétségbe! Bőségesen van alternatíva, alapértelmezés és kerülőút. Az 5.1. táblázat megmutatja, hogy könyvünk írásának idején mely böngészők támogatták a <video> elemet .

./ ./ ./ ./ ./ ./

Magának a <video> elemnek a támogatása azonban csak egy kis része a történetnek. Mindazonáltal, mielőtt a HTMLS-videókról beszélhetnénk, többet kell tudnunk a videókról úgy általában. (Ha ezen a téren kielégítőek az ismereteink, nyugodtan ugorjunk az "Ami a Weben működik" című részre.)

5. fejezet Videó a Weben l 121

Videatáralók

A videofájlokra általában úgy szoktunk gondolni, hogy "A VI-fájlok" vagy

"MP4-fájlok", a valóságban azonban az "AVI" és az "MP4" csupán tárolóformátumok. Ahogy egy ZIP-fájl is bármilyen típusú fájlt tartalmazhat, a videotároló-formátumok is csak azt határozzák meg, hogy miként kell bennük tárolni adatokat - azt viszont nem, hogy ezek milyen fajta adatok lehetnek. (A dolog persze kicsit bonyolultabb ennél, mivel nem minden video-adatfolyam tehető bármilyen formátumú tárolóba, de ezzel most ne törődjünk.)

A vicleofájlok általában több sávból (track) állnak: egy videosávból (hang nélkül), és egy vagy több audiosávból (képet nem tartalmazó hangsávból). A sávok jellemzően össze vannak kapcsolva: a hangsávok például jelzőket tartalmaznak, amelyek a kép és a hang összehangolását segítik. Az egyes sávokhoz metaadatok is rendelhetők, például a kép oldalaránya vagy a hangsáv nyelve. A tárolóknak szintén lehetnek metaadataik, például a videó címe, a videó "borítóképe", (tv-műsorok esetében) az epizód sorszáma, és így tovább.

Rengeteg vicleotároló-formátum létezik. A legnépszerűbbek közé tartoznak például az alábbiak: MPEG-4

Az MPEG-4 fájlok kiterjesztése általában .mp4 vagy .m4v. Az MPEG-4 tároló az Apple régebbi QuickTime tárolóformátumán (.mov) alapul. Az Apple webhelyén megtekinthető filmelőzetesek még mindig a régi QuickTime formátumot használják, az iTunes-ról rendelt mozifilmeket azonban MPEG-4 tárolóha csomagolva kapjuk meg.

Flash Video A Flash-videofájlok kiterjesztése általában .flv. A Flash-videók készítésére - nem meglepő módon - az Adobe Flash programot használják. A Flash 9.0.60.184 (más néven: Flash Player 9 Update 3) előtt ez volt az egyetlen tárolóformátum, amelyet a Flash támogatott, a Flash újabb változatai azonban már az MPEG-4 tárolót is ismerik.

O gg Az Ogg-fájlok kiterjesztése általában .ogv. Az Ogg nyílt szabvány, amely támogatja a nyílt forrást, és nem veri bilincsbe semmilyen szabadalom. A Firefox 3.5, a Chrome 4 és az Opera 10.5 beépített támogatást kínál hozzá, tehát az Ogg tárolóformátumhoz, az Oggvideókhoz ("Theora") és az Ogg-hangfájlokhoz ("Vorbis") ezekben

122 l Videó a Weben 5. fejezet

a böngészőkben nincs szükség külön az adott rendszerre Írt bővítményekre. Az asztali operációs rendszerek közül minden fontosabb Linux-terjesztés beépített támogatást nyújt az Ogg-hoz, de Mac-en és Windowson is használható, ha telepítjük a QuickTime-összetevőket (Mac), illetve DirectShow-szűrőket (Windows). Az Ogg-fájlok min

den rendszeren lejátszhatók a kitűnő VLC (http:llwww.videolan.org/ vlcl) segítségével is.

WebM A WebM-fájlok kiterjesztése .webm. A WebM egy új tárolóformátum, amely a felépítése szempontjából nagyon hasonlít a Marroska nevű formátumra. A WebM-et a 2010-es Google 1/0-n jelentették be, és kizárólagosan a VP8 videokodekkel, illetve a Yorbis audiokodekkel való használatra tervezték. (Ezekről hamarosan bővebben is szót ejtünk.) A Chromium, a Google Chrome, a Mozilla Firefox és az Opera következő változatai beépítve, az adott rendszerre Írt bővítmények nél

kül fogják támogarni. Az Adobe ezenkívül bejelentette, hogy a Flash következő változata is támogatja majd a WebM-videókat.

Audio Video Interleave Az Audio Vicleo Interleave-fájlok kiterjesztése általában .avi. Az AVI tárolóformátumot a Microsoft fejlesztette ki egy boldogabb időben, amikor már az is csodaszámba ment, hogy a számítógép egyáltalán

képes vicleót lejátszani. Az AVI hivatalosan nem támogatja az újabb tárolóformátumok számos szolgáltatását, például hivatalosan semmilyen video-metaadatot nem engedélyez, sőt a ma használatban levő

modern video- és audiokodekek többségének használatát sem. Az idők során a különböző cégek - egymással általában össze nem férő módon - megpróbálták kibővíteni, hogy támogassa ezt vagy azt, és az AVI máig az alapértelmezett tárolóformátuma az olyan népszerű kódolóprogramoknak, mint az MEncoder (http://www. mplayerhq. hul DOCS/HTML/enlencoding-guide.html).

Videokodekek

Amikor azt mondjuk, hogy "megnézünk egy videót", valószínűleg egy videoadatfolyam és egy audio-adatfolyam együttesére gondolunk, de nem két


külön fájlunk van, csak "egy videónk ", ami lehet egy A VI-fájl vagy- mondjuk- egy MP4-fájl. Ahogy az előző részben említettem, ezek csupán tárolóformátumok, mint a ZIP, amelyben többféle fájl is lehet. A tárolóformátum szabja meg, hogy a video- és audio-adatfolyamokat hogyan lehet egyetlen fájlban tárolni.

Amikor "megnézünk egy videót", a videolejátszó egyszerre több dolgot is csinál:

• Értelmezi a tárolóformátumot, hogy kiderítse, milyen video- és hangsávok állnak rendelkezésre, és azok hogyan tárolódnak a fájlon belül, hogy képes legyen megtalálni a következőként visszafejtendő adatokat.

• Visszafejti a videofolyamot, és megjeleníti a képek sorozatát a képernyőn. • Visszafejti az audiofolyamot, és a hangot a hangszórókra küldi.

A videokodek az az algoritmus, amellyel a vicleofolyamot kódolták - vagyis azt adja meg, hogy miként kell végrehajtani a 2. lépést a fentiek közül. (A "kodek " szó a "kódoló" és "dekódoló" kifejezések kombinációjából született.) A videolejátszónk a videokodeknek megfelelőerr visszafejti ("dekódolja") a videofolyamot, majd megjeleníti a képek sorozatát (a "képkockákat", frame) a képernyőn. A legtöbb modern videokodek mindenféle trükkel igyekszik csökkenteni az egymás utáni képkockák megjelenítéséhez szükséges információmennyiséget, például ahelyett, hogy minden egyes képkockát tároina (mintha képernyő-pillanatfelvételek lennének), csak a képkockák közötti különbségeket jegyzi meg. A legtöbb videó valójában nem változik túl sokat egyik képkockáról a másikra, ezért ez a megoldás nagyfokú tömörítést tesz lehetövé, ami kisebb fájiméretet eredményez.

Léteznek veszteséges és veszteségmentes videokodekek is. A veszteségmentes videók túlságosan nagyok ahhoz, hogy hasznukat vehessük a Weben, ezért a veszteséges kodekekre fogunk összpontosítani. Amikor veszteséges videokodeket használunk, a kódolás során végérvényesen elveszítünk bizonyos információkat. Ugyanúgy, mint amikor egy audiokazettát másolgatunk, minden alkalommal, amikor kódoljuk a videofolyamot, új abb és újabb részleteket veszítünk el a forrásvideóbóL Így a minőség egyre romlik, csak ami a hangkazettáknál "sziszegésként" jelentkezik, az a többször újrakódolt videóknál

"kockásodást" eredményez, különösen a sok mozgást tartalmazó jelenetekben. (Ez valójában akkor is megeshet, ha közvetlenül az eredeti forrásból


kódolunk, amennyiben gyenge minőségű videokodeket használunk, vagy rossz paramétereket adunk meg a számára.) Másrészt viszont a veszteséges videokodekek döbbenetes mértékű tömörítést tesznek lehetővé, és sok kodek

"csalni" is képes: lejátszás közben különféle módszerekkel elfedi a kockásodást,

hogy az az emberi szemnek kevésbé legyen észrevehető. Videokodekből tengernyi létezik, a számunkra legfontosabb három azon

ban a H.264, a Theora és a VP8.

H.264

A H.264 kodek (http:!len.wikipedia.orglwiki/H264) többféle néven is ismeretes: "MPEG-4 part 10", "MPEG-4 AVC", "MPEG-4 Advanced Vicleo Coding". A H.264-et az MPEG-csoport fejlesztette ki, és 2003-ban szabványosította. Célja, hogy egyetlen kodeket biztosítson az alacsony sávszélességű és alacsony CPU-teljesítményű eszközök (például a mobiltelefonok), a nagy sávszélességű és nagy CPU-teljesítményű eszközök (a modern asztali számítógépek) és a kettő között található minden más eszköz számára. Ennek érde

kében a H.264 szabványt "profilokra" bontották, amelyek mindegyike más

más mértékben áldozza fel a minőséget a fájlméret oltárán. A magasabb profilokban több kiegészítő lehetőség érhető el, jobb képminőséget kapunk,

miközben kisebb fájlmérettel dolgozunk, így viszont tovább tart a kódolás, a valós idejű visszafejtéshez pedig nagyobb CPU-teljesítmény szükséges.

Talán így jobban el tudjuk képzelni a profilkínálator: az Apple iPhone-ja

a Baseline (Alap) profilt támogatja, az AppleT V set-top box a Baseline és

Main (Fő) profilokat, az asztali PC-ken futó Adobe Flash pedig a Baseline, Main és High (Magas) profilokat. A YouTube (amelynek a tulajdonosa a Google, a szerző munkaadója) ma már a H.264 segítségével kódolja az Adobe Flash-en keresztül lejátszható csúcsminőségű videókat, ugyanakkor mobileszközökhöz- köztük az Apple i Phone-hoz és a Google Android nevű mobil operációs rendszerét futtató telefonokhoz - is kínál H.264 kódolású videókat. A H.264 ezenkívül egyike a Blu-ray szabvány által megkövetelt videokodekeknek is. Az ilyen kódolású Blu-ray lemezek általában a High profilt használják.

Azok a nem számítógépes eszközök, amelyek képesek H.264-videókat le

játszani (beleértve az i Phone-okat és az önálló B lu-ray lejátszókat) a dekódolás t


egy kifejezetten erre a célra szolgáló lapka segítségével végzik, mivel a központi feldolgozóegységük teljesítménye messze elmarad arról, ami a videók

valós idejű visszafejtéséhez szükséges. Sok asztali rendszerhez készült grafikus kártya ugyancsak hardveres támogatást nyújt a H.264 visszafejréséhez. H.264-kódolóból több, egymással versengő változar létezik, köztük a nyílt forrású x 264 könyvtár. A H.264 szabványt szabadalrnak kötik; felhasználási engedélyeit az MPEG LA csoport kezeli. H. 264 kódolású vicleót a legtöbb népszerű tárolóformátumba beágyazharunk (lásd a "Videorárolók" című részt a fejezet elején), többek között az MP4-be (ezt elsősorban az Apple iT unes boltja használja) és az MKV-ba (ez elsősorban a lelkes vicleoamatőrök választása).

Theora

A Theora (http:llen.wikipedia.orglwiki/7heora) a VP3 kodekből fejlődött ki, és azóta a Xiph.org Foundation fejleszti. A Theora jogdíjmentes kodek, amelyet nem köt semmilyen ismerr szabadalom az eredeti VP3-szabadalmakon kívül, amelyek szintén jogdíjmentesen felhasználhatók. Bár a szabvány 2004 óra "fagyasztott" állaporban van, a Theora projekt (amely egy nyílt forrású referencia-kódolóból és -dekódoló ból áll) csak 200 8 novemberében jelentette meg az 1.0-s változatot, és 2009 szeptemberében az 1.1-esr.

A Theora-videók bármilyen tárolóformátumba beágyazhatók, bár a leggyakrabban Ogg tárolókban szakrak előfordulni. Minden fonrosabb Linuxterjeszrés beépítve támogatja a Theorát, a Mozilla Firefax 3.5 pedig ugyancsak natív támogatást nyújt az Ogg-rárolóban elhelyezett Theora-videókhoz.

"Natív" alatt itt azt értem, hogy "minden platforrnon elérhető platformfüggő bővítmény nélkül". A Theora-videók Windowsan és Mac OS X-en is lejárszharók, ha telepítettük a Xiph.org nyílt forrású dekódoló szofrverér.

V P 8

A VP8 (http://en.wikipedia.orglwiki/VPB) egy másik videokodek az On2-ról, tehát ugyanarról a vállalatról, amelyik erederileg a VP3-ar is készítette (ebből lett később a Theora). A VP8 a minőségér tekintve hasonló a H.264 Baseline kódoláshoz, de rengeteg teret ad a jövőbeli továbbfejlesztésnek


2010-ben a Google megszerezre az On2-t, és közzétette a videokodek leírását, valamint egy nyílt forrású mintakódolót és -dekódolót. Ezzel párhuzamosan a Google "megnyitotta" az On2 által a VP8-ra benyújtott összes szabadaimat is, és a felhasználásukat jogdíjmentessé tette. (A szabadalrnak esetében ennél többet nem is várhatunk, mivel a nyílttá válásuk után nem jelentherök be újra vagy vonhatók vissza. Ahhoz, hogy támogassák a nyílt forrású fejlesztést, jogdíjmentessé kell tenni őket, így bárki felhasználhatja a szabadalrnak által lefedett technológiákat anélkül, hogy fizetnie kellene ér

tük, vagy engedélyhez kellene folyamodnia.) 2010. május 19. óta a VP8 jogdíjmentes, modern kodek, amelyet nem köt semmilyen ismert szabadalom az On2 (most már a Google) által korábban jogdíjmentessé tett szabadalmakon kívül.

Audiokodekek

Hacsak nem ragaszkodunk az 1927 előtt készült filmekhez, a videóinkban biztosan szerernénk hangsávot is. A videokodekekhez hasonlóan az audiokodekek is kódoló algoritmusok, csak éppen ezek hang-adarfolyamok kódolására szolgálnak. Ahogy a videokodekekből, úgy az audiokodekekből is léteznek veszteségesek és veszteségmentesek, és mint a veszteségmentes videók, a veszteségmentes audiofájlok is túl nagyok a webes felhasználáshoz, ezért a veszteséges audiokodekekre fogunk összpontosítani.

A kört valójában még tovább szűkíthetjük, mert a veszteséges audiokodekeknek különböző csoportjai léteznek. Hangot sok olyan helyen is alkalmaznak, ahol nincs kép (például telefonálásnál), és audiokodekek egész sorát hangolták kifejezetten beszéd kódolására. Ezekkel a kodekekkel nem CD-kről fogunk zenét lelopni, mivel az eredmény úgy hangzana, mintha egy négyéves gyerek énekelne egy hangtölcsérbe, egy Asterisk PBX-ben azonban igenis ezt fogjuk használni, mert a sávszélesség nagy kincs, ezek a kodekek pedig az emberi beszédet annak a mérernek a töredékére képesek összenyomni, amit egy általános célú kodekkel elérhetünk. Mindazonáltal a böngészők és külső bővítmények támogatásának hiányában a beszédre optimalizált audiokodekek soha nem terjedtek el igazán a Weben, ezért inkább az általános célú veszteséges audiokodekeket fogjuk az előtérbe helyezni.

Ahogy a fejezet "Videokodekek" dm ű részében említettem, amikor "videót nézünk", a számítógépünk több dolgot csinál egyszerre:


l. Értelmezi a tárolóformátumot. 2. Visszafejti a videofolyamot. 3. Visszafejti az audiofolyamot, és a hangot a hangszórókra küldi.

Az audiokodek a 3. lépés végrehajtásának mikéntjét írja le: azt, hogy miként lehet visszafejteni az audiofolyamot, és digitális hullámformává alakítani azt, amit aztán a hangszórók hanggá alakítanak. A videokodekhez hasonlóan az audiokodekek is mindenféle trükkel igyekeznek csökkenteni az audiofolyamban tárolt információmennyiséget. Mivel pedig most veszteséges audiokodekekről beszélünk, ez azt jelenti, hogy a hang rögzítésből, kódolásból, visszafejtésből és lejátszásból álló életciklusa során információt veszítünk. A különböző audiokodekek más-más információkat dobnak el, de mindnek ugyanaz a célja: becsapni a fülünket, hogy ne vegyük észre a hiányzó hangokat.

A hang esetében egy olyan fogalmat is meg kell ismernünk, ami a videónál nem létezik: ez a csatorna. A hangot a hangszórókra küldjük, igaz? Nos, hány hangszórónk is van? Ha a számítógépünk előtt ülünk, valószínűleg kettő: egy a bal, egy pedig a jobb oldalunkon. Az én asztali rendszeremen három működik: a bal, a jobb és még egy hangszóró a padlón. Az úgynevezett "surround" (térhatású) rendszerek hat vagy még több hangszóróval is rendelkezhetnek, amelyeket a szoba adott pontjain keU elhelyeznünk Mindegyik hangszóró egy bizonyos csatorna hangját kapja meg az eredeti felvételbőL A térhatású hang elmélete szerint a hat hangszóró között ülünk, így szó szerint hat külön hangcsatorna hangja vesz körül minket, és az agyunk úgy rakja össze ezeket, hogy úgy érezzük, mi is részesei vagyunk az eseményeknek. És hogy tényleg működik-e? Sokmilliárdos ipar épült rá- a befektetők nyilván úgy gondolják, hogy igen.

A legtöbb általános célú audiokodek két hangcsatornát képes kezelni: a rögzítés során bal és jobb csatornára bontja a hangot; kódoláskor mindkettőt ugyanabba az audiofolyamba menti; visszafejtéskor pedig mindkét csatornát dekódolja, és a megfelelő hangszóróra küldi. Egyes audiokodekek kettőnél több csatornát is tudnak kezelni, és nyomon követik, hogy melyik csatorna melyik, így a lejátszó a megfelelő hangokat küldheti az egyes hangszórókra.

Rengeteg audiokodek létezik. Ugyanezt mondtam volna a videokodekekről is? Felejtsük el. Audiokodekből sokkal, de sokkal több van - a Weben azonban igazán csak három számít: az MP3, az AAC és a V orbis.


MPEG-1 Audio Layer 3

Az MPEG-1 Audio Layer 3 (http:llen.wikipedia.orglwiki/MPEG-l_Audio_ Layer_3) kodeket közönségesen csak "MP3"-ként ismerjük. Ha még nem

hallottunk az MP3-ról, akkor nem tudom, mit is mondjak. A T escóban lehet kapni ilyen hordozható zenelejátszókat, amiket úgy hívnak, hogy "MP3-

lejátszó". A Tescóban. Na mindegy ... Az MP3-fájlok legfeljebb két hangcsatornát tartalmazhatnak, viszont

különféle bitsebességgel (bitrátával) kódolhatók: 64 kbps, 128 kbps, 192

kbps, és így tovább, 32 és 320 kbps (kilobit/másodperc) között. A magasabb bitsebesség nagyobb fájlméretet, de jobb hangminőséget jelent, bár a

minőség nem egyenesen arányos a bitsebességgeL (A 128 kbps bitsebességű fájlok kétszer olyan jól szólnak, mint a 64 kbps bitsebességűek, a 256 kbps azonban nincs kétszer olyan jó, mint a 128 kbps.) Ezen felül az MP3 for

mátum (amelyet 1991-ben szabványosítottak), változó bitsebességű kódolást is lehetövé tesz, ami azt jelenti, hogy a kódolt adatfolyam egyes részei erősebben, míg más részei kevésbé tömörítettek. Az egyes hangok közötti

csend például nagyon alacsony bitrátával is kódolható, hogy aztán a bitsebesség egy pillanattal később, amikor több hangszer szólaltat meg egy bonyolult akkordot, megugorjon. Az MP3-fájlok ugyanakkor állandó bitse

bességgel is kódolhatók (ezt hívják- minő meglepetés - állandó bitsebességű kódo/ásnak).

Az MP3-szabvány nem határozza meg pontosan, hogy miként kell kódoini az MP3-fájlokat (a dekódalásuk módját azonban pontosan leírja). A különféle

kódoJók más-más pszichoakusztikus modellt követnek, amelyek jelentősen

eltérő eredményt adnak, de ugyanazok a lejátszók mindet képesek visszafejteni. A legjobb ingyenes kódoló a nyílt forrású LAME, a legalacsonyabb bitsebességektől eltekintve pedig valószínűleg általában véve is a legjobb kódoló

(és pont). Az MP3 formátumot szabadalrnak kötik, ami megmagyarázza, miért nem

képes a Linux kiegészítők nélkül MP3-fájlokat lejátszani. Lényegében min

den hordozható zenelejátszó támogatja az önálló MP3-fájlokat, az MP3-audio

folyamok pedig bármely videotárolóba beágyazhatók. Az Adobe Flash az önálló MP3-fájlokat és az MP4 videotárolóba ágyazott MP3-audiofolyamokat is képes lejátszani.


Advanced Audio Coding

Az Advanced Audio Coding kodeket (http://en.wikipedia.orglwiki/Advanced_ Audio_Coding), bizalmas nevén az "AAC"-t, 1997-ben szabványosították, és akkor került reflektorfénybe, amikor az Apple ezt választotta az iTunes Store alapértelmezett formátumának Az iTunes Store-ból "vásárolt" AAC-fájlokat eredetileg levédték az Apple saját, FairPlay nevű DRM-sémájával, ma azonban már sok dal védelem nélküli AAC-fájl formájában érhető el a boltban- ezeket az Apple "iTunes Plus"-nak hívja, mert ez sokkal jobban hangzik, mintha minden mást "iTunes Minus"-nak neveznének. Az AAC formátumot szabadalrnak kötik; a felhasználási jogdíjak az Interneten megtekinthetők.

Az AAC-t úgy tervezték, hogy azonos bitsebességnél jobb hangminőséget nyújtson, mint az MP3, és az AAC tetszőleges hitrárával kódolható. (Az MP3 esetében csak adott számú bitráta áll rendelkezésre, a felső határ pedig 320 kbps.) Az AAC akár 48 hangcsatorna kódolására is képes, bár a gyakorlatban ezt senki nem használja ki. Az AAC formátum abban is különbözik az MP3-tól, hogy több profilt határoz meg, a H.264-hez hasonlóan, és azzal azonos célból. A "low complexity" ("alacsony bonyolultság") profilt a korlátozott CPU-teljesítménnyel rendelkező eszközökön történő valós idejű lejátszásra szánták, míg a magasabb profilok azonos bitsebesség mellett jobb hangminőséget kínálnak, aminek az ára a lassabb kódolás és visszafejtés.

Minden jelenlegi Apple-termék- beleértve az iPod-okat, az AppleT V-t és a QuickTime-t- támogat bizonyos AAC-profilokat az önálló audiofájlokban, illetve MP4 videotárolóba ágyazott audiofolyamokban. Az Adobe Flash az AAC valamennyi profilját támogatja az MP4-ben, akárcsak a nyílt forrású MPlayer és VLC videólejátszók. Kódolásra az FAAC könyvtár nyújt nyílt forrású lehetőséget; a könyvtárat fordításkor építhetjük be az mencoder-be és az ffmpeg-be.

Varbis

A Yorbist (http://en.wikipedia.orglwiki/Vorbis) gyakran hívják "Ogg Vorbis"nak, bár ez technikailag helytelen, hiszen az "O gg" csupán egy tárolóformátum (lásd a fejezet "Videotárolók" című részét), a Yorbis audiofolyamok pedig más tárolóformátumokba is beágyazhatók. A Yorbist nem köti semmilyen ismert


szabadalom, ezért a fontosabb Linux-terjesztések, illetve a nyílt forrású Rock Box firmware-t ("beégetett szoftvert") futtató hordozható eszközök kivétel nélkül beépített támogatást nyújtanak hozzá. A Mozilla Firefox 3.5 támogatja az Ogg tárolóha ágyazott Yorbis audiofájlokat, illetve a Yorbis audiosávval rendelkező Ogg videókat, és az Android mobiltelefonok is képesek lejátszani az önálló Yorbis audiofájlokat. A Yorbis audiofolyamokat általában Ogg vagy WebM tárolóha ágyazzák, de MP4 vagy MKV, sőt némi trükközéssel AYI tárolóha is beágyazhatók. A Yorbis tetszőleges számú hangcsatornát képes kezelni.

Yorbis-kódolóból és -dekódolóból is léteznek nyílt forrású változatok, például az OggConvert kódoló, az ffmpeg dekódoló, az aoT u Y kódoló és a Hbvorbis dekódoló. A Yorbist Mac OS X-en QuickTime-összetevők, Windowsan pedig DirectShow-szűrők segítségével játszhatjuk le.

Ami a Weben működik

Ha még nem ragadt le a szemünk, akkor jobban bírjuk a többségnéL Amint láthatjuk, a videó- és hangfájlok témaköre meglehetősen összetett - és ez még a rövidített változat volt! Most biztosan azon gondolkodunk, hogyan kapcsolódik mindez a HTML5-höz. Nos, úgy, hogy a HTML5-nek része a <vide o>

elem, amelyet videók weboldalakba ágyazására használhatunk. A videókban használható videokodekekre és audiokodekekre, illetve a tárolóformátumokra nézve nincsenek korlátozások. Egy <v ideo> elem több videofájlra is mutathat, amelyek közül a böngésző az első olyat választja ki, amelyet le tud ját

szani. Azt viszont nekünk kell tudnunk, hogy mely böngészők mely tárolókat és kodekeket támogatják.

Könyvünk írásának idején a HTML5-videók helyzete így festett:

• A Mozilla Firefox (3.5-ös és későbbi változatai) az Ogg-tárolóba ágyazott Theora-videosávokat és Yorbis-hangsávokat támogatják.

• Az Opera (10.5-ös és újabb kiadásai) az Ogg-tárolóba ágyazott Theoravideosávokat és Yorbis-hangsávokat támogatják.

• A Google Chrome (3.0-s és későbbi kiadásai) az Ogg-tárolóba ágyazott Theora-videosávokat és Vorbis-hangsávokat, valamint az MP4-tárolóba ágyazott H. 264-videosávokat (valamennyi profilt) és AAC-audiosávokat (valamennyi profilt) támogatják.


• Jelenleg (2010. június 9-én) a Google Chrome "dev channel"-je, a Chromium napi kiadásai, a Mozilla Firefox napi kiadásai és az Opera kísérleti

kiadásai mind támogatják a WebM-tárolóba ágyazott V P8-videosávokat és Vorbis-audiosávokat. (A legfrissebb információkért látogassunk el a webmproject.org oldalra, ahol a WebM-et ismerő böngészők letöltési oldalára mutató hivatkozásokat is találunk.)

• ASafari Mac-re és Windowsra Írt (3.0-s és későbbi) változatai minden olyasmit támogarnak, amit a QuickTime támogat. Elméletileg megkérhetjük a felhasználóinkat, hogy telepítsenek külső QuickTime-bővítményeket, a gyakorlatban azonban nagyon kevesen fogják ezt megtenni, így azoknál a formátumoknál kell maradnunk, amelyeket a QuickTime "beépítve"

támogat. Az eredetileg is támogatott formáturnak listája hosszú, de nem szerepel rajta sem a Theora-videó, sem a Vorbis-audió, sem az Ogg-tároló.

Ugyanakkor a QuickTime támogatja az MP4-tárolóba ágyazott (Main profilú) H.264-videosávokat és AAC-audiosávokat.

• Az olyan mobileszközök, mint az Apple i Phone vagy a Google Android, az MP4-tárolóba ágyazott (Baseline profilú) H.264-videosávokat és ("low complexity" profilú) AAC-audiosávokat támogatják.

• Az Adobe Flash (9.0.60.184-es és újabb) változatai az MP4-tárolóba

ágyazott H. 264-videosávokat (valamennyi profilt) és AAC-audiosávokat (valamennyi profilt) támogatják.

• Az Internet Explorer 9 támogaeni fogja az MP4-tárolóba ágyazott H.264-videosávokat és AAC-audiosávokat, de azt még nem lehet tudni,

hogy mely profilokat. • Az Internet Explorer 8 egyáltalán nem támogatja a HTML5-videókat, de

lényegében minden Internet Explorer-felhasználó rendelkezik az Adobe Flash bővítménnyel. A fejezet későbbi részében megmutatom, hogyan

ágyazhatunk be úgy HTML5-videókat, hogy ha szükséges, elegánsan helyettesíthessük őket Flash-fájlokkal.

A fenti információkat emészthetöbb formában megtaláljuk az 5.2. táblázatban is.

5.2. táblázat A használatban levő böngészők által támogatott videokodekek

IE Flrefox

Theora+Vorbis+Ogg - 3.5+

132 l Videó a Weben

5.0+ 10.5+

5. fejezet

H.264+AAC +MP4

W e bM

Arefmc Satari Cbrome

3.0+ 5.0+ 3.0+ 2.0+

A helyzet egy éven belül jelentősen meg fog változni: a WebM-et több böngészőben is megvalósítják, méghozzá nem kísérleti formában, és a felhasznáJók frissítik a böngészőjüket ezekre az új változatokra. A kodekek támogatása várhatóan az 5.3. táblázatban foglaltak szerint alakul majd.

5.3. táblázat A jövőbeli böngészők által támogatott videokodekek

Theora+VorbiS+Og_g - 3.5+

H.264+AAC +MP4

W e bM 9.0+· 4.0+

5.0+

3.0+ 5.0+

6.0+

10.5+

11.0+

3.0+ 2.0+

• Az Internet Explorer 9 csak akkor fogja támogatn i a WebM-et,.ha a felhasználó telepített egy

VP8-kodeket'; ami arra utal, hogy a Microsoft nem fogja mellékelni magát a kodeket.

b A Google elkötelezte magát amellett, hogy az Android.egy jövőbeli kiadásában"támogatni

fogja a WebM-et, de még nincs biztos ütemterv.

És most jöjjön a feketeleves ...


A tárolóknak és kodekeknek nincs olyan kombinációja, amelyik minden HTML5-képes böngészőben működne. Ez nem valószínű, hogy a közeljövőben meg fog változni. Ahhoz, hogy a videóink minden eszközön és rendszeren megtekinthetők legyenek, több változatban kell kódolnunk őket.

Ha a lehető legtöbb böngészővel és rendszerrel szeretnénk együttműködni, a videóink elkészítésénél az alábbi munkafolyamatot kell követnünk:

l. Készítünk egy Ogg-tárolóba ágyazott, Theora-videosávból és Vorbisaudiosávból álló változatot.

2. Készítünk egy másik, WebM (VP8 + Vorbis) formátumú változatot.


3. Készítünk még egy, MP4-tárolóba ágyazott, H.264 Baseline videosávból és AAC "low complexity" audiosávból álló változatot.

4. Mindhárom videofájlra hivatkazunk egy <v ideo> elemből, és szükség esetén Flash alapú videolejátszásra váltunk vissza.

A H.264-videók

felhasználási engedélyével kapcsolatos kérdések

Mielőtt folytatnánk, fel kell hívnom a figyelmet arra, hogy a videók többszöri kódolásának ára van. A nyilvánvaló költségen felül- mármint azon túl, hogy a többszöri kódoláshoz több idő és több számítógép-használat szükséges- a H.264

kódolású videókhoz egy nagyon is valóságos költség kapcsolódik: a jogdíj. Emlékezhetünk rá, hogy amikor először szóba került a H.264 (lásd a "H.264"

című részt néhány oldallal korábban), említettem, hogy ezt a videokodeket szabadalrnak kötik, és a felhasználását az MPEG LA konzorciummal kell engedélyeztetni. Ez meglehetősen fontos kérdés, de ahhoz, hogy megérthessük, miért is lényeges, álljon itt egy részlet a H.264 Licensing Labyrinth című cikkből*:

Az MPEG LA a H.264 jogdíj-portfolióját kétféle felhasználási enge

délyre bontja: az egyik a kódolók és dekódolók gyártóinak, a másik a tartalomszolgáltatóknak készült. [ . . . ]

A szolgáltatói oldal engedélyeit további négy alkategóriába sorolták, amelyek közül kettő (az előfizetés és a címenkénti vásárlás vagy felhasználás) esetében a végfelhasználó közvetlen ül fizet a videoszolgáltásokért,

míg kettő (a "szabad" televíziós és internetes sugárzás) esetében nem a végfelhasználó tól, hanem más forrásból szedik be a jogdíj at. [ ... ]

A "szabad" televíziós felhasználás jogdíja kétféle lehet. Az első esetében A VC-átviteli dekóderenként 2500 dollár egyszeri díjat kell fizetni, mely dekódert "az Engedélyes közvetlenül vagy áttételesen használja AVC-videók sugárzására a Végfelhasználónak", aki dekódolja és megtekinti azokat. Ha azon töprengünk, hogy ilyenkor vajon kétszeresen

* http:l!www.streamingmedia.com/Articles/Editorial/Featured-Articles/The-H.264-LicensingLabyrinth-65403.aspx


számítanak-e fel jogdíjat, a válasz: igen. A kódolót gyártó céggel már megfizettették a jogdíjat, de a műsorszolgáltatónak is ki kell fizetnie a kétféle tÍpusú jogdíj egyikét.

A jogdíj második típusát az éves sugárzási díj jelenti. [ ... ] Az éves sugárzási díjat a piac mérete (az előfizetők száma) alapján állapítják meg:

• Naptári évenként és 100 OOO-től 499 999 televíziókészülékig terjedő sugárzási piaconként 2500 dollár

• Naptári évenként és 500 OOO-től 999 999 televíziókészülékig terjedő sugárzási piaconként 5000 dollár

• Naptári évenként és l OOO OOO vagy annál több televíziókészülékig terjedő sugárzási piaconként 10 OOO dollár

[ ... ] Miért fontos a "szabad" televíziós felhasználás jogdíja azoknak, akik nem műsorsugárzással terjesztik a tartalmakat? Ahogy korábban említettem, a jogdíj-kötelezettség a tartalomszolgáltatás minden tÍpusára vonatkozik. Az MPEG LA a "szabad" televíziós sugárzás meghatározását a földi sugárzáson túlra is kiterjesztette, ezen felül pedig az imernetes sugárzásra is jogdíjakat állapított meg, mint "AVC-videók olyan terjesztésére a Világhálón, amelynek során a végfelhasználók nem fizetnek a letöltés vagy megtekintés jogáért". Más szavakkal, minden nyilvános sugárzás, legyen az földi, kábeles, műholdas vagy internetes szolgáltatás, jogdíjköteles. [ ... ]

Az internetes sugárzás jogdíja valamivel magasabb lehet- nyilván abból indultak ki, hogy az internetes tartalomközvetítés sokkal gyorsabb növekedést fog felmutatni, mint a földi sugárzás vagy a kábeles, illetve műholdas "szabad" televíziózás. Az MPEG LA a "szabad televíziós sugárzás" piaci díjához adna még egy kiegészítő díjat, de ennek megfizetése alól az első (2010. december 31-én lejáró) engedélyes periódus végéig felmentést adott, és leszögezte, hogy "a jogdíj az első periódus után sem lesz magasabb a szabad televíziós sugárzásért azonos időszakra fizetett összegnél".

A cikk elkészülte óta már változtattak is az internetes sugárzás jogdíjszerkezetén. Az MPEG LA nemrég bejelentette, hogy 2015. december 31-ig kiterjeszti az ingyenes internetes sugárzás lehetőségét. És hogy utána mi lesz? Ki tudja ... ?

5. fejezet Videó a Weben J 135

Ogg-videók kódolása a Firefogg segítségével

(Ebben a részben az "Ogg-videó" kifejezést a "Theora-videó és Yorbis-audió egy Ogg-tárolóban" helyett használom. Ez az a kodek+tároló kombináció, amelyet a Mozilla Firefox és a Google Chrome beépítve támogat.)

A Firefogg egy nyílt forrású, GPL felhasználási engedélyű Firefax-bővítmény az Ogg-videók kódolásához. A használatához telepítenünk kell a Mozilla

Firefox 3.5-ös vagy későbbi változatát, majd el kell látogatnunk a Firefogg webhelyére, amelyet az 5.1. ábrán láthatunk.

Kattintsunk az Install Firefogg (A Firefogg telepítése) gombra. A Firefox ekkor megkérdezi, hogy valóban engedélyezni szereménk-e a webhelynek egy bővítmény telepítését. A folytatáshoz kattintsunk azAllow (Engedélyezés) gombra (5.2. ábra).

A Firefox ekkor a szokványos szoftverrelepítési ablakot jeleníti meg. A foly

tatáshoz kattintsunk az Install Now (Telepítés most) gombra (5.3. ábra). A telepítés befejezéséhez a Restart Firefox (A Firefox újraindítása) lehetőséget kell választanunk (5.4. ábra). Miután a Firefox újraindult, a Firefogg webhely

megerősíti, hogy a Firefogg telepítése sikeresen lezajlott (5.5. ábra). A kódolást a Make Ogg Vicleo (Ogg-videó készítése) hivatkozásra kat

tintva indíthatjuk el (5.6. ábra), a forrásvicleót pedig a Select file (Fájl kiválasztása) gombbal választhatjuk ki (5.7. ábra).

o. ••

5.1. ábra A Firefogg honlapja


Firefog g 'fldeoentodinganduploldlngforfuefo•

Sifnus!ngf!rafuqg-Ustf!rmqgonYPyrS!II-�

5. fejezet

« F•rcftu: prcwntcd th" Jltc (fircfogg.org) from 1sl:mg you to tn sUU sof'twnrt on yout computer.

Stopptd

Firefog g vid eo eneolting and uptoalftno ror Flrefox

sttu uslng Ftrefogg - Usef!refoggonyoyrSrts-�

5.2. ábra A Firefog g telepítésének engedélyezése

5oft.- ht.ilation

.. �� yg�

Install add-ons only from authors whom you t rust.

Maliciaus software can damage you r computer or viclate you r privacy.

You have asked to install the follawing item:

Firefogg-l.O.O.xpi (Avthar not veri[ied) http :/ /firefogg .o r g/win 3 2/Fire fo gg -l. O. O.xp i

5.3. ábra A Firefogg telepítése

•

Cancel


Restart Firefax to complete your changes.

Firefogg 1.0.0 Restart to cornplete the mstallat1on .

. - .-- �· - ·:,. ' . ---· . ---- �· .. · .. - .,. .. - . fa'\.._�.:\_��J.JIJ.J.V,�_--'iol0..- ·�-:...��··� :-- •-:.O..•.l.Oc .. ,.,.,.,.-\_.•��1��

Close

5.4. ábra A Firefox újrainditása

Firefog g vid eo en toding and uploadlng for Firefox

Sdes ysjng F!ratogg. Use Fjrefoag povourSrte· �

Done

5.5. ábra A telepítés sikerült


·�-.o!!!!f ... !'P!!!!!'!f!eo----

fM_ {dit Yiew Hittory JfOOkmlor,"',.,'._.;.L0 -��·..;";.'.;.'' -- -----------'""'1 =-----..,.; : C X � "[; http�/fiRtogg.�g/ ü""1Rt· ·;._� p.j \:ilodlg-

Firefog g vieleo en coding and uploading for Firetoll

S1te s ysingfjrefoag-Usefjretogg onmyrSjtfl -"�===:::c·

http://firefogg.orrJ/mtkt[lftdex.html

5.6. ábra Készítsünk videót!

............ ,.....

� :LJ http://fireft,gg.org/mtktlindtx.html

T D Flrefogg- M.ke09g v.., ln, ... �-ru ,.. .

�-""- •

p

Ma ke O gg V i d e o Firefoga-vieleo encoding and u pioaCiing for Firefok

Srtgs US!OQ firefoga. u se flll!fogg on ygyr $(ta. Matca Ogg Vid eo

- Selectfile

{')

5.7. ábra A vicleofájl kiválasztása

5. fejezet

.,:. lll """" '·'"' •

Videó a Weben l 139

A Firefogg fő felülete hat "lapból" áll (lásd az 5.8. ábrát):

Preset (Sablon) Az alapértelmezett sablon a "web video", ami a céljainknak tökéletesen megfelel.

Encoding range (Kódolási tartomány) A videó kódolása hosszú ideig tarthat. Amikor először kódolunk, érdemes lehet a videónak csak egy részét (mondjuk az első 30 másodpercét) kódolni, amíg meg nem találjuk a nekünk tetsző beállításokat.

Basic quality and reso/ution control (Alapszintű minőség- és felbontásszabályozás) A lényeges beállítások többsége itt található.

Metadata (Metaadatok) Ezzel a lappal itt nem foglalkozom, de annyit elmondhatok, hogy olyan metaadatokat adhatunk a videóhoz, mint a videó címe és szerzője. Az iTunes vagy valamelyik másik zenerendszerező segítségével már valószínűleg adtunk metaadatokat a zenegyűjteményünkhöz -a működési elv ugyanaz.

Advanced video encoding controls (Haladó videokódolás-szabályzók) Ezekhez csak akkor nyúljunk, ha pontosan tudjuk, mit csinálunk. (A Firefogg interakdv segítséget nyújt a legtöbb beállításhoz. Ha többet szeretnénk tudni egy lehetőségről, kartintsunk a mellette látható "i" jelre.)

Advanced audio encoding controls (Haladó hangkódolás-szabályzók) Ezeket is csak akkor szabad piszkálnunk, ha pontosan tudjuk, mit csinálunk.

. (_...,......, .

• ....._.w. ........ .,.-

---

5.8. ábra Kódoljunk videót!


Csak a "Basic quality and resolution control" lapot (5.9. ábra) nézzük meg részletesen, mert minden fontos beállítás ezen található:

Video Quality (Képminőség) A képminőséget egy O-tól (legrosszabb minőség) 10-ig (legjobb minőség) terjedő skála méri. A nagyobb értékek nagyobb fájiméretet jelentenek, ezért kísérleteznünk kell, hogy megállapítsuk, milyen méret/minőség arány felel meg leginkább az igényeinknek.

Audio Quality (Hangminőség) A hangminőséget egy -l-től (legrosszabb minőség) 10-ig (legjobb minőség) terjedő skálán szabályozhatjuk A nagyobb értékek a képminőséghez hasonlóan itt is nagyobb fájiméretet jelentenek.

Video Codec (Videokodek) Itt mindig a "theora" értéket kell megadnunk.

Audio Codec (Audiokodek) Itt mindig a "vorbis" értéket kell megadnunk.

Video Width and Video Height (Képszélesség és képmagasság) Ezek alapértelmezés szerint a forrásvideó szélességéhez és magasságához igazodnak Ha a vicleót kódolás közben át is szeretnénk méretezni, itt módosíthatjuk a szélességét vagy a magasságát. A Firefogg automatikusan átállítja a másik kiterjedést, hogy megtarrsa az eredeti arányokat, így a videó képe nem nyomódik össze vagy nyúlik meg.

Az 5.10. ábrán azt láthatjuk, hogy a vicleót az eredeti szélességének a felére kicsinyírjük. Figyeljük meg, hogy a Firefogg önműködően ehhez igazítja a magasságot.


New0r1ee.ns2006 dv

� Preset: Web Video Theora, V orbis 400kbs & 400px max width

• Encodlng umye

r �-boasic qualhy •nd resolution control

OVideo Ouahty

OTVIIO Pass Encodmg f!

8 Audio Ouahty

OV•deoCodec 1heor.� •

OAud•o Codec vorb1s •

O ont �-��YSI'* 0.408> .

5.9. ábra Alapszintű minőség- és felbontásszabályzás

New0rleons2006 dv

� Preset Custom settlngs

� Encoding ra nye

Basic quality and resolution control

OTVIIO Pass Encod1ng �

O AudiO Oualdy

OVIdeoCodec

OAudio Codec

OVideo Widlh 3211

-===� OVideoHe�ght 113

httpJ!firtfogg.orgfm•kt/indtX.htmlft

5.1 O. ábra A videó képszélességének és képmagasságának szabályozása

142 l Videó a Weben s_ fejezet

Miután beállítottunk minden szabályzót, kattintsunk a Save Ogg (Ogg-fájl mentése) gombra, hogy elindítsuk a tényleges kódolást (5.11. ábra). A Firefogg ekkor egy fájlnevet kér a kódolt videó számára.

--

& � http://firtfogg.orglm•i:tftndex.htm.-

____ _ �

Li Aref�OggY"tdeoln,-� w select new file • Sl!IW 0gg

New0r1eans2006 dv .eJ • Preset Custom senings

t En coding range

• Basic quality and resolution control

• Metadala for the clip

• Advanced video encoding controls

' Advanced audio encodlng controls

http://firrlogg.org/mlktfmdex.htmltli

5.11. ábra A kódolást a .save Ogg" gombra kattintva indíthatjuk el

p

�IIIYSiow o ... ,,···

A Firefogg a videó kódolásának előrehaladását egy csinos folyamatsávon mutatja (lásd az 5.12. ábrát). Nekünk csak annyi a teendőnk, hogy várunk (és

várunk, és várunk ... ).

Ogg-videók kötegelt kódolása

az ffmpeg2theora segítségével

(Ahogy az előző részben, az "Ogg-videó" kifejezést itt is a "Theora-videó és Yorbis-audió egy Ogg-tárolóban" jelentésben fogom használni. Ez az a kodek+

tároló kombináció, amelyet a Mozilla Firefox és a Google Chrome beépítve támogat.)

Az Ogg-videók készítéséhez több kapcsolat nélkül használható kódoló is rendelkezésre áll. Ha sok vicleofájlt szeretnénk kötegelve, automatizáltan


kódolni, mindenképpen próbáljuk ki az ffmpeg2theora nevű programot (http://v2v. cel �j/ffmpeg2theora/).

Az ffmpeg2theora egy nyílt forrású, GPL felhasználási engedéllyel rendelkező alkalmazás Ogg-videók kódolásához. Előre lefordított bináris változatai Mac OS X-re, Windowsra és újabb Linux-terjesztésekre is elérhetők. Az ffmpeg2theora szinte bármilyen vicleofájlt elfogad bemenetként, beleértve az átlagfogyasztói piacra szánt karnkorderek által előállított DV-videókat is.

Az ffmpeg2theora-t a parancssorból meghívva vehetjük használatba. Windowson kövessük a Start, Programs, Accessories, Command Prompt (Start, Programok, Kellékek, Parancssor), Mac OS X-en pedig az Applications, Utilities, Terminal (Alkalmazások, Segédprogramok, Terminál) útvonalat.

f.net�dlng vldeo to Oqq X

M é 1 O%· Transcoded

• Preset CUS(Otn setti�

• Encoding r•nge

p

!O

• Basic qu.tlily •nd reso=l:.::uti :.::•• :.::co:;::ntr:.::•' ----------: ..:- a VSiow o ..... , e

5.12. ábra A kódolás folyamatban

Az ffmpeg2theora számos parancssori kapcsolót elfogad. (Ha mindet látni szeretnénk, írjuk be az ffmpeg2theora --help parancsot.) Én csak hármat emelnék ki közülük:

• --v ideo-quali ty Q (képminőség), ahol a Q egy O és 10 közötti szám • --audio-quality Q (hangminőség), ahoi a Q egy -2 és 10 közötti szám


• --max_ size=WxH (maximális méret), ahol a W és a H a videó számára engedélyezett maximális szélesség (wid th) és magasság (height). (A kettő közötti "x" csupán egy "x".) Az ffmpeg2theora a vicleót arányosan méretezi át a megadott keretek között, így előfordulhat, hogy a kódolás után a videó kisebb lesz a megadott WxH méretnél. Például ha egy 720x480 képpontos vicleót kódolunk a --max _ size 320x240 beállítással, eredményként egy 320 képpont széles és 213 képpont magas vicleót kapunk.

A fentiek szerím tehát az ffmpeg2theora-ban így kódolhatunk egy vicleót ugyanazokkal a beállításokkal, mint amelyeket az előző részben ("Ogg-videók kódolása a Firefogg segítségéve!") használtunk:

you@ localhas t$ ffmpeg2theora --videoquali ty 5 --audioquality l

--max size 320x240 pr6.dv

Az .ogv kiterjesztéssei ellátott kódolt videó ugyanabba a könyvtárba kerül, mint ahol az eredeti videó is található. Másik helyet vagy fájlnevet úgy adhatunk meg, ha átadjuk az -- output= / a / kódolt / videó/ elérési / útj a

parancssori kapcsolót az ffmpeg2theora-nak.

H.264-videók kódolása

a HandBrake segítségével

(Ebben a részben a "H.264-videó" kifejezést a "Baseline profilú H.264-videó és low complexity profilú AAC-audió egy MPEG4-tárolóban" helyett használom. Ez az a kodek+tároló kombináció, amelyet a Safari, az Adobe Flash, az iPhone és a Google Android eszközök beépítve támogatnak.)

A jogdíj kérdésétől eltekintve (lásd a fejezet "A H.264-videók felhasználási engedélyével kapcsolatos kérdések" című részét kicsit korábban) a H.264-videók kódolásának legegyszerűbb módja a HandBrake (http://handbrake.fr) használata. A HandBrake egy nyílt forrású, GPL felhasználási engedéllyel rendelkező alkalmazás H.264-videók kódolásához. (Régebben más videoformátumokat is tudott kezelni, de a legújabb változatban a fejlesztök úgy döntöttek, hogy a legtöbb formátum támogatását elhagyják, és minden erőfeszítésüket a H.264-videókra összpontosítják.) A HandErake-ből előre


lefordított bináris változatok Windowsra, Mac OS X-re és újabb Linux-terjesztésekre is elérhetők (http://handbrake.fr/downloads.php).

A HandBrake kétféle kivitelben készül: grafikus felületű és parancssori változatban. Én először a grafikus felületet mutatom be, majd azt is megnézzük, hogyan adhatók meg a javasolt beállítások a parancssorban.

Miután megnyitottuk a HandBrake alkalmazást, az első dolgunk a forrásvideó kiválasztása (lásd az 5.13. ábrát). A fájl kiválasztásához kattintsunk a Source (Forrás) ikonra, majd a lenyíló listából válasszuk a Video File (Videofájl) lehetőséget. A HandBrake szinte bármilyen vicleofájlt elfogad bemenetként, beleértve az átlagfogyasztói piacra szánt karnkorderek által előállított DV-videókat is.

5.13. ábra A forrásvideó kiválasztása

A HandBrake ekkor panaszkodni fog, hogy még nem állítottunk be alapértelmezett könyvtárat, ahová a kódolt videókat mentheti (lásd az 5.14. ábrát). Ezt a figyelmeztetést nyugodtan figyelmen kívül hagyhatjuk, de azt is megtehetjük, hogy megnyitjuk a beállítóablakot (a Tools-Eszközök- menüből), és megadunk egy alapértelmezett kimeneti könyvtárat.


'Selea.��·�cCif'JITJ.Ie i<OO:oÚ'!2) - .,.., �es: :1 .. jl1v.:u;t. 1 • w� oo�.z

dJiftgS"(Pr�l:�) """'

IOI!oEI!!!!)lr,1ooJ ......

1ZD> <�80 Asced.P

j"" L

...., KeepAspertJlat!D

] Pod5GR.I)p0rt

You currtntly � "AutOfl'\ltK:1IJy n�me. output files"ltnlbled forthe dest•IVbon file*. but you do no1 have • dd11ult directory set.

You should set 1 "Dd1ult P.th" '" H.ndB�kH preferenus. ($ee 'lools' menu ·>'Options'·> ·�..r hb·> 'tnf•ult hth')

.._ ..

pUe •Stra:t SQ:'!' 'h$�480 C2D

-�

5.14. ábra Ezt a figyelmeztetést hagyjuk figyelmen kívül

�

A jobb oldalon találjuk a sablonok listáját. Ha az "iPhone &iPod Touch"

sablont választjuk, mint az 5.15. ábrán, a beállítások többsége az általunk kívánt értékeket kapja.

Az egyik lényeges beállítás, amely alapértelmezés szerint ki van kapcsolva, a Web opeimized (Optimalizálás a Webre). Ha ezt a lehetőséget az 5.16. ábrának megfelelően bekapcsoljuk, egyes metaadatok átrendezödnek a kódolt videóban, és a videó megtekintését már akkor meg lehet majd kezdeni, amikor a nagy része még töltődik a háttérben. Én melegen ajánlom, hogy mindig kapcsoljuk be ezt a beállítást. Mivel a kódolt videó minőségére vagy fájiméretére nincs hatással, igazán nincs okunk rá, hogy ne tegyük.

A Picture (Kép) lapon a kódolt videó lehetséges legnagyobb szélességét és magasságát állíthatjuk be (lásd az 5.17. ábrát). A Keep Aspect Ratio (01-

dalarány megtartása) lehetőséget ugyancsak célszerű bekapcsolni, nehogy a HandBrake átmérerezés közben összenyomja vagy megnyújtsa a képet.


�Queue !ti:! ShowQueue .• PrNI_. !II]ActMtyWindow

T q>

Q? '"' U � -

C

5. l 5. ábra Válasszuk az i Phone sablont

�

•

.......

BA-Univet<HII .....

-·· B ........

-....

HighPt-ofie

Bl«»<Y oa .. k Apple nr teoacy iPhone leoacy iPodlt!:c;J<K:Y

li Souru • Ci Start m Add to Queue ffiJ Show Queue lill Previ- [ll] A.ctMty Window

lot

Sourcc:. � Pr

Tlte: lt(00:02:22) ·l Chapten: li:..=3 ltYou;tl c=3 0.../Jti::Jn: 00:02:22

-

�, -------------------------------------- � output SdtinQS (Pt'Uet Custom)

Ctri.Iler: [K"�Re •]l':t"..oefiescze �� Pod5G5lClJ)Ort

PicttJ"e Vüeo Fbrs Yideo Audo J � Chapters Adv-anced

Souce: 120x<480 As;:Ject.Ratio: 1.36

�: : Heqt:

� KeepAspectRolltlo

• ., .... ,, ... " ,_. = = ·J

ScanComplet:ed

5.1 6. ábra Mindig optimalizáljunk a Webre


Cropping

'""

D , ... � n -

u

5. fejezet

.. �- -. .. -.- --· -··· . -. - � '-�-. ,- ..... - .. - .

�--- '·k�J-s!iíj � líSourct• Cjsurt. -AddtoQutut 1fiJ91owQutut .Prtv�rw -ActMty'W'indow ""'"'"'� �

Tti&: b (OO:!)?:Z2) •J Chapters: � tt..ouc;t. � CU«o"l: 00:1l2:22

- - ---- � "''

Output Scttlnp (Preset: Custom) Ccrtaher: '""' Fie ·l�uroefilsize rl)Webopbnczed f)PodSGRQUt

""""' -- <•-ScMce: 720x480 AspectR«lo: 1.36 ·-_,�Ih-' � �"""'Wid:h f)CuR:OfTI •

�K�As!mBtt;!lll Top

·l o--:p -líi'i'-Loft r-� �Rdt

o .;.. """""

� Sun�ed , r-- -=·a:W--.--a��-:.o....w.,... ____"...",. '""'--�

5.1 7. ábra Állítsuk be a szélességet és a magasságot

A "Video" lapon, amelyet az 5.18. ábrán láthatunk, több fontos beállítást adhatunk meg:

Video Codec (Videokodek) Ügyeljünk rá, hogy itt a H. 264 (x264) értéket válasszuk.

2-Pass Encoding (Kétmenetes kódolás) Ha ezt a négyzetet bekapcsoljuk, a HandBrake kétszer futtatja le a videokódolót. Először csupán elemzi a videót, és olyan dolgokat vizsgál, mint a színösszetétel, a mozgás és a jelenethatárok. A videó tényleges kódolását a második menetben hajtja végre, az első körben összegyűjtött információk felhasználásával. Ahogy ez várható, ez a módszer körülbelül kétszer annyi ideig tart, mint az egymenetes kódolás, viszont jobb minőségű videót eredményez a fájlméret növelése nélkül. Én mindig engedélyezem a kétmenetes kódolást a H.264-videók esetében. Hacsak nem a következő YouTube-ot építjük, és napi 24 órában videókat kódolunk, valószínűleg nekünk is érdemes a kétmenetes kódolást választanunk.


Turbo First Pass (Gyors első menet) Ha a kétmenetes kódolást választottuk, ennek a négyzetnek a bekapcsalásával némi időt takaríthatunk meg. Ez a beállítás úgy csökkenti az első menetben elvégzett munka mennyiségét (a videó elemzésének alaposságát), hogy közben csak kis mértékben rontja a minőséget. Én általában engedélyezem ezt a lehetőséget, de ha nekünk a minőség kiemeit szempont, jobb, ha kikapcsoljuk.

Quality (Minőség) A kódolt videó "minőségét" többféleképpen is megadhatjuk: beállíthatjuk a célfájl méretét - ez esetben a HandBrake minden tőle telhetőt megtesz, hogy a végeredménykém kapott videó ne legyen nagyobb ennél a méretnél -; beállíthatunk egy átlagos "bitsebességet", ami szó szerím a kódolt videó egy másodpercének tárolásához szükséges bitek számát jelenti (azért hívják "átlagos" bitsebességnek, mert egyes másodpercek több bitet igényelnek, mint mások); de egy O-tól 100 százalékig terjedő skálán megadhatunk egy állandó minőséget is (a magasabb értékek jobb minőséget, de nagyobb fájlokat eredményeznek). A minőség beállítására nincs általános szabály.


Kérdés: Ogg-videó is készíthető kétmenetes kódolással? Válasz: Igen, de a kódoló működésének alapvető különbsége miatt erre valószínűleg nincs szükség. A kétmenetes H.264-kódolás szime mindig jobb minőségű vicleót eredményez, a kétmenetes Ogg-kódolásnak azonban csak akkor vesszük hasznát, ha a kódolt videó fájljának adott méretűnek kell lennie. (Lehet, hogy éppen ez érdekel minket, de az itt bemutatott példák nem erről szálnak, és a webes videók kódolására valószínűleg nem éri meg ennyivel több időt fordítani.) Az Ogg-videók minőségét szabályozzuk inkább a Quality-beállítással, és ne veszödjünk a kétmenetes kódolássaL


· ��-:��----��---� Souru • i; Sbrt. (��Add to Queue � ShowQueue PrN!ew [IIJ A.ttMtyWindow

Source � Pl'

_, l• ("'""'"') - il """'•" C:=::J - � ""'-' oo,oz,zz fil 7""" - � l ll Output� (PTeset: CtKtom)

cc:n-: [K>1Fie __ --:JrJla'oeflesiZe 0 web� [liPodSG�

NKel \I':!Mf!sr-s l � l,., ..l �-l Ql,aptm J A,Nanc:pd,

..... .......

YldeoeodM: !"-"'...!."""> ·l e Target.Size(MB):

Framerate(R>S): �3§�e il 8 Avostrate(l!b9s):

2-Passfnccd'lo c Const.-tQualty:

TU'bofirstPass

60.78"lloRf:20

�.. �! � :l

5.18. ábra A képminöségre vonatkozó beállítások

A példában 600 kbps átlagos bitsebességet választottam, ami egy 320x240-es videóhoz elég magas érték. Ezen kívül engedélyeztem a kétmenetes kódolást

is, gyors első menettel. Az Audio (Hang) lapon, amelyet az 5.19. ábrán láthatunk, valószínűleg

semmit sem kell megváltoztatnunk Ha a forrásvideónkban több hangsáv is található, szükséges lehet kiválasztani, hogy melyik kerüljön be a kódolt videóha. Ha a videó nagyrészt abból áll, hogy egy ember beszél (tehát nem zene vagy aláfestő hang hallható benne), a hangsáv bitsebességét valószínűleg 96 kbps-re vagy valamilyen hasonló értékre csökkenthetjük. Ettől eltekintve azonban az "iPhone" sablonból örökölt alapértelmezések többnyire megfelelnek.


OuQiut 5etbngf (Preet Co.Ktom)

ccn- j...,..B= -l ._...,.. .. "Wl!bQJibliZed PodSG�

·�.

5.19. ábra A hangminöségre vonatkozó beállítások

Következő lépésként kattintsunk a Next (Tovább) gombra, és válasszunk egy könyvtárat, illetve fájlnevet a kódolt videó számára (5.20. ábra), végül pedig indítsuk el a kódolást a Start gombbal (5.21. ábra). A HandBrake a videó kódolása közben statisztikai adatokat jelenít meg (5 .22. ábra).

·- �--... , ... Sbrt íi!l Add tn Qutut ltiJ ShcMr Qutut Prtvttw [II]AcbYityWíndow

....... � ,_",_",..,. �

llie.,I(00:02:22} ·f"-<, u::-:3 ...... � .,.._ ,,.,.,._" -R.: C:�� ........ r �

Duqlui:SetttnQs(Pt�eu.tom)

�� .... Re ·J lMQBf'-Sile " Wtlboptmacj ...... .._.

�Yidlol'bfs'l1lllo ..... - --�. Audiolr-.b

� l:iiiiiiiii:J Selectedtradt:Newtredo. .

""" .... """' - .......... .., ... ORC

[-- ·)I�U . .[ ..... ::;J�O o

,: ... -� """""""' - Sln!Pwat.Qtf.z) 8blte('li:bpJ) ORC

.l - MC(foMC) OOb)'Pt-GLOQic n .. ,,. 0.0

l. � "'-� . .

5 .20. ábra Adjuk meg a célfájl nevét


" ..........

li"'�·· ,\ti"'�-""'"""'"'�"'-""'� ··�lll""'""'"""""" -.�-

Tda: !J(OO:Ill-.m •l �' C:3 tt-nJu;to C:3 t'Uabon: 001ll:22

fle: C:�f�p9.,.�.M'W

output Sdtfroc)l' (PrH«: eu.tom) cont-.: [ijifit=::;J U L«9eNesize (l]Wflb� PodSG�

;,_,;!ifA� J

U!!iiiJ

��l�ti��·---------------------------,, AudioTradu:

�� Tradi:NIMTrd

s-u Aldo Codec: f4xdDoon Sarrcllwate !ar .u �

1- ·llMC•-> ·ll- ·ll- ·l� o

Track Sotne At.doCodac P4xdaown �ate(lrH;z) lllnte(Kbps) AN:.(JMQ �ProL.ogocn

-- �

5.21. ábra Készítsünk videót!

5.22. ábra Türelem, ifjú padawan!

H.264-videók kötegelt kódolása

a HandBrake segítségével

(Az előző részhez hasonlóan a "H.264-videó" kifejezést itt is a "Baseline profilú H.264-videó és low complexity profilú AAC-audió egy MPEG4-tárolóban" kifejezés helyett használom. Ez az a kodek+tároló kombináció, amelyet a Safari, az Adobe Flash, az iPhone és a Google Android eszközök beépítve támogatnak.)

Ahogy fentebb említettem, a HandBrake-nek parancssori változata is létezik. A grafikus kiadáshoz hasonlóan ennek is töltsük le a legfrissebb változatát, a http:llhandbrakefrldownloads2.php címrőL

Az ffmpeg2theora-hoz ( lásd a fejezet "Ogg-videók kötegelt kódolása az

ffmpeg2theora segítségével" cím ű részét) hasonlóan a HandBrake parancssori


változata is szédítő mennyiségű kapcsolót kínál. (Ha az összeset meg szeretnénk tekinteni, írjuk be a HandBrakeCLI --help parancsot egy terminálvagy parancsablakba.) Itt csak néhány fontosabbat tekintünk át:

• --preset "X", ahol az "X" egy HandErake-sablon neve (lényeges, hogy a nevet idézőjelbe tegyük). A webes H.264-videókhoz az "iPhone & iPod Touch

" sablonra van szükségünk.

• --width W, ahol a W a kódolt videó szélessége. A HandErake automa-tikusan átállítja a magasságot, hogy megtartsa az eredeti videó arányait.

• --vb Q, ahol a Q az átlagos bitsebesség (kilobit/másodpercben mérve) • --t wo-pass- ez a kapcsoló engedélyezi a kétmenetes kódolást • --turbo- ez a kapcsoló engedélyezi a gyors első menetet a kétmenetes

kódolás során • --input F, ahol az Fa forrásvideó fájlneve. • --output E, ahol az E a kódolt videó célfájljának a neve.

Íme egy példa a HandErake meghívására a parancssorból, azokkal a parancssori kapcsolókkal, amelyek megfelelnek a HandErake grafikus változatában választott beállításoknak:

you@localhost$ HandBrakeCLI --preset "iP hone & iPod Touch"

-- width 320

--vb 600

--two-pass

--turbo --inputpr6.dv

--output pr6 .mp4

Felülről lefelé: a parancs elindítja a HandErake-et az "iPhone & iPod Touch" sablonnal, a vicleót átméretezi 320x240 képpontosra, 600 kbps átlagos bitsebességet állít be, engedélyezi a kétmenetes kódolást gyors első menettel, beolvassa a pr6.dv fájlt, és pr6.mp4 néven mentve kódolja azt.

WebM-videók kódolása az ffmpeg segítségével

A WebM formátumot 2010. május 19-én tették közzé-egyetlen nappal az előtt, hogy ezt a részt írtam. Így nem csoda, hogy még nem volt nagy választék kódolóeszközökből és útmutatókból. A helyzet persze egyszerű-


södni fog, amint megírják (vagy frissítik) a WebM egykattintásos támogatásához szükséges eszközöket. Addig azonban ezekre az eszközökre lesz szükségünk:

• a libvp8 könyvtárra, valamint az ffmpeg egy különleges, kiegészítő foltokkal ellátott (a libvp8-hoz kapcsolódni képes) változatára, amely még nem része a hivatalos ffmpeg-gyűjteménynek:

-útmutató Linuxhoz (http:lllardbucket.org/bloglarchives/201 0/0511 9/vpBwebm-and-Jfmpeg/)- ezt személyesen teszteltem Ubuntu "Lucid" 10.04

rendszeren -útmutató Windowshoz (http:!lwww.ioncannon.netlmeta/1128/compiling

webm-jfmpeg-windowsl)- ezt még nem próbáltam ki

• az mkclean legújabb változatára (http://www.matroska.orgldownloads/ mkclean.html).

Készen állunk? Rendben. A parancssorból indítsuk el az ffmpeg-et paraméterek nélkül, és győződjünk meg róla, hogy a fordítás során belekerült a VP8-

támogatás:

you@localhost$ fÖ!p!g FFmpeg version SVN-r23197, Copyright (c) 2000-2010 the FFmpeg developers

built on May 19 2010 22:32:20 with gcc 4.4.3

configuration: --enable-gpl --enable-version3 --enable-nonfree --enable-

postproc

--enable-pthreads --enable-libfaac --enable-libfaad --enable-libmp3lame

--enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libtheora

--enable-libx264 --enable-libxvid --enable-xllgrab --enable-libvpx-vpB

Ha nem látjuk az --enable-libvpx-vp8 varázsszavakat, az ffmpeg-nek nem a megfelelő változatával rendelkezünk. (Ha megesküszünk rá, hogy az

imént fordítottuk le helyesen, ellenőrizzük, hogy nincs-e belőle két példányunk. Ez nem okoz gondot, mert nem fognak ütközni egymással - csak éppen a teljes elérési utat meg kell majd adnunk az ffmpeg VP8-at ismerő változatának elindításához.)

Most azt mutatom be, hogy miként lehet kétmenetes kódolást végrehaj

tani (lásd a fejezet "H.264-videók kódolása a HandBrake segítségéve!" című részét). Az első menet csak végigpásztázza a bemenő vicleofájlt (-i pr6.dv) ,

és adatokat ír ki róla egy naplófájlba (ami automatikusan a pr6.dv-O.log nevet kapja). A videokodeket a -vcodec kapcsolóval adhatjuk meg:


you@localhost$ ffmpeg -pass l -passlogfile pr6. dv -threads 16 -token_ parti tions 4

-altref l-lag 16 -keyint_min O -g 250 -mb_static_threshold O -skip _threshold O -cp:nin l -qmax 51 -i pr6. dv -vcodec li.bvpx_ vp8 -an

-f rawvideo -y NUL

A parancssorba írt ffmpeg-utasítás nagy részének semmi köze a VP8-hoz vagy a WebM-hez. A libvp8 ugyan több VP8-beállítást is támogat, amelyeket á tadhatunk az ffmpeg-nek, de ezeknek a működését még nem ismerem. Amint találok róluk egy jó leírást, felteszek egy hivatkozást ennek a könyvnek a webhelyére.

A második menetben az ffmpeg kiolvassa az első menetben rögzített statisztikai adatokat, és ténylegesen végrehajtja a kép- és a hangsáv kódolását. Az eredmény egy MKV-fájl lesz, amit majd mi alakítunk később WebM-fájllá. (Az ffmpeg idővel képes lesz közvedenül WebM-fájlokat kiírni, de jelenleg rejtélyes és veszélyes hibákat okoz, ha ilyesmivel próbálkozunk.)

Íme a második menet parancsa:

you@localhost$ ffmpeg -pass 2 -passlogfile pr6. dv -threads 16 -token_ parti tions 4

-altref l-lag 16 -keyint_min O -g 250 -mb_static_threshold O -skip _threshold O -cp:nin l -qmax 51 -i pr 6. dv -vcodec li.bvpx _ vp8 -b 614400 -s 320x240 -aspect 4:3 -acodec vorbis -y pr6 . mkv

Ebben az utasítássorban öt fontos paraméter található:

-vcodeclibvpx_vp8

Ez a paraméter azt adja meg, hogy a VP8 videokodekkel végezzük a kódolást. A WebM mindig a VP8 kodeket használja.

-b 614400

Ez a bitsebességet határozza meg. Más formátumoktól eltérően a libvp8-nak a bitek számával, és nem kilobitben kell megadnunk a bitrátát, ezért ha 600 kbps bitsebességű videót szeretnénk, a 600-at meg kell szoroznunk 1024-gyel (így jön ki a 614 400).

-s 320x240

Ez a célfájl képméretét adja meg, a szélesség és a magasság szorzataként.

-a spect 4:3


Ez a videó képarányát határozza meg. Az alapfelbomású videók általában 4:3

oldalarányúak, a magas minőségű videók oldalaránya azonban többnyire 16:9 vagy 16:10. A tesztelés során úgy találtam, hogy ezt kifejezetten meg kell adnunk a parancssorban, és nem szabad az ffmpeg automatikus észlelésére támaszkodnunk.

-acodec vorbis

Ez a paraméter azt adja meg, hogy a Yorbis audiokodekkel kódolunk A WebM mindig a Yorbis audiokodeket használja.

Ezzel egy MKY-fájlt kapunk, YP8 kódolású képpel, és Yorbis kódolású hanggal. Ez nagyon közel áll ahhoz, amit szerernénk, mert a WebM tárolóformátuma szinte megegyezik az MKY formátumával (valójában annak egy részhalmaza). Csak néhány hitet kell átállítanunk a végleges WebM-videofájl előállításához a korábban említett mkclean segédprogram segítségéve!:

you@localhost$ rnkclean -doc type 4 pr 6 .rnkv pr 6. webrn

És ennyi az egész!

És végül, a leírókód!

Felmerülhet bennünk a kérdés, hogy ha ez egy HTML-ről szóló könyv -amiben eddig biztosak volrunk -, akkor hol a leírókód? Nos, a HTML5-ben kétféle módszerrel ágyazhatunk be egy videót egy weboldalba, de mindkettőhöz szükségünk van a <video> elemre. Ha csak egy videofájlunk van, egyszerűen hivatkozhatunk rá egy src jellemzőbőL Ez nagyon hasonlít ahhoz, mint amikor egy képet ágyazunk be egy <img src=

" .. . "> címkével:

<v ideo src="pr6. wel:m"></video>

Elméletileg összesen ennyire van szükség, de az <img> címkékhez hasonlóan a <v ideo> címkékben is mindig célszerű megadni a width és height jellemzőket is. A width (szélesség) és height (magasság) jellemzők értéke ugyanaz lehet, mint amit a kódolás során maximális szélességként és magasságkém megadtunk:

<v ideo src= "pr 6. webrn" width="320" height="240"></video>


Ne aggódjunk, ha a videó valamelyik kiterjedése kicsit kisebb a fentinél, a böngésző ugyanis a <video> elem által meghatározott doboz közepére igazítja a videót, így az soha nem fog aránytalanul összenyomódni vagy megnyúlni.

Alapértelmezés szerint a <video> elem nem jelenít meg semmilyen lejátszásvezérlőt; ezeket egyszerű HTML-, CSS- és J avaScript-kóddal hozhatjuk létre. A <vide o> elemnek vannak olyan tagfüggvényei, mint a play()

(lejátszás) és a pau se() (szünet), valamint rendelkezik egy írható és olvasható, currentTime (aktuális idő) nevű tulajdonsággal, illetve szintén írhatóolvasható volume (hangerő) és muted (elnémított) tulajdonságokkal, tehát minden olyasmivel, amire a saját felületünk felépítéséhez szükségünk lehet.

Ha nem akarunk saját felületet építeni, a böngészőt is utasíthatjuk, hogy jelenítse meg a beépített vezérlőket. Ehhez csak a controls jellemzőt kell belefoglalnunk a <video> elembe:

<v ideo src= "pr 6. webm • wid th= "320" height= "240" controls></video>

Van még két további elhagyható jellemző, amelyekről említést szeretnék tenni, mielőtt rovábbmennénk: a preload és az autoplay. Ne bántsuk a hírhozót: hadd magyarázzam el, hogy ezek miért hasznosak. A preload

jellemző azt mondja a böngészőnek, hogy azt szeretnénk, hogy kezdje el letölteni a videofájlt, amint az oldal betöltése elindul. Ennek akkor van értelme, ha az oldal kimondottan azt a célt szolgálja, hogy megtekintsük a videót. Ha viszont a videó csak kiegészítő tartalom, amit csak néhány látogató fog megnézni, a preload jellemzőt none értékre állítva utasíthatjuk a böngészőt, hogy csökkentse a minimumra a hálózati forgalmat.

Íme egy példa egy olyan videóra, amelynek a letöltése (de nem a lejátszása) rögtön elindul az oldal betöltésekor:

<v ideo src= "pr 6. webm • width= "320 • height= "240 • preload></video>

Ez pedig egy olyan videó, amely az oldal betöltésekor nem töltődik le azonnal:

<v ideo src= "pr 6. webm • width= "320" height= "240 • preload="none"></video>

Az autoplay (automatikus lejátszás) jellemző pontosan azt eredményezi, amire a neve utal: azt közli a böngészővel, hogy a videofájl letöltését az oldal betöltésekor rögtön el szeretnénk kezdeni, és a videó lejátszását is el szeretnénk indítani, amint lehet. Vannak, akik rajonganak ezért, és vannak, akik gyűlölik, de hadd magyarázzam el, miért fontos, hogy a HTML5-ben legyen


egy ilyen jellemző. Egyesek akkor is automatikusan el szeretnék indítani a videóikat, ha ez idegesíri a felhasználókat. Ha a HTML5 nem határazna meg egy szabványos módszert a videók automatikus lejátszására, a fejlesztök JavaScript-trükkökkel akkor is megoldanák, például meghívnák a videó play() tagfüggvényét az ablak load eseménye közben. Ez ellen a látogatók sokkal nehezebben tudnak védekezni, egy olyan bővítményt viszont egyszerűen hozzá lehet adni a böngészőhöz (vagy írni is lehet egyet, ha szükséges), amely lehetövé teszi, hogy azt mondjuk: "hagyd figyelmen kívül azautoplay

jellemzőt, mert egyetlen vicleót sem szeretnék automatikusan elindítani". Íme egy példa egy olyan videóra, amelynek a letöltése és a lejátszása az

oldal betöltése után a lehető leghamarabb elindul:

<v ideo src= "pr 6. webm" width= "320" height= "240" autoplay><lvideo>

Az alábbiakban pedig egy olyan Greasemonkey-parancsfájlt (http://www. greasespot.net) láthatunk, amelyet a Firefax-példányunkra telepítve megakadályozhatjuk a HTML5-videák automatikus lejátszását. A parancsfájl a HTML5 által meghatározott autoplay DOM-jellemzőt használja, ami a HTML-kód autoplay jellemzőjének JavaScript-megfelelője:

l l ==UserScript==

l l @name Disable v ideo a utoplay

ll @namespace http:lldiveintomark.orglprojectslgreasemonkeyl l l @description Ensures that HTMLS v ideo elements do not autoplay

l l @include l l ==IUserScript==

var arVideos = document. getElementsByTagName ('v ideo') ;

for (var i = arVideos .length - l; i >= O; i--) {

var elmVideo = arVideos [i]; elm V ideo. autoplay = false;

De várjunk csak egy percet! Ha végig figyelemmel kísértük a fejezetet, akkor tudjuk, hogy nem csak egy, hanem három videofájlunk van. Az egyik egy .ogv fájl, amelyet a Firefogg (lásd: "Ogg-videók kódolása a Firefogg segítségéve!") vagy az ffmpeg2theora (lásd: "Ogg-videók kötegelt kódolása az ffmpeg2theora segítségéve!") használatával hoztunk létre, a második egy .mp4 fájl, amelyet a HandErake-kel (lásd: "H.264-videók kódolása a HandBrake segítségéve!") készítettünk el, a harmadik pedig egy .webm fájl, amelyet az ffmpeg-gel (lásd: "WebM-videók kódolása az ffmpeg segítségéve!")


állítottunk elő. A HTML5-ben rendelkezésre áll egy elem, amelyből mindháromra hivatkozhatunk: a <source>. Minden <video> elem tetszőleges számú <source> elemet tartalmazhat. A böngésző sorban végigmegy a videoforrások listáján, és az első olyat választja, amelyet képes lejátszani.

Ez felvet egy újabb kérdést: honnan tudja a böngésző, hogy melyik vicleót

tudja lejátszani? Nos, a legrosszabb esetben mindegyiket betölti, és megpróbálja lejátszani őket, ami persze hatalmas sávszélesség-pazarlás. Ha a böngészőt viszont mindegyik videóról előre tájékoztatjuk, jelentősen csökkenthetjük a hálózati forgalmat. Ezt a <source> elemben elhelyezett type

jellemzővel tehetjük meg:

<videe wid th= "320' height= "240 • centrels>

<seurce src="pr6 .mp4" type=' videe/mp4; cedecs= "avcl. 42E01E, mp4a. 40.2 '" >

<source src="pr6. wetm" type=' videe/webm; cedecs= 'vp8, verbis "' >

<source src="pr6.ogv" type=' videe/egg; cedecs= "theera, verbis" >

</videe>

Nézzük meg részletesen a fenti kódot! A <v ideo> elem meghatározza a videó szélességét és magasságát, de ténylegesen nem hivatkozik egyeden videofájlra sem. A <video> elemen belül azonban van két <source> elem: mindkettő egy-egy videofájlra mutat (az src jellemzővel), és megadja annak formátumát (a type jellemzővel).

A type jellemző bonyolultnak tűnik- és bizony az is! Háromféle infor

mációt tartalmaz: a tá:rolóformátumot (lásd: "Videotárolók"), a videokodeket (lásd: "Videokodekek") és az audiokodeket (lásd: "Audiokodekek"). Kezdjük a lista végével. Az .ogv vicleofájl esetében a tárolóformátum az Ogg, amit itt a video/ogg jelöl. (Ez az Ogg-videofájlok MIME-típusa.) A videokodek a Theora, az audiokodek pedig a Vorbis. Ez elég egyszerű, attól eltekintve, hogy a jellemző értékét kicsit macerás megadni: magának a code cs értékének is idézőjelben kell állnia, ezért a teljes type értéket másfajta idézőjelek közé kell zárnunk:

<seurce sr c= "pr 6. egv • type=' video/ ogg; codecs="theora, vorbis'" >

A WebM-fájl <source> eleme nagyon hasonló, csak a MIME-típus más (video/ogg helyett video/webm), illetve másik videokodek (theora helyett vp8) szerepel a codecs paraméteren belül:

<seurce src= "pr 6. webm" type=' video/wetm; codecs="vpB, vorbis"' >


A H.264-fájl <source> eleme még bonyolultabb. Emlékszünk még rá, hogy azt mondtam, hogy mind a H.264-videó (lásd:

"H.264"), mind az AAC

audió (lásd: "Advanced Audio Coding") különféle "profilú" lehet? Mi a kódolást a Baseline H.264-profillal és a

"low complexity

" AAC-profillal végez

tük, majd az egészet egy MPEG-4 tárolába csomagoltuk Ezek az információk mind szerepeinek a type jellemzőben:

<source src= "pr 6 .mp4" type='vicleo/mp4; coclecs="avcl. 42E01E, mp4a. 40 .2'">

Ennek a bonyolult meghatározásnak az az előnye, hogy a böngésző a type jellemzőt megvizsgálva eldöntheti, hogy le tudja-e játszani az adott videofájlt. Ha úgy dönt, hogy erre nem képes, nem tölti le a fájlt - még egy részét sem. Ezzel sávszélességet takarítunk meg, és a látogatóink gyorsabban tekinthetik meg azt a videót, amiért jöttek.

Ha a videóink kódolásakor a fejezet utasításait követjük, egyszerűen bemásolhatjuk a type-jellemzőértékeket az itteni példából - ha nem, akkor magunknak kell kitalálnunk a megfelelő type paramétereket.


E könyv írásának idején (2010. május 20-án) az iPad tartalmazott egy hibát, amely megakadályozta, hogy az első felsorolt videoforráson kívül bármit felismerjen. Sajnos ez azt jelenti, hogy az MP4-fájlt kell az első helyre tennünk, és csak az után következhetnek az ingyenes videoformárumok. Sóhaj.

AMIME-típusok beleköpnek a levesbe

A videós kirakósjátéknak annyi darabja van, hogy nem is igazán merem felhozni, de muszáj, mert egy rosszul beállított webkiszolgáló végtelen kínlódáshoz vezethet, amikor megpróbáljuk kideríteni, hogy miért tudjuk lejátszani a videóinkat a saját számítógépünkön, de az üzemi webhelyünkön nem. Ha ebbe a problémába ütközünk, az okot valószínűleg a MIME-típusokban kell keresnünk.


Az l. fejezetben már említettem a MIME-típusokat, de akkor valószínűleg nem mértük fel a jelentőségüket. Így hát megismétlem csupa nagybetűvel:

Leírókód professzor azt kiabálja

A VIDEOFÁJLOKAT A MEGFELELŐ MIME-TÍPUSSAL KELL SZOLGÁLTATNI!

De mi a megfelelő MIME-típus? Már láttuk: a <source> elem type jellemzőjében szereplő érték egyik része. A t y pe jellemző beállítása a HTML-kódban azonban nem elég. Arról is gondoskodnunk kell, hogy a webkiszolgáló belefoglalja a helyes MIME-típust a Content-Type H TTP-fejlécbe.

Ha az Apache webkiszolgálót vagy annak valamelyik rokonát használjuk, Add Type utasításokat használhatunk az egész webhelyre érvényes httpd. conf fájlban vagy a videofájljainkar tároló könyvtár .htaccess fájljában. (Ha más webkiszolgálót üzemeltetünk, nézzünk urána a kiszolgáló dokumentációjában, hogy miként állírhatunk be konkrét fájltípusokat a Content-Type

HTTP-fejlécben.) A következő Add Type urasírásokat kell beszúrnunk:

AddType video/agg .ogv AddType video/mp4 .mp4 AddType video/webm . webm

Az első sor az Ogg-tárolóban elhelyezett, a második az MPEG-4 tárolóha burkolt, a harmadik pedig a WebM-videók típusát adja meg. Ezeket csak egyszer kell beállítanunk, aztán megfeledkezhetünk róluk. Ha viszont nem adjuk meg ezeket a beállításokat, a videóink egyes böngészőkben biztosan nem lesznek lejátszhatók, még akkor sem, ha a H TML-kódban megadjuk a MIME-típust a type jellemzőben.

A webkiszolgáló beállírásának egyéb véres részleteit megtaláljuk a Mozilla Developer Center egyik kitűnő cikkében, amelynek címe "Configuring servers for Ogg media" ("Kiszolgálók beállítása Ogg-médiafájlok számára", https:lldeveloper. mozilla. orglen/Conjiguring_servers_for _ Ogg_media - a cikkben olvasható tanácsok az MP4- és WebM-videókra is érvényesek).

162 J Videó a Weben 5. fejezet


Miközben a könyvet Írtam, a Microsoft megjelentette az Internet Explorer 9

"fejlesztői előzetesét". Ez még nem támogatta a HTML5 <v ideo> elemét, de

a Microsoft nyilvános ígéretet tett (http:l/blogs.msdn.com/ie/archive/2010/03/161 html5-hardware-accelerated-jirst-ie9-platform-preview-available-for-developers. aspx), hogy az IE 9 végleges változata támogatui fogja az MPEG-4 tárolóban elhelyezett, H.264-videosávval és AAC-audiosávval rendelkező videofájlokat, akárcsak a Safari az asztali Mac, illetve a Mobile Safari az iOS rendszereken.

De mi a helyzet az Internet Explorer régebbi változataival- például az IE 8-cal vagy az előtte kiadott változatokkal? Nos, a legtöbb Internet Explorer

felhasználó telepíti az Adobe Flash bővítményt is, márpedig a Flash újabb változatai (a 9.0.60.184-estől kezdve) támogatják az MPEG-4 tárolóban elhelyezett, H.264-videosávval és AAC-audiosávval rendelkező videofájlokat. A Safarira elkészített H.264 kódolású videókat (lásd a fejezet "H.264-videók kódolása a HandBrake segítségéve!" című részét) lejátszhatjuk egy Flash alapú videolejátszóban is, ha észleljük, hogy a látogató nem rendelkezik HTML5-képes böngészővel.

A FlowPlayer (http://fiowplayer.orgl) egy nyílt forrású, GPL felhasználási engedélyű, Flash alapú videolejátszó. (Kereskedelmi felhasználási engedéllyel is elérhető; lásd a http:llflowplayer.orgldownload/ címen.) A FlowPlayer mit

sem tud a <video> elemről, és nem képes varázslattal Flash-objektummá alakítani egy <v ideo> címkét, de a HTML5-öt felkészítették az ilyen esetek kezelésére, hiszen egy <v ideo> elembe beágyazhatunk egy <obj e ct> elemet. A HTML5-videókat nem támogató böngészők figyelmen kívül hagyják a <video> elemet, és helyette egyszerűen a beágyazott <object> elemet jelenítik meg, amely meghívja a Flash bővítményt, és lejátssza a filmet a FlowPlayeren keresztül, míg a HTML5-videókat ismerő böngészők megkeresik az általuk lejátszható videoforrást, és azt játsszák le, teljesen figyelmen kívül hagyva a beágyazott <object> elemet.

Az utolsó mondat az egész kirakósjáték kulcsa: a HTML5 kimondja, hogy a <video> elemek minden gyermekét (a <source> elemeket kivéve) telje

sen figyelmen kívül kell hagyni. Ez teszi lehetövé, hogy az újabb böngészők lejátsszák a HTML5-videókat, miközben a régebbi böngészők elegánsan a Flash-re szorítkoznak, anélkül, hogy bármilyen JavaScript-trükkre lenne


szükség. A módszerről a Vicleo for Everybody! webhelyén (http:llcamendesign. comlcodelvideo_for_everybody) bővebben is olvashatunk.

Egy teljes példa

Nézzünk meg egy példát, amely a fenti eljárásokat alkalmazza. A Vicleo for Everybody! kódját kiegészítettem, hogy WebM formátumú videó is legyen benne. Az alábbi parancsokkal három formátumban kódoltam a forrásvideót:

U Theora/Vorbis/Ogg

you@localhost$ ffmpeg2theora --videobitrate 200 --max_ size 320x240 --output pr 6 . ogv pr 6 . dv

U H.264/AAC/MP4

you@localhost$ HandBrakeCLI --preset "iPhone & iPod Touch" --vb 200 --width 320 --two-pass --turbo --optimize --input pr 6. dv --output pr 6. mp4

## VP8/Vorbis/WebM

you@localhost$ ffmpeg -pass l -passlogfile pr6. dv -threads 16 -token_ parti tions 4

-altref l -lag 16 -keyint_min O -q 250 -mb_static_threshold O -skip _threshold O -qmin l -qmax 51 -i pr6. dv -vcodec libvpx _ vp8

-an -f rawvideo -yNULffmpeg --videobitrate 200 you@localhost$ ffmpeg -pass 2 -passlogfile pr6. dv -threads 16 -token_ parti tions 4

-altref l -lag 16 -keyint_min O -g 250 -mb_static_threshold O -skip _threshold O -qmin l -qmax 51 -i pr6. dv -vcodec libvpx _ vp8 -b 204800 -s 320x240 -aspect 4:3 -acodec vorbis -ac 2 -y pr6 .mkv

you@localhost$ mltclean --doctype 4 p r 6 .mkv pr6. wel:m

A végleges leírókód egy <vide o> elemet használ a HTML5-videolejátszáshoz, a régebbi böngészők pedig az ebben levő beágyazott <object> elemet játsz

hatják le a Flash segítségéve!:

<v ideo id= "movie" width= "320" height= "240 n preload controls>

<source src= npr6.mp4" type=' video/mp4; code cs= "avcl. 42E01E, mp4a. 40.2 "' />

<source src= npr6. webm" type=' video/webm; codecs= "vp8, vorbis "' l>

<source src= "pr 6. ogv" type=' video/ogg; code cs= ''theora, varbis '" l>

<object width= "320" height= "240" type= "application/x-shockwave-flash"

data="flowplayer-3.2.l.swf">

<par am name= "movie" value= "flowplayer-3. 2 .l. swf" l>

<par am name= "allowfullscreen" value= "true" />

<par am name= "flashvars" value=' config= {

"eli p": {"url n: "http: l /wearehugh. com/dihSigood/bbb _ 480p.mp4 ",


•autoPlay •: false, •autoBuffering •: true l l' />

<p> Download v ideo as <a href= "pr 6 .mp4 ">MP4</a>,

<a href= "pr 6. webm ">WebM</ a>, or

<a href= "pr 6. ogv ">Ogg</ a>. </p>

</object>

</video>

A HTML5 és a Flash együttes használatával a vicleót szinte bármely böngészőben és eszközön megtekinthetjük


• "The <v ideo> element" a HTML5 szabványleírásában (http://bit.lyla3kpiq) • Vicleo for Everybody! (http:llcamendesign.com/codelvideo_for_everybody) • "A gen de introduction to v ideo eneadin g" (http:lldiveintomark. orgltaglgive) • Christopher Blizzard: "Theora l. l is released-what you need to know

"

(http:llhacks. mozilla. org/2009/09/theora-1-1-re!eased/) •

"Configuring servers for Ogg media" (https:lldeve!oper.mozil!a.orglen/Con

figuring_servers_for _ Ogg_media) • "Encoding wi th the x264 codec" (http:llwww.mplayerhq.hu/DOCSIHTMLI

enlmenc-feat-x264. html) •

"Video type parameters" (http://wiki.whatwg.orglwiki/Video_type_para

meters} • Zeneader Vicleo JS (http://videojs.com)- egyéni vezérlők HTML5-videókhoz • Simon Pieters:

"Everything you need to know about HTML5 audio and

v ideo" (http:lldev. opera. comlartic!es/viewleverything-you-need-to-know-abouthtm!5-video-and-audiol )

6. fejezet

Itt áll ön (és mindenki más)

Ugorjunk fejest!

A helymeghatározás (geolokáció) annak a művészete, hogy kiderítsük, hol is vagyunk a világban, és (ha akarjuk), megosszuk ezt az információt azokkal, akikben megbízunk. A tartózkodási helyünkről sok minden árulkodik - az

IP-címünk; a drót nélküli hálózati kapcsolatunk; az adótorony, amellyel a mobiltelefonunk kommunikál; de egy GPS-eszköz is megmondhatja a szélességi és a hosszúsági fokot az űrben keringő műholdakról kapott információk alapján.


Kérdés: A helymeghatározás veszélyesnek tűnik. Ki lehet kapcso/ni?

Válasz: Természetes, hogy nem szívesen osztunk meg olyan magánjellegű információkat, mim a tartózkodási helyünk, egy távoli webkiszolgálóvaL A Geolocation API egyértelműen kimondja (http://www.w3.

org/TR/geolocation-API/#security), hogy "a böngészőknek nem szabad

a helyre vonatkozó információkar áradniuk a webhelyeknek a felhasználó kifejezett engedélye nélkül". Más szavakkal, ha nem akarjuk elárulni a tartózkodási helyünket, nem kell.

A Geolocation API

A Geolocation API segítségével megbízható webhelyekkel oszthatjuk meg a tartózkodási helyünket. Az oldalon található JavaScript-kód hozzáfér a szélességi és hosszúsági fokhoz, és ezt az információt a távoli webkiszolgálónak

6. fejezet Itt áll ön (és mindenki más) l 167

elküldve olyan helyfüggő műveleteket végezhet, mint a helyi üzletek keresése vagy a tartózkodási helyünk megjelenítése egy térképen.

Ahogy a 6.1. táblázatból láthatjuk, a helymeghatározó API-t a fontosabb asztali és mobil böngészők többsége támogatja. Ezen felül burkolókönyvtárak segítségével egyes régebbi böngészők és eszközök is képessé tehetök a használatára- ezt is látni fogjuk a fejezet későbbi részében.

6.1. táblázat A Geolocation API támogatása

3.5+ 5.0+ 5.0+ 3.0+ 2.0+

A szabványos helymeghatározó API mellett a mobileszközök különféle eszközfüggő programozási felületeket is támogatnak, amelyekről szintén szót ejtünk majd ebben a fejezetben.

Mutasd a kódot!

A helymeghatározó API középpontjában a globális navigator objektum egy új tulajdonsága áll: a navigator .geolocation. A helymeghatározó API legegyszerűbb használata így fest:

function get _location () { navigator.geolocation.getCurrentFosition(show_map);

Nincs képességérzékelés, nincs hibakezelés, és nincsenek kapcsolók. A webalkalmazásnak azonban ezek közül legalább az első kettőre szüksége szokott lenni. A helymeghatározó API támogatásának észlelésére (lásd a 2. fejezet "Helymeghatározás" című részét) a Modernizr-t használhatjuk:

function get _location () {

}

if (Modernizr.geolocation) { navigator.geolocation.getCurrentPosition(show_map);

} else { l l nincs beépített támogatás; próbáljuk meg esetleg a Gearst?

}

Az, hogy mit csinálunk, ha a helymeghatározó API nem támogatott, csak tőlünk függ. A Gears használatár, mint alapértelmezett helyettesítő megol-

168 l Itt áll ön (és mindenki más) 6. fejezet

dást, hamarosan elmagyarázom, de először arról szeretnék szót ejteni, hogy mi történik a getCurrentPosition () hívás közben. Ahogy a fejezet elején említettem, a helymeghatározás támogatása engedélyezéshez kötött. Ez azt jelenti, hogy a böngészőnk soha nem fog arra kényszeríteni minket, hogy fedjük fel az aktuális tartózkodási helyünket egy távoli kiszolgálónak. A fel

használó által tapasztalt viselkedés minden böngészőben más és más: a Mozilla

Firefaxban a Geolocation API getCurrentPosition () függvényének meghívása azt eredményezi, hogy a böngésző egy

"információs sávot" jelenít meg

a böngészőablak tetején. Az információs sáv kinézetét a 6.1. ábrán láthatjuk.

cfrveintohtm15.org wants to lmow your location. � l Shtrc location J l ()g_n t Share J � .R�ember for this srte x

6.1. ábra A helymeghatározó információs sáv

Az információs sáv megjelenése a következőkről tájékoztat minket, mint végfelhasználókat, illetve a következő műveletekre és döntésekre ad lehetőséget:

• Közli, hogy egy webhely tudni szeretné a tartózkodási helyünket. • Közli, hogy melyik webhely szeretné tudni a tartózkodási helyünket. • Egy kattintással a Mozilla

"Location-Aware Browsing" ("Tartózkodási

helyet figyelembe vevő böngészés") cím ű súgóoldalára ugorhatunk, amely elmagyarázza, miről is van szó.

• Engedélyezhetjük a tartózkodási helyünk megosztását. • Megtilthatjuk a tartózkodási helyünk megosztását.

• Utasíthatjuk a böngészőt, hogy jegyezze meg, mit választottunk (a meg

osztását engedélyezését vagy letiltását), így a szóban forgó információs sáv többé nem fog megjelenni az adott webhely meglátogatásakor.

Az információs sáv ezen kívül

• nem modális, tehát nem akadályozza meg, hogy másik böngészőablakra vagy -lapra váltsunk,

• laphoz kötődö, tehát eltűnik, ha másik böngészőablakra vagy -lapra vál

tunk, és újra megjelenik, amikor visszakapcsolunk az eredeti lapra, • feltétlenül megjelenik, tehát egy webhely semmiképpen nem kerülheti meg,

• blokkoló, tehát a webhely nem képes kideríteni a tartózkodási helyünket, amíg a válaszunkra vár.


Kicsit feljebb láttuk a JavaScript-kódot, amelynek a hatására megjelenik az említett információs sáv. Egy egyszerű függvényhívásról van szó, amelynek a paramétere egy visszahívó függvény (itt show _ map() néven). A getCurrent

Pos i t ion () hívás azonnal visszaadja a vezérlés t, de ez nem jelenti azt, hogy elérhetjük a felhasználó tartózkodási helyét. A tartózkodási helyről először

a visszahívó függvényben kapunk biztosan információt. A visszahívó függvény így fest:

function show_ map (pos i ti on)

var latitude = position. coords .latitude;

var longi tu de = pos i ti on. coords .longi tud e;

l l Jelenítsünk meg egy térképet, vagy csináljunk valami érdekeset!

l

A visszahívó függvény egyetlen paraméterrel hívódik meg; ez a paraméter egy objektum, amelynek két tulajdonsága van: a coords (koordináták) és a timestamp (időbélyeg). Az időbélyeg pontosan az, amire a neve utal: a tartózkodási hely kiszámításának dátuma és ideje. (Mivel a művelet aszinkron módon történik, nem tudhatjuk előre, hogy ez mikor következik be. A felhasználónak időbe telhet, amíg elolvassa az információs sávot, és bele

egyezik, hogy megossza a tartózkodási helyét; a GPS-sel felszerelt eszközöknek időbe telhet, amíg kapcsolódnak egy GPS-műholdhoz, és így tovább.) A coords objektumnak olyan tulajdonságai vannak, mint a l atitude

(szélességi fok) és a longitude (hosszúsági fok), amelyek pontosan azt adják

meg, amire a nevük ural: a felhasználói földrajzi helyét. A position objektum tulajdonságait a 6.2. táblázat sorolja fel.

6.2. táblázat A position objektum tulajdonságai

Tu

coords.latitude

coords.longitude

coords.altitude

coords.accuracy

double

double

double vagy null

double

coords. al ti tudeAccuracy double vagy null

coords.heading

coords.speed

timestarop

double vagy null

double vagy null

DOMTimeStamp

170 l Itt áll ön (és mindenki más)

tizedfok pontossággal

tizedfok pontossággal

az alapfelületi ellipszoid felett. méterben

méterben

méterben

a valódi északtól számított fokban, az

óramutató járása szerint

méter/másodpercben

Olyan, mint egy Da te ( ) objektum

6. fejezet

Ezek közül csak három tulajdonság (coords .lati t u de, coords .longi tud e

és coords. accuracy) jelenléte garantált. A többi null értéket is kaphat, az eszköz és a vele kommunikáló helymeghatározó háttérkiszolgáló képességeitől függően. A heading (irány) és spe ed (sebesség) tulajdonságok kiszámítása a felhasználó előző tartózkodási helye alapján történik (amennyiben ez rendelkezésre áll).

A hibák kezelése

A helymeghatározás bonyolult, mert sok minden kisiklathatja a műveletet. A

"felhasználói beleegyezést" már említettem. Ha a webalkalmazásunk meg

szeretné tudni a felhasználó tartózkodási helyét, de a felhasználó nem akarja megadni azt, meg vagyunk lőve. Mindig a felhasználó nyer. De hogyan fest mindez kódban? Úgy tűnik, a g etCurrentPosition() függvénynek egy második paramétert kell átadnunk- egy hibakezelő visszahívó függvényt:

navigator.geolocation.getCurrentPosition( show_map, handle_error)

Ha bármi félresiklik, a hibakezelő függvényünk hívódik meg egy Po sition

Error objektummaL Ennek az objektumnak a tulajdonságait a 6.3. táblázatban láthatjuk.

6.3. táblázat A PositionError objektum tulajdonságai

nous ések

code short felsoroló érték

messa_g_e DOMString nem a vé_g_felhasználóknak szánva

A code tulajdonság értéke a következők egyike lehet: • PERMISSION _ DENlED (l) -"A hozzáférés megragadva": ezt az érté

ket akkor kapjuk, ha a felhasználó a Don' t Share (Nincs megosztás) gombra kattint, vagy más módon megragadja, hogy hozzáférjünk a tartózkódási helyéhez.

• POSITION _ UNAVAILABLE (2) -"A hely nem hozzáférhető": ezt az értéket akkor kapjuk, ha nincs hálózati kapcsolat, vagy ha a helymeghatározó műholdakat nem lehet elérni.

6. fejezet Itt áll ön (és mindenki más) J 171

• TIMEOUT (3) -"Időtúllépés": ezt az értéket akkor kapjuk, ha a hálózati kapcsolat él ugyan, de túl sokáig tart kiszámítani a felhasználó tartózkodási helyét. Mennyi idő számít "túl soknak

"? A következő részben meg

mutatom, hogyan határozhatjuk meg. • UNKNOWN _ERROR (0) -"Ismeretlen hiba

": ezt az értéket akkor kap

juk, ha bármilyen más hiba lép fel. Például:

function handle _error (err) { if (err.code=l) { l l A felhasználó nemet mondott 1


Kérdés: A helymeghatározó API a Nemzetközi Ürállomáson, a Holdon és más bolygókan is müködik? Válasz: A Geolocation API szabványleírása (http:llwww.w3.org/TRI geolocation-API/#coordinates_interfoce} ezt mondja:

"A fóldrajzi vonat

koztatási rendszer, amelyet e felület jellemzői használnak, a World Geodetic System (2d) [WGS84] (geodéziai világrendszer). Egyetlen más vonatkoztatási rendszer sem támogatott." A Nemzetközi Űrállomás Föld körüli pályán mozog, ezért az állomáson tartózkodó űrhajósok (http:!!twitter.com/Astro_Tj) a helyzetüket le tudják írni szélességi és hosszúsági fokokkal, illetve magassággaL A geodéziai világrendszer ugyanakkor Föld-központú, ezért nem használható helymeghatározásra sem a Holdon, sem más bolygókon.

Választást! Szabad választást!

Egyes népszerű mobileszközök -például az iPhone és az Android telefonok - két módszerét támogatják a tartózkodási hely meghatározásának. Az első módszer háromszögeléssei számítja ki a helyzetünket a telefonszolgáltatónk különböző adótornyaihoz viszonyított közelségünk alapján. Ez a módszer


gyors, és nem igényel semmilyen különleges GPS-hardvert, viszont csak durva közelítéssel adja meg, hogy hol tartózkodunk. Attól függően, hogy hány mobiladótorony van a körzetünkben, ez a

"durva közelítés" lehet csupán

egy háztömbnyi, de akár minden irányban plusz-mínusz egy kilométer is.

A második módszer ezzel szemben valóban az eszközünk GPS-hardverét használja, hogy kommunikáljon a Föld körül keringő helymeghatározó műholdakkal. A GPS általában néhány méter pontossággal képes megállapítani a helyünket. A hátránya az, hogy a mobileszközök GPS-lapkája sok energiát

fogyaszt, ezért a telefonok és más általános célú mobileszközök többnyire kikapcsolják a lapkát, amíg ténylegesen szükség nincs rá. Ez azt jelenti, hogy némi időt igényel, amíg a lapka kapcsolatot teremt az űrben keringő GPSműholdakkal. Ha valaha is használtuk a Google Maps szolgáltatást egy iPhone-készüléken vagy más okostelefonon, már mindkét módszert láttuk mű

ködés közben. Először egy nagy kör jelenik meg, amely hozzávetőlegesen mutatja a helyzetünket (a legközelebbi mobiladótorony alapján), majd egy kisebb kör

(a más adótornyokkal végzett háromszögelés alapján), végül pedig egy pont, ami a pontos helyzetünket mutatja (a GPS-műholdaktól kapott adatok szerint).

Azért írom le mindezt, mert a webalkalmazásunktól függően nem biztos, hogy nagy ponrosságra van szükségünk. Például ha a közelben levő mozik

műsorára vagyunk kíváncsiak, valószínűleg az "alacsony pontosságú" hely

meghatározás is elegendő. Annyira nincs sok filmszínház, még a sűrűn lakott

városokban sem, és valószínűleg magunk is ismerünk néhányat. Ha viszont valós idejű útbaigazítást adunk sarokról sarokra, pontosan tudnunk kell a felhasználó helyét, hogy azt mondhassuk: "20 méteren belül fordulj jobbra" (vagy valami ilyesmit).

A getCurrentPasi t ion() függvény egy nem kötelező harmadik paramétert is elfogad: egy PositionOptions objektumot. A PositionOptions

objektumoknak három tulajdonsága állítható be (lásd a 6.4. táblázatot). Egyik tulajdonság megadása sem kötelező: beállírhatunk egyet, kettőt vagy hármat, de akár el is hagyhatjuk mindet.

6.4. táblázat A PositionOptions objektum tulajdonságai

enableHighAccuracy

timeout

maximumA9:e

6. fejezet

boolean

long

long_

rtetmezés

false

(nincs alapértelmezés)

o

a true lassabb lehet

ezredmásodpercben

ezredmásode.ercben

Itt áll ön (és mindenki más) l 173

Az enableHighAccuracy ("nagy pontosság engedélyezése") tulajdonság pontosan arra való, amire a neve utal: ha true-ra állítjuk, és az eszköz támogatja, illetve a felhasználó is beleegyezik, hogy megossza a pontos helyzetét, az eszköz megpróbálja kideríteni a pontos helyet. Az alacsony és a nagy pontosságú helymeghatározást az i Phone és Android telefonokon egyaránt külön

kell engedélyezni, ezért előfordulhat, hogy a getCurrentPosition() hívása enableHighAccuracy: true értékkel kudarcot vall, de enableHigh

Accuracy: false értékkel sikerrel jár. A timeout tulajdonság azt adja meg, hogy a webalkalmazásunk hány

ezredmásodpercet hajlandó várni a helymeghatározásra. Az időzítő csak az után kezd visszaszámolni, hogy a felhasználó engedélyt adott a helyzete kiszámítására, tehát nem a felhasználónak ketyeg az óra, hanem a hálózatnak.

A maximumAge tulajdonság lehetővé teszi az eszköznek, hogy azonnal visszaadjon egy elraktározott helyzetet. Tegyük fel például, hogy első alkalommal hívjuk meg a getCurrentPasi t ion() függvényt. A felhasználó engedélyezi a műveletet, az ehhez kötött visszahívó függvény ("success_ callback") pedig egy olyan helyzettel hívódik meg, amelynek a kiszámítása pontosan délelőtt 10 órakor történt. Pontosan egy perccel később (de. 10:01-

kor) ismét meghívjuk a getCurrentPasi t ion () függvényt, a maximumAge

tulajdonságnak a 75000 értéket adva:

navigator.geolocation.getCurrentPosition(

success _ callback, error_ callback, { maximumAge: 7 500 0}) ;

Itt azt mondjuk, hogy nem feltétlenül a felhasználó jelenlegi helyzetére vagyunk kíváncsiak; azzal is megelégszünk, ha tudjuk, hol volt 75 másodperccel (75 OOO ezredmásodperccel) ezelőtt. Esetünkben az eszköz azt tudja, hogy hol tartózkodott a felhasználó 60 másodperccel (60 OOO ezredmásodperccel) korábban, mert kiszámította a helyzetét, amikor először hívtuk meg a getCurrentPos it ion() függvényt. Mivel ez a megadott időtartományon belülre esik, az eszköz nem vesződik azzal, hogy ismét kiszámalja a felhasználó helyzetét, hanem pontosan azt az információt adja vissza, amit az első alkalommal: ugyanazt a szélességi és hosszúsági fokot, ugyanazt a pontosságot, és ugyanazt az időbélyeget (10:00 AM).

Mielőtt azonban lekérdeznénk a felhasználó helyzetét, végig kell gondolnunk, hogy milyen ponrosságra van szükségünk, és ennek megfelelően kell beállítanunk az enableHighAccuracy tulajdonságot. Ha a felhasználó


helyét egynél többször kell meghatároznunk, azt is tisztáznunk kell, hogy legfeljebb milyen régi lehet az információ ahhoz, hogy még hasznát vehessük, és ennek megfelelően be kell állítanunk a maximumAge tulajdonság értékét is. Ha viszont folyamatosan kell figyelnünk a felhasználó helyzetét, akkor

a getCurrentPosition () függvény nem felel meg nekünk- helyette a watchPosition() függvényt kell használnunk.

A watchPosition () függvény felépítése megegyezik a getCurrent

Po sition () függvényével: ugyanúgy két visszahívó függvényt kell megadnunk neki - egyet siker, egyet pedig kudarc esetére -, és ugyanúgy elfogad egy PositionOptions objektumot (az imént látott tulajdonságokkal). A különbség annyi, hogy a visszahívó függvény minden alkalommal meghívódik, amikor a felhasználó helyzete megváltozik Nincs szükség tehát a tartózkodási hely aktív lekérdezésére: az eszköz határozza meg az optimális lekérdezési időközt, és gondoskodik a visszahívó függvény meghívásáról, amikor úgy ítéli meg, hogy a felhasználó helyet változtatott. Ezt felhasználhatjuk például

arra, hogy egy térképen jelezzük a felhasználó mozgását; utasításokat adjunk neki, hogy merre menjen; és így tovább. A lehetőségeknek csak a fantáziánk

szab határt. Maga a watchPosition() függvény egy számot ad vissza, amelyet

érdemes elraktároznunk valahol. Ha már nem kívánjuk figyelni a felhasználó helyváltoztatását, ezt a számot átadva hívjuk meg a clearWatch ()

függvényt, és az eszköz abbahagyja a visszahívó függvényünk hívogatását. A dolog ugyanúgy működik, mint a JavaScriptben a setinterval () és clearinterval () függvények.


Az Internet Explorer nem támogatja a W3C helymeghatározó API-ját, amelyről eddig beszéltünk (lásd a fejezet "A Geolocation API" dmű részét), de ne essünk kétségbe. AGears (http:lltools.google.comlgearsl) egy nyílt forrású böngészőbővítmény a Google cégtől, amely Windowson, Macen, Linuxon, vala

mint Windows Mobile és Android rendszereken is működik, és különféle szolgáltatásokat biztosít a régebbi böngészők számára - többek között egy helymeghatározó API-t. Ez a programozási felület nem teljesen azonos a W3C Geolocation API-jával, de ugyanazt a célt szolgálja.


Ha már a régi rendszereknél tartunk, szeretnék rámutatni, hogy a mobiltelefonokon az eszköztől függően különféle helymeghatározó API-kkal találkozhatunk. A BlackBerry, a Nokia, a Palm és az OMTP BOND I mind saját helymeghatározó felületet biztosítanak, amelyeknek a működése természetesen eltér a Gearsétől, ami viszont másképp működik, mint a W3C Geolocation API-ja . . .

A felmentő sereg: geo.js

A geo.js (http:llcode.google.comlplgeo-location-javascriptl) egy nyílt forrású, MIT felhasználási engedélyű JavaScript-könyvtár, amely elsimítja a különbségeket a W3C helymeghatározó API-ja, a Gears API-ja és a mobileszközök által kínált különféle API-k között. A használatához két <script> elemet kell beszúrnunk az oldalunk aljára. (Elméletileg bárhová tehetjük ezeket, de a <head> részben elhelyezett parancsfájlok lelassítják az oldal betöltését, ezért ne oda tegyük őket!)

Az első parancsfájl a gears_init.js (http:llcode.google.comlapislgearslgears_ initjs), amely előkészíti a Gearst, amennyiben az telepítve van, a másik parancsfájl pedig a geo.js (http:llgeo-location-javascript.googlecode.comlsvnltrunkl jslgeojs}. Az oldalba például az alábbihoz hasonló kóddal szúrhatjuk be őket:

<! DOCTYPE html>

<html>

<head>

<me ta char set= "utf-8 ">

<title>Dive Into HTML 5</title>

</head>

<body>

<script src=" gears _ini t. js "X/ script> <script src=" geo. js "X/ script>

</body>

</html>

Most már készen állunk bármelyik telepített helymeghatározó API használatára:

if (geo_position_js.init()) { geo_position_js.getCurrentPosition(geo_success, geo_error);

)


Nézzük végig egyenként a lépéseked Először is, kifejezetten meg kell hívnunk egy init() függvényt, amely true-t ad vissza, ha valamelyik támogatott helymeghatározó API elérhető:

if (geo_yosition_js.init()) {

Az i n i t () függvény meghívásával még nem derítjük ki a felhasználó tartóz

kodási helyét, csupán arról bizonyosodunk meg, hogy a helymeghatározás lehetséges. Ahhoz, hogy ténylegesen megtudjuk a felhasználó helyzetét, meg

kell hívnunk a getCurrentPosition() függvényt:

geo_yosition_js.getCurrentPosition(geo_success, geo_error);

A getCurrentPosition() függvény hatására a böngésző engedélyt kér a felhasználótól, hogy meghatározza és megossza a tartózkodási helyét. Ha a

helymeghatározást a Gears biztosítja, egy párbeszédablak jelenik meg, amely

azt kérdezi, hogy a felhasználó megbízik-e a webhelyben annyira, hogy megengedje neki a Gears használatár. Ha a böngésző beépítve támogatja a Geo

location API-t, a párbeszédablak másképp fog kinézni. A Firefox 3.5 például egy információs sávot jelenít meg az oldal tetején, és a felhasználó ezen engedélyezheti a helyzete megosztását a webhelyünkkeL

A getCurrentPosition () függvény paraméterként két visszahívó

függvényt vár. Ha a getCurrentPosition () függvény sikeresen megha

tározta a felhasználó helyzetét - vagyis a felhasználó engedélyt adott erre, és a Geolocation API el is végezte a feldarát -, az első paraméterként kapott

függvényt hívja meg. Az alábbi példában a siker viszahívó függvénye a geo success nevet viseli:

geo_position_js.getCurrentPosition(geo_success, geo_error);

Ez a visszahívó függvény egyeden paramétert vár, amelyben a tartózkodási helyet leíró adatok találhatók:

function geo_success (p) { alert ('Found you at latitude • + p.coords .latitude + " longitude "+p.coords.longitude);

}

Ha a getCurrent Po sition () függvény nem tudta kideríteni a felhasználó

tartózkodási helyét - vagy azért, mert a felhasználó ezt nem engedélyezte; vagy azért, mert a helymeghatározó API nem járt sikerrel valamilyen okból

6. fejezet Itt áll ön (és mindenki más) J 177

kifolyólag-, akkor a második paraméterként kapott függvényt hívja meg. Az alábbi példában a kudarc viszahívó függvénye a ge o _ error nevet viseli:

geo_position_js.getCurrentPosition(geo_success, geo_error);

Ennek a visszahívó függvénynek nincsenek paraméterei:

function geo _error () ( alert ('Could not find you! ' );

J

A geo.js jelenleg nem támogatja a watehPosition () függvényt. Ha folya

matos helymeghatározásra van szükségünk, magunknak kell újra és újra le

kérdeznünk a helyet a getCurrentPosition () függvénnyeL

Egy teljes példa

Nézzünk végig egy példát arra, hogy a geo.js segítségével hogyan deríthetjük ki a felhasználó helyzetét, és jeleníthetünk meg egy térképet a közvetlen kör

nyezetéről! Amikor az oldal betöltődik, meg kell hívnia a geo _ position _js.

init() függvényt, hogy megállapítsa, hogy van-e lehetőség helymeghatározásra a geo.js által támogatott valamelyik felületen keresztül. Ha igen, akkor létrehozhatunk egy hivatkozást, amelyre kattintva a felhasználó kiderítheti a helyzetét. A hivatkozásra kattintás az alább látható lookup _ loeation ()

függvényt hívja meg:

function lookup _location () geo_position_js.getCurrentPosition(show_map, show_map_error);

)

Ha a felhasználó engedélyt ad a helyzete nyomon követésére, és a háttérszalgáitatás ténylegesen képes megállapítani a helyzetét, a geo.js meghívja az első, show _map() nevű visszahívó függvényt, a loe nevű egyetlen paraméterrel. A loe objektum eoords tulajdonsága tartalmazza a szélességi és hoszszúsági fokot, valamint a helymeghatározás pontosságát leíró információkat.

(Ez utóbbit nem használjuk fel ebben a példában.) A show _ map() függvény többi része egy beágyazott térképet jelenít meg a Google Maps API se

gítségéve!:


function show_ map (loe) { $("1geo-wrapper") .css({'width' :'320px','height' :'350px' )); var map� new GMap2 (document .getElementByid ( "geo-wrapper ')); var center� new GLatLng (loe. eoords .latitude, loe. coords. longitudel; map.setCenter(center, 14);

map. addControl (new GSmallMapControl () ) ; map. addControl (new GMapTypeControl ()); map.addOverlay (new GMarker (center, {draggable: false, title: 'You a re here

(more or less) ")));

)

Amennyiben a geo.js nem képes meghatározni a helyzetet, a második visszahívó függvényt, a show_ map_ error()-t hívja meg:

function show_ map_ error () { $ ( '#live-geolocation ") .html (' Unable to determine your location.');

)


• A W3C helymeghatározó API-ja (http://www. w3.org!TR!geolocation-APII) • Gears (http://tools.google. comigears/j • A BlackBerry helymeghatározó API-ja (http:llwww.tonybunce.com/2008/

05108/Blackberry-Browser-Amp-GPS. aspx) • A Nokia helymeghatározó API-ja (http:llwww.forum.nokia.com/infocenterl

index.jsp?topic=!Web_Developers_Library!GUID-4DDE3IC7-ECOD-4EEC-BC3A-AOB0351154F8. html)

• A Palm helymeghatározó API-ja (http:l!developer.palm.comlindex.php? option=com_content&view=article&id=1673#GPS-getCurrentPosition)

• Az OMTP BONDI helymeghatározó API-ja (http:llbondi.omtp.org!I.O/ apislgeolocation. h tm l)

• geo.js (http:llcode.google.comlplgeo-location-javascriptl)- a helymeghatározó API burkoló parancsfájlja

7. fejezet

A helyi tárolás múltja, jelene és jövője

a webalkalmazásokban

Ugorjunk fejest!

A maradandó helyi tárolás az egyik olyan terület, ahol a beépített ügyfélprograrnak hagyományosan előnyt élveznek a webalkalmazásokkal szemben. A beépített alkalmazások számára az operációs rendszer jellemzően egy elvont réteget biztosít az olyan, alkalmazáshoz kapcsolódó adatok tárolására és

kinyerésére, mint a felhasználói beállítások vagy a futási állapot. Ezek az adatok tárolódhatnak a rendszerleíró adatbázisban (beállírásjegyzékben), INI-fájlokban, XML-fájlokban és más helyeken is, a rendszer hagyományainak megfelelően. Ha egy beépített ügyfélalkalmazásnak a kulcs-érték párokon túlmutató helyi tárolásra van szüksége, használhat saját adatbázist, saját

fájlformátumot vagy más, tetszőleges megoldást. A webalkalmazások hagyományosan nem rendelkeznek ilyen luxusszol

gáltatásokkal. A Világháló történetének korai időszakában feltalálrák ugyan a sütiket (cookie), amelyek valóban használhaták is kis mennyiségű információ maradandó helyi tárolására, de számos hátrányuk van, amelyek válóoknak bizonyulharnak:

• A sütiket minden HTTP-kérelemhez mellékelni kell, ami szükségtelenül lelassítja a webalkalmazást, hiszen ugyanazokat az adarokat küldjük el újra és újra.

• A sütiket a HTTP-kérelmekhez mellékeljük, ami azt jelenti, hogy az adatokat titkosírás nélkül küldjük el az Interneten át (kivéve akkor, ha

a teljes webalkalmazás SSL-kapcsolaton keresztül működik). • A sütik legfeljebb 4 KB adatot tárolhatnak. Ez elég ahhoz, hogy lelassítsa

az alkalmazást (lásd feljebb), de ahhoz már kevés, hogy igazán hasznos legyen.

7. fejezet A helyi tárolás múltja, jelene és jövője ... l 181

Amire ténylegesen szükségünk van: • Jelentős méretű tárolóhely ... • az ügyfélgépen ... • amely oldalfrissítés után is megőrzi a tartalmár ... • és nem küldi el azt a kiszolgálónak.

Ezeknek a céloknak az elérésére számos megoldás született, de végsősoron -így vagy úgy - egyik sem bizonyult kielégítőnek.

A helyi tárolásra a HTMLS előtt alkalmazott trükkök

rövid története

Kezdetben csak az Internet Explorer létezett - legalábbis a Microsoft azt akarta, hogy a világ ezt higgye. Ennek érdekében az első Nagy Böngészőháború ideje alatt a Microsoft egy csomó dolgot talált fel és épített be "a böngészőbe, amely örökre véget vet minden böngészőháborúnak", vagyis az Internet Explorerbe. Ezek egyike volt a D HTML Behaviors ("D HTML-viselkedések"

vagy "DHTML-műveletek"), amelynek a részét képezte a userData ("felhasználói adatok") nevű "viselkedés".

A userDate tartományonként 64 KB-nyi, hierarchikus XML alapú szerkezetben elhelyezett adat tárolását teszi lehetővé a weboldalaknak (A megbízható tartományok - például az intraneres vagy belső hálózati webhelyek -tízszer ennyi adatot tárolhatnak 640 KB-nak elégnek kell lennie bárkinek, nem?) Az IE nem jelenít meg semmilyen engedélykérő párbeszédablakot, és nem engedi meg a rendelkezésre álló tárolóhely növelését sem.

2002-ben az Adobe beépített egy szolgáltatást a Flash 6-ba, amely a szerencséden és félrevezető "Flash-sütik" néven vált ismertté, de a Flash-környezeten belül Local Shared Objects (röviden LSO, magyarul "helyi megosztott objektumok") a tisztességes neve. Az LSO röviden annyit csinál, hogy lehetővé teszi a Flash-objektumoknak, hogy tartományonként akár 100 KB adatot tároljanak 2005-ben Brad Neuberg kifejlesztette a Flash-JavaScript híd egy korai prototípusát, amelyet AJAX Massive Storage Systemnek (AMASS) nevezett el, de ezt korlátok közé szorította a Flash néhány tervezési furcsasága. 2006-ra - az Externallnterface megjelenésével a Flash 8-ban- az LSO-k JavaScript-kódból történő elérése nagyságrendekkel könnyebbé és

182 l A helyi tárolás múltja, jelene és jövője ... 7. fejezet

gyorsabbá vált. Brad átírta az AMASS-t, és do j ox. s torage néven beépítette a népszerű Dojo Toolkitbe. Ennek a megoldásnak köszönhetőerr minden tartomány "ingyen" megkapja a szokásos 100 KB tárolóhelyet, ráadásul a felhasználó nagyságrendenként (l MB, 10 MB stb.) eldöntheti, hogy növeli-e a tárolóhely méretét.

2007-ben aztán a Google útjára bocsátotta a Gearst- azt a nyílt forrású böngészőbővítményt, amelyet azzal a céllal készítettek, hogy kiegészítő képességekkel lássa el a böngészőket. (A Gearsről korábban már ejtettünk szót, amikor a helymeghatározó API támogatásáról beszéltünk az Internet Explorerben - lásd az előző fejezet "Mi a helyzet az Internet Explorerrel?" című részét.) A Gears egy az SQLite-on alapuló beágyazott SQL-adatbázishoz nyújt felületet. AGearsnek csak egyszer kell megszereznie a felhasználó engedélyét, és tartományonként korládan mennyiségű adatot tárolhat az SQLadatbázis tábláiban.

Közben Brad Neuberg és mások folytatták a dojox.storage felturbózását, hogy egységes felületet biztosítsanak a különböző bővítményekhez és API-khoz. 2009-re a do j ox. starage képessé vált önműködően észlelni (és egységes felülettel ellátni) az Adobe Flash, a Gears és az Adobe AIR tárolóit, valamint a HTML5-tároló korai prototípusát, amelyet csak a Firefax régebbi változataiban valósítottak meg.

Ha áttekintjük ezeket a megoldásokat, kirajzolódik egy minta: minden megoldás vagy egy adott böngészőhöz kötődik, vagy egy külső bővítményre támaszkodik. A megoldások a különbségek kiegyengetésére irányuló (a do j ox. s torage-ben megvalósított) minden hősies erőfeszítés ellenére gyökeresen eltérő felülettel, tárolási korlátokkal és felhasználó élménnyel rendelkeznek. Ezt a problémát igyekszik orvosoini a HTMLS: szabványos felületet igyekszik nyújtani, amelyet a különféle böngészők beépítve és egységesen valósítanak meg, anélkül, hogy külső bővítményekre támaszkodnának.

Bemutatkozik a HTML5-tároló

Az, amit én "HTMLS-tárolónak" (HTMLS Storage) nevezek, valójában a Web Starage nevezetű szabvány, amely egy időben része volt magának a HTMLS-szabványtervezetnek, de később - számunkra érdektelen üzletpolitikai okokból - önálló leírásba különítették el. Egyes böngészőgyártók

7. fejezet A helyi tárolás múltja, jelene és jövője . . . l 183

"Local Storage" (helyi tároló) vagy "DOM Storage" (DOM-tároló) néven is hivatkoznak rá. A helyzetet még jobban bonyolítja, hogy bizonyos hasonló célú, kidolgozás alatt álló szabványok, amelyekre a fejezerben még kitérek, hasonló nevek alatt futnak.

Mi is valójában a HTML5-tároló? Egyszerűen megfogalmazva, egy mód

szer, amellyel a weboldalak nevesített kulcs-érték párokat tárolhatnak hely

ben, az ügyfél webböngészőjén belül. A sütikben tárolt adatokhoz hasonlóan ezek az adatok is megőrződnek, amikor távozunk a webhelyről, bezárjuk a böngészőablakot, kilépünk a böngésző ből, vagy más hasonló műveletet végzünk. A sütikkel ellentétben azonban ezeker az adatokat soha nem visszük át egy távoli webkiszolgálóra (hacsak valamilyen rejtélyes okból kifolyólag nem tesszük meg ezt saját kezűleg). Ezen felül a maradandó helyi tárolásra irányuló (fentebb ismertetett) korábbi kísérletekkel ellentétben a HTML5-

tárolót a webböngészők belsőleg valósítják meg, tehát ott is elérhető, ahol nem állnak rendelkezésre külső böngészőbővítmények.

Mely böngészőkről is van szó? Ahogy a 7.1. táblázatban láthatjuk, a

HTML5-öt lényegében minden böngésző legújabb változata támogatja -még az Internet Explorer is!

7.1. táblázat

8.0+ 3.5+ 4.0+ 4.0+ 10.5+ 2.0+ 2.0+

A HTML5-tárolót JavaScript-kódból a globális window objektum lo ca l

Starage objektumán keresztül érhetjük el. Mielőtt azonban használatba vehetnénk, ki kell derítenünk, hogy a böngésző támogatja-e (lásd a "Helyi

tárolás" című részt a 2. fejezetben):

function supports _ htmlS _ storage ()

return (' loealStor age' in window) && window [' localStorage' ] ! ��null;

l

Azt is megreherjük, hogy nem magunk írjuk meg ezt a függvényt, hanem a Modernizr-t használjuk (lásd a 2. fejezet "Modernizr: egy HTML5-észlelő könyvtár" című részét) a HTML5-tároló támogatásának felderítésére:

if (Modernizr .localstorage) { l l A window. loealS torage elérhető!

) else {


l l Nincs beépített támogatás a HTML5-tárolóhoz : (

l l Próbáljuk meg esetleg a dojox. storage

l l vagy egy külső megoldás használatát

A HTML5-tároló használata

A HTML5-tároló kulcs-érték párokon alapul. Az adatokat egy nevesített kulccsal tároljuk, és ugyanezzel a kulccsal nyerhetjük ki őket:

interface Storage (

getter any getltem (in DOMString key);

setter creator void setitem (in DOMString key, in any data);

);

A nevesített kulcs egy karakterlánc, az adatok pedig bármilyen típusúak le

hetnek, amit a JavaScript támogat: karakterláncok, logikai értékek, egész

vagy lebegőpontos számok. Ugyanakkor az adatok ténylegesen karakterláncként tárolódnak. Ha nem karakterláncot, hanem valami mást szeret

nénk tárolni és visszanyerni, olyan függvényeket kell használnunk, mint

a parseint () vagy a parseFloat (), amelyek a kinyert adatokat a várt

JavaScript-adattípusra alakítják. Ha a setitem ()-et egy már létező nevesített kulccsal hívjuk meg, a függ

vény szó nélkül felülírja a korábbi értéket. Ha a getrtem ()-et nem létező

kulccsal hívjuk meg, a függvény kivétel kiváltása helyett null-t ad vissza.

Más JavaScript-objektumokhoz hasonlóan a loealStor age objektumot is kezelhetjük társírásos (asszociatív) tömbként, így a getrtem () és se ti tem()

függvények helyett írhatunk egyszerűen szögletes zárójeleket is. Ezt a kód

részletet például. ..

var foo = localStorage .get! tem( "bar");

l l ... localStorage.setitem( "bar", foo);

... erre is átírhatjuk:

var foo = localStorage ["bar" l ;

l l ... localStorage["bar"] = foo;


Arra is léteznek tagfüggvények, hogy eltávolítsuk egy adott nevesített kulcs értékér, vagy kipucoljuk a teljes tárolóterületet (vagyis egyszerre töröljünk minden kulcsot és értéket):

interface Starage { deleter void removertem (in DOMString key);

void clear () ;

};

Ha a removertem ()-et egy nem létező kulccsal hívjuk meg, nem csinál semmit.

Végül, van olyan tulajdonság is, amellyel megkaphatjuk a tárolóterületen

található értékek számát, illetve sorszám szerint végigmehetünk az összes kulcson (hogy kiolvassuk az egyes kulcsok nevét):

interface Starage { readonly attribute unsigned long length;

getter DOMString key (in unsigned long index);

};

Ha a key()-t egy olyan sorszámmal hívjuk meg, amely nem O és (length-l)

-vagyis a tömb hossza mínusz l -közé esik, a függvény null-t ad vissza.

A HTML5-tárolóterület változásainak nyomon követése

Ha nyomon szeretnénk követni a tárolóterület változásait, a storage eseményt kell elfognunk. A window objektum storage eseménye akkor következik be, amikor valaki meghívja a setitem(), a removertem (l vagy a ele ar () függvényt, és az ténylegesen megváltoztat valamit. Például ha egy

elemet egy már létező értékre állítunk, vagy akkor hívjuk meg a clear ()-t, amikor nincsenek nevesített kulcsok, a storage esemény nem indul el, mert a tárolóterületen nem történik semmilyen változás.

A storage esemény mindenhol támogatott, ahol a localStarage objektum, így az Internet Explorer 8-ban is. Az IE 8 ugyanakkor nem támogatja a W3C szabványos addEventListener függvényét (bár az IE 9-be már be fog kerülni a támogatása), így a storage eseményhez csak akkor kapcsolódhatunk, ha előbb megvizsgálj uk, hogy a böngésző melyik esemény

kezelő rendszert ismeri. (Ha már csináltunk ilyesmit más eseményekkel kapcsolatban, nyugodtan átugorhatjuk ezt a részt. A storage esemény elfogása


ugyanúgy történik, mint más események csapdába ejtése. Ha az eseménykezelőink bejegyzésére a jQuery-t vagy valamelyik másik JavaScript-könyvtárat részesítjük előnyben, a starage esemény esetében sem kell lemondanunk róluk.) Ezt kell tennünk:

if (window.addEventListener)

window. addEventListener ( "starage ", handle _ storage, false) ;

) else { window.attachEvent("onstorage", handle_storage);

l;

A hand le _ starage () visszahívó függvény egy StarageEvent objektummal hívódik meg, kivéve az Internet Explorerben, ahol az eseményobjek

tum a windaw.event-ben tárolódik:

function handle_storage (e) { if (!e) { e= window. event; l l

Ezen a ponton az e változóban egy StarageEvent objektum található, amelynek hasznos tulajdonságait a 7.2. táblázat sorolja fel.

7 .2. táblázat A StarageEvent objektum tulajdonságai

key

oldValue

newValue

url•

String

tetszőleges

tetszőleges

String

sek A hozzáadott, eltávolított vagy módosított nevesített kulcs

A korábbi érték (amelyet felülírtunk) vagy null, ha új elemet

hoztunk létre

Az új érték vagy null, ha eltávolítottunk egy elemet

A változást előidéző tagfüggvényt meghívó oldal

• Az url tulajdonság neve eredetileg uri volt, és egyes böngészők ez utóbbi tulajdonsággal

kerültek piacra, még az előtt, hogy a szabványleírás megváltozott volna. A lehető legteljesebb

körű együttműködés érdekében célszerű előbb az url tulajdonság létezését ellenőriznünk,

majd- ha nem létezik- megvizsgál nunk, hogy létezik-e az uri tulajdonság.

A starage esemény nem vonható vissza. A hand le _ starage () visszahívó függvényen belülről nincs rá mód, hogy megakadályozzuk a változás bekövetkezését. Az esemény csupán arra szolgál, hogy a böngésző közölhesse velünk: "Ez történt az imént. Semmit nem tehetsz ellene; csak azt akartam, hogy tudd.".


A jelenleg használt böngészők korlátai

Amikor a külső bővítményekkel megvalósított helyi tárolási megoldásokról beszéltem (lásd e fejezet "A helyi tárolásra a HTML5 előtt alkalmazott trükkök rövid története" című részét), külön hangsúlyoztam az egyes módszerek korlátait, például a tárolható adatok mennyiségét. A most már szabványosított HTML5-tároló korlátairól azonban még egy szót sem ejtettem.

Alapértelmezés szerint minden webhely 5 MB tárolóterületet kap. Ez meglepőerr egységes minden böngészőben, annak ellenére, hogy a HTML5-tároló szabványleírása csupán ajánlásként fogalmazza meg. Az egyik dolog, amit észben kell tartanunk, hogy az adatokat nem az eredeti formájukban, hanem karakterláncokként tároljuk. Ha sok egész vagy lebegőpontos számot tárolunk, az ábrázolás eltérése összességében jelentős különbséget eredményezhet,

mert minden számjegy karakterként tárolódik, nem pedig a lebegőpontos számok szokásos ábrázolása szerint.

Ha túllépjük a rendelkezésünkre álló tárhelyet, QUOTA _ EXCEEDED _

ERR kivétel lép fel. A következő kérdésünk nyilván az lesz, hogy "Kérhetek a felhasználótól több tárhelyet?". A válasz: "Nem". E könyv írásának idején egyetlen böngésző sem támogatja semmilyen módszerét annak, hogy a webfejlesztők további tárolóterületet igényeljenek. Vannak ugyan böngészők -például az Opera -, amelyek lehetővé teszik a felhasználónak, hogy szabályazza az egyes webhelyek tárhelykvótáját, de ez kizárólag a felhasználótól függ; a webfejlesztő nem építheti be a webalkalmazásaiba.

A HTML-tároló működés közben

Nézzük meg egy példán keresztül, hogyan is működik a HTML5-tároló! Idézzük fel magunkban a 4. fejezetben elkészített Halma-játékot (lásd az említett fejezet "Egy teljes példa" című részét). A játékkal van egy aprócska gond: ha játék közben bezárjuk a böngészőablakot, elveszítjük az addigi lépéseket. A HTML5-tárolóval azonban képessé válunk arra, hogy helyben, ma

gán a böngészőn belül mentsük a játékot. A http:lldiveintohtml5.orglexamples/

localstorage-halma.html címen megtekinthetjük, hogyan is működik ez élőben. Végrehajtunk néhány lépést, bezárjuk a böngészőlapot, majd újra megnyitjuk. Ha a böngészőnk támogatja a HTML5-tárolót, a bemutatóoldal


csodák csodájára emlékezni fog a játék állására- beleértve a lépéseink számát

és a bábuknak a táblán elfoglalt helyét -, sőt még arra is, hogy melyik bábu volt kiválasztva.

Hogyan működik mindez? Nos, minden alkalommal, amikor valami megváltozik a játékban, meghívjuk ezt a függvényt:

function saveGameState ( ) { if (! supportsLocalStorage ()) { return false; )

localStarage ["halma .game. in .progress "l = gGameinProgress;

for (var i= 0; i< kNumPieces; i++) { localStarage [ "halma. piece. " + i + ". row "l = gPieces [i l . row;

localStarage [ "halma. pi e ce. " + i + ".column "l = gPieces [i l . column;

}

localStarage ["halma. selectedpiece "l = gSelectedPieceindex;

localStorage[ "halma.selectedpiecehasmoved"l gSelectedPieceHasMoved;

localStarage ["halma .movecount "l = gMoveCount;

return true;

Amint láthatjuk, a kód a localStarage objektum segítségével menti (a gGameinPrag ress logikai változóba), hogy folyamatban van-e egy já

ték. Ha igen, akkor végigmegy a bábukon (a gPieces JavaScript-tömbön), és mindegyikről elraktározza, hogy hányadik sorban és oszlopban áll. Ezt követően további információkat ment a játék állapotáról, például azt, hogy

melyik bábu van kiválasztva (a gSelectedPieceindex egész szám típusú változóba), hogy a bábu egy potenciálisan hosszú ugrássorozat közepén tartózkodik-e (a gSelectedPieceHasMaved logikai változóba), illetve az addig megtett lépések számát (a gMoveCaunt egész típusú változóba).

Az oldal betöltésekor ahelyett, hogy automatikusan egy newGame () nevű függvényt hívnánk meg, amely a bedrótozott alapértékekre állítaná viszsza az említett változókat, egy resumeGame () függvényt hívunk meg. A

resumeGame () függvény a HTML5-tárolóra támaszkodva megvizsgálja,

hogy vannak-e a helyi tárolóban mentett adatok egy folyamatban levő játék állapotáról, és ha igen, visszaállítja az értékeket a localStarage objektum

segítségével:

function resumeGame ()

if {! supportsLocalStorage ()) { return false; }

gGameinProgress = ( localStarage ["halma .game. in .progress "l == "true");

if ('gGameinProgress) { return false;}

gPieces =new Array (kNumPieces);

for (var i= O; i< kNumPieces; i++) {

7. fejezet A helyi tárolás múltja, jelene és jövője . .. l 189

var row = parseint ( localStarage [ "halma. piece. " + i + ".ro w "l ) ; var column= parseint ( localStarage ["halma .piece. "+i+ ".column"]);

gPieces [i] = new Cell (row, column);

l gNumPieces = kNumPieces;

gSelectedPieceindex = parsein t ( localStarage ["halma. selectedpiece "l); gSelectedPieceHasMoved = localStarage ["halma. selectedpiecehasmoved "] ==

� "true";

gMoveCount = parseint ( localStarage ["halma .movecount "l); drawBoard();

return true;

Ennek a függvénynek a legfontosabb része azzal az ellentmondással kapcsola tos, amelyet a fejezet korábbi részében említettem. Még egyszer: az adatok ténylegesen karakterláncként tárolódnak- ha nem karakterláncot, hanem valami mást tárolunk, visszanyerés előtt magunknak kell azt a megfelelő adattípusra alakítanunk. Az a jelző például, amelyik megadja, hogy van-e folyamatban levő játék

(gGameinProgress), Boolean típusú. A saveGameState () függvényben csak elraktároztuk ezt a jelzőt, és nem foglalkoztunk az adattípusával.

localStarage [ "halma. game. in. progress "l = gGameinProgress;

A resumeGame () függvényben azonban a helyi tárolóból kiolvasott értéket karakterláncként kell kezelnünk, és saját kezűleg kell felépítenünk a megfe

lelő logikai értéket:

gGameinProgress = ( localStarage ["halma .game. in .progress "] = "true");

Ehhez hasonlóan a lépések száma egész számként tárolódik a gMoveCount változóban. A saveGameState () függvényben csak elraktároztuk:

localStarage [ "halma. movecount "l = gMoveCount;

A resumeGame () függvényben azonban az értéket egész számmá kell ala

kítanunk a JavaScript beépített parseint () függvényének segítségével:

gMoveCount = parsein t ( localStarage ["halma .movecount "l);


A kulcs-érték párokon túl: versengő elképzelések

Míg a múlt trükkökkel és kerülő megoldásokkal terhelt (lásd az "A helyi tárolásra a HTML5 előtt alkalmazott trükkök rövid története" című részt a fejezet elején), a HTML5-tárolás jelene meglehetősen rózsás: szabványosítottak egy új API-t, amelyet meg is valósítottak minden fontosabb böngészőben,

rendszeren és eszközön. Webfejlesztőként nem mindennap látunk ilyesmit, nem igaz? Az élet azonban többről szól, mint 5 megabájtnyi kulcs-énék párról, a maradandó helyi tárolás jövője pedig ... hogy is mondjam? ... fogalmazzunk úgy, hogy több, egymással versengő elképzelés létezik.

Az egyik látomást egy betűszó jelképezi, amellyel már valószínűleg találkoztunk: az SQL. 2007-ben a Google útjára bocsátotta a Gearst- azt a nyílt forrású, böngészőfüggetlen bővítményt, amely egy az SQLite-on alapuló beágyazott adatbázist tartalmaz. Ez a korai prototípus ihlette később a Web SQL Database szabványt. A Web SQL Database (korábbi nevén: "WebDB") egy SQL-adatbázishoz készült vékony burkoló, és az alábbihoz hasonló mű

veletek elvégzését teszi lehetövé JavaScript-kódokból:

openDatabase (' documents', 'l. 0', 'Local document storage', 5*1024*1024, function (db) {

db. changeVersion (' ' , ' l. O' , function (t) { t. executeSql ( ' CREATE TAB LE doc i ds (id, name) ' ) ;

} , error);

) );

Amint láthatjuk, a lényeg az executeSql ( ) tagfüggvénynek átadon karak

terláncban történik. Ez a karakterlánc bármilyen támogatott SQL-utasítás lehet, beleértve a SELECT, az UPDATE, az INSERT és a DELETE utasítást is. Pontosan olyan, mint a háttéradatbázisok programozása, csak éppen JavaScriptbőL Minő élvezet!

A 7.3. táblázat megmutatja, mely böngészők valósították meg eddig a Web SQL Database szabványt:

7.3. táblázat A Web SQL Database támogatása

IE Firefox Satari Chrome

4.0+ 4.0+

iPhone Android

10.5+ 3.0+

7. fejezet A helyi tárolás múltja, jelene és jövője . .. l 191

Természetesen, ha már több adatbázis-terméket is használtunk életünkben, akkor tisztában vagyunk vele, hogy az "SQL" inkább piaci márka, mintsem kőbe vésett szabvány. (Egyesek ugyanezt mondanák a HTML5-ről is, de ezzel most ne törődjünk.) Létezik persze tényleges SQL-szabvány is- SQL-92-nek hívják - de nincs a világon olyan adatbázis-kiszolgáló, amely kizárólag ehhez a szabványhoz igazodna. Van az Oracle SQL-je, a Microsoft SQL-je, a MySQL SQL-je, a PostgreSQL SQL-je, az SQLite SQL-je, és ezen temékek mindegyike folyamatosan új szolgáltatásokkal bővül, tehát még az sem írja körül pontosan, hogy miről beszélünk, ha azt mondjuk, hogy "SQLite SQL'' -azt kell mondanunk, hogy "az SQL-nek az a változata, amelyet az SQLite X.Y.Z. változata tartalmaz

".

Mindez az alábbi nyilatkozathoz vezet minket, amely jelenleg a Web SQL Database szabvány elején olvasható:

Ez a szabvány zsákutcába került: minden érdekelt megvalósító ugyanazt az SQL-háttérkiszolgálót (Sqlite) használja, de több független megvalósírásra van szükségünk ahhoz, hogy a szabványosírást folytathassuk. Amíg egy ú jabb fejlesztőcég érdekeltté nem válik abban, hogy megvalósítsa ezt a szabványt, az SQL-nyelvjárás leírása egyszerűen egy az Sqlite-ra mutató hivatkozás marad, ami egy szabvány esetében elfogadhatatlan.

Ennek a háttérinformációnak a birtokában muratom be a következő elképzelést, amely a webalkalmazások számára biztosított fejlett, maradandó helyi tárolás megvalósítására irányul: az Indexed Database API-t, amelyet korábban "WebSimpleDB

"-ként ismertek, ma pedig "lndexedDB

"-nek be

céznek. Az lndexed Database API egy úgynevezett objektumtárolót tesz elérhetővé.

Az objektumtárolók sok szempontból hasonlítanak az SQL-adatbázisokra: vannak "adatbázisok

" "rekordokkal

", és minden rekord adott számú "mező

vel"

rendelkezik. Minden mezőnek van egy meghatározott adattípusa, amelyet az adatbázis létrehozásakor kell megadni. Kijelölhetjük a rekordok egy részhalmazát, majd kinyerhetjük azokat egy "kurzorral

" (sormutatóval). Az

objektumtár módosítása "tranzakciókon"

keresztül történik. Ha már programoztunk SQL-adatbázisokat, ezek a kifejezések valószínű

leg ismerősek a számunkra. A legfontosabb különbséget az jelenti, hogy az objektumtárnak nincs strukturált lekérdezőnyelve. Nem építünk fel olyan


utasításokat, mint a "SELECT * from USERS where ACTIVE = 'Y'",

hanem ehelyett az objektumtár által biztosított tagfüggvényekkel megnyitunk egy sarmutatót a USERS nevű adatbázisban, végigmegyünk vele a rekordokon, kiszűrjük az inaktív felhasznáJók rekordjai t, és kiolvassuk az egyes mezők értékét a fennmaradó rekordokbóL Az

"early walk-through ofindexedDB"

(http:!lhacks.mozilla.org/2010/06/comparing-indexeddb-and-webdatabasel) remekül bemutatja az IndexedD B működését, és egymás mellé helyezve összehasonlítja az IndexedDB-t a Web SQL Database-szel.

E könyv írásának idején az IndexedDB-t még nem valósították meg egyetlen fontosabb böngészőben sem. 2010 júniusának elején a Mozilla azt mondta, hogy

"néhány héten belül rendelkezésre áll majd pár tesztváltozat", de arról

semmi hír, hogy akár a Firefox 4-be bekerülne az IndexedDE támogatása. (Ezzel szemben viszont a Mozilla kijelentette, hogy soha nem fogja megvalósítani a Web SQL Database-t.) A Google állítása szerint gondolkodik az IndexedDE támogatásán, és még a Microsoft is úgy nyilatkozott, hogy az IndexedDE

"kitűnő megoldás a Web számára".

Mit kezdhetünk tehát mi, webfejlesztők, az IndexedDB-vel? Jelenleg az égvilágon semmit. És egy év múlva? Talán valamit. Addig is böngésszünk a

"További olvasmányok" cím alatt található oktatóanyagok között, hogy le

gyen honnan elindulnunk


HTML5-tároló: • A HTML5-tároló szabványleírása (http:lldev.w3.orglhtml5/webstoragel) •

"Introduction to DOM Storage" (http:llmsdn.microsoft.com/en-us/libraryl

ccl97062(VS.85).aspx) az MSDN-en • Shwetank Dixit: ,;web Storage: easier, more powerful dient-side data storage"

(http:lldev. opera. com/ articles/view/web-storagel) •

"Introduction to DOM Storage" (https:l/developer.mozilla.orglen/dom/

storage) a Mozilla Developer Center oldalán. (Megjegyzés: az oldal nagy részét a globalStarage objektum Firefox-beli prototípus-megvalósításának szentelték, amely egy nem szabványos előfutára a localStarage

objektumnak. A Mozilla a Firefox 3.5-ben adta a böngészőhöz a szabványos localStarage felület támogatását.)


• "Unlock local storage for mobile Web applications with HTML5" (http:/1 www. ibm. comldeveloperworks/xmlllibrarylx-html5mobile2/), oktatóanyag at IBM DeveloperWorks oldalán

Brad Neuberg és mások korai (a HTMLS előtti) munkái: • "Internet Explorer Has Native Support for Persisrence?!?!" (http:llcoding

inparadise. orgiweblog/2 005/08/ ajax-internet-explorer-has-native. h tm l}, a userData objektumról az Internet Explorerben

• Do j o Storage (http://docs.google. com/View?docid=dhkhksk4_ 8gdp9gr#dojo _ storage), egy nagyobb oktatóanyag része, amely a (ma már nem fejlesz

tett) Dojo Offline könyvtárról szól • A dojox.storage.manager API leírása (http://api.dojotoolkit.org/

jsdoc/HEAD/dojox.storage. manager) • A do j ox. starage Subversion-tár (http:llsvn.dojotoolkit.orglsrcldojoxl

trunklstoragel)

Web SQL Database:

• A Web SQL Database szabványleírása (http:!ldev.w3.orglhtml5/webdatabasel) • Remy Sharp: "Introducing Web SQL Databases" (http:llhtml5doctor.com/

introducing-web-sql-databasesl) • Web Database-bemutató (http:llhtml5demos.comldatabase) • persistence.js (http:llzefme/2774/persistence-js-an-asynchronous-javascript

orm-for-html5gears), egy "aszinkron JavaScript OR M", amely a Web

SQL Database és Gears tetejére épül

IndexedD B:

• Az Indexed Database API szabványleírása (http:lldev.w3.org/2006/webapil IndexedD B!)

• Arun Ranganathan és Shawn Wilsher: "Beyond HTML5: Database APis and the Road to IndexedDB" (http:llhacks.mozilla.org/2010/06/beyondhtml5-database-apis-and-the-road-to-indexeddb!)

• Arun Ranganathan: "Firefox 4: An early walk-through of IndexedD B"

(http:llhacks. mozilla. org/20 l 0/06/comparing-indexeddb-and-webdatabase/)

8. fejezet

Bontsuk a kapcsolatot!

Ugorjunk fejest!

Mi az a kapcsolat nélküli webalkalmazás? Az elnevezés első hallásra önellentmondásnak tűnik, hiszen a weboldalakat letöltjük, hogy megjeleníthessük, a letöltés pedig hálózati kapcsolatot feltételez. Hogyan tölthetünk le valamit, ha nem kapcsolódunk a hálózatra? Természetesen sehogy- akkor viszont igen, amikor a kapcsolat él. A kapcsolat nélküli (offiine) HTML5-alkalmazások pontosan így működnek.

A legegyszerűbb formájában egy kapcsolat nélküli webalkalmazás csupán egy sor URL, amelyek HTML-, CSS- vagy JavaScript-fájlokra, képekre és egyéb erőforrásokra mutatnak. A kapcsolat nélküli webalkalmazás kezdőoldala erre a jegyzékfájlnak (manifest fájlnak) nevezett listára mutat, ami nem más, mint egy egyszerű szövegfájl, ami valahol a webkiszolgálón található.

A kapcsolat nélküli HTML5-alkalmazásokra felkészített webböngészők kiolvassák az URL-címeket a jegyzékfájlból, letöltik az erőforrásokat, helyi gyorstárba írják őket, és önműködően frissítik a helyi másolatokat, ha az eredetijük megváltozik Amikor a webalkalmazást hálózati kapcsolat nélkül próbáljuk elérni, a webböngésző automatikusan a helyi másolatra vált.

A fentieken kívül szinte minden másról mi, a webfejlesztök gondoskodunk.

A DOM-ban van egy jelző, amely tájékoztat róla, hogy hálózati kapcsolattal vagy anélkül dolgozunk, és bizonyos események is elindulnak, amikor az állapot megváltozik (vagyis amikor az egyik pilanatban nincs kapcsolat, aztán ismét van, vagy fordítva), de lényegében ennyi. Ha az alkalmazásunk adatokat hoz létre vagy állapotot ment, a mi feladatunk helyben elraktározni ezeket az információkat (lásd a 7. fejezetet), amíg nem él a kapcsolat, majd összehangolni azokat a távoli kiszolgálóval, amint ismét kapcsolódtunk a hálózatra. Más szavakkal, a HTML5 képes kapcsolat nélkül is megőrizni a webalkalmazásunkat, de az már tőlünk függ, hogy mit csinálunk, amikor a kapcsolat

8. fejezet Bontsok a kapcsolatot! l 195

megszakad.A 8.1. táblázatban megtekimhetjük, hogy mely böngészők támogatják a kapcsolat nélküli webalkalmazásokat.

8.1. táblázat A kapcsolat nélk.;;u:....'li:....m:....ú:....' k:....öd:....e:....' s:....ta:....· m:....o;..:g:.;.a.;.; tá:....sa=---------------. IE Flrefox Satari Chrame

A gyorstárjegyzék

O ra iPhone Android

_ _c../ _ ___ ../

A kapcsolat nélküli webalkalmazások működéséhez elengedhetetlen egy gyorstárjegyzék (cache manifest). Ahogy már említettem, a jegyzék sorolja fel az összes erőforrást, amire a webalkalmazásnak szüksége lehet, amikor nem kapcsolódik a hálózathoz. Ahhoz, hogy lehetövé tegyük az erőforrások letöltését és gyomárba írását, a <html> elemben a manifest jellemzővel hivat-koznunk kell a jegyzékfájlra:

•

< ' DOCTYPE HTML>

<htrnl manifes t=" /cache.manifest">

<body>

</body>

</html>

A gyorstárjegyzék bárhol lehet a webkiszolgálón, de mindenképpen a text/

eaehe-manifest tartalomtípussal kell szolgáltatni. Ha Apache alapú webkiszolgálót futtatunk, valószínűleg elég egy AddType utasítást elhelyeznünk a webkönyvtár gyökerében található .htaccess fájlban:

AddType text/eaehe-manifest . manifest

Ügyeljünk rá, hogy a gyorstárjegyzék fájlneve .manifest-re végződjön. Ha másik webkiszolgálót vagy más Apache-beállításokat használunk, nézzünk utána a kiszolgáló dokumentációjában, hogy mikém szabályozhatjuk a Content-Type fejlécet.

196 l Bontsok a kapcsolatot! 8. fejezet


Kérdés: A webalkalmazás om több oldalt fog át. Minden oldalon szükség van

külön manifest jellemzőre, vagy elég csak a kezdőoldalon elhelyezni egyet?

Válasz: A webalkalmazás minden oldalán lennie kell egy manifest

jellemzőnek, ami a reljes alkalmazás gyorstárjegyzékére mutat.

Jó, tehát minden egyes HTML-oldalunk hivatkozik a gyorstárjegyzékre, és a gyorstárjegyzéket a megfelelő Content-Type fejléccel szolgáltatjuk. De mi kerül a jegyzékfájlba? A dolog itt kezd érdekessé válni.

Minden gyorstárjegyzék első sora így fest:

CACHE MANIFEST

Ezt követően minden jegyzékfájl három részre oszlik: a kifejezett szakaszra, a tartalék szakaszra és a hálózati fehérlista szakaszra. Mindegyik szakaszt külön sorban szereplő fejléc vezeti be. Ha a jegyzékfájlban nincsenek szakaszfejlécek, akkor minden felsorolt erőforrás úgy tekintendő, mintha a kifejezett szakaszban szerepelne. A terminológiával ne foglalkozzunk túl sokat, nehogy szétrobbanjon a fejünk.

Íme egy érvényes jegyzékfájl, amely három erőforrást- egy CSS- és egy JavaScript-fájlt, valamint egy JPEG-képet - sorol fel (amelyekből egy óra áll össze):

CACHE MANIFEST /clock.css /clock.js /clock-face. jpg

Ebben a jegyzékfájlban nincsenek szakaszfejlécek, tehát minden felsorolt erőforrás alapértelmezés szerint a kifejezett szakaszba tartozik. A kifejezett szakaszban szereplő erőforrások letöltődnek és a helyi gyorstárba kerülnek, az alkalmazás pedig ezeket a másolatokat használja a hálózaton található eredeti fájlok helyett, ha éppen nem kapcsolódunk a hálózatra. Amikor tehát beröltjük a fenti gyorstárjegyzéket, a böngésző letölti a clock.css, clock.js és clockface.jpg fájlokat a webkiszolgáló gyökérkönyvtárábóL Ezt követően kihúzhatjuk a hálózati kábelt, és újratölthetjük az oldalt: valamennyi erőforrás kapcsolat nélkül is elérhető lesz.



Kérdés: A HTML-o/dalaimat is fol kell sorolnom a gyorstdrjegyzékben? Válasz: Igen is, meg nem is. Ha a teljes webalkalmazást egyetlen oldal tartalmazza, csak arról kell gondoskodnunk, hogy az oldal a ma n if es t

jellemzőben hivatkozzon a gyorstárjegyzékre. Amikor egy manifest

jellemzővel rendelkező HTML-oldalra ugrunk, ezt az oldalt a böngésző

a webalkalmazás részének tekinti, tehát nem kell feltüntetnünk magában a jegyzékfájlban. Ha azonban a webalkalmazás több oldalt fog át, az összes HTML-oldalt fel kell sorolnunk a jegyzékben, különben

a böngésző nem fogja tudni, hogy vannak más HTML-oldalak is, amelyeket le kell töltenie és gyorstárba írnia.

Hálózati szakaszok

Nézzünk egy kicsit bonyolulrabb példát! Tegyük fel, hogy azt szeretnénk,

hogy az óraprogramunk nyomon kövesse a látogatókar egy tracking.cgi nevű parancsfájl segítségéve!, amely dinamikusan töltődik be egy <img src>

jellemzőbőL Ezt az erőforrást nem írhatjuk gyorsrárba, mert az meghiúsítaná a nyomon követésr. Fel kell tehát rüntetnünk, hogy soha nem kerülher gyors

tárba, és így nem érhető el kapcsolat nélkül:

CACHE MANIFEST NETWORK: /tracking.cgi CACHE: /clock.css /clock.js /clock-face. jpg

Ez a gyorstárjegyzék már tartalmaz szakaszfejlécekeL A NETWORK: ("hálózar") sor a hálózari fehérlista szakasz kezdete. Az ebben a szakaszban felsorolt erőforrások soha nem íródnak gyorstárba, és nem érhetők el kapcsolat nélkül. (Ha kapcsolat nélkül próbáljuk betölteni őket, hibát kapunk.) A CACHE:

szöveget tartalmazó sor a kifejezett szakasz kezdetét jelzi. A jegyzékfájl fenn

maradó része megegyezik az előző példában szerepiőveL A felsorolt három erőforrást a böngésző gyorstárazza, és kapcsolat nélkül elérhetővé teszi.


Tartalék szakaszok

A jegyzékfájlokban egy másik típusú szakasz is lehet: a tartalék szakasz. A tartalék szakaszokban azt adhatjuk meg, hogy mivel helyettesíthetők azok

a hálózati erőforrások, amelyek valamilyen oknál fogva nem írhatók gyorstárba, vagy a gyorstárazásuk nem sikerült. A HTML5-szabványleírás ezt

a példát hozza fel a tartalék szakaszok használatára:

CACHE MANIFEST

FALLBACK:

l /offline.html

NETWORK:

Mit eredményez ez a jegyzékfájl? Először is, gondoljunk egy olyan webhelyre - mondjuk a Wikipediára -, amely oldalak millióit tartalmazza. A teljes web

helyet nem tölthetjük le - nem is akarnánk ilyet tenni. De tegyük fel, hogy egy részét elérhetővé tehetjük kapcsolat nélkül. Mi alapján döntenénk el,

hogy mely oldalakat írjuk gyorstárba? Mi szólnánk ehhez: minden olyan

oldalt letöltünk és elraktározunk, amit valaha is megtekintettünk a képzeletünkben létező, kapcsolat nélkül is működő Wikipedián. Ebbe beletartozik

az enciklopédia minden olyan cikke, amelyet valaha olvastunk, minden cse

vegőoldala (ahol vitatkozhatunk egy adott szócikkről) és minden szerkesztő

oldala (ahol módosíthatjuk az említett cikket). Erre való a fenti jegyzékfájL Tegyük fel, hogy a Wikipedián minden

HTML-oldal (cikk, csevegőoldal, szerkesztőoldal, előzményoldal) hivatkozik

erre a gyorstárjegyzékre. Ha ellátogatunk egy olyan oldalra, amely erre

a gyorstárjegyzékre mutat, a böngésző azt mondja: "Hé, ez az oldal egy kapcsolat nélküli webalkalmazás része! Ismerem ezt a webalkalmazást?". Ha a bön

gésző még soha nem töltötte le ezt a bizonyos jegyzékfájlt, létrehoz egy új kapcsolat nélküli "alkalmazás-gyorstárat" (application cache, röviden "appcache"), letölti a jegyzékfájlban felsorolt összes erőforrást, majd hozzáadja az aktuális oldalt az alkalmazás-gyorstárhoz. Ha a böngésző már korábban létrehozta az említett jegyzékfájlt, egyszerűen hozzáadja az oldalt a meglevő alkalmazás

gyorstárhoz. A meglátogatott oldal mindkét esetben az alkalmazás-gyorstárban köt ki. Ez lényeges, mert azt jelenti, hogy lehet egy kapcsolat nélküli

webalkalmazásunk, amely "önműködően" rögzíti a meglátogatott oldalakat, így nem kell minden egyes HTML-oldalt felsorolnunk a gyorstárjegyzékben.


Most nézzük meg a tartalék szakaszt. A jegyzékfájl tartalék szakasza egyetlen sort tartalmaz. A sor első fele (a szóköz előtti rész) nem URL-cím, hanem egy URL-minta. Az egyetlen perjel (/ ) karakter a webhely minden oldalára illeszkedik, nem csak a kezdőoldalra. Amikor egy oldalt kapcsolat nélkül próbálunk megtekinteni, a böngésző megnézi, hogy megvan-e az alkalmazás-gyorstárban. Ha ott megtalálja az oldalt (mert már megtekintettük azt, amíg a hálózatra kapcsolódtunk, és így a böngésző rögzítette az oldalt az alkalmazás-gyorstárban), megjeleníti az oldal tárolt másolatát. Ha a böngésző nem találja az oldalt az alkalmazás-gyorstárban, nem hibaüzenetet jelenít meg, hanem az /offiine.html oldalt, amit a tartalék szakasz sorának második fele határoz meg.

Végül vizsgáljuk meg a hálózati szakaszt. A fenti jegyzékfájl hálózati szakasza szintén egyeden sorból áll, amelyben csak egy csillag (*) karakter található. Ennek a karakternek különleges jelentése van a hálózati szakaszban- ez a "hálózati fehérlista általános helyettesítő karaktere". Ez a nyakatekert név csak annyit takar, hogy ami nem szerepel az alkalmazás-gyorstárban, azt nyugodran töltsük le, ha él a hálózati kapcsolat, ami egy "nyílt végű", kapcsolat nélküli webalkalmazás esetében igazán fontos. A példánkat folytatva, ez azt jelenti, hogy miközben a hálózaton böngészünk a képzeletbeli, kapcsolat nélkül is működő Wikipedián, a böngészőnk a szokásos módon letölti a képeket, videókat és más beágyazott erőforrásokat, még akkor is, ha azok egy másik tartományban találhatók. (Ez megszakott a nagyobb webhelyeken, még ha azok nem is egy kapcsolat nélküli webalkalmazás részei: a HTMLoldalak előállírása és kiszolgálása helyben történik, míg a képek és videók egy másik tartományban található tartalomszolgálrató hálózatról származnak.) Az általános helyettesítő karakter nélkül a képzeletbeli, kapcsolat nélkül is működő Wikipedia furcsán viselkedne, amikor a hálózaton vagyunk: konkrétan, nem töltene be egyeden külső tárolású képet és videót sem!

Teljes ez a példa? Nem. A Wikipedia nem csak HTML-fájlokból áll: az oldalak szokványos CSS- és JavaScript-fájlokat, illetve képeket is tartalmaznak. Ezen erőforrások mindegyikét kifejezetten fel kellene sorolnunk a jegyzékfájl CA CHE: szakaszában ahhoz, hogy az oldalak helyesen jelenjenek meg és működjenek kapcsolat nélkül is. A tartalék szakasz célja azonban éppen az, hogy lehessen egy "nyílt végű" kapcsolat nélküli webalkalmazásunk, amely túlnyúlik a jegyzékfájlban konkrétan felsorolt erőforrásokon.


Az eseményfolyam

Amit eddig a kapcsolat nélküli webalkalmazásokról, a gyorstárjegyzékekről és a kapcsolat nélküli alkalmazás-gyorstárakról ("appcache") mondtam, féligmeddig hókuszpókusznak tűnhet: az erőforrások letöltődnek, a böngésző döméseket hoz, és minden "csak úgy működik". Ezt persze nem hisszük el, ugye? Végtére is, webfejlesztésről van szó, ahol soha semmi nem működik

"csak úgy". Először is az eseményfolyamról, konkrétan a DOM-eseményekről kell

szót ejtenünk. Amikor a böngészőnk megnyit egy oldalt, amely egy jegyzékfájira mutat, egy sor eseményt indít el a window. applicationCache

objektumon (lásd alább). Tudom, hogy bonyolultnak tűnik, de higgyük el, ennél egyszerűbben nem tudnám megfogalmazni úgy, hogy ne hagyjak ki fontos információkat. Íme a folyamat:

l. Amint észrevesz egy manifest jellemzőt a <html> elemben, a böngésző elindít egy checking eseményt. (Minden itt felsorolt esemény a window. applicationCache objektum eseményeként indul el.) A checking eseményre mindig sor kerül, függetlenül attól, hogy korábban ellátogattunk-e már erre vagy bármely más oldalra, amely ugyanerre a gyorstárjegyzékre mutat.

2. Ha a böngésző még soha nem találkozott ezzel a jegyzékfájllal: • Elindít egy downloading eseményt, majd megkezdi a gyorstárjegyzékben

felsorolt erőforrások letöltését. • Miközben letölt, a böngésző időről időre progress eseményeket indít

el, amelyek arról tartalmaznak információt, hogy a böngésző hány fájlt töltött már le, és hány fájl vár még letöltésre.

• Miután a jegyzékben szereplő összes erőforrást sikeresen letöltötte, a böngésző elindít még egy utolsó, cached nevű eseményt. Ez jelzi, hogy a kapcsolat nélküli webalkalmazás teljes egészében a gyorstárba került, és készen áll a kapcsolat nélküli használatra. Ennyi az egész; készen vagyunk.

3. Ezzel szemben, ha az említett oldalt vagy bármely más oldalt, amely ugyanarra a jegyzékfájira mutat, korábban már meglátogattuk, a böngészőnk már tudni fog erről a jegyzékfájlról, és már el is helyezhetett bizonyos erőforrásokat- akár a teljes kapcsolat nélküli webalkalmazást-az alkalmazás-gyorstárban.


A kérdés ebben az esetben tehát az, hogy a jegyzékfájl megváltozott-e azóta, hogy a böngésző utoljára ellenőrizte?

• Ha a válasz nem, tehát a jegyzékfájl nem változott meg, a böngésző azonnal elindít egy noupdate eseményt, és ezzel végzett is.

• Ha a válasz igen, tehát a jegyzékfájl megválrozott, a böngésző egy downloading eseményt indít el, és megkezdi a jegyzékben felsorolt valamennyi erőforrás letöltését.

Miközben lerölt, a böngésző időről időre progress eseményeket indít el, amelyek arról tartalmaznak információt, hogy a böngésző hány fájlt töltött már le, és hány fájl vár még letöltésre.

Miután a jegyzékben szereplő összes erőforrást sikeresen újra letöltötte, a böngésző elindít még egy utolsó, updateready nevű eseményt. Ez jelzi, hogy a kapcsolat nélküli webalkalmazás új változata teljes egészében a gyorstárba került, és készen áll a kapcsolat nélküli használatra. Ekkor azonban még nem az új változatot látjuk. Ha "menet közben" az új változatra szeretnénk váltani, anélkül, hogy a felhasználót az oldal újratöltésére kényszerítenénk, saját kezűleg meg kell hívnunk a window.applicationCache.

swapCache ( ) függvényt. Ha a folyamat bármely pontján félresiklik valami, a böngésző egy error

eseményt vált ki, és leállírja a műveletet. Hogy mi okozhat hibát? Íme egy a végletekig lerövidített lista:

• A jegyzékfájl egy 404-es (Page Not Found- "Az oldal nem található") vagy 410-es (Permanemly Gone- "Véglegesen törölve") HTTP-hibát ad ViSSZa.

• A jegyzékfájl megvan, és nem változott meg, de a rá mutató HTMLoldal nem töltődött le helyesen.

• A jegyzékfájl megvan, és megváltozott, de a böngészőnek nem sikerül letöltenie a benne felsorolt erőforrások egyikét.


A hibakeresés művészete,

avagy "Ölj meg! Ölj meg itt és most!"

Két fontos dologra szeretném felhívni itt a figyelmet. Az elsőről éppen most olvastunk, de lehet, hogy nem igazán fogtuk fel, úgyhogy elismétlem: ha a jegyzékfájlban felsoroltak közül akár csak egyetlen erőforrás letöltése is sikertelen, a kapcsolat nélküli webalkalmazás gyorstárazásának teljes művelete kudarcot vall. A böngésző elindítja az error eseményt, de arról nem kapunk viszszajelzést, hogy pontosan mi volt a probléma, ami a hibakeresést rendkívül bosszantóvá teheti a kapcsolat nélküli webalkalmazásokban.

A másik fontos dolog elméleti értelemben nem hiba, de komoly böngészőhibának tűnhet, amíg rá nem jövünk, hogy miről is van szó. Arról ugyanis, hogy a böngésző pontosan hogyan is ellenőrzi, hogy a jegyzékfájl megváltozott-e. A művelet három lépésből áll. Tudom, hogy unalmas, de muszáj tudnunk, úgyhogy figyeljünk. Íme az eljárás:

l. A böngésző a szokványos HTTP-eljárásokkal ellenőrzi, hogy a gyorstárjegyzék lejárt-e. Mint minden más fájl esetében, amelyet HTTP-n keresztül szolgáltat, a webkiszolgáló általában az ilyen fájlokról is metaadatokat helyez el a HTTP-válaszfejlécekben. Egyes HTTP-fejlécek (az Expires és a Cache-Control) arról tájékoztatják a böngészőt, hogy milyen feltételekkel gyorstárazhatja a fájlt anélkül, hogy megkérdezné a kiszolgálótól, hogy a fájl megváltozott-e. Ennek a fajta gyorstárazásnak semmi köze a kapcsolat nélküli webalkalmazásokhoz: lényegében minden HTML-oldalra, stíluslapra, parancsfájlra, képre és más webes erőforrásra vonatkozik.

2. Ha a jegyzékfájl lejárt (a HTTP-fejlécek szerint) , a böngésző megkérdezi a kiszolgálótól, hogy van-e belőle új változat, és ha igen, letölti azt. Ehhez a böngésző egy HTTP-kérelmet ad ki, amely tartalmazza a jegyzékfájl utolsó módosításának dátumát - azt a dátumot, amelyet a webkiszolgáló közölt a HTTP-válaszfejlécben, amikor a böngésző utoljára letöltötte a fájlt. Ha a webkiszolgáló úgy találja, hogy a jegyzékfájl nem módosult az említett dátum óta, egyszerűen a 304 (Not Modified)- "Nem módosult"- válaszkódot adja vissza. Ez sem kizárólag a kapcsolat nélküli webalkalmazások sajátossága - lényegében minden erőforrás esetében ez történik a Weben.

3. Ha a webkiszolgáló úgy gondolja, hogy a jegyzékfájl megváltozott az említett dátum óta, a 200-as (OK) HTTP-állapotkódot adja vissza, amelyet az új fájl tartalma, valamint az új eaehe-Control fejlécek és az utolsó


módosítás új dátuma követ. Ez biztosítja, hogy az l. és 2. lépés legközelebb is helyesen működjön. (A HTTP klassz. A webkiszolgálók mindig gondolnak a jövőre. Ha a webkiszolgálónak feltétlenül el kell küldenie nekünk egy fájlt, mindent megtesz annak érdekében, hogy feleslegesen ne kelljen kétszer elkülden ie.) Miután a böngésző letöltötte az új jegyzékfájlt, összeveti annak tartalmát a legutóbb letöltött másolattal. Ha a jegyzékfájl tartalma megegyezik a korábbi változatéval, a böngésző nem tölti le újra a jegyzékfájlban felsorolt egyik erőforrást sem.

A fenti lépések bármelyike buktatónak bizonyulhat, amikor egy kapcsolat nélküli webalkalmazást fejlesztünk és tesztelünk Tegyük fel például, hogy közzéreszünk egy változatot a jegyzékfájlunkból, majd 10 perccel később rájövünk, hogy még egy erőforrást hozzá kell adnunk. Semmi gond, igaz? Csak beleírunk a jegyzékbe még egy sort, és újra közzétesszük a fájlt. Csakhogy ekkor a következő történik: újratöltjük az oldalt, a böngésző észleli a manifest jellemzőt, elindítja a checking eseményt, és ... semmi nem történik. A böngésző makacsul ragaszkodik ahhoz, hogy a gyorstárjegyzék nem változott meg. Miért? Azért, mert a webkiszolgálót alapértelmezés szerint valószínűleg úgy állították be, hogy a böngészőket arra utasítsa, hogy néhány óráig gyorstárazzák a statikus fájlokat (HTTP-eljárásokon keresztül, a eaehe-Control fejlécek használatával). Ez azt jelenti, hogy a böngésző soha nem jut túl a háromlépéses művelet l. lépésén. A webkiszolgáló természetesen tudja, hogy a fájl megváltozott, de a böngésző nem jut el odáig, hogy ezt megkérdezze a webkiszolgálótóL Miért? Azért, mert amikor utoljára letöltötte a jegyzékfájlt, a webkiszolgáló azt mondta neki, hogy néhány óráig ezt az erőforrást tárolja a gyorstárában (HTTP-eljárásokon keresztül, a eaehe

Control fejlécek használatával). A böngésző pedig most, 10 perccel később, pontosan ezt teszi.

Világossá szeretném tenni, hogy ez nem hiba, hanem kényelmi szolgáltatás, ami pontosan úgy működik, ahogy működnie kell. Ha a webkiszolgálóknak nem lenne rá módjuk, hogy közöljék a böngészőkkel (és a köztes számítógépekkel), hogy bizonyos dolgokat gyorstárazniuk kell, a Web egy szempillantás alatt összeomlana. Ez persze nem vigasztal minket, ha órákat töltöttünk azzal, hogy rájöjjünk, miért nem veszi észre a böngészőnk, hogy a jegyzékfájl frissült. (És ami a legszebb az egészben: ha elég ideig várunk, az alkalmazás ismét működni kezd! Mert a HTTP-gyorstár elévült! Ahogy az elő van írva! Öljetek meg! Öljetek meg itt és most!)


Egy dolgot tehát mindenképpen el kell még végeznünk: át kell állítanunk a webkiszolgálót, hogy a jegyzékfájl ne kerülhessen a HTTP-gyorstárba. Ha Apache alapú webkiszolgálót futtatunk, elég ezt a két sort elhelyeznünk a .htaccess fájlban:

ExpiresActive On

ExpiresDefault •access •

Ez a két sor letiltja az adott könyvtárban és annak alkönyvtáraiban található fájlok gyorstárazását. Az üzemi környezetben valószínűleg nem ezt szeretnénk, ezért vagy minősítenünk kell a fenti meghatározást egy <Fi les> utasítással, hogy csak a jegyzékfájlunkra vonatkozzon, vagy létre kell hoznunk egy alkönyvtárat, amelyben csak a gyorstárjegyzék és ez a .htaccess fájl található. Ahogy az lenni szokott, a beállítás részletei a különféle webkiszolgálókan eltérhetnek, ezért nézzünk utána a kiszolgáló dokumentációjában, hogy miként szabályozhatjuk a HTTP-gyorstár fejléceit.

Mindazonáltal a HTTP-gyorstárazás letiltása a gyorstárjegyzékre vonatkozóan önmagában nem oldja meg minden gondunkat. Így is előfordulhat, hogy módosítjuk az alkalmazás-gyorstár valamelyik erőforrását, de az továbbra is ugyanazon az URL-en található a webkiszolgálón. Ebben az esetben a háromlépéses művelet 2. lépése akaszt meg minket. Ha a jegyzékfájl nem változott meg, a böngésző soha nem fogja észrevenni, hogy az egyik korábban gyorstárba Írt erőforrás módosult. Vegyük az alábbi példát:

CACHE MANIFEST

#rev 42

c lock. js

clock.css

Ha módosítjuk a clock.css fájlt, és újra közzétesszük, nem fogjuk látni a változást, mert maga a gyorstárjegyzék nem módosult. Minden alkalommal, amikor változtatunk a kapcsolat nélküli webalkalmazás valamelyik erőforrásán, magát a jegyzékfájlt is módosítanunk kell, de ehhez elég akár egyeden karaktert megváltoztatni. Talán az a legegyszerűbb, ha a jegyzékfájlban elhelyezünk egy megjegyzéssort a változat számával, és amikor változtatunk valamelyik erőforráson, a megjegyzésben szereplő változatszámot írjuk át. A webkiszolgáló a módosított jegyzékfájlt adja vissza, a böngésző pedig észreveszi, hogy a fájl tartalma megváltozott, és újra letölti a jegyzékben felsorolt összes erőforrást:


CACHE MANIFEST

t rev 43 clock.js clock.css

Építsünk egyet!

Emlékszünk még a Halma-játékra, amelyet a 4. fejezetben készítettünk (lásd ott az "Egy teljes példa" című részt), majd később kiegészítettünk, hogy képes legyen maradandó helyi tároló ba memeni a játék állapotát ("A HTML-tároló működés közben")? Nos, itt az ideje, hogy a Halma-játékunkat leválasszuk a hálózatról.

Ehhez egy jegyzékfájlt kell készítenünk, amely felsorolja az összes erőforrást, amire a játéknak szüksége van. Van ugye a fő HTML-oldal, egy JavaScript-fájl, amely a játék kódját tartalmazza, és .. . ennyi. Nincsenek képek, mivel a grafikát teljes egészében programból, a Canvas API-n keresztül vezéreljük (lásd a 4. fejezetet), és minden szükséges CSS-stílus egy <style>

elemben található a HTML-oldal elején. A jegyzékfájlunk tehát így fest:

CACHE MANIFEST

halma.html .. /halma-localstorage.js

Egy megjegyzés az elérési utakkal kapcsolatban: létrehoztam egy offiine/ alkönyvtárat az examples/ könyvtárban, és a fenti jegyzékfájl ebben az alkönyvtárban kapott helyet. Mivel a HTML-oldalt egy apró kiegészítéssel kell ellátnunk, hogy kapcsolat nélkül is működjön (erre mindjárt visszatérünk), készítettem egy másolatot a HTML-fájlról, és ezt is az offiine/ alkönytárba tettem. Maga a JavaScript-kód azonban nem változott a helyi tárolás támogatásának hozzáadása óta (lásd a 7. fejezet "A HTML5-tároló működés közben" című részét), ezért ugyanazt a .js fájlt hasznosítjuk újra, amelynek a helye a szülőkönyvtár (examples/). Összefoglalva, a fájlok helye így fest:

/examples/localstorage-halma.html /examples/halma-localstorage.js /examples/offline/halma.manifest /examples/offline/halma.html

A gyorstárjegyzékben (lexampleslofflinelhalma. manifes t) két fájira szeretnénk hivatkozni. Az első a HTML-fájl kapcsolat nélküli változata (lexamplesloffline/

206 J Bontsok a kapcsolatot! 8. fejezet

halma.html), amely a jegyzékfájlban Útvonalelőrag nélkül szerepel, mert a két fájl ugyanabban a könyvtárban található. A második a JavaScript-fájl, amelynek a helye a szülőkönyvrár (lexampleslhalma-localstoragejs), és amelyet a jegyzékben relatív URL-címmel tüntetünk fel (. ./halma-localstoragejs). Pontosan így használjuk az <img src> jellemzőkben is a relatív URL-eket. Ahogy a következő példában Járni fogjuk, (az aktuális tartomány gyökeréből kiinduló) abszolút elérési urakat vagy akár (más tartományok erőforrásaira murató) abszolút URL-eket is használhatunk.

A HTML-fájlhoz hozzá kell adnunk a manifest jellemzőt, amely a jegyzékfájira murat:

<! OOCTYPE html> <htmllang= "en" manifes t= "halma. manifest ">

Ennyi az egész! Amikor egy kapcsolat nélküli működést támogató böngésző először tölti be a kapcsolat nélküli működésre felkészített HTML-oldalt, letölti a hivatkozott jegyzéket, annak alapján pedig a szükséges erőforrásokat, és elraktárazza azokat a kapcsolat nélküli alkalmazás-gyorstárban. Innen kezdve a kapcsolat nélküli alkalmazás algoritmusa veszi át az irányítást, amikor csak betöltjük az oldalt. A játékot így kapcsolat nélkül is játszhatjuk, és mivel az alkalmazás helyben menti a játék állapotát, akkor függesztjük fel, vagy indítjuk újra, amikor csak akarjuk.


Szabványok: • Kapcsolat nélküli webalkalmazások a HTML5-szabványleírásban (http:/1

bit. ly leCk WZa)

A böngészőgyártók dokumentációi: • "Offline resources in Firefox" (https:lldeveloper.mozilla.org/En/Ofjiine_

resources_in_Firefox) a Mozilla Developer Center webhelyén • "HTML5 Offline Application Cache" (http:lldeveloper.apple.comlsaforil

libraryldocumentation/iPhone/Conceptual/Safori]SDatabaseGuide!Offline ApplicationCache!OfjiineApplicationCache.html), a "Safari Client-Side Storage and Offline Applications Programming Guide" (http://developer.apple.com/


saforillibraryldocumentationliPhone/Conceptual!Safori]SDatabaseGuide! !ntroductionl!ntroduction. h tm l} része

Oktatóanyagok és bemutatók: • Andrew Grieve: "G maii for Mobile HTMLS Series: U sing Appeaehe to

Launeh Offiine-part l" (http:!lgooglecode.blogspot.com/2009/04/gmailfor-mobile-html5-series-using. h tm l)

• Andrew Grieve: "G maii for Mobile HTMLS Series: U sing Appcaehe to Launeh Offline-part 2" (http:llgooglecode.blogspot.com/2009/05/gmailfor-mobile-html5-series-part-2.html}

• Andrew Grieve: "G maii for Mobile HTMLS Series: U sing Appeaehe to Launeh Offline-part 3" (http:!lgooglecode.blogspot.com/2009/05/gmailfor-mobile-html5-series-part-3.html)

• Jonathan Shark: "Debugging HTMLS Offline Application Caehe"

(http:lljonathanstark.com/blog/2009/09/27/debugging-html-5-offlineapplication-cachel)

• Paul Ro u get: "An HTMLS offline image editor and u pioader applieation"

(http://hacks. mozilla. orgi201 0/02/an-htm/5-offline-image-editor-anduploader-application/)

9. fejezet

Őrült űrlapok

Ugorjunk fejest!

Mindenki ismeri a webes űrlapokat, nem igaz? Létrehozunk egy <form>

címkét, hozzáadunk néhány <input type= "text"> és talán egy <input

type="password"> elemet, az űrlapot egy <input type="submit">

gombbal tesszük teljessé, és készen is vagyunk. Ez smafu. A HTML5 több mint egy tucat új bevitelielem-típust határoz

meg, amelyeket az űrlapokon használhatunk. Amikor pedig azt mondom, hogy "használhatunk", úgy értem, hogy azon nyomban- mindenféle trükk, szemfényvesztés és kerülő megoldás nélkül. Azért ne örüljünk túlságosan: nem azt akarom mondani, hogy a böngészők kivétel nélkül támogatják is az izgalmas új szolgáltatások mindegyikét. Ó, dehogy. A legkevésbé sem. A legújabb böngészőkben persze hasítani fognak az űrlapjaink, a régi böngészőkben azonban éppen hogy csak működnek majd - hasításról nemigen beszélhetünk. Ami viszont jó hír, hogy ez azt jelenti, hogy az említett szolgá!tatások minden böngészőben elegánsan kapcsolnak alacsonyabb fokozatba. Még az IE 6-ban is.

Helyőrző szöveg

Az első többletszolgáltatás, amellyel a HTML5 kiegészíti a webes űrlapokat,

az a lehetőség, hogy helyőrző szöveget helyezhetünk el a beviteli mezőkben. A helyőrző szöveg addig látható a beviteli mezőben, amíg a mező üres, és

nincs rajta a fókusz. Amint a mezőbe kattintunk (vagy a tabulátorbillentyűvel állítjuk rá a fókuszt), a helyőrző szöveg eltűnik.

Valószínűleg találkoztunk már helyőrző szövegekkel. Ahogy a 9.1. ábrán láthatjuk, a Mozilla Firefox 3.5 például a "Search Bookmarks and History"

9. fejezet Örültűrlapok l 209

(Keresés a könyvjelzők és az előzmények között) szöveget jeleníti meg a címsávban.

l ( Search Bookmorks ond Hístmy ·l

9.1. ábra Helyőrző szöveg a Firefox keresőmezőjében

Ha a címsávra kattintunk (vagy a tabulátorbillentyűvel ráállírjuk a fókuszt), a helyőrző szöveg eltűnik (lásd a 9.2. ábrát).

9.2. ábra A helyőrző szöveg eltűnik, amikor a fókuszt a mezőre visszük

Ironikus módon a Firefox 3.5 azt nem támogatja, hogy a saját webes űrlapjainkat is helyőrző szöveggel lássuk el. C'est la vie. A helyőrző szöveg támogatását a különféle böngészőkben a 9.1. táblázat mutatja.

9.1. táblázat A helyőrzők támogatása

IE Firefox Satari

3.7+ 4.0+

Chrome O

4.0+

Helyőrző szöveget egyébként az alábbi módon szúrhatunk be egy webes űrlapba:

<form>

<input name= "q" placeholde="Search Bookmarks and History"> <input type= "submit" value= "Search">

</form>

A helyőrzőker nem támogató böngészők egyszerűen figyelmen kívül hagyják

a placeholder (helyőrző) jellemzőt.

210 l Örültűrlapok 9. fejezet


Kérdés: A placeholder jellemzőben szerepe/het HTML-kód? Egy képet sze

retnék beszúrni, vagy esetleg megváltoztatnám a színeket.

Válasz: A placeholder jellemző csak szöveget tartalmazhat, HTML

kódot nem. Egyes gyártóknak ugyanakkor vannak saját CSS-bővítményei (http: 1/trac. web kit. o rg/export/3 7527/trunki Layout Tests/fast/forms/

placeholder-pseudo-style.html), amelyek lehetövé teszik, hogy bizonyos böngészőkben formázzuk a helyőrző szöveget.

Automatikus fókuszálású mezők

Sok webhely JavaScript-kód segítségével önműködően a webes űrlapok első beviteli mezőjére állítja a fókuszt. A Google.com nyitóoldala például automati

kusan a keresőmezőre állítja a fókusz t, hogy a kulcsszavakat azonnal beír hassuk, anélkül, hogy előbb a mezőbe kellene vinnünk a kurzort. Ez a legtöbb ernber számára kényelmes, de a gyakorlott felhasználóknak vagy a különleges igényekkel bíró felhasználóknak idegesítő lehet: ha lenyomjuk a szóköz billentyűt, arra számítva, hogy ezzel görgetjük az oldalt, csalódni fogunk, mert

a fókusz már egy űrlapmezőben található, ezért az oldal nem fog lejjebb gördülni. Helyette egy szóközt írunk a beviteli mezőbe. Ha egy másik beviteli rnezőre állítjuk a fókuszt, rniközben az oldal még töltődik, a webhely amofókusz-kezelő parancskódja "segít", és visszateszi a fókuszt az eredeti beviteli mezőbe, amint az oldal teljesen betöltődött, így megszakítja a munkánkat, és rossz helyre fogunk gépelni.

Mivel az automatikus fókuszállítás JavaScript-kód segítségével történik, nehéz lehet rninden szélsőséges esetet kezelni, és nem sok lehetősége marad azoknak, akik nem akarják, hogy a weboldal

"ellopja" a fókuszt.

A probléma megoldására a HTML5 egy autofocus nevű jellemzőt vezet be a webes űrlapok rninden vezérlője számára. Az autofocus jellemző pon

tosan azt teszi, arnire a neve utal: a fókuszt egy adott beviteli mezőre állítja. Mivel azonban ez csak leírókód, és nem parancskód, a viselkedése minden webhelyen azonos. Ezen kívül a böngészőgyártók (illetve a bővítmények készítői) rnódot adhatnak a felhasználóknak az automatikus fókuszálás

9. fejezet Őrültűrlapok l 211

kikapcsolására. Azt, hogy mely böngészők támogatják az automatikus fókuszálást, a 9.2. táblázatban láthatjuk.

9.2. táblázat Az a utofókusz támogatása

IE Flrefox Safarl 4.0+

Így tehetünk egy űrlapmezőt automatikus fókuszálásúvá:

<form>

<input name= "q" autofocus>

<input type= "submit" value= "Search">

</form>

Az autofókuszt nem támogató böngészők egyszerűen figyelmen kívül hagyják az autofocus jellemzőt.

Tessék? Azt szeretnénk, hogy az automatikus fókuszálású mezőink minden böngészőben működjenek, ne csak a csili-vili HTML5-ös böngészőkben? Nos, a régi amofókusz-kezelő parancskódunkat nyugodtan megtarthatjuk, csak két apró változtatást kell végrehajtanunk:

l. Adjuk hozzá az autofocus jellemzőt a HTML-kódhoz. 2. Derítsük ki, hogy a böngésző támogatja-e az autofocus jellemzőt

(lásd az "Automatikus űrlapfókusz" című részt a 2. fejezetben), és csak akkor futtassuk a saját amofókusz-kezelő parancskódunkat, ha a böngészőben nincs beépített támogatás az automatikus fókuszáláshoz:

<form name= "f ">

<input id= •q" autofocus> <script>

if (! ( "autofocus" in document. =eateElement ("input") ) )

document .getElementByld ("q") . focus ();

) </script>

<input type= "submit • value= "Go">

</form>

Ha látni szecetnénk egy példát az autofocus jellemző használarára biztonsági tartalékra való visszakapcsolással együtt, látogassunk el a http:lldiveintohtml5.orglexampleslinput-autofocus-withfallback.html oldalra.



Sok webhely vár a fókusz beállításával, amíg a window.onload ese

mény be nem következik. Ez az esemény azonban addig nem indul el, amíg

valamennyi kép be nem töltődött. Ha az oldalon sok-sok kép található,

a fentihez hasonló naiv parancskód visszaállíthatja a fókuszt a mezőre,

miközben a felhasználó már az oldal másik részén tevékenykedik. (Ezért

utálják a haladó felhasznáJók az aurofókusz-parancskódokat.) A fenti példa

az amofókusz-parancskódot közvetlenül a hivatkozott űrlapmező után

helyezi el, a háttérrendszereink azonban nem biztos, hogy ilyen rugalma

sak. Ha nem tudunk az oldal közepére parancskódot beszúrni, a fó

kuszt a window.onload helyett egy olyan egyéni eseményben kell

beállítanunk, mint a jQuery $ (document). ready () eseménye.

E-mail címek

Több mint egy évtizeden keresztül a webes űrlapok csupán néhány fajta me

zőből álltak. A legelterjedtebbeket a 9.3. táblázat sorolja fel.

9.3. táblázat Bevitelimezö-típusok a HTML4-ben

• n•sfrY .. HYa • • • II' b-!W,.. Me�yzések 1

Jelölőnégyzet

Választógomb

Jelszómező

Lenyíló lista

Fájlválasztó

Elküldö gomb

Egyszerű szövegmező

<input type;"checkbox">

<input type;"radio">

<input type;"password">

<select><option> ...

<input type; "file">

<input type;"submit">

<in�e;"text">

Ki- és bekapcsolható

Más beviteli elemekkel egy csoportba

foglalható

A karaktereket pontokkal (csillagokkal)

helyettesíti, miközben a felhasználó gépel

Egy fájlmegnyitó párbeszédablakot

jelenít meg

A type jellemző elhagyható

A fenti bevitelielem-típusok a HTML5-ben is működnek. Ha az oldalainkat

"előléptetjük HTML5-té" (például a dokumentumtípus módosításával-lásd

9. fejezet Őrült ürlapok l 213

"A dokumentumtípus" cím ű részt a 3. fejezet elején), semmit sem kell változ

tatnunk a webes űrlapjainkon. Éljen a visszirányú megfelelőség! A HTML5 ugyanakkor több új mezőtípust is meghatároz, és nincs rá

okunk, hogy ne kezdjük el használni őket- mindjárt világossá is válik, miért. Az új bevitelielem-típusok közül az elsőt az e-mail címekhez szánták. Így

néz ki:

<form> <input type=" email"> <input type= "submit" value= "'Go">

</form>

Ide egy olyan mondatot akartam írni, ami így kezdődön volna: "Azokban a böngészőkben, amelyek nem támogatják a type="email"-t . .. ".De nem tettem. Hogy miért? Mert nem igazán tudom, mit jelent az, hogy egy böngésző nem támogatja a t y pe= "e ma i l "-t. Minden böngésző támogatja. Lehet, hogy nem csinálnak vele semmi különöset (a type="email" különleges kezelésére hamarosan látunk néhány példát), de azok a böngészők, amelyek nem ismerik fel a type= "email" típusú mezőket, egyszerűen type= "text"

típusúként kezelik őket, és sima szövegmezőként jelenítik meg. Nem tudom eléggé hangsúlyozni, mennyire fontos ez. A Világhálón űr

lapok milliói találhatók, amelyek egy e-mail cím beírását kérik, és mindegyik az <input type="text"> típust használja. Látunk egy szövegmezőt, beírjuk az e-mail címünket a mezőbe, és ennyi. Aztán jön a HTML5, és külön meghatározza a t y pe= "e mai l "-t. Ettől kiakadnak a böngészők? Nem. A Földön minden egyes böngésző type="text"-ként kezeli az ismeretlen type jellemzőket, még az IE 6 is. A webes űrlapjainkat tehát most rögtön

"előléptethetjük" a type= "email" használatára.

És mit jelent az, ha azt mondjuk, hogy egy böngésző támogatja a type=

"email "-t? Nos, ez több dolgot is jelenthet. A HTML5 szabványleírása nem követel meg adott felületeket az új bevitelielem-típusok számára. Az Opera az e-mail címmezőket egy apró e-mail ikonnal jelzi. Más HTML5-képes böngészők, például a Safari vagy a Chrome, egyszerűen szövegmezőként jelenítik meg öket- pontosan úgy, mint a type="text" típusú mezőket -,így a felhasznáJók észre sem veszik a különbséget (hacsak nem tekintik meg az oldal forrását).

Aztán ott van az iPhone.

214 l Őrültűrlapok 9. fejezet

Az iPhone nem rendelkezik fizikai billentyűzetteL A "

gépelés" a képernyőn megjelenő virtuális billentyűzet tapogatásával történik, ami akkor bukkan fel, amikor szükség van rá, például amikor egy űrlapmezőre állítjuk a fókuszt egy weboldalon. Az Apple azonban nagyon ügyes megoldást alkalmaz az iPhone webböngészőjében: a böngésző a HTML5 új bevitelielem-típusai közül többet is felismer, és dinamikusan az adott típusú beviteli mezőhöz igazítja a képernyőn megjelenő billentyűzetet.

Az e-mail címek például szöveges adatok, igaz? Igaz, de különleges szövegek: szinte minden e-mail cím tartalmazza a@ jelet és legalább egy pontot(.), szóközt viszont valószínűleg nem. Amikor tehát egy iPhone-felhasználó egy <input type= "email"> elemre fókuszál, egy olyan billentyűzet jelenik meg a képernyőn, amelyen a szóköz billentyű a szokásosnál kisebb, és külön billentyűk találhatók rajta a @ és . karakterek számára ( lásd a 9.3. ábrát).

Összefoglalva: nincs semmilyen hátránya annak, ha az e-mail címet váró összes űrlapmezőnket máris type= "email" típusúvá alakítjuk. Valószínűleg senki nem fogja észrevenni - talán az iPhone-használókat kivéve (de még ők sem biztos). Akiknek mégis feltűnik, azok csak csendben elmosolyodnak majd, és köszönetet ruandanak nekünk, hogy kicsit kényelmesebbé tettük a Web használatár.

Webcímek

A webcímek - amelyeket sokan URL, a pedánsabbak pedig URI néven ismernek- szintén különleges célú szöveges adatok. A webcímek alakját internetes szabványok szabályozzák. Ha valaki azt kéri, hogy írjunk be egy webcímer egy űrlapra, valami olyasmit vár, mint a http://www.google.com,

nem pedig olyasmit, mint a "125 Farwood Road". Perjelek és a pontok gyak

ran előfordulnak a webcímekben, a szóközök használata azonban tilos. Ezenkívül minden webcím végén áll egy tartomány-utótag, például a ".com" vagy az

".org". És akkor jöjjön az ... (dobpergést kérek) ... <input type="url">! Ez

az elemtípus az iPhone-on úgy fest, mint a 9.4. ábrán.


<form>

<input type="email">

9.3. ábra E-mail címek beírására optimalizált billentyűzet

<form>

<input type="url">

9.4. ábra URL-címek beírására optimalizált billentyűzet


Ahogy az e-mail címer váró mezőkhöz, az iPhone a webcímekhez is optimális virtuális billemyűzetet biztosít. A szóköz billentyű helyét teljes egészében átveszi a pom, a perjel és a ".com" virtuális billemyűje. Ha a ".com" billentyűt

lenyomva tartjuk, más gyakori utótagot - például ".org" vagy ".ner" - is választhatunk.

A HTML5-öt nem támogató böngészők a type="url"-t pomosan úgy kezelik, mint a type= "text "-et, tehát nincs semmilyen hátrányos következménye annak, ha minden webcímer váró mezőhöz a type="url" típust rendeljük.

Számok léptetőmezőkben

Következzenek a számok. Egy számot kérni sok szempomból nehezebb, mim egy e-mail vagy webcímet. Először is, a számok bonyolultabbak, mint azt

gondolnánk. Nézzünk egy gyors példát: válasszunk egy számot. -l? Nem jó, egy l és 10 közötti számra gondoltam. 7 1/2? Nem, nem törtszámot, ugyan már. n? Na, ez már tényleg irracionális.

Azt akarom mondani, hogy általában nem "csak egy számot" kérünk. Valószínűbb, hogy egy adott tartományba eső számot szeretnénk, és azon

belül is csak bizonyos típusú számokat engedünk meg - például az egész számokar igen, de a törteket vagy tizedestörteket nem, vagy esetleg valami egzotikusabbat akarunk, például egy tízzel osztható számot. A HTML5 erre

is gondolt. Nézzünk egy példát:

<input type="number"

min= "0" max="lO"

step= "2" value="6">

Nézzük végig egyenként a jellemzőker (a szöveger követherjük egy "élő" példán is, ha akarjuk):

• A type= "number" azt jelenti, hogy egy számmezőről van szó.

• A m i n= "0" a mezőben elfogadható legkisebb értéket határozza meg. • A max= "10" az elfogadható legnagyobb érték megadására szolgál.

• A step="2" (lépésköz =2) a mi n értékkel kombinálva a O, 2, 4 stb. tartományra korlátozza az elfogadható értékeket, egészen a max értékig.


• A value="6" az alapértelmezett érték. Ennek ismerősnek kell lennie, mert ugyanaz a jellemző, mint amit korábban mindig is használtunk az űrlapmezők értékeinek meghatározására. (Itt azért említem meg, hogy hangsúlyozzam, hogy a HTML5 a HTML előző változataira épül. Tehát amit már tudunk és használunk, azt nem kell újra megtanulnunk.)

Ez a számmezők leírókód része. Ne feledjük, hogy az említett jellemzők egyike sem kötelező. Ha van legkisebb elfogadható érték, de legnagyobb nincs, megadhatjuk csak amin jellemzőt, és elhagyhatjuk a max-ot. Az alapértelmezett lépésköz az l, tehát a step jellemzőt csak akkor kell megadnunk, ha ettől eltérő lépésközt szeretnénk. Ha nincs alapértelmezett érték, a value jellemző értéke lehet egy üres karakterlánc, de teljesen el is hagyhatjuk.

A HTML5 azonban nem éri be ennyivel. Ugyanazon a jutányos ároningyen- az alábbi hasznos JavaScript-tagfüggvényekhez is hozzájutunk: input.stepUp(n)

A mező értékét n-nel növeli.

input. stepDown (n)

A mező értékét n-nel csökkenti. input.valueAsNumber

Az aktuális értéket lebegőpontos számként adja vissza (az input.value

tulajdonság értéke mindig egy karakterlánc).

Nehezen tudjuk magunk elé képzelni? Nos, az, hogy a számbeviteli mezők pontosan hogyan jelennek meg, a böngészőnktől függ, és a különböző böngészőgyártók más-más felülettel valósították meg a számmezők támogatását. Az iPhone-on - ahol a bevitel eleve körülményes - a böngésző megint csak egy másik, ezúttal a számbevitelhez igazított virtuális billentyűzetet jelenít meg (lásd a 9.5. ábrát).


<form>

<input type="number">

9.5. ábra Számok beírására optimalizált billentyűzet

Az Opera asztali rendszerekre Írt változatában ugyanez a type= "number"

mező egy "léptetőmező" (spinbox) formájában jelenik meg, kis lefelé és felfelé mutató nyilakkal, amelyekre kattintva módosíthatjuk az értéket (9.6. ábra).

l si�� <form>

<input type="number"

min="o••

max=" l O"

step="2"

value="6">

9.6. ábra Léptetőmező


Az Opera figyelembe veszi amin, max és step jellemzőket, ezért mindig elfogadható számértéket kapunk. Ha az értéket feltoljuk a maximum ra, a léptetőmező felfelé mutató nyila kiszürkül (9.7. ábra).

L.._ __ 1_,0 l�

9.7. ábra Léptetőmező maximális értéken

Mint minden más bevitelielem-tÍpus esetében, amelyről ebben a fejezetben szó esik, itt is igaz, hogy a type="number"-t nem támogató böngészők az

ilyen típusú mezőket type= "text "-ként kezelik. Az alapértelmezett érték megjelenik a mezőben (mivel a value jellemzőben tárolódik), de a többipéldául amin és amax-jellemzőt a böngésző figyelmen kívül hagyja. Ezeket megvalósíthatjuk magunk, de újrahasznosíthatjuk a léptetőmezőket megvalósító számos JavaScript-keretrendszer egyikét is. Előtte azonban ne felejtsük el az alábbi módon megvizsgálni, hogy a böngészőben van-e beépített HTML5-támogatás (lásd a 2. fejezet "Bevitelielem-tÍpusok" című részét):

if ( !Modernizr. inputtypes. number) { l l nincs beépített támogatás a type: "number" me zök számára

l l esetleg próbáljuk ki a Dojo-t vagy egy másik JavaScript-keretrendszert

J

Számok csúszkákon

A számbevitel ábrázolására nem az előző részben ismertetett léptetőmezők jelentik az egyetlen megoldást. Valószínűleg találkoztunk már olyan "csúszka"

(slider) vezérlőkkel is, mint amilyen a 9.8. ábrán látható.

9.8. ábra Csúszka

Most már a webes űrlapokon is használhatunk csúszkákat. A kód kísértetiesen hasonlít a léptetőmezőkére:

220 l Örült űrlapok 9. fejezet

<input type="range" min�·o" max="lO" ste�"2" value:;:::"6">

A rendelkezésre álló jellemzők ugyanazok, mint a type= "number" esetében

- min, max, step és value -, és a szerepük is ugyanaz. Az egyeden

különséget a felhasználói felület jelenti. A type= "range" típusú vezérlőker a böngészőnek nem olyan mezőként kell megjelenítenie, amelybe írhatunk,

hanem csúszkaként. E könyv írásának idején a Safari, a Chrome és az Opera legújabb változatai mind képesek volrak erre. (Sajnos az iPhone egyszerű szö

vegmezőt jelenít meg, és még a képernyőn megjelenő billentyűzetet sem számbevitelhez igazítja.) Minden más böngésző type= "text" típusúként kezeli a type= "range" mezőket, tehát semmi nem tarthat vissza minket

attól, hogy akár rögtön használatba vegyük őket.

Dátumválaszták

A HTML4-ben nem volt dátumválasztó vezérlő. Ezt a hiányosságat külön

féle JavaScript-keretrendszerekkel- például a Dojo, a j Query UI, a YUI vagy

a Closure Library segítségével - orvosolhattuk, de ezek a megoldások termé

szetesen a dátumválasztót kínáló reljes keretrendszer alkalmazását igényelték.

A HTML5 végre módot ad rá, hogy beépített dátumválasztó vezérlőket

használjunk, és ne kelljen magunknak parancskódokat írnunk. Valójában nem is egy módot, hanem hatot: használhatunk dátumválasztót, hónapvá

lasztót, hétválasztót, időválasztót, dátum- és időválaszrót, illetve dátum-, idő

és időzónaválasztÓL A támogatás azonban jelenleg- amint azt a 9.4. táblázat is szemlélteti

meglehetősen gyér.

9.4. táblázat A dátumválasztó támogatása

Betitelimez�tíous Qoera

type�"date"

type�"month"

9. fejezet

9.0+

9.0+

Minden___másbönaész�

Örült űrlapok l 221

type= "week • 9.0+

type= "time • 9.0+

type= "da tetime • 9.0+

type= "da tetime-local" 9.0+

A 9.9. ábrán azt láthatjuk, hogy az Opera hogyan jelenít meg egy <input type="date"> mezőt. Ha a dátum mellé egy időpontot is szerernénk, az Operában <input type= "da tetime "> mezőket is használharunk (lásd a 9.10. ábrát). Ha csak évet és hónapot szeretnénk választani (például egy hi

telkártya lejárati idejénel megadásához), egy <input type= "month "> típusú mezőre (9.11. ábra) van szükségünk- az Opera ezt is támogatja.

9.9. ábra Dátumválasztó

l 2009-12-25: ... J fGol l� l December 0�

Week lolon Tuo Wed Thu Fri Sat Sun

., 1 � � � � !! I. � l! � 11 g �

.. � � 1!! 1!. � 1l! � .. � � � �

�� ?I.

E 3 � � � � 3

o � 10

Today l None

12009-12-25 .. j�� UTC � �l December L •][2009�

Week Wen Tue Wed Thu Fri S..t S...

! � � � !! !! Z ! �l!!!l!l� ��:!!.!l.!!�� ""-� ll � � � .!! �- 3

-s ;,. 10

Today N�

9.1 0. ábra Dátum- és időválasztó


9.11. ábra Hónapválasztó

j2009-12 :TJ(Go_] G] De<:ember 0J2009J�

Uon Tue Wed Thu Fn Sat St.. � 1 2 3 4 5 6

!. !�� ll g � � � .!.!! !l .!.!! !!! � � � � � � � � � � � � � 3

10

i[ Today No-ne ___ ]

Ritkábban használjuk, de ugyancsak rendelkezésre áll az <input type=

"week"> mező, amellyel az év egy adott hetét választhatjuk ki (lásd a 9.12.

ábrát). Végül, de nem utolsó sorban, egy időpontot is kiválaszthatunk egy <input type="time"> mező segítségéve!; ezt a 9.13. ábra szemlélteti.

9.12. ábra Hétválasztó

9.13. ábra Időválasztó

J2009-W52 l T J � j[ • j -D��- l� JI2009J�

w-

� � 21. � � .!

Uon Tue Wed Tm Fn Sat Sun

.! � � � � � :?. � �!Q.!.!gQ

��.!.!!!l.!.!!!!!� � �� !! " 3

7 � 10

�ay J None J

16:201��

Valószínű, hogy idővel más böngészők is támogatni fogják ezeket a bevitelielem-típusokat, de addig is nyugodtan használhatjuk őket, mert a type=

"email"-hez (lásd a fejezet "E-mail címek" című részét) és más beviteli elemekhez hasonlóan ezeket az űrlapmezőket is egyszerű szövegmezőként jelenítik meg azok a böngészők, amelyek nem ismerik fel a t y pe= "da te "-et és a többi új típust. Ha tetszik, dönthetünk úgy, hogy az <input


type= "date ">-et és társait használjuk, boldoggá téve az Operát használókat, és egyszerűen megvárjuk, amíg a többi böngésző felzárkózik, de azt is megtehetjük, hogy az <input type= "date"> mellett észlelőkódot alkalmazunk, hogy megállapítsuk, hogy a böngésző támogatja-e a dátumválasztókat (lásd a "Bevitelielem-típusok" című részt a 2. fejezetben), és biztonsági tartalékként egy nekünk tetsző parancskódot mellékelünk:

<form>

<input type= "date">

</form>

<script>

var i = docurnent. createElement ("input");

i. setAttribute ("type •, "date");

if (i. type== "text") { l l Nincs beépített dátumválasztó-támogatás : ( l l A Dojo/jQueryUI/YUI/Closure használatával

l l vagy valamilyen más megoldással készítsünk egyet,

l l majd dinamikusan cseréljük le az <input> elemet

) </script>

Keresőmezők

Ez egy kicsit bonyolultabb lesz. Pontosabban, az elv elég egyszerű, de a megvalósírások némi magyarázato t igényelnek. Íme ...

Keresés. Nem csak a Google Search vagy a Yahoo! Search segítségével (persze ezekkel is): gondoljunk egy tetszőleges keresőmezőre egy tetszőleges oldalon, egy tetszőleges webhelyen. Az Amazonnak is van keresőmezője, a Neweggnek is, és a legtöbb blognak is. Hogyan fest a leírókódjuk? Hát így: <input type="text">- olyan, mint minden más szövegmező a Weben, de ezen a HTML5-ben segíthetünk:

<form>

<input name= •q" type=" search">

<input type= "submit" value= "Find ">

</form>

Egyes böngészőkben semmilyen különbséget nem fogunk észrevenni a szokványos szövegmezőkhöz képest. Ha viszont Safarit használunk Mac OS X-en, a mező úgy fog festeni, mint a 9.14. ábrán.


9.14.ábra Keresőmező

®

<form>

<input type•"search">

<input type•"submit" '

</form>

Látjuk a különbséget? A beviteli mezőnek lekerekített sarkai vannak! Tudom, tudom, állati izgalmas! De várjunk csak, tovább is van! Amikor gépelni kezdünk egy type= "search" mezőben, aSafari egy apró "x" gombot szúr be a mező jobb oldalára. Ha az "x"-re kattintunk, a böngésző törli a mező tartalmár. (A Google Chrome, amely a háttérben sok mindenben osztozik a Safarival, szintén így viselkedik.) Mindkét apróság azt a célt szolgálja, hogy a mező úgy nézzen ki és viselkedjen, mint az iTunes és más Mac OS X-ügyfélalkalmazások beépített keresőmezői (lásd a 9.15. ábrát).

foo ®

<form>

<input type•"searcb">

<input type•"submit" '

</form>

9.1 5. ábra Keresőmező fókusszal

Az Apple webhelye is az <input type="search ">kódot használja a webhely keresőmezőjéhez, hogy a webhely "Mac-érzést" nyújtson. A megoldásban azonban nincs semmi, ami csak a Mac sajátja lenne. Az egész csupán leíró kód, tehát minden böngésző minden rendszeren a saját szakásainak megfelelően jelenítheti meg a keresőmezőt. Ezen kívül, mint minden más új bevitelielem-típusnál, a type= "search" kódot nem ismerő böngészők az ilyen mezőket type= "text" típusúként kezelik, vagyis semmi, de semmi okunk arra, hogy ne kezdjük el már ma használni a type= "search" típusú keresőmezőket.



Pomosabban, van egy érv, ami az <input type=" search"> használata ellen szólhat: a Safari a keresőmezőkre nem alkalmazza a szokásos CSS-stílusokat. ("Szokásos stÍlusok" alatt az olyan alapvető dolgo

kat értem, mint a szegély, a háttérszín, a háttérkép, a kitöltés, és így tovább.) Viszont lekerekített sarkokat kapunk!

Színválasztók

A HTML5 az <input type= "color"> mezőtípust is meghatározza, amely egy szín kiválasztását teszi lehetővé, és a választott szín tizenhatos számrend

szerű (hexadecimális) ábrázolását adja vissza. Még egyetlen böngésző sem támogatja, ami szégyen, mert én mindig is imádtam a Mac OS színválasztóját. Talán egyszer.

És még egy dolog ...

Ebben a fejezetben a beviteli elemek új típusait, illetve olyan új szolgáltatásokat mutattam be, mint az automatikus fókuszálású űrlapmezők, de még nem beszéltem arról, ami talán a legizgalmasabb része a HTML5-űrlapoknak: az

automatikus bemenetellenőrzésről. Gondoljunk az e-mail címek bevitelének szokásos problémájára: a webes űrlapokra beírt e-mail címeket valószínűleg valamilyen ügyféloldali JavaScript-kóddal ellenőrizzük, ezt pedig PHP,

Python vagy más kiszolgálóoldali parancsnyelven írt ellenőrzőkód futtatása követi a kiszolgáló oldalán. Az e-mail címekJavaScript-kóddal történő ellenőrzése két nagy buktatót rejt:

• A látogatók közül meglepően sokan nem engedélyezik a JavaScript

kódok futtatását (a Felhasználók mintegy 10 százaléka). • Az ellenőrzést rosszul fogjuk megvalósítani.

Azt, hogy a megvalósításba hiba fog csúszni, a legkomolyabban gondoltam. Azt megállapítani, hogy egy tetszőleges karakterlánc érvényes e-mail cím-e,


hihetetlenül bonyolult (http://www. regular-expressions. info/email. htmf}. Minél közelebbről vizsgáljuk a kérdést, annál bonyolultabb (http://www.ex-parrot. comlpdw/Maii-RFC822-Address.htmf}. Mondtam már, hogy nagyon, nagyon bonyolult (http:l/haacked.com/archive/2007/08/21/i-knew-how-to-validatean-email-address-until-i.aspx)? Nem lenne egyszerűbb megspórol ni a fejfájást, és az egészet a böngészőre bízni?

A 9.16. ábrán látható képernyőfelvétel az Opera 10-ben készült, bár a bemu

tatott szolgáltatás már az Opera 9 óta jelen van a böngészőben. A leírókódban csak annyi kell a működéséhez, hogy a t y pe jellemzőt "email" értéke állírjuk (lásd az "E-mail címek" részt kicsit korábban). Amikor egy Opera-felhasználó egy olyan űrlapot próbál benyújtani, amelyen <input type="email">

mező található, a böngésző automatikusan felajánlja az RFC-megfelelő címellenőrzést, még akkor is, ha a parancskóclak futtatását letiltották.

Az Opera emellett az <input type="url"> mezőkbe írt webcímek és

az <input type= "number"> számmezők érvényességének ellenőrzését is biztosítja. A számellenőrzés során az Opera még a min és max jellemzőket is figyelembe veszi, tehát nem engedi, hogy a felhasználó benyújtsa az űrla

pot, ha például túl nagy számot írt be (lásd a 9.17. ábrát).

IEJtoobar 1 �� too bar is not a legal e-mail address

9.16. ábra E-mail mező ellenőrzése az Operában

1111� rc;o-1 11 is too high. The

highest value you can u se is 1 O.

9.17. ábra Számmező ellenőrzése az Operában

Sajnos még egyetlen más böngésző sem támogatja a HTML5-űrlapellenőrzést, ezért egy ideig még parancskód alapú megoldásokra kell szorítkoznunk.



Szabványok és leírások:

• <input> típusok (http://bit.ly/akweH4) • Az <input placeholder> jellemző (http://bit.ly!caGLBN) • Az <input autofocus> jellemző (http://bit.ly!dbJFj4)

JavaScript-könyvtárak:

• A Modernizr HTML5-észlelő könyvtár (http:l!www.modernizr.com/)

Ugorjunk fejest!

10. fejezet

"Elosztott", "bővíthetőség"

és más divatos szavak

A HTML5-ben 100-nál is több elem található (http://simon.html5.orglhtml5-elements). Találunk közöttük jelenréstükröző elemeket (lásd a 3. fejezetet), míg mások csupán tárolók az oldalon felhasználható API-khoz (lásd a 4. fejezetet). A HTML története során (lásd az l. fejezetet) a szabványügyi bizottságok tagjai mindig is vitatkoztak, hogy mely elemek kerüljenek bele a nyelvbe. Legyen a HTML-ben <figure> elem? Vagy <person> elem? Esetleg <r ant>? Aztán meghozzák a döntést, megírják a szabványokat, a szerzők

szereznek, a megvalósírók megvalósítanak, a Web pedig tovább terjeszkedik. A HTML természetesen nem tehet mindenki kedvére. Erre egyetlen szab

vány sem képes. Egyes ötletek leverik a lécet. A HTML5-ben például nincs <person> elem. (Sőt, <r ant> elem sincs, hogy a fene vinné el!) Semmi nem akadályoz meg minket abban, hogy egy <person> elemet tegyünk egy weboldalra, csak éppen nem számít majd érvényesnek, a működése nem lesz egységes a különböző böngészőkben (lásd a "Hosszú kitérő arról, hogy mikém kezelik a böngészők az ismeretlen elemeket" című részt a 3. fejezetben), és ütközhet a jövőbeli HTML-szabványokkal, ha azokban már esetleg szere

peini fog ez az elem.

Ha viszont a saját elemek létrehozása nem megoldás, mit tehet egy a jelentéstükröző kódra odafigyelő webfejlesztő? A HTML korábbi változatainak bővítésére számos kísérletet tettek. A legnépszerűbbnek a mikroformátumok (http://microformats.org/) alkalmazása bizonyult, amelyek a HTML4-ben a class és rel jellemzökre támaszkodnak. Egy másik megoldást kínál az

RO Fa (http://www. w 3. org!TR/rdfo-syntaxl), amelyet eredetileg az XHTML-ben

10. fejezet ,.Elosztott", ,.bővíthetőség"... l 229

való használatra terveztek (lásd az l. fejezetben az "

Utószó" című részt), de a HTML-re is átültetik.

Mind a mikroformátumoknak, mind az RDFa-nak megvannak a maga előnyei és hátrányai, viszont gyökeresen más módon próbálják elérni ugyanazt a célt: a weboldalak olyan jelentésű elemekkel való bővítésér, amelyek nem képezik részét a HTML nyelv magj ának. Ebben a fejezetben nem szeretnék szenvedélyes vitár nyitni ezekről a formátumokról (ehhez tényleg kellene egy <r ant> elem!), ehelyett inkább egy harmadik lehetőségre összpontosítanék, amely magának a HTML5-nek is szerves része: a mikroadatokra.

Mik azok a mikroadatok?

A következő mondatban minden egyes szó számít, ezért nagyon figyeljünk!


A mikroadatok hatókörrel ellátott, különböző szótárakból származó név-érték párokkal egészítik ki a DOM szerkezetét.

Mit jelent ez? A mikroadatok egyéni szótárakra (custom vocabularies) épülnek.

"Az összes HTML5-elem halmaza" például egy szótár. Ez a szótár ma

gában foglalja a szakaszokat és cikkeket jelölő elemeket (lásd a 3. fejezet "

Új jelentéstükröző elemek a HTML5-ben" című részét), de a személyeket vagy eseményeket leíró elemeker nem. Ha be szeretnénk mutatni egy személyt egy weboldalon, saját szótárat kell meghatároznunk. A mikroadatok ezt teszik lehetövé. Bárki meghatározhat mikroadat-szótárat, és annak segítségével hozzálátha t, hogy egyéni tulajdonságokat ágyazzon be a saját weboldalaiba.

A következő dolog, amit tudnunk kell a mikroadatokról, hogy név-érték párokból állnak. Minden mikroadat-szótár névvel rendelkező (nevesített) tulajdonságok halmazár határozza meg. Egy Person (

"Személy") szótár megha

tározhat például olyan tulajdonságokat, mint a name ("

név") vagy a photo

(,,fénykép"). Egy adott mikroadat-tulajdonság beágyazásához a weboldal egy adott pontján meg kell adnunk a tulajdonság nevét. Azt, hogy milyen módon

230 J .,Elosztott", .,bővíthetőség" ... 10. fejezet

nyerhetjük ki a tulajdonság értékér, a mikroadatok szabályai határozzák meg, attól függően, hogy hol vezetjük be a tulajdonság nevét. (Erről a következő részben bővebben is szót ejtünk.)

A nevesített tulajdonságok mellett a mikroadatok erőteljesen támaszkodnak a "hatókörökre" is. A mikroadatok hatókörét úgy képzelhetjük el a legegyszerűbben, ha a DOM elemei közötti természetes szülő-gyermek kapcsolatokra gondolunk. A <html> elem (lásd a 3. fejezet "A gyökérelem" című részét) általában két gyermekelemet tartalmaz: a <head> (lásd "A <head> elem" cínű részt a 3. fejezetben) és a <body> elemet. A <body> elemnek jellemzően több gyermeke is van, amelyek mindegyikének saját gyermekei lehetnek. Egy oldalunk például tartalmazhat egy <hl> elemet egy <hgroup>

elemen belül, amely egy <header> elemben található (lásd a "Címsorok"

című részt a 3. fejezetben), az pedig a <body> elemben. Ehhez hasonlóan, egy adattáblázat <td> elemeket tartalmazhat <tr> elemeken belül, amelyek pedig egy <table> elemben helyezkednek el (a <body> elemen belül). A mikroadatok magának a DOM-nak a hierarchikus szerkezetét hasznosírják újra, hogy azt mondhassák: "minden tulajdonság, ami ezen az elemen belül

található, ebből a szótárból származik". Ez lehetövé teszi, hogy ugyanazon az oldalon több mikroadat-szótárat is használhassunk. A mikroadat-szótárakat

akár más szótárakba is ágyazhatjuk, az egész láncban a DOM természetes felépítését újrahasznosítva. (Az egymásba ágyazott szótárakra a fejezet során több példát is láthatunk majd.)

Már érintettem a DOM kérdését, de érdemes alaposabban kifejteni. A mikroadatok célja az, hogy kiegészítő jelentéssei lássák el azokat az adatokat, amelyek már amúgy is láthatók a weboldalon. A mikroadatokat tehát nem önálló adatformátumnak szánták, hanem a HTML kiegészítésének. Ahogy a következő részben látni fogjuk, a mikroadatok akkor működnek a legjobban, ha egyébként helyesen használjuk a HTML-t, de a HTML szótárát nem találjuk elég kifejezőnek. A mikroadatok a DOM-ban már szereplő adatok jelentésének finomhangolására alkalmazhatók kiválóan. Ha az adatok, amelyeknek a jelentését körül szetetnénk írni, nem szerepeinek

a DOM-ban, célszerű megvizsgálnunk, hogy valóban a mikroadatok jelentik-e a megoldást.

Most már jobban értjük Leírókód professzor fenti kijelentését? Remélem, igen. Akkor nézzük meg, hogyan is működik mindez a gyakorlatban!

10. fejezet "Elosztott", "bővíthetőség" . . . l 231

A mikroadatok adatmodellje

Saját mikroadat-szótárat meghatározni könnyű. Először is egy névtérre van szükségünk, ami csupán egy URL. A névtér URL-je mutathat például egy működő weboldalra, bár ez szigorúan véve nem kötelező. Tegyük fel, hogy egy olyan mikroadat-szótárat szeretnénk meghatározni, amely egy személyt ír le. Ha a birtokunkban van a data-vocabulary.org tartomány, a mikroadatszótárunk névtereként a http:l!data-vocabulary.org!Person címet használhatjuk. Így egyszerűen létrehozhatunk egy globálisan egyedi azonosítót: csak ki kell választanunk egy URL-t egy olyan tartományból, amelyet mi irányítunk

Ebben a szótárban meg kell határoznunk néhány nevesített tulajdonságot. Kezdjük három alaptulajdonsággal:

• name (a felhasználó teljes neve) • photo (a felhasználó arcképére mutaró hivatkozás) • url (egy a felhasználóhoz társított webhelyre, például egy webnaplóra

vagy Google-profilra mutató hivatkozás)

A fenti tulajdonságok közül kettő URL, a harmadik pedig sima szöveg. Tehát mindegyik egyszerűen ábrázolható leírókóddal; ehhez még nem kell sem mikroadatokat, sem szótárakat használnunk. Tegyük fel, hogy van egy profiloldalunk vagy egy "névjegy" ("about") oldalunk. Ezen a nevünk valószínűleg címsorként, például egy <hl> elemmel jelölve szerepel. A fényképünk feltehetőleg egy <img> elem, mivel azt szeretnénk, hogy mások lássák. Ezen kívül a profilunkhoz társított URL-ekből már nyilván hiperhivatkozásokat hoztunk létre, hiszen azt szeretnénk, hogy a látogatók rájuk kattintsanak. A példa kedvéért tételezzük fel, hogy a teljes profilt egy <section> elembe burkoltuk, hogy elválasszuk az oldaltartalom többi részétől. Így:

<section>

<hl>Mark Pilgrim</hl>

<p><img sr c= "h t tp: l /www. example. com/photo. jpg" alt=" [me smiling] "></p>

<p><ahref="http://diveintomark.org/">weblog</a></p>

</section>

A mikroadatok adarmodelljét a név-érték párok jelentik. Egy mikroadattulajdonság nevét (amilyen a példánkban a name, a photo vagy az url) mindig egy HTML-elemben adjuk meg, a neki megfelelő tulajdonságértéket

232 l ,.Elosztott", ,.bővíthetőség" ... 10. fejezet

pedig az elem DOM-jából olvassuk ki. A legtöbb HTML-elem esetében a tulajdonságérték egyszerűen az elem szövegtartalma. Mindazonáltal - ahogy a 10.1. táblázat is mutatja-ez alól van néhány kivétel.

1 0.1. táblázat Honnan származik a mikroadat-tulajdonságok értéke? ették

<me ta> con ten t iellemző

<audio> sr c jellemző

<embed>

<iframe>

<img>

<source>

<v ideo>

<a> href jellemző

<a re a>

<link>

<object> data jellemző

<L ime> datetime jellemző

Minden más elem Szöve.9.es tartalom

"Mikroadatokat hozzáadni" egy oldalhoz csupán annyiból áll, hogy a már meglevő HTML-elemeket kiegészítjük néhány jellemzőveL Az első teendőnk minden esetben az, hogy egyitemtype jellemző hozzáadásával bejelentjük, hogy melyik mikroadat-szótárat használjuk. A második teendőnk mindig a szótár hatókörének meghatározása egy itemscope jellemzőveL Ebben a példában minden adat, aminek a jelentését le szeretnénk írni, egy <section> elemben található, ezért az itemtype és itemscope jellemzőket ebben a <section> elemben adjuk meg:

<section i temscope i temtype="http: //data-vocabulary. org/Person">

A <section> elemen belül az első adat a nevünk, amelyet egy <hl> elem burkol be. A <hl> elem nem igényel semmilyen különleges feldolgozást, vagyis a 10.1. táblázat "Minden más elem" szabálya alá tartozik, amelynél a mikroadattulajdonság értéke egyszerűen az elem szövegtartalma (a dolog ugyanilyen jól működik, ha a nevünket egy <p>, <div> vagy <span> elembe burkoljuk):

<hl itemprop="name">Mark Pilgrim</hl>

10. fejezet "Elosztott", "bővíthetőség"... l 233

Ez magyarul annyit tesz, hogy "Íme a http://data-vocabulary.org/

Person szótár name tulajdonsága. A tulajdonság értéke Mark Pilgrim."

A következő a photo tulajdonság, amelynek elvileg egy URL-nek kell lennie. A 10.1. táblázat szerint az <img> elemek "értékér

" az src jellemző

jükben találjuk. Nézzenek oda, hiszen a profilfotónk URL-je már egy <img

src> jellemzőben található! Mindössze annyit kell tennünk, hogy bejelentjük, hogy az <img> elem a photo tulajdonság:

<p><img itemprop="photo" src= "h t tp: l /www. example. com/photo. jpg"

al t=" [mosolygok) "></p>


Person szótár photo tulajdonsága. A tulajdonság értéke http://www.

example. com/ photo .jpg.".

Végül, az url tulajdonság szintén egy URL. A 10.1. táblázat szerím az <a> elemek "értékér

" a href jellemzőjükben találjuk. Ez ismét csak tökéle

tesen illeszkedik a meglevő kódunkhoz, hiszen csak annyit kell tennünk, hogy azt mondjuk, hogy a meglevő <a> elem az url tulajdonság:

<a itemprop="url" href= "h t tp: l /diveintomark. org/ ">dive in to mark</ a>


Person szótár url tulajdonsága. A tulajdonság értéke http://diveinto

mark.org/."

Természetesen ha a leírókódunk némileg különbözik, az nem jelent gondot. Mikroadat-tulajdonságokat és -értékeket tetszőleges HTML-kódhoz hozzáadhatunk, még az igazán durva, XX. századi, táblázatokkal formázott, "Ó, istenem, miért is vállaltam el a karbantartását?

" sóhajt kiváltó HTML

oldalakhoz is. Én ugyan nem ajánlom, hogy az alábbihoz hasonló kódot használjunk, de attól még mindig meglehetősen elterjedt - és nyugodtan kiegészíthetjük mikroadatokkal:

<TABLE>

<TR><TD>Name<TD>Mark Pilgrim

<TR><TD>Link<TD>

<A href=# onclick=goExternalLink () >http: l /diveintomark. org/</A>

</TABLE>

A name tulajdonság megjelöléséhez csak annyit kell tennünk, hogy hozzáadunk egy i temprop jellemzőt a nevet tartalmazó táblázatcellához. A táb-

234 l "Elosztott", "bővíthetőség" ... 10. fejezet

lázatcellákra nem vonatkoznak különleges szabályok, ezért a mikroadatok az alapértelmezett értéket kapják, tehát a mikroadat értéke az elem szövegtartalma lesz:

<TR><TD>Name<TD itemprop="name">Mark Pilgrim

Az url tulajdonság hozzáadása bonyolulrabbnak látszik, a kódunk ugyanis nem megfelelően használja az <a> elemet: ahelyett, hogy a hivatkozás célját a href jellemzőben helyezné el, a href jellemzőben semmi hasznosat nem tartalmaz, inkább az onclick jellemzőbe tett JavaScript-kód segítségével hív meg egy függvényt (ami itt nem szerepel), amely kinyeri az URL-t, és a benne levő címre ugrik. "Ó, a francba, ne már!" bónuszpontokért tegyünk úgy, mintha a függvény a hivatkozott oldalt ráadásul egy apró, gördítősávok nélküli előugró ablakban nyitná meg. Ugye milyen vicces volt az Internet a múlt században?

Ettől függetlenül azért mikroadat-rulajdonsággá alakíthatjuk a kódunkat, csak egy kicsit kreatívnak kell lennünk. Az <a> elem közvetlen használatát kizárhatjuk A hivatkozás célja nem a href jellemzőben található, és nincs rá mód, hogy felülbíráljuk a szabályt, amely kimondja, hogy

"egy <a> elem

ben a mikroadat-tulajdonság értéket a href jellemzőben kell keresni". Viszont azt megtehetjük, hogy egy burkolóelembe ágyazzuk az egész katyvaszt, és ennek a segítségével adjuk meg az url mikroadat-tulajdonságot:

<TABLE i temscope i temtype= "http: l ldata-vocabulary. orgiPerson ">

<TR><TD>Name<TD>Mark Pilgrim

<TR><TD>Link<TD>

<span itemprop= "url">

<A href=# onclick=goExternalLink () >http: l ldi veintomark. orgi<IA>

<lspan>

<ITABLE>

Mivel a <span> elem nem igényel semmilyen különleges feldolgozást, az alapértelmezett szabály vonatkozik rá, amely szerint

"a mikroadat-tulajdonság

értéke a szövegtartalom". A "

szövegtartalom" ugyanakkor nem "

az adott elemen belül található összes leírókódot" jelenti (mint mondjuk az innerHTML

DOM-tulajdonság esetében), hanem csupán annyit tesz: "

csak a szöveget, asszonyom". Esetünkben a <span> elemen belül található <a> elem szövegtartalma a http://diveintomark.org/ cím.

Összefoglalva: mikroadat-tulajdonságokat bármilyen leírókódhoz hozzáadhatunk, de könnyebbnek fogjuk találni, ha helyesen használjuk a HTML-r.

10. fejezet .,Elosztott", .,bővíthetőség"... l 235

Személyek felcímkézése

Az előző részben szereplő bevezető példák nem voltak teljesen légből kapottak: valóban létezik mikroadat-szórár a személyekhez kapcsolódó adatok megjelölésére, és valóban ilyen egyszerű a használata. Nézzük meg közelebbről!

Mikroadatokat a legkönnyebben a "névjegyoldalunkon" ("About") ágyazharunk be a személyes webhelyünkbe. Ugye van "About" oldalunk? Ha nincs,

kövessük azt, ahogy a http:!ldiveintohtml5.orglexampleslperson.html címen található mintaoldalt bővítettem jelentéstükröző elemekkeL A végered

mény a http://diveintohtml5.orglexampleslperson-plus-microdata.html címen

tekinthető meg. Először vessünk egy pillantást a nyers leírókódra, bármilyen mikroadat

rulajdonság hozzáadása előtt:

<section>

<img wid th= "204" height= "250"

src="http://diveintohtml 5.org/examples/2000_05_mark.jpg "

alt=" [Mark Pilgrim, ci r ca 200 0 l ">

<hl>Contact Information</hl>

<dl>

<dt>Name</dt>

<dd>Mark Pilgrim</ dd>

<dt>Position</dt>

<dd>Developer advocate for Google, Inc. <Idd>

<dt>Mailing address</dt>

<dd>

1 00Main Street<br>

Anytown, PA 19999<br>

USA

</dd>

</dl>

<hl>My Digital Footprints</hl>

<ul>

<li><a href= "http: l /diveintomark. org/ ">weblog</a></li>

<li>< a href= "h t tp: l /www. google. com/profiles/pilgrim ">Google prof ile</

a></li>

<li><a href= "h t tp: l /www. reddit. com/user/MarkPilgrim ">Reddit. com

profile</a></li>

<li><a href= "http: l /www. twitter. com/diveintomark ">Twitter</a></li>

</ul>

</section>


Az első teendőnk minden esetben az, hogy bejelentjük, hogy milyen szótárat használunk, és megadjuk a hozzáadni kívánt tulajdonságok hatókörét. Ezt úgy tehetjük meg, hogy hozzáadjuk az itemtype és itemscope jellemzőket a tényleges adatokat tartalmazó elemeket magába foglaló legkülső elemhez. Ez a mi esetünkben egy <section> elem:

<section i temscope itemtype="http: l /data-vocabulary. org/Person">

� � Az itt végrehajtott változtatásokat az Interneten is nyomon követhetjük. Előtte: http:!ldiveintohtml5.orglexampleslperson.html. Utána: http://diveintohtmi5. orglexampleslperson-plus-microdata. h tm l.

Most már nekiállhatunk meghatározni a http://data-vocabulary.org/

Person szótár mikroadat-tulajdonságait. De mik is ezek a tulajdonságok? Nos, a tulajdonságok listáját történetesen megtekinrhetjük, ha ellátogarunk a http:!ldata-vocabulary.org/Person címre. A mikroadatok szabványleírása ezt nem követeli meg, de én feltétlenül "ajánlott eljárásnak" tekintem. Végtére is, ha azt szeretnénk, hogy a fejlesztök valóban használják is a mikroadat-szótárunkat, akkor valahogy dokumentálnunk kell azt. És hol lenne jobb helye ennek a dokumentációnak, mint magának a szótárnak az URL-címén? A Person (Személy) szótár tulajdonságait a 10.2. táblázatban láthatjuk.

1 0.2. táblázat A Person szótár

Leírás

name Név

nickname Becenév

photo Képhivatkozás

ti tle A személy beosztása (például .gazdasági igazgató")

ro le A személy munkaköre (például.könyvelö")

url Weboldal ra, például az illetö honlapjára mutató hivatkozás

af fi l i a t ion Annak a szervezetnek!cégnek a neve, ahová az ille tó tartozik (például alkalmazottként)

fr i end Egy társas kapcsolatot azonosít az adott és egy másik személy között (barát)

con t act Egy társas kapcsolatot azonosít az adott és egy másik személy között (üzletfél)

acquaintance Egy társas kapcsolatot azonosít az adott és egy másik személy között (ismerös)

address Az illetö címe (olyan résztulajdonságai lehetnek, mint a street-address, a loea

li ty, a reg ion, a postal-code és a country-name, vagyis utca, helység,

körzet!állam/megye, postai irányítószám és ország)

10. fejezet "Elosztott", "

bővíthetőség" ... l 237

A személyes adatoknak ezen a mintaoldalán elsőként egy kép szerepel rólam, amit természetesen egy <img> elemmel címkéztem fel. Ahhoz, hogy bejelentsem, hogy ez az <img> elem az én profilképem, csak annyit kellett tennem, hogy hozzáadtam az i temprop= "photo" jellemzőt:

<img itemprop="photo" width= "204" height= "250" src="http:/ /diveintohtml5.org/examples/2000_05_mark.jpg" alt=" [Mark Pilgrim, circa 200 0] ">

Hol találjuk a mikroadat-tulajdonság értékér? Már ott van, az src jellemzőben. A 10.1. táblázatból emlékezhetünk rá, hogy az <img> elemek "értékér"

az src jellemzőjük adja meg. Minden <img> elemnek van src (forrás) jel

lemzője - különben a képet nem lehetne megjeleníteni -, és a forrás mindig egy URL. Látjuk? Ha a HTML-t helyesen használjuk, a mikroadatok használata is egyszerű.

Ezenkívül az említett <img> elem nem önmagában árválkodik az oldalon, hanem annak a <section> elemnek a gyermeke, amelyet az imént az itemscope jellemzővel vezettünk be. A mikroadatok az oldal elemeinek

szülő-gyermek kapcsolatait hasznosítják újra a mikroadat-tulajdonságok hatókörének meghatározásához. Hétköznapi nyelven, ezt mondjuk: "Ez a <section> elem egy személye ábrázol. Minden mikroadat-tulajdonság, amelyet a <section> elem gyermekeiben találunk, ennek a személynek egy

egy tulajdonsága.". Ha az segít, a <section> elemre gondolhatunk úgy is,

mint egy mondat alanyára. Az i temprop jellemző a mondat állítmányavalami olyasmi, mint az alábbi példában a "látható" - a mondat tárgya pedig

a mikroadat-tulajdonság értéke:

Ez a személy [közvetlenül a <sect ion item s cope itemtype=" ... ">-ból] ezen a képen látható: [közvetlenül az <img itemprop="photo">-ból] http: l /diveintohtml5 .org/ex a mples/2000 05 m ark .jpg [közvetve, az <img src> jellemzőből]

Az alanye csak egyszer kell meghatározni, az itemscope és i temtype jellemzőket a legkülső <section> elemhez adva, az állítmányt pedig az i temprop= "photo" jellemzőt az <img> elemhez adva határozzuk meg.

A mondat tárgya nem igényel semmilyen különleges leírókódot, mert a 10.1.

táblázat azt mondja, hogy egy <img> elem tulajdonságértéke az elem src

jellemző je.


A kódban tovább haladva egy <hl> címsort láthatunk, valamint egy <dl>

lista elejét. Sem a <hl>, sem a <dl> elemet nem szükséges mikroadatokkal kiegészítenünk. Nem minden HTML-részlemek kell mikroadat-tulajdonságnak lennie. A mikroadatok lényegér maguk a tulajdonságok jelentik, nem az

azokat körülvevő Ieírókóclok vagy címsorok. Az említett <hl> elem nem tulajdonság, csupán egy címsor, és ugyanígy a "Name

" <dt> elem is csak egy

szövegcímke:

<hl>Contactinformation</hl> <dl>

<dt>Name</dt>

<dd>Mark Pilgrim</ dd>

Hol van tehát az igazi információ? A <dd> elemben, tehát ide kell tennünk

az i temprop jellemzőt. Melyik tulajdonságról van szó? A name tulajdonságróL Mi ennek a tulajdonságnak az értéke? A <dd> elemben található szö

veg. Kell külön jelölnünk valamit? A 10.1. táblázat azt mondja, hogy nem:

a <dd> elemek nem igényelnek különleges feldolgozást, tehát a tulajdonság értéke egyszerűen az elemben található szöveg:

<dd itemprop="name">Mark Pilgrim</ dd>

Ezt hogyan is fogalmazhatjuk meg hétköznapi nyelven? "Ennek a személynek a neve Mark Pilgrim.

" Akkor jó. Tovább.

A következő két tulajdonság kicsit nehezebb. A kód ez volt a mikroadatok

hozzáadása előtt:

<dt>Position</dt>

<dd>Developer advocate for Google, Inc.</dd>

Ha megnézzük a Person szótár meghatározását, a "Developer advocate for

Google, Inc."

szöveg valójában két tulajdonságból áll: a beosztásból (title:

"Developer advocate") és a szervezet nevéből (affiliation: "Google, Inc.

").

Hogyan fejezhetjük ki ezt mikroadatokkal? A válasz röviden: sehogy. A mikro

adatok nem adnak módot arra, hogy szövegfolyamokat önálló tulajdonságokra bomsunk fel. Nem mondhatjuk azt, hogy "ennek a szövegnek az első

18 karaktere egy mikroadat-tulajdonság, az utolsó 12 karaktere pedig egy másik mikroadat-tulajdonság

".

Mindazonáltal nincs minden veszve. Tegyük fel, hogy a "Developer advocate

" szöveget más betűtípussal szeretnénk formázni, mint a "Google,


Inc." szövegrészt. Erre a CSS sem képes. Mit tehetünk hát? Először olyan

álelemekbe kell burkolnunk az egyes szövegrészeket, mint a <span>, majd

különböző CSS-stílusokat kell alkalmaznunk az egyes <span> elemekre. Ez a módszer a mikroadatoknál is működik. A példánkban kétféle infor

mációt kell kezelnünk: a title és az affiliation tulajdonságokat. Ha

mindkettőt egy-egy <span> álelembe burkoljuk, megadhatjuk, hogy az egyes

<span> elemek önálló mikroadat-tulajdonságok:

<dt>Position</dt> <dd><span itemprop="title">Developer advocate</span> for

<span i temprop="affiliation">Google, Inc. <span>< l dd>

Csiribú-csiribá! A fenti kód magyarul annyit tesz, hogy "

Ennek a személynek a beosztása

"Developer advocate". Ez a személy a

"Google, Inc." alkalmazásában

áll." Két mondat, két mikroadat-tulajdonság. Egy kicsivel több kód, de megéri.

Ugyanezt a megoldást a postai címeknél is alkalmazhatjuk. A Person szótár meghatároz egy address (cím) tulajdonságot, amely maga is egy mikro

adat. Ez azt jelenti, hogy a címnek is megvan a saját szótára (http:!ldata-vocabulary.org!Address), és saját tulajdonságokat- street-address, local it y,

region, postal-code és country-name- határoz meg.

Ha programozók vagyunk, valószínűleg ismerjük az objektumok és azok

tulajdonságainak "

pont jelöléssel" történő meghatározását. Az objektumok

közötti kapcsolatokra gondoljunk így:

• Person

• Person.address

• Person.address.street-address

• Person.address.locality

• Person.address.region

• Person.address.postal-code

• Person.address.country-name

Ebben a példában az utcát és a házszámot (street-address) egyetlen <dd>

elem tartalmazza. (Még egyszer: a <d t> elem csak egy címke, így nem játszik

szerepet a kód jelentésének mikroadatokkal történő bővítésében.) Az address

tulajdonság megadása egyszerű: csak hozzá kell adnunk egy i temprop jellem

zőt a <dd> elemhez:

<dt>Mailing address</dt> <dd itemprop="address">


Ne feledjük azonban, hogy maga az address tulajdonság is egy mikroadat.

Ez azt jelenti, hogy az itemscope és itemtype jellemzőket is hozzá kell adnunk:

<dt>Mailing address</dt>

<dd itemprop= "address" i temscope

itemtype="http://data-vocabulary.org/Address">

Mindezt már korábban is láttuk, de csak a legfelső szintű elemeknéL Egy

<section> elem határozza meg az itemscope és i temtype jellemzőket, és a <section> elemben található minden mikroadat-tulajdonságokat meg

határozó elem a megadott szótár "hatókörébe"

tartozik. Ez az első eset azon

ban, hogy egymásba ágyazott hatóköröket látunk: egy új elemtípust és -hatókört (itemscope és itemtype) határozunk meg (a <dd> elemre) egy meglevő elemtípuson és -hatókörön (a <section> elemén) belül. Az egymásba ágya

zott hatákörök pontosan ugyanúgy működnek, mint a HTML DOM. A <dd>

elem mindegyik gyermekeleme a <dd> elemnél megadott szótár hatókörébe

tartozik. Amint a <dd> elemet lezárjuk a hozzá tartozó </dd> címkével,

visszatérünk a szülőelem (esetünkben a <section>) szótárához. Az Address (Cím) szótár tulajdonságai ugyanazt a problémát vetik fel,

mint amit a tit le és a ff iliation tulajdonságok: csak egy hosszú szöveg

folyamunk van, amit viszont több önálló mikroadat-tulajdonságra szeretnénk

felbontani. A megoldás is ugyanaz: az egyes információkat egy-egy <span>

áldembe burkoljuk, majd ezekben a <span> elemekben egyesével bevezet

jük a mikroadat-tulajdonságokat:

<dd i temprop= "address " i t emseope


<span itemprop="street-adclress">lOO Main Street</span><br>

<span itemprop="locality" >Anytown</span>,

<span i temprop=" reg ion"> PA< l span>

<span itemprop="postal-code" >19999</span>

<span i temprop=" country-name">USA</ span>

</dd>

</dl>

Ez magyarul annyit tesz, hogy "Ennek a személynek van egy levelezési címe. A levelezési címben az utca és a házszám "100 Main Street

", a helység

" Anytown", az állam "PA'', a postai irányítószám "19999'', az országnév pedig

"USA''. Egyszerűbb már nem is lehetne.

10. fejezet "Elosztott", "bővíthetőség" ... l 241


Kérdés: A fenti címformdtum csak az Egyesült Államokra vonatkozik? Válasz: Nem. Az Address szótár tulajdonságai elég általánosak ahhoz, hogy a legtöbb címer képesek legyenek leírni a világon. Nem minden címben lesz értéke minden egyes tulajdonságnak, de ezzel nincs gond. Egyes címek megkövetel hetik, hogy egyetlen tulajdonságba egynél több "sort" gyömöszöljünk, de ez is rendben van. Ha a levelezési címben például utca, házszám és lakásszám is található, mindhárom a street

address résztulajdonságba kerül: <p i temprop=" address" i t emseope


<span i temprop=" street -address">

100Main Street Sui te 415

</span>

</p>

A minta-névjegyoldalunkon még egy dolog található: egy URL-lista. A Person szótár erre is tartalmaz egy tulajdonságot: az url-t. Az url tulajdonság bármi lehetne (persze egy URL-nek kell lennie, de ezt valószínűleg kitaláltuk)- úgy értem, az url tulajdonság meghatározása nagyon tág. A tulajdonság értéke bármilyen fajta URL lehet, amit egy személyhez társíthatunk: egy webnapló vagy egy fotógaléria címe, vagy egy profilé egy másik webhelyen, például a Facebookon vagy a T witteren.

A másik lényeges dolog, amit meg kell jegyeznünk, hogy egyeden személynek több url tulajdonsága is lehet. Elvileg bármelyik tulajdonság szerepelhet többször, de ennek eddig nem használtuk ki az előnyeit. Lehet például két photo

tulajdonságunk, amelyek különböző képek URL-jére mutatnak. Itt négy URLcímer szeretnék felsorolni: a webnaplómét, a Google-profiloldalamét, a Redditfelhasználói profilomét és a T witter-fiókomét. A HTML-ben ez egy hivatkozáslis ra: négy <a> elem, amelyek egy-egy önálló <li> elemben találhatók. Mikroadatként mindegyik <a> elem egy itemprop="url" jellemzőt kap:

<hl>My Digital Footprints</hl>

<ul>

<li><a href= "http: l /diveintomark. org/"

itemprop="url">weblog</a></li>

<li><a href= "http: l /www. google. com/profiles/pilgrim"

242 l "

Elosztott", "bővíthetőség" ... 10. fejezet

itemprop="url">Google profile</a></li>

<li><a href; "http: l /www. reddit. com/user/MarkPilgrim"

i temprop="url">Reddi t. com profile</a></ li>

<li><ahref;"http://www.twitter.com/diveintomark"

itemprop="url">Twitter</a></li>

</ul>

A 10.1. táblázat szerint az <a> elemek különleges feldolgozást igényelnek. A mikroadat-tulajdonság értéke a href jellemző, nem a szövegtartalom. Az egyes hivatkozások szövegét a mikroadat-feldolgozó valójában figyelmen kívül hagyja. A fenti kód tehát magyarul annyit tesz, hogy "Ehhez a személyhez kapcsolódik a http://diveintomark.org/ URL, valamint a http://www.google. comlpro.fileslpilgrim/ URL, valamint a http:llwww.reddit.com/user/MarkPilgrim URL, illetve a http://www.twitter.com/diveintomark URL.

Bemutatkozik a Google Rich Snippets

Egy pillanatra szeretnénk visszalépni egy kicsit, és feltenni a kérdést: "Miért is csináljuk ezt?". Csak azért adunk jelentéstükröző elemeket a kódhoz, hogy legyenek benne ilyen elemek? Nem szeretném, ha bárki félreértene: mint minden webfejlesztő, én is szeretek csúcsos zárójelekkel játszani. De miért pont mikroadarokkal? Miért fontos ez?

Két fő alkalmazástípus létezik, amely HTML-t és így HTMLS-mikroadatokat is fogyaszt:

• a webböngészők és • a keresőmotorok.

A böngészők számára a HTMLS különféle DOM-függvényeket határoz meg a mikroadatok, tulajdonságok és tulajdonságértékek kinyerésére a weboldalakbóL Jelen könyv írása idején azonban még egyetlen böngésző sem támogatja ezt az API-t. Egyetlen egy sem. Így ez egyfajta zsákutca, legalábbis amíg a böngészők fel nem zárkóznak, és meg nem valósítják az ügyféloldali API-t.

A HTML-fogyasztók másik nagy csoportját a keresőmororok jelentik. Mit tehet egy kereső egy személyhez kapcsolódó mikroadat-tulajdonságokkal? Képzeljük magunk elé ezt: a kereső ahelyett, hogy egyszerűen az oldal címét és egy részletet jelenítene meg az oldal szövegéből, beágyaz néhányat ezek közül a strukturált információk közül is: a személy reljes nevét, beosztását,

10. fejezet "Elosztott", "bővíthetőség" ... \ 243

munkálrarójár, címér, esetleg a profilforója miniarűrjér. Ez felkeltené az érdeklődésünket? Az enyémet biztosan.

A Google a Rich Snippers programja részekém támogatja a mikroadarokar

(http:llwww.google.com/supportlwebmasterslbin/answers.py?hl=en&answer= 99170).

Amikor a Google webes keresőpókja feldolgozza az oldalunkar, és olyan mikroadar-rulajdonságokar talál, amelyek megfelelnek a h t t p: l l da ta

vocabulary. or g /Person szórárnak, kigyűjri ezeker a tulajdonságokat, és elrakrározza azokar az oldal többi adarával együtt. A Google még egy olyan hasznos eszközt is biztosít, amely megmutatja, hogy a Google hogyan "látja"

a mikroadar-rulajdonságainkar. Ha kipróbáljuk a mikroadarokkal ellátorr minra-névjegyoldalunkon (http:lldiveintohtml5.o rglexampleslperso n-plusmicrodata.htmf), ezt a kimeneter kapjuk:

It em

Type: http://data-vocabulary.org/person photo� http: l /dlvelntohtml5 .org/examples/2000 _0 5_ mark. jpg

name� Mark Pilgrim title � Developer advocate

affiliation � Google, Inc. address � Item ( l )

url� http: l /diveintomark. org/

url � http: l /www. google. com/profiles/pilgrim

url� h t tp: l /www. reddit. com/user/MarkPilgrim

url� h t tp: l /www. twitter. com/diveintemark

Item l

Type: http://data-vocabulary.org/address

street-address� 100Main Street

locality � Anytown

region �PA

postal-code � 19999 country-name �USA

Orr van minden: a photo tulajdonság az <img src> jellemzőből, mind a négy URL az <a href> jellemzők lisrájából, sőt még a címobjektum (minr

"Irem l") és annak mind az öt résztulajdonsága is. Hogyan hasznosítja a Google ezeker az információkat? Arról függ. Nin

csenek kőbe véserr szabályok arra nézve, hogy mikénr kell megjeleníteni a mikroadat-rulajdonságokat, hogy mely tulajdonságokar kell megjeleníteni, vagy hogy egyáltalán meg kell-e jeleníteni őket. Ha valaki a "Mark Pilgrim"

nevet keresi, és a Google arra a következtetésre jut, hogy a névjegyoldalunknak szerepelnie kell az eredmények között, és a Google úgy dönt, hogy az


oldalon talált mikroadat-tulajdonságokat érdemes megjeleníteni, akkor a ke

resés eredménye valahogy úgy fog kinézni, mint a 10.1. ábrán.

About Mark Pilgrim Anytown PA- Developer advocate- Google, Inc. Excerpt from the page will show up here. Excerpt from the page will show up here. diveintohtml5.org/examples/person-plus-microdata.html - Cached - Similar pages

l O. l. ábra Példa egy mikroadatokkal kiegészített személyes oldal keresésének eredményére

Az első sor-"

About Mark Pilgrim"- igazából az oldal címe, amit a <ti tle>

elem ad meg. Ez nem túl izgalmas - a Google minden oldal címét megjele

níti. A második sor azonban már tele van olyan információkkal, amelyek

közvetlenül az oldalhoz fűzött mikroadatokból származnak. Az "

Anytown

PA" az oldalon a levelezési cím részeként szerepelt, amelyet a h t tp: l ldata

vocabulary. orgiAddress szótár segítségével jelöltünk meg, a "

Developer

advocate" és a "

Google, Inc." pedig a http:lldata-vocabulary.orgl

Person szótár két tulajdonsága (title és aff iliation) .

Ez az, ami igazán lenyűgöző: nem kell tekintélyes, a keresőprogramok

gyártóival egyedi szerződésben álló cégnek lennünk ahhoz, hogy testreszabjuk

a keresési eredményeket- elég rászánnunk tíz percer, és hozzáadnunk néhány

HTML-jellemzőt az egyébkém is közzérenni kívánt adarokhoz.


Kérdés: Mindent úgy csináltam, ahogy itt szerepelt, a Google-ben mégis ugyanazt az eredményoldalt kaptam kereséskor, mint korábban. Mit csinálok rosszul? Válasz: "A Google nem garantálja az adott oldalakon vagy webhelyeken

szereplő Ieírókóclok felhasználását a keresési eredményekben" (http:/1 www.google.com/supportlwebmasterslbinlanswer.py?hl=en&answer=99170). Mindazonáltal az, hogy a Google nem használja fel az oldalunkhoz fű

zött mikroadarokat, még nem jelenti azt, hogy más keresők sem fog

ják. A HTML5 többi részéhez hasonlóan a mikroadatok is nyílt szab

ványnak számítanak, amelyet bárki megvalósírhar. A mi feladatunk az,

hogy annyi adatot adjunk meg, amennyit csak tudunk - a világ pedig

eldönrheti, hogy mit kezd velük. Csak meg ne lepődjünk!


Szervezetek felcímkézése

A mikroadatok nem korlátozódnak egyetlen szótárra. Egy "névjegyoldal"

hasznos, de valószínűleg csak eggyel rendelkezünk belőle. T öbbet szeretnénk? Tanuljuk meg, hogy címkézhetünk fel cégeket és szervezeteket!

Készítettem egy üzleti mintaoldalt (http:lldiveintohtml5.orglexampleslorganization.html); nézzük is meg az eredeti HTML-kódot, mikroadatok nélkül:

<article>

<hl>Google, Inc.</hl>

<p>

1600 Amphitheatre Parkway<br>

Mountain View, CA 94043<br>

USA

</p>

<p>650-253-0000</p>

<p><a href="http://www.google.com/">Google.com</a></p>

</article>

�Az itt végrehajtott változtatásokat az Interneten is nyomon kö

vethetjük. Előtte: http://diveintohtml5.orglexamples/organization.html. U tán a: h ttp:/1 diveintoh tm/5. orglexamples/ organization-plus -microdata.

h tm l.

A kód bájosan rövid. A szervezettel kapcsolatos összes információt az <article>

elem tartalmazza, ezért kezdjük itt:

<article i temscope i temtype= "http: l /data-vocabulary. org/Organization ">

Ahogy a személyek felcímkézésénél, itt is hozzá kell adnunk az itemtype

és itemscope jellemzőket a legkülső elemhez, ami a mi esetünkben egy <article> elem. Az itemtype jellemző a használt mikroadat-szótárat (http://data-vocabulary.org/Organization) adja meg, míg az itern

scope jellemző azt, hogy a gyermekelemekre beállított minden tulajdonság ebből a szótárból származik.

De mi van az Organization (Szervezet) szótárban? Nos, ez a szótár nagyon

egyszerű, sőt egy részének már ismerősnek kell lenn ie. A lényeges tulajdonságokat a 10.3. táblázatban láthatjuk.


name A szervezet neve (például.,lnitech")

url A szervezet webhelyére mutató hivatkozás

address A szervezet címe. Olyan résztulajdonságokat tartalmazhat, mint a s tr ee t-

tel

g eo

address, a loeali ty, a regio n, a postal-code és a country-name.

A szervezet telefonszáma

A cím földrajzi koordinátái. Mindig két résztulajdonságot-lati tude és

longi tude, vagyis szélességi és hosszúsági fok- tartalmaz.

A legkülső <ar ticle> elemen belül az első kódcímke egy <hl> elem. Ez a <hl> elem egy cég nevét tartalmazza, ezért közvetlen ül egy i temprop= "name"

jellemzővel látjuk el:

<hl itemprop="name">Google, Inc. </hl>

A 10.1. táblázat szerint a <hl> elemek nem igényelnek semmilyen különleges feldolgozást. A mikroadat-tulajdonság értéke egyszerűen a <hl> elem szövegtartalma. Ez magyarul annyit tesz, hogy az imént ennyit mondtunk:

"A szervezet neve Google, Inc." A következő elem a cím. Egy szervezet címét pontosan ugyanúgy jelölhet

jük meg, mint egy személyér. Először egy itemprop="address" jellemzőt adunk a cím legkülső eleméhez (ami ebben az esetben egy <p> elem). Ez jelzi, hogy ez a szervezet address tulajdonsága. De mi a helyzet magának a címnek a tulajdonságaival? Ahhoz, hogy jelezzük, hogy ez egy olyan Address elem, amelynek saját tulajdonságai vannak, meg kell határoznunk az i tem type és item scope jellemzőket is:

<p itemprop="address" itemscope itemtype="http://data-vocabulary.org/Address">

Végül, minden információegységet egy-egy <span> áldembe kell burkolnunk, hogy hozzájuk adhassuk a megfelelő mikroadar-tulajdonságneveket (st reet

address, lo cality, region, postal-co de és count ry-name):

<p itemprop= "address" itemscope


<span itemprop="street-address"> 1600 Amphitheatre Parkway</ span><br>

10. fejezet ,.Elosztott", "bővíthetőség"... l 247

<span itemprop="locality" >Mountain View</span>,

<span itemprop="region">CA</span>

<span i temprop="postal-code">94 0 43</ span><br>

<span i temprop=" country-name">USA</ span>

</p>

Magyarul, az előbb ezt mondtuk: "Ennek a szervezernek van egy címe. Az utca és házszám »1600 Amphitheatre Parkway«, a helység »Mountain View«, az állam »CA«, a postai irányítószám »94043«, az országnév pedig »USA«".

Most a szervezet telefonszáma következik. A telefonszámok kezelése hírhedten nehéz, és a telefonszámok formátuma országonként különbözik. (Ha másik országba szerernénk telefonálni, még rosszabb a helyzet.) A példánkban Egyesült Államokbeli telefonszám szerepel, az USA-n belüli hívásra alkalmas alakban:

<p itemprop="tel">650-253-0000</p>

(Ha esetleg nem vettük észre, kikerültünk az Address szótár hatóköréből, amikor a <p> elemet lezártuk, és visszatértünk az Organization szótár tulajdonságainak meghatározásához.)

Ha több telefonszámot szerernénk felsorolni - mondjuk egyet az amerikai, egyet pedig a más országbeli ügyfelek számára -, azt is megtehetjük. Bármelyik mikroadat-tulajdonság ismétlődhet. Csak arra kell ügyelnünk, hogy mindegyik telefonszám a saját HTML-elemében szerepeljen, a hozzájuk fűzött esetleges szövegcímkéktől függetlenül:

<p>

US customers: <span itemprop="tel">650-253-0000</ span><br>

UK customers: <span itemprop="tel">OO +l*+ 6502530000</span>

</p>

A 10.1. táblázat szerint sem a <p>, sem a <span> elem nem igényel különleges feldolgozást. A tel mikroadat-tulajdonság értéke egyszerűen a szövegtartalom. Az Organization mikroadat-szótár nem tesz kísérletet arra, hogy részeikre bontsa a telefonszámokat; az egész tel tulajdonság csupán szabad formátumú szöveg. Ha a körzetszámot zárójelbe szeretnénk tenni, vagy a számokar kötőjelek helyett szóközökkel választanánk el, azt is megtehetjük. Ha egy ügyfélprogram elemekre szeretné bontani a relefonszámot, ezt reljes egészében magának kell megoldania.

248 l .,Elosztott", .,bővíthetőség" ... 10. fejezet

Ismét egy ismerős tulajdonság következik: az url. Ugyanúgy, ahogy az előző részben egy személyhez társítottunk UR L-t, egy szervezethez is rendelhetünk URL-t. Ez lehet a cég honlapjának, egy kapcsolati oldalnak, egy termékoldalnak vagy bármi másnak a címe. Ha az adott URL-címen található oldal a szervezetről szól vagy a szervezethez tartozik, címkézzük fel egy itemprop="url" jellemzővel:

<p><a itemprop="url" href= "http: l /www .google. com/ ">Google .com</ a></ p>

A 10.1. táblázat szerint az <a> elem nem igényel különleges feldolgozást. A mikroadat-tulajdonság értéke a href jellemző értéke, nem pedig a hivatkozás szövege. A fenti kód tehát ennyit tesz: "Ehhez a szervezethez a http://www. google.coml URL kapcsolódik.". A kapcsolatról ennél nem mond több konkrétumor, és nem szerepel benne a hivatkozás szövege, vagyis a "Google.com".

Utolsóként a helymeghatározásról szeretnék szót ejteni. Nem, nem a W3C Geolocation API-járól (lásd a 6. fejezetben), hanem arról, hogy miként jelölhetjük meg egy szervezet földrajzi helyét mikroadatok segítségéveL

Eddig minden példában látható adatok felcímkézéséről volt szó. Az egyik esetben volt egy <hl> elemünk a cég nevével, ezért hozzáadtunk egy i temprop jellemzőt ehhez a <hl> elemhez, hogy jelezzük, hogy a (látható) címsorszöveg egy cég neve. A másik esetben egy <img> elemmel rendelkeztünk, amely egy fényképre muratott, így hozzáadtunk egy i temprop jellem

zőt ehhez az <img> elemhez, hogy jelezzük, hogy a (látható) kép egy személyt ábrázol.

Ebben a példában a helymeghatározási információk nem ilyenek. Nincs látható szöveg, ami megadja a szervezet helyének pontos szélességi és hosszúsági fokát (négy tizedesjegy pontossággal!). Valójában a mikroadatok nélküli szervezeti mintaoldalunk egyáltalán nem tartalmaz helymeghatározással kapcsolatos információkat. Csupán egy hivatkozással murat a Google Maps-re, de még ennek a hivatkozásnak az URL-jében sincsenek hosszúsági és szélességi koordináták (csak hasonló adatok, a Google-nek megfelelő formátumban). De még ha lenne is egy olyan képzeletbeli internetes térképszolgáltatásra mutató hivatkozásunk, amely URL-paraméterekként hosszúsági és szélességi koordinátákat fogad, a mikroadatok nem adnak módot arra, hogy egy URL-t a részeire bontsunk. Nem jelenthetjük be, hogy az első URL-paraméter a hoszszúsági, a második a szélességi fok, a maradék pedig nem érdekes.


Az ilyen szélsőséges esetek kezelése érdekében a HTML5 arra is módot ad, hogy megjelöljük a láthatatlan adatokat, ezt azonban csak végszükség esetére

tartogassuk. Ha van rá lehetőség, hogy megjelenítsük a fontosnak vélt adatokat, tegyük is meg. Az olyan láthatatlan adatok, amelyeket csak a számítógépek képesek elolvasni, hajlamosak gyorsan "megpenészedni", vagyis valószínű, hogy később jön valaki, aki módosítja a látható szöveget, de megfeledkezik

a láthatatlan adatok frissítésérőL Ez gyakrabban megesik, mint gondolnánk - és velünk is biztosan meg fog.

Mindazonáltal vannak helyzetek, amikor elkerülhetetlen, hogy láthatatlan adatokat használjunk. Megeshet például, hogy a főnökünk nagyon sze

retné, ha egy oldalon gép által olvasható helymeghatározási információk

szerepelnének, de nem akarja áttekinthetetlen hatjegyű számpárokkal tele

zsúfolni a felületet. Ilyenkor a láthatatlan adatok használata jelenti az egyetlen megoldást. Csak az enyhíti némileg a helyzetet, hogy a láthatatlan adatokat közvetlenül az után a látható szöveg után helyezhetjük el, amelyhez

kapcsolódnak, így talán emlékeztethetjük azt a személyt, aki később módo

sítja a látható szöveget, hogy a rögtön utána következő láthatatlan adatokat is frissítenie kell.

A példánkban létrehozhatunk egy <span> áldemet ugyanazon az <article>

elemen belül, amelyben az összes többi szervezeti tulajdonság is található, majd

a láthatatlan helymeghatározási adatokat ebbe a <span> elembe tehetjük:

<span itemprop="geo" itemscope

itemtype="http://data-vocabulary.org/Geo">

<meta itemprop= "latitude" content= "37. 414 9"/>

<me ta i temprop= "longitude" content= "-122. 07 8" l>

</span>

</article>

A helymeghatározási információkhoz is saját szótár tartozik, ugyanúgy, mint egy személy vagy szervezet címéhez. Az említett <span> elemnek tehát há

rom jellemzőre van szüksége: i temprop= "ge o"

Ez a jellemző azt mondja, hogy az elem a kapcsolódó szervezet ge o tulajdonságát jelképezi.

i tem type="http://data-vocabulary.org/Geo"

Ez a jellemző azt adja meg, hogy az elem tulajdonságai melyik mikroadatszótárnak felelnek meg.


itemscope

Ez a jellemző azt mondja, hogy az elem egy saját (az itemtype jellemző

ben megadott) szótárral rendelkező mikroadat-elem befoglaló eleme. Az ebben az elemben található összes tulajdonság a Geo szótár (http://data

vocabulary.org/Geo) tulajdonsága, nem a kapcsolódó szervezeti szótáré (http: l /data-vocabulary .org/Organization).

A következő nagy kérdés, amelyre ez a példát választ ad, hogy "Miként cím

kézhetjük fel a láthatatlan adatokat?". Nos, ezt a <meta> elemmel tehetjük

meg. A HTML korábbi változataiban a <me ta> elemet csak az oldal <he ad>

részében használhattuk ( lásd a 3. fejezet "A <head> elem" című részét),

a HTML5-ben azonban a <meta> elemet bárhol alkalmazhatjuk. Pontosan így teszünk itt is:

<meta itemprop= "latitude" content= "37. 414 9"/>

A 10.1. táblázat szerint a <meta> elem különleges feldolgozást igényel.

A mikroadat-tulajdonság értéke a content jellemző. Mivel ez a jellemző

soha nem jelenik meg, tökéletesen alkalmas korlátlan mennyiségű láthatatlan adat tárolására. A nagy hatalom nagy felelősséggel jár. Ez esetben a miénk a felelősség, hogy gondoskodjunk róla, hogy ezek a láthatatlan adatok összhangban maradjanak az őket körülvevő látható szöveggel.

Az Organization szótárat a Google Rich Snippets nem támogatja közvet

lenül, így nem tudok semmilyen tetszetős mintát mutatni a keresési eredményekre. Mindazonáltal a szervezetek nagy szerepet kapnak a következő két

-az eseményekkel és a kritikákkal kapcsolatos- esettanulmányban, és ezeket a Google Rich Snippets már támogatja.

Események felcímkézése

Mindig történik valami. Egyes dolgok pedig előre meghatározott időpon

tokban történnek. Nem lenne klassz, ha pontosan megmondharnánk a kere

sőknek, hogy egy adott dologra mikor kerül sor? Nos, van erre egy csúcsos zárójel.

Induljunk ki egy minta-ütemtervből, amely az én előadásaimat sorolja fel

(http:!ldiveintohtml5.orglexamples/event.htmf):


<article>

<hl>Google Developer Da y 2009</hl>

<img wid th= "300" height= "200"

src="http://diveintohtmlS.org/examples/gdd-2009-prague-pilgrim.jpg"

alt=" [Mark Pilgrim at podium] ">

<p>

Google Developer Days are a chance to learn about Google

developer products from the engineers who built them. This

one-da y conference incluctes seminars and "office hours"

on web technologies like Google Maps, OpenSocial, Android,

AJAXAPis, Chrome, and GoogleWeb Toolkit.

</p>

<p>

<time datetime= "2009-ll-06T08: 30+01: 00 ">2009 November 6, 8: 30</time>

–

<time datetime= "2009-ll-06T20: 30+01: 00 ">20: 30</time>

</p>

<p>

Congress Center<br>

5th kvetna 65<br>

140 21 Praha 4<br>

Czech Republic

</p>

<p><a href="http://code.google.com/intl/cs/events/developerday/2009/

home. html ">GDD/Prague home page</ a></p>

</article>

�Az itt végrehajtott változtatásokat az Interneten is nyomon kö

vethetjük. Előtte: http:l!diveintohtml5.orglexampleslevent.html. Utána: http:lldiveintohtml5. orglexamples/event-plus-microdata. h tm l.

Az eseménnyel kapcsolatos minden információt az <article> elem tartalmaz, ezért oda kell tennünk az i temtype és itemscope jellemzőket:

<article i temscope i temtype="http: l l data-vocabulary. org/Event">

Az Event (Esemény) szótár URL-je a http:/ /data-vocabulary.org/

Event, és ezen a címen történetesen egy csinos kis táblázat is található a szótár tulajdonságairól. Hogy mik ezek a tulajdonságok? Tekintsük meg a

10.4. táblázatban!


surrunary

url

location

Az esemény címe

Az esemény részleteit tartalmazó oldalra mutató hivatkozás

Az esemény színhelye. Egy beágyazott Szervezet (lásd a fejezet.,Szervezetek felcímkézése"

cím ü részét) vagy Cím (lásd a fejezet.Személyek felcímkézése" cím ü részét) is jelöl heti.

description Az esemény leírása

startDate Az esemény kezdetének dátuma és ideje ISO-dátumformátumban

end Da te Az esemény végének dátuma és ideje ISO-dátumformátumban

duratien Az esemény időtartama ISO-dátumformátumban

eventType Az esemény besorolása (például.,koncert" vagy .,előadás"). Nem felsorolt jellemző, tehát

tetszőleges karakterlánc lehet.

g eo A helyszín földrajzi koordinátái. Mindig két résztulajdonságot -la ti tu de és

long i tu de, vagyis szélességi és hosszúsági fok- tartalmaz.

fl. hO tO Az eseményhez kapcsolódó fotóra vagy más képre mutató hivatkozás.

Az esemény címe egy <hl> elemben található. A 10.1. táblázat szerint a <hl>

elemek nem igényelnek semmilyen különleges feldolgozást. A mikroadattulajdonság értéke egyszerűen a <hl> elem szövegtartalma. Tehát csak anynyit kell tennünk, hogy hozzáadjuk az itemprop jellemzőt, hogy bejelentsük, hogy ez a <hl> elem tartalmazza az esemény címét:

<hl i�rop="slll!lllarY">Google Developer Day 2009</hl>

Ez magyarul annyit tesz, hogy "Az esemény címe »Google Developer Day 200 9«."

Ehhez az eseményhez tartozik egy fénykép is, amelyet a photo tulajdonsággal jelölhetünk meg. Ahogy azonban azt várhatjuk, a fotónak már van egy címkéje: egy <img> elem. A Person szótár (lásd a fejezet korábbi, "A mikroadatok adatmodellje

" című részét) photo tulajdonságához hasonlóan az Event

szótár photo tulajdonsága is egy URL. Mivel a 10.1. táblázat azt mondja, hogy egy <img> elem tulajdonságértéke az elem src jellemzője, csak annyit kell tennünk, hogy hozzáadjuk az itemprop jellemzőt az <img> elemhez:

<img itemprop= "photo" wid th= "300 • height= "200"

src="http://diveintohtmlS.org/examples/gdd-2009-prague-pilgrim.jpg"

alt=" [Mark Pilgrim at podium] ">


Ez magyarul annyit tesz, hogy "Az ehhez az eseményhez tartozó fénykép a http:/1 diveintohtm/5. orglexamples/gdd-2009-prague-pilgrimjpg címen található".

Ezt egy hosszabb leírás (description) követi az eseményről, ami csupán egy bekezdésnyi tetszőleges szöveg:

<p itemprop= "description ">Google Developer Days are a chance to

learn about Google developer products from the engineers who buil t

them. This one-day conference incluctes seminars and "office

hours" on web technologies like Google Maps, OpenSocial,

Android, AJAX AP Is, Chrome, and Google Web Toolkit. </p>

A következő elem valami új. Az eseményekre általában konkrét napokon kerül sor, és adott időben kezdődnek, illetve végződnek. A HTML5-ben azonban a dátumokat és időpontokar a <time> elemmel kell megjelölni

(lásd a 3. fejezet "Dátumok és időpontok" című részét), és ezt már meg is tettük itt. A kérdés tehát az, hogy miként adhatunk mikroadat-tulajdonságokat ezekhez a <time> elemekhez? Ha visszalapozunk a 10.1. táblázathoz, láthatjuk, hogy a <time> elem különleges feldolgozást igényel. Egy <time> elem mikroadat-tulajdonságainak értéke a datetime jellemző értéke. Az Event szótár startDate és endDate tulajdonságai ráadásul ugyanúgy ISO formátumú dátumot várnak, mint egy <time> elem datetime tulajdonsága. A HTML alapszótára tehát itt is szépen illeszkedik az egyéni mikroadat

szótárunk elemeinek jelentéséhez. A kezdő- és záródárumok mikroadatokkal történő felcímkézése ilyen egyszerű:

l. Először is, használjuk helyesen a HTML-t (a dátumokat és időpontokat címkézzük fel <time> elemekkel).

2. Adjunk a kódhoz egyetlen i temprop jellemzőt:

<p>

<time itemprop="startDate" date time= "2009-ll-06T08: 30+01: 00 ">200 9

November 6, 8: 30</ time>

–

<time itemprop="endDate" date time= "2009-ll-06T20: 30+01: 00 ">20: 30</

time>

</p>

Ez magyarul annyit tesz, hogy "Ez az esemény 2009. november 6-án, reggel 8:30-kor kezdődik, és 2009. november 6-án 20:30-ig tart (prágai idő, tehát GMT+l szerint).".

254 J "Elosztott", "bővíthetőség" ... 10. fejezet

Következzen a location tulajdonság. Az Event szótár meghatározása azt

mondja, hogy a helyszín egy szervezet és egy cím is lehet. Ebben az esetben az eseményt egy konferenciateremben tartják, a prágai Kongresszusi Központban. Ha a helyszínt egy szervezettel (Organization) címkézzük fel, nem csak a helyszín címét, hanem a nevét is megadhatjuk.

Először is, jelentsük be, hogy a címet tartalmazó <p> elem az esemény location tulajdonsága, és hogy ez az elem egyben önmaga is egy mikroadat

elem, amely a http://data-vocabulary.org/Organization szótárnak felel meg:

<p itemprop="location" itemscope

itemtype="http://data-vocabulary.org/Organization">

Ez urán címkézzük fel a szervezet nevét, a nevet egy <span> áldembe burkolva, majd egy i temprop jellemzőt adva a <span> elemhez:

<span i temprop="name">Congress Center</ span><br>

A "name" az Organization, és nem az Event szótár egy tulajdonságát határozza meg. A <p> elemet ugyanis, amellyel megjelöltük a szervezeti tulajdonságok hatókörének elejét, még nem zártuk le egy </p> címkével. Minden mikroadat-tulajdonság, amit itt meghatározunk, az utoljára megnyitott hatókörű szótár tulajdonsága. Az egymásba ágyazott szótárak olyanok, mint egy

verem. A verem tetejéről még nem emeltük le a később berakott elemet, tehát még mindig a szervezet tulajdonságairól beszélünk.

Sőt, egy harmadik szótárat is a veremre fogunk helyezni: az esemény (Event) helyszínét biztosító szervezet (Organization) címét (Address):

<span itemprop="acldress" itemscope


A cím egyes részeit ezúttal is önálló mikroadat-tulajdonságként szetetnénk megjelölni, ezért szükségünk lesz néhány <span> álelemre, amelyekre felaggathatjuk az i temprop jellemzőinket. (Ha túl gyorsan haladnék, lapozzunk vissza, és olvassuk el még egyszer a fejezet "Személyek felcímkézése", illetve

"Szervezetek felcímkézése" című részeit.) <span itemprop="street-acldress">Sth kvetna 65</span><br> <span itemprop="postal-code">l40 21</span> <span itemprop="locality">Praha 4</span><br> <span i temprop=" country-name">Czech Republic</ span>


A címnek nincs több tulajdonsága, ezért bezárjuk az Address szótár hatókörét megnyitó <span> elemet, és ezzel leemeljük a legfelső elemet a veremről:

</span>

A szervezernek sincs több tulajdonsága, tehát az Organization szótár hatókörét megnyitó <p> elemet is bezárjuk, és ismét leemeljük a legfelső elemet a veremről:

</p>

Ezzel visszatértünk az esemény tulajdonságainak meghatározásához. A következő tulajdonság a geo, amely az esemény fizikai helyszínét jelképezi. Ez a tulajdonság ugyanazt a Geo szótárat használja, mint amelyet az előző részben egy szervezet foldrajzi helyének megjelölésére alkalmaztunk. Tárolóként szükségünk van egy <span> elemre; ebbe tesszük az i temtype és itemscope

jellemzőket. Ezen a <span> elemen belül két <meta> elemet kell megadnunk -egyet a latitude, és egyet a longitude tulajdonság számára:

<span itemprop="geo" itemscope itemtype="http: //data-vocabulary .org/Geo">

<me ta itemprop="latitude" content= "50. 047893" />

<meta itemprop="longitude" content= "14. 4 491"/>

</span>

Mivel a Geo tulajdonságokat tartalmazó <span> elemet lezártuk, ismét az esemény tulajdonságait határozzuk meg. Az utolsó tulajdonság az url, amely

nek már ismerősnek kell lennie. Egy eseményhez ugyanúgy társíthatunk egy URL-t, mint egy személyhez (lásd a "Személyek felcímkézése" részt) vagy egy szervezethez (lásd a "Szervezetek felcímkézése" részt). Ha a HTML-t he

lyesen használjuk (a hiperhivatkozásokat <a href> címkékkel jelöljük meg), egy hiperhivatkozásról bejelenteni, hogy url mikroadat-tulajdonság, csupán annyiból áll, hogy hozzáadjuk az i temprop jellemzőt:

<p>

<a itemprop="url"

href='http://code.goog1e.com/intl/cs/events/developerday/2009/home.html">

GDD/Prague home page

</a>

</p>

</article>

Az esemény-mimaoldalunk (http:lldiveintohtmf5.orglexampleslevent.htmf) egy második eseményt is felsorol: a montreali ConFoo konferencián tartandó előadásomaL A rövidség kedvéért ennek a kódján nem megyek végig sorról sorra. Lényegében úgyis megegyezik a prágai eseményével: egy Event elem


beágyazott G eo és Address elem ekkel. Csak azért ernlitern meg futólag, hogy emlékeztessek rá, hogy egy oldalon több esemény is lehet, amelyek mindegyikét felcímkézhetjük mikroadatokkal.

A Google Rich Snippets visszatér

A Google Rich Snippets Testing Tool nevű tesztelőeszköze szerint a Google keresőpókjai az alábbi információkat nyerik ki az esemény-mintaoldalunkból (http:!/diveintohtm/5. orglexampleslevent-plus -microdata. h tm l):

I tem

Type: http://data-vocabulary.org/Event

summary = Google Developer Da y 200 9

eventType = conference

photo= h t tp: l /diveintohtmlS. org/examples/gdd-2009-prague-pilgrim. jpg

description= Google Developer Days a re a chance to learn about Google

developer products from the engineers who built them. This

one-da y conference incluctes seminars and office hours on web

technologies li ke Goo ...

startDate = 2009-11-06T08: 30+01: 00

endDate = 2009-11-06T20: 30+01: 00

location = Item(_l)

geo = Item(_3)

url= http: l /code .google. com/intl/cs/events/developerday/2009/home. html

I tem

Id: l

Type: http://data-vocabulary.org/Organization

name= Congress Center

address = Item (_2)

I tem

Id: 2

Type: http://data-vocabulary.org/Address

street-address= Sth kvetna 65

postal-code = 140 21

locality = Praha 4

country-name =Czech Republic

It em

Id: 3

Type: http://data-vocabulary.org/Geo

latitude =50. 04 789 3

longitude = 14.4 491

10. fejezet ,.Elosztott", ,.bővíthetőség" ... l 257

Amint láthatjuk, itt van minden információ, amit mikroadatokkal adtunk meg. Azok a tulajdonságok, amelyek önálló mikroadat-elemek, belső azonosítókat kaptak- Item( _ 1), Item( _2 ) stb.-, de ez nem része a mikroadatok

szabványának, csupán a Google resztelőeszközének egyezményes módszere, amellyel lineárissá teszi a kimenetet, és megmutatja a beágyazott elemek és

azok tulajdonságai csoportosítását. Hogyan jelenítheti meg a Google a mintaoldalunkar a keresési eredmé

nyek között? (Megint csak hangsúlyoznom kell, hogy ez csupán egy példa- a Google bármikor megváltoztathatja a ralálati oldalak formátumát, és semmi

sem garantálja, hogy figyelembe veszik a mikroadat-értékeket.) Az eredmény valahogy úgy festhet, mint a 10.2. ábrán.

Mark Pilgdm's event calendar Excerpt from the page will show up here. Excerpt from the page will show up here. Google Deyeloper Pay 2009 Fd, Nov 6 Congress Center. Praha 4, Czech Republic

ConFoo.ca 2010 Wed, Mar 10 Hilton Montreal Bonaventura, Montréal, Québec, Canada diveintohtrn15.org/examples/event-plus-microdata.htrnl - Cached - Similar pages

1 0.2. ábra Példa egy mikroadatokkal kiegészített eseményoldal keresésének eredményére

Az oldal címe és az automatikusan előállított szövegkivonat után a Google az oldalhoz adott mikroadatok felhasználásával egy kis táblázatot jelenít meg az eseményekről. Figyeljük meg a dátum formátumát: "Fri, Nov 6". Ez nem egy

olyan karakterlánc, amely bárhol is szerepelt volna a HTML- vagy mikroadatkódunkban. Mi két teljesen minősített, ISO formátumú karakterláncot -

2009-11-06T08:30+01:00 és 2009-11-06T20:30+01:00- használtunk

A Google fogta ezt a két dátumot, rájött, hogy ugyanarra a napra esnek, és

úgy döntött, hogy egyetlen dátumot jelenít meg, barátságosabb alakban.

Most nézzük meg a földrajzi címeket. A Google csak a színhely nevét, a helységet és az országot jelenítette meg, az utcát és a házszámot nem. Ezt az

tette lehetövé, hogy a címer öt résztulajdonságra- name, street-address,

region, locality és country-name - bonrottuk, és mindegyik részr

külön mikroadat-tulajdonsággal jelöltük meg. A Google ezt kihasználva jele

nít meg rövidített címet. Ugyanezt a mikroadatkódot más "fogyasztók" másképp is feldolgozhatják, és más elemek megjelenítése vagy más formázás mel

lert dönthetnek. Nincs helyes és helytelen módszer: a mi feladatunk az, hogy

annyi adatot adjunk meg, amennyit csak tudunk, és olyan pontosan, amenynyire csak tudjuk. A világ majd eldönti, hogy mit kezd velük.

258 J "Elosztott", "bővíthetőség" ... 10. fejezet

Kritikák felcímkézése

Az üzlet- és termékismertetők újabb példát szolgáltatnak arra, hogy miként tehetjük jobbá a Világhálót (és a keresők találari oldalait) a leírókádon keresztül. Az alábbiakban egy rövid kritika látható, amelyet a lakhelyem közelében található kedvenc pizzázómról írtam. (Mellesleg egy létező étteremről van szó. Ha bármikor az észak-karolinai Apexben járunk, érdemes betérni.) Nézzük meg az eredeti kódot (http:lldiveintohtml5.orglexampleslreview.html):

<article> <hl>Anna' s Pizzeria</hl>

<p>***** (4 csillag 5-ből) </p> <p>New York-i stílusú pizza itt, Apex történelmi belvárosában</p> <p>

Az étel elsőrangú, a hangulat pedig éppen olyan, rnint a "sarki családi pizzázóban ". Maga az étterem vállban kissé szük; ha túlsúlyosak vagyunk, nehézséget okozhat leülni vagy felállni a székből, illetve lavírozni az asztalok között. Régebben ajándék fokhagymás batyuval kedveskedtek az újonnan betérőknek; rnost már csak sima kenyeret adnak, a finomságokért fizetni kell. De rnindent egybevéve szuper hely.

</p> <p>

100 North Salern Street<br> Apex, NC 27502<br> USA

</p> <p>- írta: Mark Pilgrim, utolsó frissítés: 2010. március 31. </p>

</article>

i''IAz itt végrehajtott változtatásokat az Interneten is nyomon követhetjük. Előtte: http:l/diveintohtm/5. orglexampleslreview.html. Utána: http:l/diveintohtm/5. orglexampleslreview-plus-microdata. h trni.

Az ismertetőt egy <article> elem tartalmazza, ezért ide kell tennünk az i tem t y pe és i t ems c ope jellemzőket. Íme ennek a szótárnak a névrerét megadó URL:

<article i temscope i temtype="http: l /data-vocabulary. org/Review">

Milyen tulajdonságok állnak rendelkezésre a Review (Kritika/Ismertető) szótárban? Örülök a kérdésnek- tessék megnézni a 10.5. táblázatot.


1 0.5. táblázat A kritikák szótára

itemreviewed A kritika tárgyának megnevezése. A kritika tárgya lehet egy termék, egy

szolgáltatás, egy üzleti vállalkozás stb.

rating A kritika tárgyának számszerü minősítése egy l-től 5-ig terjedő skálán. Beágyazott,

a http: l /data-vocabulary. erg/Rating címen található szótárat használó

értékelés is lehet, ha nem szabványos skálát szerelnénk használni.

reviewer

dtreviewed

summary

description

A krítika szerzőjének neve

A kritikai vizsgálat dátuma ISO-dátumformátumban

A kritika rövid összegzése

A kritika szövegtörzse

Az első tulajdonság egyszerű: az itemreviewed csupán egy szöveg, amelyet itt egy <hl> elem tartalmaz, ezért az i temprop jellemzőt itt kell elhelyeznünk

<hl itemprop="itemreviewed">Anna' s Pizzeria</hl>

Magát az értékelést most átugrom; majd a végén visszatérek rá.

A következő két tulajdonság szintén önmagáért beszél. A summary tulajdonság a kritika tárgyának rövid leírása, a description tulajdonság pedig a kritika szövegtörzse:

<p itemprop="sl.llllllélry">New York-i stílusú pizza itt, Apex történelmi belvá

rosában</p>

<p itemprop="clescription">

Az étel elsőrangú, a hangulat pedig éppen olyan, mint a "sarki családi

pizzázóban ". Maga az étterem vállban kissé szük; ha túlsúlyosak

vagyunk, nehézséget okozhat leülni vagy felállni a székből,

illetve lavírozni az asztalok között. Régebben ajándék fokhagymás

batyuval kedveskedtek az újonnan betérőknek; most már csak sima

kenyeret adnak, a finomságokért fizetni kell. De mindent egybevéve

szuper hely.

</p>

A location és geo tulajdonságokkal már találkoztunk korábban (lapozzunk vissza a személyek, szervezetek, illetve helymeghatározási információk felcímkézéséről szóló korábbi részekhez):

<p itemprop="location" itemscope


<span itemprop="street-address">lOO North Salem Street</span><br>

<span i temprop="locali ty">Apex</ span>,

<span i temprop="region">NC</ span>


<span itemprop="postal-code">27502</span><br> <span i temprop=" country-name">USA</ span>

</p> <span itemprop="geo" itemscope

itemtype="http://data-vocabulary.org/Geo">

<me ta itemprop="latitude" content� '35. 730796' /> <meta itemprop="longitude" content�"-78.851426" />

</span>

Az utolsó sorban egy ismerős problémát találunk: két információ szerepel egyetlen elemben. A kritika szerzőjének neve Mark Pilgrim, a kritika születésének dátuma pedig 2010. március 31. Hogyan címkézzük fel ezt

a két önálló tulajdonságot? Szokás szerint saját elemekbe csomagoljuk őket ( lásd a fejezet "Személyek felcímkézése" című részét), és mindkét elemet ellátjuk egy-egy i temprop jellemzőveL A példában szereplő dátumot egyébként már eleve egy <time> elemmel kellett volna megjelölni, ami természetes "akasztó" lenne, amire felakaszthatjuk az itemprop jellemzőt. A szerző nevét egyszerűen egy <span> áldembe burkoljuk:

<p> <span itemprop="reviewer">Mark Pilgrim</ span>, utolsó frissítés: <time itemprop="dtreviewed" datetime="2010-03-31">

2010. március 31. </time>

</p> </article>

Rendben, akkor beszéljünk az értékelésrőL Egy kritika vagy ismertető felcímkézésének legnehezebb része mindig az értékelés. A Review szótár osztályza

tai alapértelmezés szerint l-től 5-ig terjednek, ahol az l a "szörnyű", az 5

pedig a " fantasztikus". Ha más skálát szeretnénk használni, természetesen megtehetjük. Először azonban vizsgáljuk meg az alapértelmezett skálát:

<p>***** ( <span itemprop� "rating ">4</ span> csillag 5-ből) </p>

Ha az l-től 5-ig terjedő alapértelmezett skálát használjuk, az egyeden tulaj

donság, amelyet fel kell címkéznünk, maga az értékelés (tehát esetünkben a 4-es osztályzat). De mi a helyzet akkor, ha más skálát szeretnénk használni?

Ezt is megtehetjük, csak meg kell adnunk a választott skála határait. Például ha egy O-tól 10-ig terjedő skálát akarunk alkalmazni, ugyanúgy be kell ve

zetnünk az i temprop= "rating" tulajdonságot, az osztályzat közvetlen megadása helyett azonban egy beágyazott, a http://data-vocabulary.


orgiRating szótáron alapuló értékelést használhatunk az egyéni skála legrosszabb (worst) és legjobb (best) osztályzatainak, illetve azon belül a tényleges értékelésnek a meghatározására:

<p itemprop= "rating" itemscope itemtype="http://data-vocabulary.org/Rating">

*********

(<span itemprop= "value ">9</span> egy <span i temprop= "wo r st ">0</ span>-tól

<span itemprop= "be st ">10</span>-ig terjedő skálán) </p>

Ez magyarul annyit tesz, hogy "Az értékelt termék egy O-tól 10-ig terjedő skálán 9-es osztályzatot ért el."

Említettem, hogy a kritikákhoz tartozó mikroadatok hatással lehetnek a keresők találari oldalaira? Úgy bizony! Íme a "nyers adatok", amelyeket a Google Rich Snippets eszköze kinyert a mikroadatokkal kiegészített kritikámból (http:llwww.google.com/webmastersltoolslrichsnippets?url=lldiveintohtml5. orglexampleslreview-plus-microdata. h tm!}:

I tem

Type: http://data-vocabulary.org/Review

itemreviewed =Anna' s Pizzeria

rating= 4

summary =New York-style pizza right in histor ic downtown Apex

description = Food is top-notch. Atmasphere is just right ...

address= Item( l)

geo = Item (_2)

reviewer =Mark Pilgrim

dtreviewed = 2010-03-31

I tem

Id: l

Type: http://data-vocabulary.org/Organization

street-address = 100 North Salem Street

locality = Apex

region = NC

postal-code = 27502

country-name =USA

I tem

Id: 2

Type: http://data-vocabulary.org/Geo

latitude =35. 730796

longitude =-78. 851426


A 10.3. ábrán láthatjuk, hogy mikénr festene a kritikám egy kereső találari oldalán (a Google szeszélyeitől, a holdfázistól és egyebektől eltekintve).

Anna's Pizzeria: review *****Review by Mark Pilgrim- Mar 31, 2010 Excerpt from the page will show up here. Excerpt from the page will show up here. diveintohtml5.org/examples/review-plus-microdata.html - Cached - Similar pages

l 0.3. ábra Példa egy mikroadatokkal kiegészített kritikai oldal keresésének eredményére

A csúcsos zárójelek engem általában hidegen hagynak, de el kell ismernem, hogy ez elég klassz.


A mikroadatokkal kapcsolatos források:

• Live microdata játszótér (http:llfoolip.orglmicrodatajsllivel) • A HTMLS-mikroadatok szabványleírása (http:llbit.lylckt9Rj)

Google Rich Snippets-források: • "About rich snippets and structured data" (http://www.google.com/

supportlwebmasterslbin/answer.py?hl=en&answer=99170) • "People" (http:llwww.google.com/supportlwebmasterslbin/answer.py?hl=

en&answer=l46646) • "Businesses & organizations" (http:llwww.google.com/supportlwebmastersl

binlanswer.py?hl=en&answer=146861) • "Evenrs" (http://www.google. comlsupportlwebmasterslbinlanswer.

py?hl=en&answer=164506) • "Reviews" (http:llwww.google.com/supportlwebmasterslbinlanswer.

py?hl=en&answer=146645) • "Review ratings" (http://www.google. com/supportlwebmasterslbin/answer.

py?hl=en&answer=172705) • Google Rich Snippets tesztelőeszköz (http://www.google.com/webmastersl

tools/richsnippets) • Google Rich Snippets tippek és trükkök (http:llknol.google.comlklgoogle

rich-snippets-tips-and-tricks)

Függelék

A "mindent egyben tartalmazó és majdnem ábécésorrendbe rendezett" útmutató,

amelyet követve bármit észlelhetünk

Összezavarodtunk? Bevezetésként olvassuk el a 2. fejezetet. Vagy inkább egy mindent egyben tartalmazó programkönyvtárra lenne szükségünk? Próbáljuk ki a Modernizr-t (http://www.modernizr.com)!

Az elemek listája

<audio> http:J /bit.ly/cZxl7k

return! !document.createElement('audio') .canPlayType;

<audio> MP3 formátumban http:/ /en.wiki pedia.org/wiki/MP3

var a= document. createElement ('audio' ) ;

return ! ! (a. canPlayType && a. canPlayType (' audio/mpeg;') . replace (/no/,

� "));

<audio> Verbis formátumban http://en.wikipedia.org/wikiNorbis

var a= document. createElement ('audio') ;

return ! ! (a. canPlayType && a. canPlayType (' audio/ogg; codecs= "vorbis "') . � replace(/no/, ''));

<audio> WAV formátumban http://en.wikipedia.org/wiki/WAV

var a= document. createElement ('audio' ) ;

return ! ! (a. canPlayType && a. canPlayType (' audio/wav; code cs= "l"') .

� replace(/no/, ''));

<a u d i o> AAC formátum ba n http:/ /en.wikipedia.org/wiki/ Advanced_Audio_Coding

var a= document. createElement ('audio') ;

return ! ! (a. canPlayType && a. canPlayType (' audio/mp4; codecs= "mp4a. 40.2 "') . � replace(/no/, ''));

Függelék l 265

<canvas> Lásd a 4. fejezetben

return! !document.createElement('canvas') .getContext;

<canvas> text API Lásd a"Szöveg" cím ű részt a 4. fejezetben

var c; document. createElement (' canvas');

return c. getContext && typeof c. getContext ('2 d' ) . fill Text= 'function' ;

<command> http://bit.ly/aQt2Fn

return 'type' in document. createElement ('command' ) ;

<datalist> http://bit.ly/9WVzSp

return 'options' in document. createElement (' datalist');

<details> http:/ /bit.ly/c08mQy

return 'open' in document. createElement (' details');

<device> http://bit.ly/aaBeUy

return ' type' in document. createElement ('device' ) ;

<form> megszorítás-ellenőrzés http:/ /bit.ly/cb9Wmj

return 'noValidate' in document .createElement ('form');

<iframe sandbox> http://blog.whatwg.org /whats-next-in-html-episode-2-sandbox

return 'sandbox' in document. createElement ('i frame');

<iframe srcdoc> http://blog.whatwg.org/whats-next-in-html-episode-2-sandbox

return 'srcdoc' in document. createElement ('i frame');

<input autofocus> Lásd az"Automatikus fókuszálásó mezők" cím ű részt a 9. fejezetben

return 'autofocus' in document. createElement ('input');

<input placeholder> Lásd a" Helyőrző szöveg" cím ű részt a 9. fejezetben

return 'placeholder' in document. createElement ('input' ) ;

<jn put type="color"> http:/ /bit.ly/9H keN n

var i; document. createElement ('input');

266 J Függelék

i.setAttribute('type', 'color');

return i. type ! =='text';

<input type="email"> Lásd az.E-mail címek" cím ú részt a 9. fejezetben

var i= document. createElement ('input');

i.setAttribute('type', 'email');

return i. type ! == 'text' ;

<input type="number"> Lásd a,.Számok léptetőmezőkben"címú részt a 9. fejezetben

var i = document. createElement ('input') ;

i.setAttribute('type', 'number');

return i. type ! == ' text' ;

<input type="range"> Lásd a .Számok csúszkákon" cím ú részt a 9. fejezetben


i.setAttribute('type', 'range');


<input type="search"> Lásd a ,.Keresőmezők" cím ű részt a 9. fejezetben

var i = document. createElement ('input' ) ;

i.setAttribute('type', 'search');


<input type="tel">


i.setAttribute('type', 'tel');

return i. type 1 == 'text' ;

http://bit.ly/bZmOQS

<input type=" url"> Lásd a ,.Webcímek" cím ű részt a 9. fejezetben


i.setAttribute('type', 'url');

return i. type 1 == 'text' ;

<input type="date"> Lásd a ,.Dátumválasztók" cím ú részt a 9. fejezetben

var i = document. createElement ('input');

i. setAttribute ('type', 'date');


<input type="time"> Lásd a,.Dátumválasztók" cím ú részt a 9. fejezetben


i. setAttribute ('type' , 'time' ) ;

return i. type !=='text';

<input type="datetime"> Lásd a.Dátumválasztók" címú részt a 9. fejezetben


Függelék l 267

i.setAttribute('type', 'datetime');

return i. type !=='text';

<input type="datetime-local"> Lásd a .,Dátumválasztók" cím ű részt a 9. fejezetben


i.setAttribute('type', 'datetime-local);

return i. type 1 =='text';

<input type="month"> Lásd a.Dátumválasztók" cím ű részt a 9. fejezetben

var i= document. createElement ('input' ) ;

i. setAttribute ('type', 'month');

return i. type ! = 'text' ;

<input type="week"> Lásd a.,Dátumválasztók" cím ű részt a 9. fejezetben


i. setAttribute ('type' , 'week') ;

return i. type ! == 'text' ;

<meter>

return 'value' in document. createElement ('me ter' ) ;

<output>

return 'value' in document .createElement ('output');

<progress>

return 'value' in document. createElement (' progre ss') ;

<time>

return 'valueAsDate' in document. createElement ('time');

<video>

return! !document.createElement('video') .canPlayType;

<video> feliratok

return 'sr c' in document. createElement ('track');

<video poster>

return 'pos ter' in document. createElement ('v ideo' ) ;

268 l Függelék

http:/ /bit.ly/cOpXOI

http://bit.ly/asJaqH

http:/ /bit.ly/bjDMy6

http:/ /bit.ly/bl62jp

Lásd az 5. fejezetben

http://bit.ly/9mliRr

http://bit.ly/b6RhzT

<video> WebM formátumban http://www.webmproject.org/

var v= document. createElement ('v ideo' ) ;

return ! ! (v. canPlayType && v. canPlayType (' video/webm; code cs= "vp8,

� varbis "' ) . replace (/no/, '' ) ) ;

<video> H.264 formátumban Lásd a .H.264" cin ű részt az 5. fejezetben


return 1 1 (v. canPlayType && v. canPlayType (' video/mp4; codecs= "avcl. 42E01E,

� mp4a. 4 O. 2 "' ) . replace (/no/, ' ' ) ) ;

<video> Theora formátumban Lásd a,,Theora"cínű részt az 5. fejezetben


return ! ! (v. canPlayType && v. canPlayType (' video/ogg; codecs= "theora "') . � replace (/no/, ''));

contentEditable http://bit.ly/alivbS

return 'isContentEditable' in document. createElement (' span');

Dokumentumok közötti üzenetküldés http://bit.ly/cUOqXd

return! 1window.postMessage;

Előzmények http:/ /bit.ly/9JGAGB

return 11 (window.history && window.history.pushState);

File API http:J /dev.w3.org/2006/webapi/FileAPI/

return typeof FileReader ! = 'undefined';

Helyi tárolás http://dev.w3.org/html5/webstorage/

return 'localStorage' in window && window [' localStorage' l 1== null;

Helymeghatározás Lásd a 6. fejezetben

return! 1navigator.geolocation;

"Húzd és ejtsd" http://bit.ly/aNORFQ

return 'draggable' in document. createElement (' span');

Kapcsolat nélküli webalkalmazások Lásd a 8. fejezetben

return ! !window.applicationCache;

Függelék l 269

Mikroadatok http:/ /bit.ly/dBGnqr

return ! !document.getitems;

Munkamenet-tárolás http:/ /dev.w3.org/html5/webstorage/

try {

return 'sessionStorage' in window && window [' sessionStorage' ] ! == null;

} catch(e) { return false;

Server-Sent Events http:/ /dev.w3.org/htm 15/eventsource/

(kiszolgáló által küldött események)

return typeof EventSource ! = 'undefined' ;

SVG http:/ /www.w3.org!TR/SVG/

return ! 1 (document. createElementNS && document. createElementNS ('h t tp: l l

� www.w3.org/2000/svg' , 'svg' ) .createSVGRect);

SVG text/html http://hacks.mozilla.org/201 0/05/

firefox-4-the-html5-parser-inline-svg-speed-and-more/

var e= document. createElement (' div');

e. innerHTML = '<svg></ svg>' ;

return ! ! (window. SVGSVGElement && e. firstChild instanceof window.

� SVGSVGElement);

Visszavonás http:/ /bit.ly/bs6JFR

return typeof UndoManager ! == 'undefined' ;

WebSimpleDB http:/ /dev.w3.org/2006/webapi/WebSim pl e DB/

return ! ! window. indexedDB;

Web Sockets http:/ /dev.w3.org/htm 15/websockets/

return ! 1 window. Web5ocket;

Web SQL Database http://dev.w3.org/html5/webdatabase/

return ! !window.openDatabase;

270 l Függelék

Web Workers (webmunkások) http:/ /bit.ly/9jheof

return 1 1 window. Wo r ker;


Szabványok és leírások: • HTML5 (http://bit.ly/bYiOQp) • Geolocation (http://www. w 3. org/TR/geolocation-APII) • Server-Sem Events (http:lldev. w 3. orglhtm/5/eventsourcel) • WebSimpleD B (http://dev. w 3. org/2006/webapi/WebSimpleD B/) • Web Sockets (http:lldev.w3.orglhtml5/websocketsl) • Web SQL Database (http://dev.w3.orglhtml5/webdatabasel) • Web Starage (http:lldev.w3.orglhtml5/webstoragel) • Web Workers (http://www. whatwg. orglspecslweb-workerslcurrent-workl)

J avaScri pr-könyvtárak: • Modernizr (),egy HTML5-észlelőkönyvtár

A

<article>, 71, 80 -

<aside>, 72

AAC, 130

addColorSrop, 107

addEventListener, 186

Add Type, 162

Advanced Audio Cod ing, 130

AJAX Massive Storage System, !82

alkalmazás-gyorstár, 199

állandó bitsebességű kódolás, 129

almost standards mode, 58

Andrew, 21

Apache, !62

appcache, 199

applicationCache, 47

application/xhtml+xml, 25, 27

arc(), 119

audiokodekek, 127

Audio Video Interleave, 123

aurofocus, 52, 211

auromatikus bemenetellenőrzés, 226

auromatikus fókuszálású mezők, 211

auromatikus hírfolyam-felderítés, 66

auromatikus lejátszás, 158

automatikus űrlapfókusz, 52

auroplay, 158

AVI, 123

azonos eredet elve, 45

Index

B

Basic quality and resolution control, !41

betűjellemzők, 102

betüméret, 103

beviteli elemek, 49

bitráta, 129

bitsebesség, 129

c

<canvas>, 37, 93

CACHE:, 198

Cache-Control, 203

cached, 201

cache manifest, 196

canPlayType(), 41, 42

Canvas text API, 38

ceruza-tagfüggvény, 98

checking, 201

cikkek, 80

címek, 242

címkék, 70

címsorcsoport, 72

címsorok, 77

clear(), 186

clearWatch(), 175

Closure Library, 221

code, 171

content sniffing, 14

Content-Type, 14, 63, 162

context.font, 103

Index J 273

comrols, 158 cookie, 181 coords, 170 createLinearGradiem, 106 createRadialGradiem, 106 csatorna, 128 CSS, 66 csúszka, 220

D

$(document).ready(), 213 datetime, 84 dátum, 83, 254 dárumválasztók, 221 DHTML Behaviors, 182 Display Postscript, 21 doctype, 57 Dojo, 221 dokumemum nyelve, 67 dokumentumobjektum-modell, 35 dokumemumtípus, 57 dokumemumvázlat, 78 DOM, 35 DOM-események, 201 DOM Srorage, 184 downloading, 201, 202 drawlmage(), 110

E

egyéni szótárak, 230 egymásba ágyazott hatókörök, 241 egymásba ágyazott szórárak, 231 e-mail címek, 213 em-négyzet, 102 enableHighAccuracy, 174 error, 202 értékelés, 261 események, 251 eseményfolyam, 201

274 l Index

eseménykezelő, 117 excanvas.js, 113 Expires, 203 explorercanvas, 38 ExplorerCanvas, 113

F

<footer>, 72, 87 <form>, 209 fa, 60 FAAC, 130 FairPlay, 130 fejléc, 14 ffmpeg, 154 ffmpeg2theora, 143 fillrect, 95 filiStyle, 95 filiText(), 39, 103 Firefogg, 136, 140 Firefox, 23 Flash-sütik, 182 Flash Video, 122 FlowPlayer, 163 fókusz, 213 font, 102 fordított hivatkozás, 69 függő alapvonal, 102

G

Gears, 49, 175, 183 gears_init.js, 176 geodéziai világrendszer, 172 geo.js, 176 geolocation, 48 Geolocation API, 167 geolokáció, 48, 167 getComext(), 37, 94 getCurrentPosition(), 169, 173 getltem(), 185

getitems(), 54 Google Rich Snippets, 243, 257 G PS, 170, 173 gradiem, 106 Greasemonkey, 159 gyermekelem, 60 gyökérelem, 60 gyorstár, 196 gyorstárjegyzék, 196

H

<a href>, 64 <head>, 61 <header>, 72, 78

<hgroup>, 72, 79 .htaccess, 162 H.264, 125, 145, 153 hálózati fehérlista szakasz, 198 hálózati szakasz, 198 HandBrake, 145 handle_srorage(), 187 hatókör, 231, 233 hártérszálak, 46 helyi megosztort objektumok, 182 helyi tárolás, 44, 181 helymeghatározás, 48, 167, 172

helyőrző szöveg, 51, 209 hibakeresés, 203 hiperhivatkozások, 65 hivatkozások, 64 hreflang, 67 HTML+, 20 HTML 4.0, 25 HTML5, 80 HTML5 Srorage, 183 HTML5-támogatás, 35 HTML5-tároló, 183, 185 HTML-munkacsopon, 26

HTML Working Group, 26 HTTP, 16

HTTP2, 17

httpd.conf, 162

HTTP-fejléc, 63, 203

HyTime, 22, 24

<img>, 109

<input type="color">, 226

<input type=" date">, 222

<input type="datetime">, 222

<input type="momh">, 222

<input type="search">, 225

<input type="time">, 223

<input type="url">, 215

<input type="week">, 223

időbélyeg, 170

időpont, 254

ikon, 68

lmage.onload, lll

img, 14

INCLUDE, 22

lndexed Database API, 192

IndexedDB, 192

információs sáv, 169

input type, 49

inpur.value, 218

Imermedia, 20

Internet Explorer, 23, 163

ismeretlen elemek, 73

itemscope, 233, 237, 246

itemtype, 233, 237, 246

i Tunes Plus, 130

J

jegyzékfájl, 195, 197

jelenréstükröző elemek, 71

jQuery Ul, 221

Index l 275

K

kapcsolat nélküli webalkalmazás, , 46, 195 karakterkódolás, 62, 64 kategória-kulcsszavak, 70 Képek, 109 képernyőolvasó, 86 képkocka, 124 keresés, 70 keresőmezők, 224 key(), 186 kifejezett szakasz, 198 kitőltési stílus, 95 kodek,41 kódolás, 143 koordináták, 170 kör, 119 korlátozott trükköző mód, 59 körvonalstílus, 95 kötegelt kódolás, 143, 153 kövér lábléc, 88 kritikák, 259 kulcs-érrék párok, 185 külső erőforrásra mutató hivatkozások, 65

L

<linb, 65 lábléc, 72, 87 LAME, 129 lang, 61 láthatatlan adatok, 250 latitude, 170 leképezési mód, 58 lépésköz, 218 léptetőmező, 217, 219 levélcsomópont, 60 libvp8, 155 limited quirks mode, 59 lineTo(), 98 Local Shared Objects, 182 localStorage, 45, 184, 185 Local Storage, 184

276 l Index

longitude, 170 LSO, 182

M

<mark>, 72 <meta>, 62, 251 <meta charset>, 64 <meta http-equiv>, 64 majdnem szabványkövető mód, 58 manifest, 195, 196 maximumAge, 174 metaadatok, 61 Midas, 17 mikroadatok, 53, 230 mikroadatok adatmodellje, 232 mikroformátumok, 229 MIME-típusok, 13, 161 mkclean, 155, 157 Modernizr, 36, 168, 184 Modernizr.inputtypes, 51 morzsaútvonal, 68 Mosaic, 16 MouseEvent, 117 moveTo(), 98 Mozilla, 23 MPEG-1 Audio Layer 3, 129 MPEG-4, 122

N

<nav>, 71 navigációs sáv, 85, 86 navigator, 48, 168 navigator.geolocation, 168 nem trükköző mód, 58 Netscape Navigator, 23 NE TWORK:, 198 név-érték párok, 230, 232 nevesített kulcs, 185 nevesített tulajdonságok, 231 névtér, 232

no quirks mode, 58

noupdare, 202

nyelv, 61, 66

o

objekrumrároló, 192

offiine, 47, 195

Ogg, 122, 136, 143

oldalsáv, 72

OpenSearch, 70

p

parh, 98

pingback, 69

placeholder, 51, 210

pont jelölés, 240

pontosság, 174

posirion, 170

PosirionError, 171

PosirionOprions, 173, 175

preload, 158

progress, 201, 202

pubdare, 83

Q

QuickTime, 122

quirks mode, 58

QUOTA_EXCEEDED_ERR, 188

R

rajzkörnyezer, 94

rajzvászon, 37, 93

rajzvászon-koordinárák, 96

rajzvászonra írr szöveg, 38

RDFa, 229

rel, 65

rel = alrernare, 66

rel = "archives", 67

rel = "aurhor", 67

rel= "exrernal", 67

rel = "icon", 68

rel= "license", 68

rel="nexr", 67

rel = "nofollow", 68

rel = "noreferrer", 69

rel = "pingback", 69

rel = "prefetch ", 69

rel="prev", 67

rel = "search", 70

rel = "sidebar", 70

rel = "starr", 67

rel="srylesheer", 65

rel = "tag", 70

rel="up", 68

removeltem(), 186

Rich Snippets, 244

s

<section>, 71

<source>, 160

setltem(), 185

sizes, 68

skip link, 87

SLAC, 17

slider, 220

spinbox, 219

SQL, 191

standards mode, 58

step, 218

srepDown, 218

srepUp, 218

stíluslap, 66

starage esemény, 186

SrorageEvent, 187

stroke(), 99

strokeStyle, 95, 99

supporcs_canvas(), 37, 39

supporcs_geolocation(), 48

Index l 277

suppons_inpur_aurofocus(), 53 supports_input_placeholder(), 52 suppons_local_storage(), 45 supports_microdata_api(), 54 supports_offiine(), 47 supports_video(), 41 supports_web_workers(), 46 surround, 128 süti, 181 szabványkövető mód, 58 szakasz, 71 szakaszfejlécek, I 98 szál, 46 számok, 217 személyek, 236 szervezetek, 246 színállomás, 107 színátmenetek, 106 színválasztók, 226 szótár, 230 szöveg, 102 szöveg-alapvonal, 102 szülőcsomópont, 60

T

<rime>, 72, 83, 254 tanalék szakasz, 199 tanalomszimatolás, 14 tartalomrípus, 14 tartomány-utótag, 215 Technorati-címkék, 70 telefonszámok, 248 testvér, 60 textAlign, I 02 textBaseline, 102, 103 text/cache-manifest, 196 text/html, 26 Theora, 126 timeour, 174 timestamp, 170 rolltagfüggvény, 98 rrükköző mód, 58

278 l Index

type, 66, 160 rype="number", 217

u

ugróhivatkozás, 87 updateready, 202 URI, 215 URL, 215, 242 űrlap, 49 űrlapellenőrzés, 227 űrlapok,26,209 URL-minta, 200

userData, 182 útvonal, 98

v

-vcodec, 155 <video>, 40, 121, 131, 157 változó birsebességű kódolás, 129 value, 218 valueAsNumber, 218 videó, 40 Video for Everybody!, 40 videoformárumok, 41, 42 videokodekek, 123 videorárolók, 122 viszonyított betűmérer, 103 visszhangérresírés, 69 viszonyleíró elemek, 64 VML, 113 Vorbis, 130 VP8, 126

w

watchPosition(), 175 webcímek, 215 WebDB, 191 webes űrlapok, 26, 49, 209

WebM, 43, 123, 154 webmunkások, 45 WebSimpleDB, 192 Web SQL Database, 191 Web Srorage, 183 Web Worker API, 45 WGS84, 172 window.applicationCache, 201 window.applicationCache.

�swapCache(), 202 window.evenr, 187 window.onload, 110, 213 Worker, 46 World.Geodetic System, !72

x

x264, 126 XHTML,27 XHTML 1.0, 25 XHTML Extended Fo rrns, 26 XHTML névtér, 60 xml:lang, 61 xmlns jellemző, 60 XMosaic, 16

y

YUI, 221

A szerzőről

Mark Pilgrim fejlesztési tanácsadóként dolgozik a Google-nél; a szakterületét a nyílt forrás és a nyílt szabványok jelentik. Mark szám os műszaki témájú könyv szerzője; eddig megjelent kötetei között olyanok találhatók, mint a Greasemonkey Hacks (O'Reilly) a Dive lnto Python (APress) vagy a Dive lnto Accessibility. (Ez utóbbi egy szabadon hozzáférhető elektronikus tanfolyam a webes tartalmak akadálymentesítéséről.) Mark Észak-Karotinában él feleségével, két fiával és nagy, nyáladzó kutyájával.