Proměny syntaxe HTML
Obsah
Související
HTML bude mít svou vlastní syntaxi. Co to znamená? Bude nutné přepisovat dějiny a zdrojové kódy webových stránek, nebo se vlastně nic zvláštního neděje? Tomu se budeme věnovat v této krátké stati.
Nahlédnutí do historie
HTML je od roku 1995, tedy prakticky od svého počátku, postaven na SGML syntaxi. SGML je metajazyk definovaný ISO normou 8879 z roku 1986. Obsahuje řadu nadbytečných věcí, jejichž vinou se pak jeví poněkud složitý. Možná proto si nezískal sympatie vývojářů webových prohlížečů, kteří SGML syntaxi do HTML parserů neimplementovali důsledně, ba právě naopak se soustředili na vůči syntaktickým prohřeškům tolerantní interpretaci HTML kódu.
Vytvořila se tedy díky prohlížečům zvláštní HTML syntaxe, která se v mnoha ohledech výrazně odchýlila od standardní SGML syntaxe. Je poměrně jednoduchá, velmi intuitivní a platí v ní přívětivé pravidlo: dovoleno jest vše – např. ampersand není potřeba zapisovat entitou, tagy lze míchat dle libosti, žádný element se nemusí ukončovat (on už se někde ukončí sám) atd. To mělo pronikavý vliv na počínání kodérů, kteří experimentovali a pozorovali: éto móžno i éto tože, vsjó charašó. Ze svých empirických poznatků pak vyvodili ten neblahý závěr, že HTML výtečně znají a nepotřebují studovat jakési specifikace. U většiny po čase zvítězila sebereflexe, jiní se naopak ve svém přesvědčení dokonce utvrdili natolik, že se pustili do psaní odborných publikací. Například Craig Swann a Greg Caines, autoři svérázné knihy Flash s využitím XML, která už z knihkupectví naštěstí zmizela, byli tak laskaví, že v ní zanechali i několik pozoruhodných úvah o HTML.
„Pro zobrazení takového nadpisu budete pravděpodobně chtít využít takové HTML tagy, jakými jsou <u>, <font> nebo <b>.“
Tato sentence ze strany 19 nás nemusí tolik zajímat, neboť se netýká syntaxe, ale rozhodně je nutné pozvednout varovně prst při čtení pasáže ze str. 32, v níž se praví, že na rozdíl od HTML, které vám umožňuje změnit pořadí tagů…
Toto HTML určitě neumožňuje! Změny v pořadí tagů by vedly k překřížení elementů, což by vážně porušilo strukturu dokumentu. Nebylo by totiž jasné, který element je „rodičem“, který „potomkem“ a který „sourozencem“, a tudíž by bylo zhola nemožné normálním způsobem sestavit objektový model dokumentu. (Petr Václavek má však na knihu docela příznivý názor.)
Na níže uvedené ukázce je několik zvláštností, které ji odlišují od běžného HTML kódu: a) u meta tagu chybí uzavírací závorka b) textový obsah elementů je vepsán mezi lomítka c) odpadl element body.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-2"
<title /Jedna paní povídala/
</head>
<p /Jedna paní povídala, že se něco stane./
</html>
Ano, i takto může vypadat korektní HTML kód, můžete si jej zvalidovat. PseudoHTML parsery prohlížečů jej však zpracují podle svých vlastních pravidel.
Kdybychom to tedy měli shrnout: proti SGML syntaxi stojí dva faktory – prvním z nich je relativní složitost SGML, druhým, souvisejícím a klíčovým je neochota SGML syntaxi respektovat. Toto všechno je třeba mít na paměti, abychom dobře pochopili, co stálo za fenomenálním nástupem XML.
V minulé dekádě se W3C rozhodlo nepokračovat ve vývoji HTML a nahradit jej novým jazykem, založeným na XML. Tento záměr byl diktován univerzalistickou snahou Konsorcia sjednotit značkovací jazyky pod jedním jednoduchým datovým formátem. Ona univerzalistická snaha ovšem nebyla samoúčelná, cílem bylo dosáhnout maximální konvertibility a umožnit tak snazší práci s daty.
Je asi zbytečné polemizovat, jestli by se XHTML uchytil, nebo ne. Nadšení pro něj sice bylo velké, leč jeho hlemýždí a chybně koncipovaný vývoj měl spolu s dalšími problémy za následek všeobecný úpadek zájmu o XHTML. Je-li polemika zbytečná, proč se nějakým XML, resp. XHTML vůbec zabývat? Protože měl mimořádný vliv na syntaxi HTML. Například se díky němu víceméně prosadilo nepoužívání velkých písmen (ne snad, že by to bylo důležité, ale dříve se malá písmena používala většinou jen pro hodnoty atributů). Někteří odborníci mu dokonce přičítají i zásluhu na celkové kultivaci kódu. XHTML se dokonce dostal tam, kde jej jeho odpůrci vidí asi nejméně rádi – do specifikace HTML 5.
Nahlédnutí do specifikace HTML 5
V předchozí části jsme si představili dosti tristní současnou situaci: na jedné straně nevyhovující HTML parsery prohlížečů, na straně druhé velké množství stránek, jejichž kód neodpovídá standardním syntaktickým pravidlům. Standardizátorům bylo jasné, že lpět na pravidlech, která se příliš nedodržují postrádá smysl, proto nejprve důkladně analyzovali podobu současných HTML kódů a jejich interpretaci v prohlížečích za účelem dokumentace stavu, který se v průběhu let na webu spontánně vytvořil. Tato dokumentace pak posloužila jako podklad pro navržení nových syntaktických pravidel, na která se nyní podíváme detailněji, protože si vskutku zaslouží pozornost.
Error handling
V otázce, jak zacházet s chybami, se přístup značkovacích jazyků rozchází, SGML tuto věc neupravuje, což asi není úplně ideální, neboť kodéři se chyb dopouští, a to celkem s lehkým srdcem, neboť spoléhají na to, že prohlížeče si s chybami poradí. Ty to sice zvládnou, ale dosažení interoperability stálo jejich vývojáře hodně úsilí.
„Všichni velcí výrobci prohlížečů dnes vkládají alespoň polovinu svých zdrojů přidělených na vývoj prohlížeče do reverzního inženýrství ostatních prohlížečů, aby zjistili, jak věci mají fungovat.“
Ian Hickson v rozhovoru pro xhtml.com
U XML je to nejjednodušší. Jakmile XML parser narazí na syntaktickou chybu, zpracovávání dokumentu se přeruší a konec. Úderné to kladivo na lajdácké kodéry, jenže… může se přihodit, že dokument bude porušen nebo (třeba nějakým všetečným softwarem) upraven do nevyhovující podoby, takové věci se někdy stávají s XHTML dokumenty a výsledkem je nezpracování dokumentu.
HTML 5 na to jde precizně. Nejen, že definuje syntaxi, ale také podrobně instruuje parsery, jak se mají vypořádat s chybami, na které narazí. Vezměme si za příklad entitu &hellip, jíž chybí, jak vidno, středník. Prohlížeče by ji měly přesto interpretovat jako tři tečky, což konec konců dělají už dnes, ale zřejmě v rozporu s dosud platící normou.
Velká a malá písmena
U HTML obecně platí, že velikost písmen se nerozlišuje. <BODY>, <body> i <Body> je tedy pořád to samé. Specifikace HTML 4 však u hodnot některých atributů (name, id, for, target, href, class) stanovuje výjimku – id="kap" a id="KAP" by tedy měly být dva unikátní identifikátory. Prohlížeče to ovšem, jak je jejich zvykem úplně nedodržují. Připravovaná specifikace HTML 5 proto tyto výjimky ruší, na druhé straně však zavádí jiné (_charset_, pattern).
Zvláštním případem jsou entity, kde na velikosti písmen rozhodně záleží. Nelze zaměňovat např. ‡ s † apod.!
DOCTYPE deklarace
Zkracuje se DOCTYPE deklarace. Nový tvar má mít podobu <!DOCTYPE HTML> (pro vygenerovaný kód je přípustná i delší varianta: <!DOCTYPE HTML SYSTEM "about: legacy-compat">). Uvádět DOCTYPE je teoreticky zbytečné, neboť elementy, atributy, entity jsou v HTML pevně stanoveny a DTD nelze upravovat, pouze ji opsat. Prakticky je to ale velice důležité, protože slouží jako přepínač mezi renderovacími režimy. Pokud bychom DOCTYPE deklaraci v kódu neuváděli, prohlížeče by stránky renderovali v režimu zpětné kompatibility, proto se standardizátoři rozhodli tuto deklaraci z HTML neodstranit a pouze ji zkrátili.
NET zápis
V HTML 4 by teoreticky šlo psát elementy úspornějším způsobem. Pomocí NET zápisu. Vypadalo by to následovně:
<strong /Te Deum laudamus/ místo <strong>Te Deum laudamus</strong>
Prakticky to samozřejmě nejde, poněvadž prohlížeče to nepodporují. Budoucí verze HTML už NET zápis, stejně jako ostatní nevyužívané SGML pomůcky, nepřipouští.
Rozdělení elementů
HTML 5 rozděluje elementy do pěti skupin:
- prázdné elementy (
area, base, br, col, command, embed, hr, img, input, keygen, link, meta, param, source) - CDATA elementy (
style, script) - RCDATA elementy (
title, textarea) - cizí elementy (elementy importované z SVG, XForms)
- normální elementy
Mnozí kodéři upřednostňují XHTML, aby jejich kód byl zpracovatelný XML nástroji, zároveň však nechtějí dopustit, aby jejich stránky byly nekompatibilní se staršími a některými současnými prohlížeči. Řeší to obvykle tak, že nastaví odesílání XHTML souborů s MIME typem text/html a vyhnou se koncovce .xhtml v názvu souboru. Tímto způsobem prohlížeče přinutí, aby XHTML kód zpracovávaly HTML parsery a je tak zachována jak kompatibilita, tak XML syntaxe. HTML parsery, ať už vyhovující nebo nevyhovující, se však potom kvůli tomu musí potýkat mimo jiné s koncovými lomítky, které u prázdných elementů nemají co dělat. A tak tedy, aby bylo vše v souladu, budou koncová lomítka u prázdných elementů povolena.
Některé stránky dnes nejsou validní jen kvůli tomu, že jejich interní CSS nebo JS kód obsahuje znaky & či <. Tato nepříjemnost bude v brzké budoucnosti zažehnána tím, že obsah elementů script a style bude parsery dle specifikace interpretován jako znaková data. Napůl stejně tomu bude i u elementů textarea a title, jen ampersand se zde bude muset i nadále zapisovat jako entita.
Kam to vede?
Jak známo specifikace HTML 5 je připravována ve dvou „gramatických“ variantách. Kromě staronové HTML syntaxe bude možno používat i XML syntaxi (tzv. XHTML 5). Není tato dvoukolejnost zbytečná? Možná ano. I když se XML používá k lecčemus, stále není ničím víc, než pouhým datovým formátem. Naproti tomu web je čím dál víc o aplikacích a je velkou otázkou, dá-li se XHTML pro takové věci uzpůsobit. XHTML je totiž limitovaný striktními pravidly, např. (podle úsudku autora) neumožňuje postupné vykreslování stránek (tzv. progresivní rendering). (XML to sice nezakazuje, jenže, aby bylo možné část obsahu stránky zobrazit, musí být stránka předběžně sestavena z neúplného kódu, k němuž je nutné si provizorně domyslet ty koncové tagy, ke kterým se parser ještě nedostal. A právě to je kamenem úrazu. Domýšlení koncových tagů v režii XML je těžko představitelné.) Další omezení jsou v XHTML u elementu noscript. Dokladů, že XHTML není příliš vhodný jako základní jazyk budoucích webových stránek, by se dalo jistě najít více, důležité je však sledovat trend vývoje. Ten je jednoznačný – vzrůstající dynamika, sílící důraz na interaktivitu (člověk si už pomalu nemůže na stránce ani kliknout bez obav, aby nespustil nějakou akci), čím dál sofistikovanější webové aplikace atd. Kam to spěje? K XHTML nejspíš ne. (Bohužel.)
Zdroje
Mohlo by vás také zajímat
-
Gaming na HDR monitoru: Stojí to za to?
12. srpna 2024 -
Monitory OLED: klíčové pojmy a funkce
13. května 2024 -
-
Jak zvýšit CTR vašeho e-mail marketingu
9. září 2024
Nejnovější
-
Jak chránit webové stránky před Web/AI Scrapingem
27. listopadu 2024 -
Jaký monitor je nejlepší k novému Macu Mini?
25. listopadu 2024 -
Výkonný a kompaktní: ASOME Max Studio s výjimečným poměrem cena/výkon
11. listopadu 2024 -
Šokující data od Microsoftu: Kyberútoky rostou o stovky procent!
8. listopadu 2024
Radek
Říj 15, 2009 v 10:09Tato problematika v mnoha lidech z nějakého důvodu vyvolává emoce a to tím větší, čím méně o ní vědí. Konečně to někdo rozebral věcně správně, bez obvyklých omylů a pověr a bez emocí. Nezbývá než se vším souhlasit a doufat v další rozumný vývoj.
v6ak
Říj 15, 2009 v 18:02No mám pocit, že od jedné verze Firefoxu (tuším 3.0) je postupné renderování podporováno. Ono to možné je – stačí použít event driven XML parser. Pravda, v případě, že se parser najednou dozví chybu, to bude menší problém. A nevím, jak jsou na tom ostatní prohlížeče. Ale nemožné to asi není.
Eric Force
Říj 16, 2009 v 9:49Pěkný a přínosný článek. Osobně si myslím, že jediná a skutečná šance jak udělat kvalitní a přínosné XHTML by bylo udělat tlustou čáru za současným vývojem a vykašlat se na zpětnou kompatibilitu a začít tzv. znovu. Nová jádra prohlížečů, nové specifikace, ale nemusela by se z toho aspoň dělat kaše beroucí ohledy na mnoho faktorů a omylů minulosti. Toto ale není samozřejmě možné, protože by zavládl na internetu dočasný chaos, přinášející ztráty a proto si myslím, že přes všechny snahy XHTML nakonec „odpadne“ a zbyde jen to dobré HTML…
kahi
Říj 17, 2009 v 12:15Díky, zajímavý článek. Mohl bys ještě vysvětlit, co Tě vedlo k poslednímu slovu? Proč by měl někdo to „X“ postrádat?
Pavel Salvet
Říj 18, 2009 v 18:14Co mě vedlo k poslednímu slovu? Moje preference. Ale toho si nevšímejte. Těch, kteří prosazují systematický, modularizovaný jazyk s nekomplikovanou syntaxí, je málo, brzy vymřou a přestanou si stěžovat.
SilentCry
Říj 19, 2009 v 13:27„“na rozdíl od HTML, které vám umožňuje změnit pořadí tagů…“ Toto HTML určitě neumožňuje!“ – toto je docela nepřesné. Např:
ahoj vytvori stejny vysledek jako ahoj, takze HTML zmenu poradi tagu umoznuje….
SilentCry
Říj 19, 2009 v 13:29Aha, tady nejsou videt tagy – ten priklad kodu byl:
{b}{i}ahoj{/i}{/b}
{i}{b}ahoj{/b}{/i}
nicmene, alespon je videt, ze vysledek je totozny…
Pavel Salvet
Říj 20, 2009 v 16:19Byla míněna taková změna v pořadí tagů, která by vedla k překřížení elementů. Můžete se ostatně podívat do oné knížky na udanou stránku.
Megaloman
Říj 25, 2009 v 20:32XHTML vzbuzuje ve spoustě lidí spoustu vášní i proto, že není tolerantní vůči syntaktickým chybám (pominu-li hromady dalších mýtů a polopravd).
Ale chtěl bych vidět Céčkaře (příp. jiného programátora), jak se vášnivě rozčiluje nad nějakým jazykem, protože v něm napsal syntakticky špatný kód a překladač mu jej nevzal!
Pokud chcete psát stránky v (X)HTML, pište jej validně v souladu s normou. Pokud nechcete, dělejte raději něco užitečného :-)
Miloslav Ponkrác
Lis 5, 2009 v 21:12XHTML je hlavně zbytečnost a truc W3C. To, že je XHTML lepší, nebo vhodnější pro webové stránky, to je věcí mnoha mýtů a polopravd.
Jeden z největších mýtů, kteří se snaží někteří lidé rozšířit je, že všichni nechtějí XHTML jen proto, že nedovoluje chyby. Je to ale lež.
Jak je to doopravdy: W3C zmršila a nikdy nedokázal řídit pořádně vývoj HTML. Namísto toho hledala chybu v HTML a ne u sebe. Protože všechnu vinu za svojí špatnou práci svedla na HTML, a nepoučila, vyvinula zcela nový, naprosto zbytečný jazyk XHTML a poslala ho do háje zcela stejně jako HTML. Nekompetence W3C totiž přetrvala. To je zcela pravdivý příběh.
Mezitím se objevil někdo, kdo byl trochu schopnější jménem Ian Hickson a začal řídit HTML daleko schopnějším způsobem, který o mnoho řádů přesahoval cokoli, co byli schopní vyprodukovat nekompetentní W3C. Tím to mělo XHTML spočítané, protože W3C svojí práci zkrátka neumí.
Aby to nebyla moc velká ostuda, převedl se vývoj HTML do W3C, nicméně za podmínek, který nedostal žádný jiný W3C projekt.
Kdyby W3C a webdesignéři nezbošťovali XHTML, nepřestali vidět realitu a nechtěli revolučně přebourat svět, mohlo tu dnes být XHTML a rozšířit se. Ale neschopnost přiznat chyby W3C a neschopnost přiznat chyby XHTML nakonec utáhlo XHTML smyčku.
To je celé a jednoduché a bez mýtů.
tiso
Lis 18, 2009 v 11:03„Mnozí kodéři upřednostňují XHTML, aby jejich kód byl zpracovatelný XML nástroji, zároveň však nechtějí dopustit, aby jejich stránky byly nekompatibilní se staršími a některými současnými prohlížeči. Řeší to obvykle tak, že nastaví odesílání XHTML souborů s MIME typem text/html a vyhnou se koncovce .xhtml v názvu souboru.“
Tá koncovka tam robí čo? Na nej záleží spracovateľnosť XML nástrojmi? Alebo zobrazenie v prehliadačoch?
Pavel Salvet
Lis 23, 2009 v 10:47V některých případech ovlivňuje MIME typ.