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őinek: "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/ htm l
MIME-típussal szalgálták ki.
1. fejezet
Hogyan jutottunk el idáig? l 27
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
/> -csupán az oldalak töredéke használja az
/> vagy
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. w3. org/2004/04/webapps-cdfws/
paperslopera. htm/): A következő hét alapelv jelképezi, hogy mi mit tartunk a legfontosabb követelményeknek:
28 l Hogyan jutottunk el idáig?
l.
fejezet
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
Afelhaszná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. 1.
fejezet
Hogyan jutottunk el idáig? l
29
Nyíltfolyamat 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
(http:llwww.w3.org/2004104/webapps cdfwslsummary) a W3C tagjai ezt írták: " A W3C jelenleg nem kíván semmi
szavaztak. A műhely összefoglalójában
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 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ü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. orginewsistart): 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.
30 l Hogyan jutottunk el idáig?
1.
fejezet
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ő
l.
fejezet
Hogyan jutottunk el idáig? l
31
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, a mely 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 X ML-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
32
l Hogyan jutottunk el idáig?
1.
fejezet
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 űrlapnyelv. 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 www. w3.
(http:/1
org/2009/06/xhtml-faq. htm/):
Amikor a W3C 2007 márciusában bejelentette a HTML- és XHTML 2-munkacsoporrok megalakítását, jelezte, hogy folya matosan 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.
1. fejezet
Hogyan jutottunk el idáig?
l
33
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.
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 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 -t, minden - 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ó 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 "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 ú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: <meta char set= •utf-8 "> Dive into HTMLS
<script src="modernizr .min. js"X/script>
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 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 l else { ll l
{
alakzatokat!
nincs elérhető beépített rajzvászon-támogatás
:(
A rajzvászon A HTML5 a