Hlavní navigace

Webové aplikace podle WHATWG

10. 4. 2007
Doba čtení: 11 minut

Sdílet

 Autor: 29
Ve druhém článku o skupině WHATWG se podíváme na zoubek specifikaci Web Applications 1.0. Ta je vlastně naplněním cílů skupiny - tj. kodifikací současné praxe webových prohlížečů a rozšířením HTML o další prvky. Zamyslíme se také nad tím, zda má WHATWG šanci opravdu ovlivnit vývoj webu.

Web Applications 1.0

Oproti specifikaci Web Forms 2.0 popsané v minulém článku je specifikace Web Applications 1.0 podstatně rozsáhlejší – ostatně ve své finální verzi bude celou specifikaci Web Forms 2.0 obsahovat. Web Applications 1.0 je v podstatě naplněním cílů WHATWG – tj. kodifikací současné praxe webových prohlížečů a rozšířením HTML o další prvky.

Poměrně významný a pro mnohé potěšující je fakt, že mnohé z novinek Web Applications 1.0 už jsou dnes prohlížeči implementovány. Aktivní jsou v tomto směru především Opera a Firefox. Aktuální přehled stavu implementace najdete na wiki WHATWG.

Pojďme se podívat, co zajímavého specifikace Web Applications 1.0 přináší.

HTML, nebo XHTML?

O sporu HTML vs. XHTML už toho bylo napsáno mnoho. Kterou cestou se vydává Web Applications 1.0? Poněkud pragmaticky oběma. Ian Hickson sice silně preferuje HTML, ale zároveň nepochybuje o tom, že spousta lidí se bude chtít vydat cestou XHTML, a pro interoperabilitu je lepší, pokud budou kodifikovány cesty obě. Specifikace je tedy psána tak, aby ji bylo možno použít jak s XML, tak s HTML syntaxí. Jazyk, který specifikace definuje, je pak často nazýván HTML5, resp. XHTML5.

V případě HTML syntaxe je na místě otázka, co to vlastně je. Specifikace HTML od W3C říkají, že HTML je aplikace SGML, ale ve skutečnosti žádný existující prohlížeč SGML úplně neimplementuje a jazyky definované implementacemi prohlížečů se od „HTML dle W3C“ podstatně liší. Web Applications 1.0 proto syntaxi HTML zcela redefinuje (už nikoliv jako aplikaci SGML) a specifikuje ji do nejmenších detailů, včetně zpracování chybných dokumentů. Na základě této definice už dokonce vznikla první implementace v Pythonu.

Ze specifických vlastností HTML5 stojí za zmínku nový způsob deklarace kódování dokumentu ( <meta charset="kódování">) a zkrácení <!DOCTYPE> deklarace na jednoduché <!DOCTYPE html> (což ve všech důležitých současných prohlížečích stačí k vyvolání režimu zpracování stránky dle standardů), které už nemá význam deklarace typu dokumentu v SGML. Cílem je mimo jiné omezit množství kódu v hlavičce stránek, který většina autorů bezmyšlenkovitě kopíruje.

Stávající elementy HTML

Mnoho existujících elementů v HTML má poněkud nejasnou sémantiku a u některých není příliš šťastně definován jejich povolený obsah. Web Applications 1.0 se snaží situaci napravit, tj. sémantiku a povolený obsah elementů zpřesnit. Specifikace ale nepokrývá všechny elementy a atributy HTML 4.01, zejména některé označené jako „deprecated“, ponechává nedefinované (více viz přehled zrušených atributů a elementů na wiki WHATWG). Spolu s definicí elementů a jejich atributů specifikace definuje i jejich objektový model (DOM rozhraní) a události, které elementy mohou vyvolat.

Kodifikace rozšíření

Kromě standardizovaných elementů, atributů a API DOM podporují dnešní prohlížeče několik syntaktických rozšíření, objektů a rozhraní, které standardizovány nikde nejsou, ale v praxi je tvůrci obsahu běžně používají. Web Applications se snaží zavést pořádek i v této oblasti a standardizuje chování následujících rozšíření HTML/DOM:

Sekce

Jedním z výsledků průzkumu v databázi dokumentů indexovaných Googlem, který prováděl Ian Hickson, bylo zjištění, že spousta stránek má podobnou strukturu – např. velká část obsahuje navigační část nebo patičku. Web Applications proto definuje nové elementy, které tyto běžné části stránek – v terminologii specifikace sekce – vyznačují. Z pohledu layoutu se tyto elementy chovají podobně jako dnešní <div>, ale nesou s sebou sémantickou informaci navíc. Ta může být využita např. při zařazování stránky do databáze vyhledávačů, ale i prohlížečem (volba „skrýt navigaci“ apod.).

Definované sekce jsou: <body> , <section> , <nav> , <article> , <blockquote> , <aside> , <h1>...<h6> , <header> ,<footer> a <address> . Element <section> slouží pro obecné sekce (např. kapitoly delších dokumentů), <article> pro vyznačení samostatných částí obsahu (text článku, komentáře apod.), <aside> pro vyznačení textu s nějakým vztahem k textu obklopujícímu, který ale není součástí jeho obsahu (např. poznámky). Elementy <h1></h6> a <header> vyznačují nadpisy sekcí a mají mezi sebou komplikovanější vztah, do jehož rozboru se tu nebudu pouštět. Role zbývajících elementů je myslím zřejmá.

Interaktivní elementy

Nový element<details> slouží k definici „rozklikávací“ oblasti stránky. Vnořený element <legend> představuje nadpis této oblasti, zbytek obsahu elementu je pak obsah dostupný uživateli na vyžádání.

Element<datagrid> slouží k zobrazování stromů, seznamů a tabulek. Je poměrně silný a mj. umožňuje, aby data do mřížky byla dodávána přes javascriptový objekt implementující definované rozhraní. Ve spojení s  XMLHttpRequest em tak lze dodávat data dynamicky ze serveru, což se hodí zejména v případě, kdy je dat hodně a my je nechceme uživateli posílat všechna přímo ve stránce.

Pomocí elementu<menu> je ve spolupráci s dalšími elementy možné vytvořit menu: jak klasické aplikační, tak kontextové (to lze připojit k elementu atributem  contextmenu).

Další nové elementy

Nový element<meter> je určen na indikaci číselné hodnoty z předem známého rozsahu, jako je třeba zaplnění disku nebo oblíbenost článku na nějaké stupnici. Element<progress> vyjadřuje stav průběhu nějaké operace a má smysl jen při použití v aplikacích, kdy bude dynamicky updatován JavaScriptem.

Zajímavou novinkou je element <figure> , který řeší typickou situaci, kdy chceme do dokumentu vložit externí obsah (obrázek, applet apod.) zároveň s popiskem. Ve Web Applications 1.0 stačí příslušný element obsahu (např. <img>) doplnit popiskem v elementu <legend> a obklopit elementem  <figure>.

Elementy pro vkládání externího obsahu <iframe>, <img>, <object> + <param> zůstávají zachovány, vrací se ovšem také element <embed>. Novinkou je element<video> určený pro vkládání videa do stránky a jeho ovládání – obsahuje na to poměrně bohaté API. (Specifikace obsahuje i definici objektuAudio pro práci se zvuky, o elementu <audio> se uvažuje.)

Drobnostmi jsou nový element <dialog> , určený k vyznačování dialogů (např. konverzace na chatu),<m> na zvýraznění textu (např. zvýraznění klíčových slov při přístupu na stránky přes vyhledávač) a <time> , vyznačující čas.

Styly

Styly je nyní možné specifikovat nejen pro celý dokument, ale jen pro jeho část. Kdo někdy vkládal cizí komponenty (např. ovládací prvky od Yahoo) do své stránky a bojoval s tím, že mu styly komponenty stránku rozhodily, nebude o užitečnosti omezené platnosti stylů pochybovat. Atribut type už není u elementu <style> povinný a má výchozí hodnotu text/css (podobně je tomu i u elementu  script).

Atribut class

Atribut „class“ v HTML 4.01 nenese žádný sémantický význam. Poměrně kontroverzním rozhodnutím je možné mu ho v určitých případech přiřadit. Ve specifikaci jsou definované třídy „copyright“, „error“, „example“, „issue“, „note“, „search“ a „warning“ s celkem zřejmým sémantickým významem. Specifikace dále říká, že seznam známých tříd může být rozšiřován pomocí speciální stránky ve wiki WHATWG. Na poměrně důležitou specifikaci je to neobvykle flexibilní mechanismus, což něco vypovídá o stylu práce WHATWG.

Sekce o využití atributu class k sémantice je ve Web Applications 1.0 začleněna spíše jako experiment a je možné, že tato myšlenka bude v případě negativní zpětné vazby od implementátorů a autorů obsahu opuštěna.

Atribut ping

Element <a> se dočkal novinky v podobě atributu ping , obsahujícího jedno či více URL, která má prohlížeč „pingnout“, pokud uživatel na odkaz klikne. Mělo by to ušetřit přesměrování či javascriptové hacky v případech, kdy je potřeba vědět, že uživatel klikl na odkaz, a zároveň je cíl odkazu mimo kontrolu autora dokumentu.

Canvas

Webovým aplikacím dlouho chyběla možnost kreslení do oblasti stránky pomocí JavaScriptu, bez nutnosti nového natažení obrázku ze serveru. Tento problém se před několika lety rozhodl vyřešit Apple, když v prohlížeči Safari implementoval element <canvas>, fungující jako „malířské plátno“. Dnes <canvas> podporují i Firefox a Opera a pracovat s ním lze za pomoci knihovny i v IE. Specifikace Web Applications 1.0 obsahuje popis tohoto elementu. Nutno dodat, že <canvas> je určen pro kreslení do roviny (2D), ale někdy do budoucna se počítá i s 3D API, které bude pravděpodobně založeno na Open GL. (Samozřejmě i dnes je možné vykreslovat trojrozměrné obrázky pomocí rovinných operací, jen si vše musíte počítat sami.)

Pokud chcete vidět <canvas> v akci, na webu lze najít několik hezkých ukázek.

Session storage

Webové aplikace často potřebují ukládat data u klienta mezi jednotlivými požadavky a sezeními. Dnes se k tomuto účelu používají cookies, které jsou ale značně omezené – především svou maximální velikostí (4 kB na jeden cookie) a možností uchovávat jen textové řetězce. Webové aplikace již dnes potřebují ukládat větší a komplexnější data, a tato potřeba časem jistě poroste, zejména pokud se začnou prosazovat aplikace schopné pracovat v offline režimu. Web Applications proto přichází s novou technologií session storage, která ukládání dat u klientů řeší lépe. S touto technologií například nebude problém vytvořit webovou aplikaci pro přístup k e-mailové schránce, která bude fungovat, i když budete offline – budete si moci pročítat došlé maily a odpovídat na ně, přičemž odpovědi se odešlou, až se opět připojíte.

Session storage definuje dva nové objekty:window.sessionStorage a window.globalStorage . První slouží k uchovávání dat platných po dobu aktuální relace (tj. do zavření okna nebo panelu prohlížeče), druhý uchovává data dlouhodobější a je indexován podle domény s tím, že každá stránka smí přistupovat pouze k datům ze své domény, nebo domény nadřazené. Data mohou být libovolné javascriptové objekty a žádost o jejich uložení je vyjádřena přiřazením do vlastnosti objektu globalStorage resp. sessionStorage (např. sessionStorage.transactionID = 55, resp. globalStorage["example.com"].configuration = { theme: "blue"; articlesPerPage: 20 }). Načtení dat je vyjádřeno prostým použitím vlastnosti.

Narozdíl od cookies nejsou data implicitně posílána na server při každém požadavku, je potřeba použít JavaScript. Doporučená maximální velikost dat je 5 MB na každou doménu, ale toto číslo je velmi předběžné – čeká se na zpětnou vazbu od implementátorů. Zajímavá vlastnost je, že pokud jako doménu u objektu globalStorage uvedeme "" (prázdný řetězec), přistupujeme do sdíleného globálního prostoru, který mohou využívat stránky ze všech domén. Můžeme tak komunikovat mezi aplikacemi.

Komunikace se serverem a mezi aplikacemi

Častým problémem webových aplikací je notifikace o událostech ze serveru (např. když chceme v rozhraní webmailu upozornit uživatele na nový e-mail, nebo když ve webovém rozhraní chatovacímu klientu přijde zpráva). Dnes se na to nejčastěji používají dvě řešení: periodické dotazy na server (typicky přes objekt XMLHttpRequest) nebo skrytý <iframe>, kde je otevřeno dlouhodobé spojení na server, který v případě události pošle klientovi několik řádků JavaScriptu s instrukcemi pro update rozhraní. Obě řešení jsou v podstatě hacky a nejsou zdaleka ideální.

Web Applications 1.0 definuje nový element <event-source> , jehož atribut src odkazuje na URL, na kterém může server posílat klientské části události v jednoduchém formátu. Prohlížeč pak zajistí jejich vyvolání. Lze vyvolat jak konkrétní události na jednotlivých elementech v dokumentu („klikni na tlačítko s ID cancel-button“), tak poslat stránce obecná data, která zpracuje samotný element <event-source> v rámci ošetření události  onmessage.

Se serverovými událostmi souvisí i komunikace aplikací mezi sebou. Web Applications obsahuje definici nových rozhraní pro tuto funkcionalitu, ale tato část specifikace zatím není příliš stabilizována.

Typy dokumentů

Velká část obsahu na webu je servery zasílána označena špatným MIME typem. Příčin je několik: od nepořádku v MIME typech samotných přes obtížnou konfiguraci MIME typů pro uživatele nemající přístup k webovému serveru až po přehlížení HTTP hlavičky Content-Type Internet Explorerem. Ian Hickson zjišťování MIME typu pomocí Content-Type v mnoha situacích považuje za mrtvé, a Web Applications 1.0 proto obsahuje celou sekci věnovanou tomu, jak zjistit skutečný typ dokumentu. K Content-Type  se přitom přihlíží, ale v řadě případů není tato hlavička chápána jako autoritativní a skutečný typ je zjištěn sniffováním obsahu dokumentu.

Má WHATWG šanci?

Specifikace Web Forms 2.0 a Web Applications 1.0 nepochybně obsahují nemálo zajímavých funkcí, které tvůrcům webových aplikací mohou v mnohém ulehčit jejich práci. Otázkou ale je: Je toto správná cesta pro vývoj webu? A má WHATWG šanci své specifikace doopravdy prosadit?

Odpověď na první otázku je dle mého názoru kladná. „Velký redesign webu“, založený na XML, jak si ho představovalo W3C, se neuskutečnil a zřejmě neuskuteční. Současný web je závislý na HTML a není na světě síla, která by to mohla změnit. Jedinou šancí je postupnými kroky HTML vylepšovat a upravovat žádoucím směrem a smířit se s tím, že některé nepěkné vlastnosti v něm zkrátka zůstanou. A je jedině dobře, pokud se výrobci prohlížečů dokážou shodnout na tom, co na HTML upravovat, aby nedocházelo k nekompatibilitám jako v minulosti.

To, že další vývoj HTML má smysl, přiznalo i samo konzorcium W3C, když po letech znovu založilo pracovní skupinu pro vývoj HTML. Otázkou je, jaký vztah bude mít tato skupina k WHATWG. Vzniknou dvě rozdílné větve vývoje? Nebo nová skupina a WHATWG nějakým způsobem zkonvergují a výsledkem bude jedna cesta? Těžko soudit, ale zatím na obou stranách – zdá se – panuje dobrá vůle.

Osobně nejsem vznikem pracovní skupiny HTML ve W3C příliš nadšený – bojím se, že to přinese jen více byrokracie a politiky a ve svém důsledku to bude odvádět lidi od práce na specifikacích, které pod vlivem různých kompromisů nebudou tak kvalitní. W3C má na druhou stranu mnohem větší autoritu než „nějaká WHATWG“. Případná specifikace od W3C tak snad bude více respektována ze strany velkých firem a organizací. (Je ovšem otázka, do jaké míry je toto potřeba a zda nestačí, aby specifikace podpořili výrobci prohlížečů a Google, což se v případě WHATWG vcelku určitě stane.)

BRAND24

Velkou neznámou je v současnosti také účast Microsoftu, jakožto výrobce nejrozšířenějšího webového prohlížeče, v celém podniku. Zatím tato firma stála tiše stranou, pokud nepočítáme fakt, že její zaměstnanec Chris Willson je jedním ze dvou šéfů pracovní skupiny HTML ve W3C. To je ale spíš výsledek souhry okolností než strategický záměr Microsoftu.

Ať už vše dopadne jakkoliv, jisté je jedno: Je dobře, že vývoj webu nestagnuje jako v několika minulých letech, a věci se opět dávají do pohybu.

Uvítali byste větší cookies?

  • Ano, často.
    8 %
  • Ano, zřídka.
    17 %
  • Ne, takhle mi to stačí.
    60 %
  • Ne, cookies nepoužívám.
    14 %

Byl pro vás článek přínosný?

Autor článku

Autor studuje a zároveň trochu učí na MFF UK. Zajímají ho především programovací jazyky, problémy programování jako takového a webové aplikace.
Upozorníme vás na články, které by vám neměly uniknout (maximálně 2x týdně).