Na serveru w3schools.com se objevil stručný přehled značek HTML5. Pokud v HTML5 píšete, může se vám hodit, je rozhodně přehlednější než dolovat některé věci ze specifikace.
Pamatujte ale při tom, že W3schools nemá nic společného s W3C (kromě dvou znaků v názvu) a může se stát, že údaje na něm budou zastaralé nebo nepřesné (což zatím místy skutečně jsou).
Pokud se podíváte na pravé dva sloupce tabulky s přehledem značek, získáte představu, kolik značek je v HTML5 nových, a kolik jich naopak bylo vypuštěno. Pokud chcete srovnávat i s dalšími verzemi, použijte přehled značek Jense Meierta.
neděle 31. srpna 2008
sobota 30. srpna 2008
Firefox dokáže překreslit obsah videa do canvasu
Do dalších verzí Firefoxu se dostane malé rozšíření canvasu. Konkrétně metody drawImage. Ta jako argument dostane existující obrázek, který vykreslí do canvasu. Dobře poslouží, pokud do canvasu chceme vykreslit komplikovaný obrázek, a protože nechceme začíst na zelené louce, hodláme vyjít z již existujícího obrázku.
Vývojáři Firefoxu metodu rozšíříli, takže dokáže pracovat nejen s obrázkem, ale i s videem vykreslovaným značkou video. Při zavolání drawImage v takovém případě dojde k vykreslení aktuálního zobrazeného snímku videa do canvasu.
Ian Hickson se dosud nevyjářil, zda toto rozšíření bude zahrnuto do specifikace či nikoliv.
Vývojáři Firefoxu metodu rozšíříli, takže dokáže pracovat nejen s obrázkem, ale i s videem vykreslovaným značkou video. Při zavolání drawImage v takovém případě dojde k vykreslení aktuálního zobrazeného snímku videa do canvasu.
Ian Hickson se dosud nevyjářil, zda toto rozšíření bude zahrnuto do specifikace či nikoliv.
(Via whatwg.org)
pátek 29. srpna 2008
Rozhovor s Ianem Hicksonem na Techrepublic
Na Techrepublic vyšel rozhovor s Ianem Hicksonem. Ian se rozepisuje o termínu dokončení HTML5 a vysvětluje "proč to celé trvá tak dlouho", popisuje, které části HTML5 vyvolaly rozporuplné reakce (např. probíhající kauza atributu alt), a jaké jsou největší úspěchy.
Několik citací:
Několik citací:
We’re also fully intending to do something that none of the aforementioned specs really did, which is to have a comprehensive test suite that we will require at least two browsers to completely pass before we call it a day.
If one were to try to write such a test suite for HTML4 and DOM2 HTML, one would find that there isn’t even one browser that fully implements those specifications, let alone two.
The problem is that if we ever specify something that the browser vendors disagree with, they will just ignore the specification, and we might as well go home. If we write a specification that is ignored, we’re just fiction writers.
The features that don’t end up being used will be cut. We’ve already dropped a lot of things over the years, and I’m sure we’ll drop more.Celý rozhovor HTML 5 Editor Ian Hickson discusses features, pain points, adoption rate, and more si můžete přečíst na Techrepublic.com.com (netušíte někdo, proč má v adrese 2x dotcom?)
čtvrtek 28. srpna 2008
Firefox asi implementuje window.toStaticHTML z IE8
Součástí přicházejícího Internet Exploreru 8 je i nová metoda windows.toStaticHTML. Ta z jakéhokoliv HTML fragmentu udělá fragment bezpečný, zcela zbavený skriptů. Ve světě dennodenních XSS problémů je to užitečná věc. Zejména, protože se blíží crossdomain-AJAX (samostatná specifikace) a crossdomain zasílání zpráv mezi okny (součástí HTML5).
Také vývojáři Firefoxu uvažují o implementaci toStaticHTML. V tuto chvíli se jedná o nestandardní rozšíření ze strany prohlížečů, pokud se ovšem k implementaci rozhodne i Firefox (a pravděpodobně se rozhodne), bude toStaticHTML na tuty zařazeno do specifikace HTML5.
Proč? Historie nás poučila, že pokud cokoliv implementují dva prohlížeče na vrcholu žebříčku popularity (a to IE a FF jsou), ostatní ono "cokoliv" implementují rovněž. A je lepší, pokud to rovnou implementují správně (resp. interoperabilně = každý stejně), než aby několik let po implementaci vychytávaly chyby.
Všimněte si, nakolik se dnešní situace liší od doby před takovými šesti lety, kterou někteří z nás asi ještě pamatují. Tenkrát často trvalo roky, než se jeden prohlížeč odhodlal k implementace nestandardního rozšíření jiného prohlížeče (document.all, innerHTML, contenteditable a další). Dnes jde vše neuvěřitelně rychle (toStaticHTML byla oznámena letos na jaře a ještě ji nikdo nestačil ani začít používat). Prohlížeče jsou pod vzájemným drobnohledem a nechtějí si nechat ujet vlak.
Pokud se implementace včas podchytí, může i tato nestandardní situace proběhnout zcela bez problému a webdesigneři nakonec budou jásat nad novou vlastností webových standardů, aniž by měli potuchy, že se ve skutečnosti jedná o standardizované nestandardní rozšíření. To jim je ostatně šumafuk.
Také vývojáři Firefoxu uvažují o implementaci toStaticHTML. V tuto chvíli se jedná o nestandardní rozšíření ze strany prohlížečů, pokud se ovšem k implementaci rozhodne i Firefox (a pravděpodobně se rozhodne), bude toStaticHTML na tuty zařazeno do specifikace HTML5.
Proč? Historie nás poučila, že pokud cokoliv implementují dva prohlížeče na vrcholu žebříčku popularity (a to IE a FF jsou), ostatní ono "cokoliv" implementují rovněž. A je lepší, pokud to rovnou implementují správně (resp. interoperabilně = každý stejně), než aby několik let po implementaci vychytávaly chyby.
Všimněte si, nakolik se dnešní situace liší od doby před takovými šesti lety, kterou někteří z nás asi ještě pamatují. Tenkrát často trvalo roky, než se jeden prohlížeč odhodlal k implementace nestandardního rozšíření jiného prohlížeče (document.all, innerHTML, contenteditable a další). Dnes jde vše neuvěřitelně rychle (toStaticHTML byla oznámena letos na jaře a ještě ji nikdo nestačil ani začít používat). Prohlížeče jsou pod vzájemným drobnohledem a nechtějí si nechat ujet vlak.
Pokud se implementace včas podchytí, může i tato nestandardní situace proběhnout zcela bez problému a webdesigneři nakonec budou jásat nad novou vlastností webových standardů, aniž by měli potuchy, že se ve skutečnosti jedná o standardizované nestandardní rozšíření. To jim je ostatně šumafuk.
středa 27. srpna 2008
Na Web přijde JavaScript s více vlákny
Jednovláknovost JavaScriptu ve webových prohlížečích skýtá jistá omezení. Přitom v jednom vlákně neběží pouze skript jedné stránky, ale pokud se stránka skládá z více rámů nebo otevřela vyskakovací okno, pak všechny jejich skripty poběží v jednom jediném vláknu. Přitom se mezi sebou střídají pro obsluhování jednotlivých událostí. Celé to silně připomíná starý kooperativní multitasking. HTML5 se snaží dát zpracování události jistý řád a navíc umožní použití více vláken.
Event loops
Princip a pořadí obsluhování událostí je v HTML5 specifikován pomocí Event loops. Event loops zavádí fronty úloh, do kterých se ukládají např. události uživatelského rozhraní, události parseru nebo síťového rozhraní. Specifikace popisuje, v jakém pořadí mají být dále zpracovávány.
Ačkoliv jsou webové prohlížeče s námi již řadu let, jedná se, pokud vím, o historicky první specifikaci tohoto druhu. Dosud se prohlížeče mohly chovat každý jinak, což také i víceméně dělaly (přečtěte si loňskou diskusi u Misantropa). Ve výsledku tak zmizí další rozdíl způsobující, že webová aplikace v jednom prohlížeči běžela v pořádku a ve druhém způsobila nepochopitelný problém.
Přichází vlákna
Mnohem zajímavější je ovšem zavedení vláken do skriptování webových prohlížečů. Je jim věnována zvláštní specifikace Web Workers (zkráceně WW), čítá asi 30 stran a v budoucnu se pravděpodobně stane součástí velké specifikace HTML5.
Web Workers navíc ke stávajícímu vykonávání JavaScriptu definují pracovní vlákna, která běží na pozadí (mimo interakci s uživatelským rozhraním prohlížeče) a mají sloužit ke zpracování výkonnostně nebo časově náročnějších činností. Jelikož neblokují uživatelské rozhraní, nebudou omezovány, mohou tedy bez přestání běžet desítky minut nebo i hodin (průběh stávajících skriptů totiž bývá omezen např. na desítky vteřin ve Firefoxu, což komplikuje vykonávání náročnějších úloh).
Ukažme si jednochuché použití pracovního vlákna. Všimněte si, že pracovní vlákno s vláknem uživatelského rozhraní komunikuje prostřednictvím zpráv (událost
Pracovní vlákno může získávat data pro svou práci pomocí událostí, database storage nebo pomocí síťové komunikace (komunikace s webovými servery pomocí AJAXu nebo nového rozhraní Web Sockets - o tom jindy). Přímý přístup k uživatelskému rozhraní nebo k zobrazované webové stránce pracovní vlákno NEMÁ.
Pracovní vlákno má navíc některé metody, např. importScripts(url1, url2...), která zajístí načtení dalších skriptů (potřebná metoda, nemůžeme totiž použít běžnou značku script, jelikož nemáme přístup k HTML dokumentu).
Kromě konstruktoru Worker existuje kontruktor SharedWorker, který založí pracovní vlákno, jenž má být sdíleno více rámy (nebo okny) aplikace.
Celá specifikace je v počátečním stádiu a výrobci prohlížečů se k ní postupně vyjadřují. Troufnu si odhadovat, že ačkoliv přináší velké změny, nakonec se do prohlížečů dostane, byť je pravděpodobné, že před tím ještě projde úpravami. S ohledem na to, že JavaScript je v prohlížečích stále rychlejší, začíná být srovnáván nejen s dalšími skriptovacími jazyky, ale třeba s céčkem, začíná být představa složitějších skriptů běžících na pozadí reálná.
Event loops
Princip a pořadí obsluhování událostí je v HTML5 specifikován pomocí Event loops. Event loops zavádí fronty úloh, do kterých se ukládají např. události uživatelského rozhraní, události parseru nebo síťového rozhraní. Specifikace popisuje, v jakém pořadí mají být dále zpracovávány.
Ačkoliv jsou webové prohlížeče s námi již řadu let, jedná se, pokud vím, o historicky první specifikaci tohoto druhu. Dosud se prohlížeče mohly chovat každý jinak, což také i víceméně dělaly (přečtěte si loňskou diskusi u Misantropa). Ve výsledku tak zmizí další rozdíl způsobující, že webová aplikace v jednom prohlížeči běžela v pořádku a ve druhém způsobila nepochopitelný problém.
Přichází vlákna
Mnohem zajímavější je ovšem zavedení vláken do skriptování webových prohlížečů. Je jim věnována zvláštní specifikace Web Workers (zkráceně WW), čítá asi 30 stran a v budoucnu se pravděpodobně stane součástí velké specifikace HTML5.
Web Workers navíc ke stávajícímu vykonávání JavaScriptu definují pracovní vlákna, která běží na pozadí (mimo interakci s uživatelským rozhraním prohlížeče) a mají sloužit ke zpracování výkonnostně nebo časově náročnějších činností. Jelikož neblokují uživatelské rozhraní, nebudou omezovány, mohou tedy bez přestání běžet desítky minut nebo i hodin (průběh stávajících skriptů totiž bývá omezen např. na desítky vteřin ve Firefoxu, což komplikuje vykonávání náročnějších úloh).
Ukažme si jednochuché použití pracovního vlákna. Všimněte si, že pracovní vlákno s vláknem uživatelského rozhraní komunikuje prostřednictvím zpráv (událost
message
) - online verze:<script>
var worker = new Worker('worker.js');
worker.onmessage = function(event){ document.getElementById('result').innerHTML = event.message;
};
</script>
Pracovní vlákno může získávat data pro svou práci pomocí událostí, database storage nebo pomocí síťové komunikace (komunikace s webovými servery pomocí AJAXu nebo nového rozhraní Web Sockets - o tom jindy). Přímý přístup k uživatelskému rozhraní nebo k zobrazované webové stránce pracovní vlákno NEMÁ.
Pracovní vlákno má navíc některé metody, např. importScripts(url1, url2...), která zajístí načtení dalších skriptů (potřebná metoda, nemůžeme totiž použít běžnou značku script, jelikož nemáme přístup k HTML dokumentu).
Kromě konstruktoru Worker existuje kontruktor SharedWorker, který založí pracovní vlákno, jenž má být sdíleno více rámy (nebo okny) aplikace.
Celá specifikace je v počátečním stádiu a výrobci prohlížečů se k ní postupně vyjadřují. Troufnu si odhadovat, že ačkoliv přináší velké změny, nakonec se do prohlížečů dostane, byť je pravděpodobné, že před tím ještě projde úpravami. S ohledem na to, že JavaScript je v prohlížečích stále rychlejší, začíná být srovnáván nejen s dalšími skriptovacími jazyky, ale třeba s céčkem, začíná být představa složitějších skriptů běžících na pozadí reálná.
úterý 26. srpna 2008
W3C začleňuje HTML5 do validátoru
Vývojář validátoru W3C Olivier Thereaux včera oznámil novou alfa verzi HTML validátoru, která přidává podporu pro HTML5. Interně je validace řešena voláním HTML5 conformance checkeru Henriho Sivonena.
Nová verze není zatím bez chyb, nerozpozná kupříkladu zjednodušenou deklaraci kódování dokumentu
Jakmile se podpora HTML5 dostane do veřejné verze na adrese validator.w3.org, odpadne psychologická bariéra pro experimentování s HTML5. Pokud totiž dnes na vašem webu použijete HTML5 (ať již k tomu máte jakékoliv důvody), můžete obdržet (a tedy nejspíš obdržíte) reakci, že váš web NENÍ validní. A vysvětlujte, že váš web validní JE, ale podle specifikace, kterou ten božský validátor zatím neumí.
Nová verze není zatím bez chyb, nerozpozná kupříkladu zjednodušenou deklaraci kódování dokumentu
<meta charset="utf-8">
a nefunguje tlačítko revalidate, proto zatím stále zůstávám u Henriho nástroje.Jakmile se podpora HTML5 dostane do veřejné verze na adrese validator.w3.org, odpadne psychologická bariéra pro experimentování s HTML5. Pokud totiž dnes na vašem webu použijete HTML5 (ať již k tomu máte jakékoliv důvody), můžete obdržet (a tedy nejspíš obdržíte) reakci, že váš web NENÍ validní. A vysvětlujte, že váš web validní JE, ale podle specifikace, kterou ten božský validátor zatím neumí.
čtvrtek 21. srpna 2008
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ů
ke kterým můžete přistupovat přes jednoduché API
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á:
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
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
úterý 19. srpna 2008
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.
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.
pondělí 18. srpna 2008
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#.
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)
úterý 12. srpna 2008
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.
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.
pondělí 11. srpna 2008
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:
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č.
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.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.
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.
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í.
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í.
neděle 10. srpna 2008
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.
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.
Přihlásit se k odběru:
Příspěvky (Atom)