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.
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
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
AMIME-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
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 XHTML1.0
és az XHTML1.1
felváltására hivatott. A HTMLS olyan új szolgáltatásokat kínál, amelyek elengedhetetlenek a modern webalkalma zá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ük sé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ámo gatá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)• 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óz
kodá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 bizto sí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ít hetjü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ámaszkodjunkannak 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ájl neveket é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.
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ő ahttp://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 ahttp://diveintohtml5.orgl
címre, de vegyük figye lembe, 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
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 legfon tosabb fejléc neve Content-Type, és így néz ki:
Content-Type: text/html
A text/html az oldal "tartalomtípusa" (content type) vagy "MIME típusa". Ez a fejléc az egyeden dolog, ami meghatározza, hogy valójában mi lyen 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álko zunk 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 tesz szü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étre hoztá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.
A "nyílt terepen" fejlesztett szabványokban az az egyik legjobb, hogy visz szarnehetü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 le hetne, 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 olda lon leírt Üzenetválrás a "Nexr message" (Következő üzener) és "Previous message" {Előző üze net) hivatkozásokra kaninrva köverherő.
tudassa velem. Tudom, hogy a képformátum szempontjából ködös meg oldá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 rendsze reken 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.
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
XMosaic 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ő webki
szolgá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
WWWterületén, mivel öt oldalt működtetett a webkiszolgálóján, méghozzá példát
lanul 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 tet
szőleges méretben) szöveges dokumentumokba. Amikor aztán megérke
zik a HTTP2, a beágyazott dokumentum formárumát külön meg le
hetne 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áz
latot 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 bu tá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 Berners Lee 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 ak kor 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 tartalom tí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 tet sző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ámoga tandó 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 doku mentumleí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 to vá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 szab vá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 hi bá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 dokumentum ban, 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 vicleoszab ványok egymástól függetlenül fejlődhetnének, ami mindkettőn segítene. Legyen az
IMG
címkeINCLUDE,
és mutasson tetszőleges dokumentumtÍ pusra. Vagy legyenEMBED,
ha azINCLUDE
úgy hangzana, mintha cpp beá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ítot tá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 azICON
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 va laha 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
tml}.
• 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. Kanyar gós, itt-ott csomókkal és vadhajtásokkal tarkított - evolúciós fája jócs ká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ör tem 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 egy szerre 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 felismer
hető formában. A Netscape Navigator fejlesztését 1998-ban abbahagy tá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
vissza, ahol a programot még asztaltémákkal és egy flipperjátékkal cso magoltá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 Vilá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 Win dows 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 "web szabvá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 dol goztak, 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épsze rű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 elfo gadott 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 kombi ná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 megol dá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értelme zett tartalmat. 17 évvel később még mindig küszködünk a tartalom kiszimato lá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-alkalma zá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 "ösz szefoglalja 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 dokumen tumban 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 bi zonyos 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 HTML oldalakat 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. Mi vel 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ég zetes 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 fel dolgozá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ő olda lak 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ítet tek" 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 jellem zőé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 figyel men kívül hagyja a leírókód hibáit, és soha nem figyelmezteti a végfelhasz ná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 hibake zelé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-olda laink" 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 szab vá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ány tervezeteket 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ű alkalma zá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/webapps
cdfwslsummary) a W3C tagjai ezt írták: " A W3C jelenleg nem kíván semmi
lyen 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 web-alk-alm-azások-at 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üle tett 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 web bö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ütt mű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 szab vá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 MIME tí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 hi bá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 mun kaó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 jelen tő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 Webforms csapat terve- elmondásuk szerint- a HTML-űrlapok bövítése.
A W3C újonnan felállított HTML-munkacsoportjának egyik legelső dön té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.
További olvasmányok
• 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.
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 hasz nálatára, ha a régebbi böngészők nem támogatják?". A kérdés azonban félre vezető, ugyanis a HTML5 nem egyetlen nagy egység, hanem önálló szolgál tatá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 olda lon 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ó objek tumok 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ön gé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óAPI támogatásának vizsgálatára pár oldallal később, a fejezet "Helymeg hatá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 kide rí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 ál lí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ügg vé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
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 hasz nálhatunk". A rajzvászon egy téglalap alakú terület az oldalon, amire JavaScript kó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ű tag fü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, ame lyek 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átmene teket ("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 Explo rerben 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 rajz vá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égez nü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.
