Komu patří data atributy v HTML?

HTML5 přináší data atributy. Jakékoliv značce můžete přidat libovolný počet různých atributů
  data-cokoliv="vaše data",
ke kterým můžete přistupovat přes jednoduché API
  element.dataset["cokoliv"].

HTML5 se tak snaží specifikovat (sjednotit), co někteří kodéři dělají již dávno (přidávají si vlastní datové atributy pro potřeby svých skriptů).

Pokud by se totiž nešvar vlastních atributů rozmohl, tak nejenže časem ubude validních stránek (to by až tolik nevadilo), ale objeví se počet konfliktů, kdy atribut používaný uživatelem A je v konfliktu s atributem frameworku B a obojí je v konfliktu s připravovaným atributem další verze značkovacího jazyka.

HTML5 tedy vymezuje hranice a říká: "S data-* si dělejte co chcete, ale nikam jinam už nesahejte." Z data-* atributů se tak stává místo s cedulí "Zde jsou lvi", kterému se validátory budou vyhýbat jako čert kříži.

Otázkou je, komu toto nově uvolněné místo vlastně patří. Specifikace k tomu říká:

Data atributy jsou určeny k ukládání dat patřících stránce nebo aplikaci, pro které neexistují vhodnější značky a atributy.

Vzpomínám si, že ta formulace měla uchovat data atributy čisté a nezaplevelené pro koncového vývojáře a měla být odvedena pozornost např. komunity okolo mikroformátů, aby je nevzala útokem. Toť idea.

Nebude asi překvapením, že se v diskusním listu mikroformátů objevily reakce "hurá, to se nám hodí" vedle reakcí "ne, to není pro nás".

Specifikace jen těžko určí, kdo má nebo nemá které atributy používat. Teprve čas ukáže, zda si nově objevenou zemi nějaký dobyvatel nezabere pro sebe. Při dnešním počtu JavaScriptových frameworků není problém, "zaplevelit" data atributy desítkami předdefinovaných názvů (a vemte v úvahu, že na jednom webu se často používá frameworků několik nebo alespoň jeden framework s několika pluginy) . Podobně, pokud by data atributy nakonec použily mikroformáty.

Je to trochu podobné se zavedením značky object (embed). Otevřela bránu do nové země, nikdo netušil, k čemu všemu může začít sloužit a dnes se zpožděním se zavádí značky video a audio, ačkoliv mohly být zavedené už dávno, pokud by se média od začátku necpala do nejsnazšího místa, kam to šlo, čili do objectu.

Data atributy jsou snadné místo pro rozšíření HTML, že snazší už být nemůže, ale to není jejich účel. Mají sloužit pro uchovávání dat, která mají význam pro kód koncové webové aplikace, nikoliv pro data, která budou mít význam napříč celým Webem.

A komu patří data atributy v HTML podle vás? Koncovým vývojářům nebo autorům frameworků?

Další čtení: John Resig: HTML 5 data- Attributes

Open Web podcasty nejen o HTML5

Nedávno byla odstartována serie Open Web podcastů. Stojí za nimi Dion Almaer (Ajaxian), John Resig (jQuery) a Alex Russel (Dojo toolkit). První podcast byl věnovaný mj. HTML5, druhý podcast se věnoval JavaScriptu.

Jedná se o zajímavý zdroj informací (vedle rovněž nedávno založeného Standards Suck), tedy pokud vám nevadí, že jednou kromě rychlého pročtení článku musíte poslouchat půlhodinový až hodinový stream, abyste se něco dozvěděli (pokud spěchám, tak mi to pěkně vadí, tyhlety podcasty, ale pro zpestření je to zajímavé).

Zároveň na blogu WHATWG odstartoval Mark Pilgrim sérii týdenních článků, ve kterých shrnuje, co se právě okolo HTML5 děje.

O informace z oblasti webových technologií není tohle léto nouze.

HTML5 parser v JavaScriptu

Henri Sivonen, autor experimentálního HTML5 validátoru (resp. conformance checkeru), přeložil pomocí Google Web Toolkitu svůj parser psaný v Javě do JavaScriptu. Na adrese livedom.validator.nu tak můžete snadno experimentovat s HTML5 parserem, aniž byste museli cokoliv instalovat.

Zajímavé není parsování validního kódu (zde výsledek asi nikoho nepřekvapí), ale právě parsování těch fragmentů HTML, které bylo v předcházejících specifikacích nedefinované. Nástroj není ani tak zajímavý pro webdesignery (ti si píší svůj kód stále stejně a zda prohlížeč akceptuje i jiný kód, jim může být v zásadě jedno), ale hlavně pro výrobce prohlížečů, autory parserů a knihoven pracujících s HTML.

Pokud se výrobci prohlížečů na HTML5 parseru shodnou (a je to skutečně možné, byť ne nevyhnutelné), bude se jednat o jednotný způsob parsování HTML.

Specifikace HTML5 parseru se stále dolaďuje a Henri svůj parser podle specifikace průběžně upravuje. Nejedná se o jediný existující HTML5 parser, existuje další projekt v Pythonu a experimentuje se i s Ruby nebo C#.

(Zdroj: blog.whatwg.org)

Firefox 3.1 s podporou videa, Opera zatím jen experimentální buildy

Připravovaná nová řada Firefoxu 3.1 již podporuje HTML5 značky <video> a <audio>. Až donedávna byla jejich podpora dostupná pouze v neoficiálních verzích Firefoxu, nyní jej obsahují pravidelné vývojové verze řady 3.1. První stabilní verze řady 3.1 je odhadována na konec roku.

Podpora ve Firefoxu zahrnuje přehrávání formátů Ogg Vorbis (zvuk) a Ogg Theora (video) podobně, jako plánuje prohlížeč Opera.

Předpokládám, že se obnoví diskuse o nalezení společného kodeku, která se zatím veřejně nikam dál neposunula. Ian Hickson sdělil, že v tomto směru probíhají neveřejná jednání. Víc se neví.

Vývojář Firefoxu Robert O'Callahan tvrdí, že je třeba tlačit na Microsoft a Apple, aby implementovali Ogg rovněž (což nebude jednoduché ne-li nemožné), zároveň vývojáři Firefoxu pracují i na univerzální podpoře nainstalovaných kodeků na uživatelově počítači (skrze Directshow, Quicktime a GStreamer).

Zároveň i Opera uvolnila další experimentální build s podporou značek <video> a <audio>.

Když jsem se loni ptal Který prohlížeč první implementuje video?, tipoval jsem právě Operu, která s implementací začala jako první (odhadem již před rokem a půl!). K mému překvapení ji zatím předběhlo jak Safari, tak to vypadá, že brzy i Firefox.

Opera zatím nezařadila podporu ani do vývojových verzí a pouze jednou za několik měsíců vydá speciální vývojový build. Buď řeší nějaké implementační problémy nebo to má prostě jen nízkou prioritu.

Aktualizováno: Na komentář Applu k problematice kodeku upozorňuje server Ajaxian.

Proč v HTML5 není univerzální odkaz

Eric Meyer již nějaký čas navrhuje začlenění univerzálního odkazu do HTML5. Tedy aby přidáním atributu href se mohla jakákoliv značka stát odkazem. Myšlenka to není nijak nová, její první návrh jsem našel již z roku 1994. Eric přistupuje k problému zodpovědně, sepsal use cases pro jednotlivé případy a naposledy vytvořil i zajímavé demo.

Nicméně tato vlastnost se do HTML5 s největší pravděpodobností nedostane.

Odpovědí na otázku: "Proč tomu tak je?" není (jak někdo posledně napsal v komentářích) neochota podobat se XHTML2, které univerzální odkaz obsahuje, ale zpětná vazba implementátorů.

Ian Hickson k tomu poznamenal:

Otázka globálního atributu href="" se objevuje znovu a znovu. Existuje pro něj řada oprávněných use case, např. možnost udělat odkaz ze všech buněk řádků tabulky nebo vytvořit banerovou reklamu jako jeden blokový odkaz.

Bohužel implementátoři mi znovu a znovu opakují, že globální href="" je špatný nápad a oni jsou těmi, kdo má poslední slovo, a proto se nedá svítit.

Ian Hickson kdysi pravdivě (a trochu smutně) prohlásil, že jeho moc jako editora specifikace HTML5 sahá jen tak daleko, dokud specifikuje to, co by implementátoři jinak stejně implementovali. Zamyslete se nad tím a pochopíte nejen tento příklad, ale i řadu dalších věcí okolo vývoje HTML5.

A pokud v (X)HTML univerzální odkaz opravdu chcete, zeptejte se vývojářů vašeho prohlížeče, proč jej v něm nelze implementovat? Ať vám pěkně vysvětlí proč.

Mezi dalšími přírustky jsou i outerHTML a insertAdjacentHTML

Ve specifikaci HTML5 se dnes v noci objevily i outerHTML a metoda insertAdjacentHTML. Obě vlastnosti byly před časem zavedeny v Internet Exploreru a fungují pouze v HTML dokumentech, narozdíl od innerHTML, které funguje i v XML dokumentech.

Nenašel jsem zatím zdůvodnění, proč byly do specifikace zahnuty. Mám za to, že obě implementoval pouze a jen Internet Explorer. (Naopak třeba innerHTML bylo zahrnuto již dávno, protože je implementují i další prohlížeče a na webu se běžně používá.)

Ian Hickson ve specifikaci ponechává jen věci, o kterých je přesvědčen, že je prohlížeče budou implementovat. Proto buď má vyjádření od ostatních prohlížečů, že implementují i tato rozšíření, nebo na takové vyjádření právě čeká a podle výsledku případně obě metody opět odstraní.

Dostane atribut alt složené závorky?

Diskuse okolo (ne)povinnosti atributu ALT u obrázků stále pokračuje, obě strany se stále nepochopily a nemají k sobě o moc blíže. V takové situaci: "Babo raď!"

Babská rada (i když jejím původcem je asi Ian Hickson s Davidem Baronem) se snaží o nový pohled, který má překonat onu spornou oblast, když obrázek neobsahuje textovou informaci, a učinit ji lépe přístupnou.

Tedy obrázek, který textovou informaci buď nenese (resp. nese, ale ta se nevztahuje k obsahu), nebo tato informace není prostě známá (např. uživatel nahrál sadu fotek z dovolené do fotogalerie a webová fotogalerie nezná textovou alternativu fotek, ačkoliv fotografie by textovou alternativu mohly mít).

V tuto chvíli konzervativní strana tvrdí, že je nutné buď zadat prázdný alt nebo jej něčím vyplnit (alt="Photo"). Druhá strana by alt naopak vypustila.

Ona babská rada snažící se o kompromis v takovém případě navrhuje alt vyplnit, ale vložit jej do složených závorek, např alt="{Photo}". Tím by alt byl poskytnut, ale je zdůrazněno, že neobsahuje textový ekvivalent obrázku (což mohou na základě závorek hlasové čtečky rozpoznat).

Použití ve spojení s novou HTML5 značkou figure, která páruje obrázek s textem by pak mohlo vypadat takto (zde je textová alternativa obrázku uložena ve značce legend a alt obsahuje pouze planý text ve složených závorkách):

<figure>
<img src="foto-2008-08-10-145.jpg" alt="{photo}">
<legend>Péťa překonávající pod stolem svůj osobní rekord v počtu vypitých piv</legend>
</figure>

Jedná se zatím jen o námět do diskuse. Uvidíme, zda pomůže celý spor vyřešit.