čtvrtek 28. června 2007

Rozdíly HTML4 a HTML5 smeřují k Working Draft

Ačkoliv podle původních plánů měla být během června zveřejněna první pracovní verze (working draft) specifikace HTML5, pracovní skupina nestíhá a je zřejmé, že k tomu v červnu (a odhaduji, že ani v následujících měsících) nedojde. Specifikace HTML5 čítá asi 300 stran a její revize se podle mne potáhne alespoň čtvrt roku.

HTML WG v této chvíli dokončuje dokument obsahující přehled hlavních rozdílů mezi HTML4 a HTML5. A předseda Dan Connolly vyzval členy, aby hlasovali, zda chtějí tento dokument vydat jako working draft. Průběžné výsledky hlasování vyjadřují s tímto návrhem souhlas. Odhaduji, že začátkem července bychom se vydání sumarizujícího dokumentu mohli dočkat.

Z hlediska vlastního vývoje HTML5 to není žádný zásadní krok, na specifikaci se bude pracovat stejně jako před tím. I takto zveřejněné věci se mohou měnit a dále vyvíjet.

Větší rozdíl nastane ve vnímání HTML5 okolním světem. HTML5 přestane být řadou lidí chápáno jako něco neurčitého, nabyde konkrétnější podoby a určitě se o něm začne i víc psát. Již teď můžete odhadovat, kolik se objeví příspěvků na české scéně souhlasících či nesouhlasících s přidáním nebo zrušením toho kterého atributu, té které HTML značky. A to je účel vydání tohoto dokumentu - připravit veřejnost na novou verzi (X)HTML a získat k ní dostatečný feedback.

pondělí 25. června 2007

Bude Apple implementovat Ogg Theora?

Pod příspěvky na téma video v HTML5 někteří ze čtenářů vyjadřovali obavy, zda opravdu dojde nejen k implementaci elementů <video> a <audio> v prohlížečích, ale i k implementaci společného formátu videa a audia. K tomu specifikace zatím říká:
User agents may support any video and audio codecs and container formats.

User agents should support Ogg Theora video and Ogg Vorbis audio, as well as the Ogg container format.
Ono důležité SHOULD, které v angličtině nevyjadřuje stoprocentní jistotu, je bráno v souladu s RFC2119, kde je definováno takto:
SHOULD : This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
Tedy implementace Ogg Theora/Vorbis v tuto chvíli není jednoznačně povinná.

A právě na toto téma se již třetí den diskutuje v konference WHATWG ve vláknu The issue of interoperability of the <video> element, které rozpoutal Ivo Emanuel Gonçalves. Točí se převážně okolo Apple a zda bude či nebude Ogg Theora implementovat.

Maciej Stachowiak z Apple odpověděl prozatím spíše negativně:
Our current plan is to primarily support MPEG-4, including H.264/AVC video and AAC audio. We may support other codecs as well - it won't necessarily be the full set of codecs supported by QuickTime. This has been discussed to death already, but here are our basic reasons:

- MPEG-4 is an ISO open standard (although unfortunately patent-encumbered).
- Ogg Theora/Vorbis offers a royalty-free license for the few known patents, but we would assume additional risk of submarine patents if we supported it.
- H.264 offers considerably better quality at the same bitrate than Theora/Vorbis.
- H.264 is better for video delivery to limited-capability and low-power devices that support hardware video decoding. You may have heard that YouTube will be serving their video content as H.264 to AppleTV and iPhone.

That's our current plan. We may revise it in light of future events, but it is unlikely that even a MUST-level requirement in the HTML spec would have much effect on whether we support Ogg or not.
Jelikož téma výchozí kodek na webu je velmi citlivé, myslím, že do vydání finální HTML5 se můžeme dočkat ještě dalších překvapení (všemi směry) včetně lobbistických pokusů prosadit ten či onen formát. Já se v oblasti kodeků nevyznám, a neodvažuji se cokoliv prorokovat.

Podotýkám, že Opera a Mozilla implementaci Ogg Theora plánují, Microsoft se na toho téma zatím nijak nevyjádřil.

WHATWG spouští projekt "Bible5"

Do konference W3C minulý týden dorazil zajímavý e-mail, jehož překlad uvádím.

Silicon Valley - červen 2008


Po úspěšné práci na HTML5, CSS5, XML5, SVG5 a Web5, oznámilo WHATWG spuštění projektu připravujícího novou verzi Bible označovanou jako "Bible5".

"Jedna z nejnápadnějších změn se týká desatera," řekl Ian Hickson, vedoucí skupiny a autor celého nápadu. "Plánujeme například změnit 'Nezabiješ,' na 'NEMĚL BYS zabíjet' s patřičným odkazem na RFC 2119. Je totiž očividné, že po tisíciletých zkušenostech s touto specifikací, lidé nejednají v souladu s tím, co specifikace požaduje. My ji tedy upravíme, lze také říci modernizujeme, aby odpovídala tomu, jak ji lidé skutečně používají. Chci říct, k čemu jsou výstrahy, které většina lidí nerespektuje?" zeptal se a dodává: "To byla jen řečnická otázka. Chci říct, k čemu je specifikace, která něco zakazuje? Pak je pro lidi těžší žít se specifikací v souladu." "Tahle byla rovněž řečnická," stihl rychle dodat.

Alan van Finckelstein, jedna z těch, kdo začali na specifikaci pracovat, navázala: "Jedním z problémů Bible je její neúplnost." "Ačkoliv Bible zmiňuje několik hříchů, které jsou zakázány, a další, které jsou očividně v pořádku - napadá mě třeba incest v případě Lotových dcer - ponechává Bible stovky, pokud ne tisíce hříchů zcela nespecifikovaných. Snažíme se využít Google k nalezení a identifikaci všech aktuálně známých a praktikovaných hříchů, abychom je mohli zahrnout do seznamu povolených činností."

Otevřený proces

"Jednou z odlišností práce WHATWG oproti uzavřeným a tajnůstkářským křesťanům je, že se jedná o zcela otevřený proces," dodává Ian Hickson. "Kdokoliv se může zapojit (vlastně jste se již zapojili). Rádi bychom požádali všechny, aby nám zaslali své hříchy, které spáchali v minulosti nebo které mají v úmyslu v budoucnu spáchat, i s případy zhřešení (use case), abychom je mohli začlenit do specifikace.

"Rychlost je naše další výhoda," sdělila Alan. "Křesťanům trvala tvorba specifikace 325 let, než ji prohlásili za recommendation na Nicejském koncilu. Takže nám říkejte něco o pomalosti. To my jsme přesvědčeni, že novou verzi můžeme zhotovit během asi dvou týdnů."

"Bude se pochopitelně jednat jen o pracovní návrh, tedy working draft!" upozornil Hickson. "Ale doufáme, že dosáhneme stavu candidate recommendation během několika následných týdnů. V tuto chvíli připravujeme sadu testů. Specifikace nemůže dospět do candidate recommendation, dokud nenajdeme důkaz, že každý hřích byl spáchán nejméně dvakrát. Náš časový rozvrh ukazuje, že pravděpodobně zůstaneme v CR stavu asi tak po dobu 325 let. A po té se možná budeme muset vrátit zase zpět do stavu pracovního návrhu."

"Není nutné zdůrazňovat," směje se Finckelstein, "že Bible ve skutečnosti nikdy CR neprošla, což je pro ni typické." Pokračuje: "Pokud by se tak stalo, nikdy by bývala nedosáhla stavu recommendation. Je plná chyb a nekonzistencí nebo také věcí, které nikde nebyly definovány. Tak například, když Mojžíš sešel s desaterem z hory a spatřil hřešící lid, neovládl se a mramorové desky s desaterem rozbil - jak je vidět, rozbití Božího majetku nebylo na seznamu věcí, které nemáte dělat - a po té se pustil do vraždění třech tísíc svých následovníků. Tolik k ''Nezabiješ!'"

"V každém případě", uzavírá Hickson, "velkou výhodou Bible5 je okamžité snížení počtu hříšníků a kriminálníků. Jen si představte ta prázdná vězení. Poprvé v historii budeme společnost plně dodržující zákon!"

A co přijde dál? Finckelstein tvrdí, že: "Zásuvky a elektrické vedení," a Hickson: "pravidla silničního provozu, bezpečnost leteckého provozu, no prostě je tu ještě hromada věcí, které můžeme zlepšit."

neděle 24. června 2007

Jak by měl vypadat XMLHttpRequest 2

Před pěti dny oznámil Anne van Kesteren vydání working draftu specifikace pro XHR (XMLHttpRequest).

XHR není obsažen v HTML5, byť by tam logicky patřil, pravděpodobně proto, že jeho specifikace začala pod křídly pracovní skupiny pro Web API. Jelikož řada členů Web API WG je zároveň členy WHATWG a HTML WG, není se třeba bát nekonzistencí.

Připravovaná specifikace XHR nepřináší v zásadě nic nového, jejím cílem je hlavně specifikovat XHR tak, jak byl na základě prvotní specifikace Microsoftu implementován webovými prohlížeči a zajistit společný jmenovatel, který bude v každém prohlížeči implementován stejně.

A protože se v zásadě jedná o specifikaci relativně starou (četli jste historii XHR začínající u Outlook Web Access od Alexa Hopmanna?), která neměla ani tušení, jaký boom AJAXu jednou nastane, Anne se zamýšlí, jak by mohl vypadat takový XMLHttpRequest 2. Tedy XMLHttpRequest vyvinutý dle dnešních potřeb.

Srovnejme stávající XHR a Annův návrh XHR2:
// XMLHttpRequest today

function handler() {
if (this.readyState == 4 && this.status == 200)
// so far so good
else if (this.readyState == 4 && this.status != 200)
// fetched the wrong page or network error...
}

var r = new XMLHttpRequest();
r.open("GET", uri);
r.onreadystatechange = handler;
r.send();

//////////////////////////////////////////
// XMLHttpRequest 2

// start "script block"
var r = new XMLHttpRequest(uri);
// uri argument causes implicit invocation
// of r.open("GET", uri)
r.onload = function() { … }
r.onerror = function() { … }
r.onabort = function() { … }
// end "script block" causes implicit invocation
// of r.send()

Anne vkládá URL přímo do konstruktoru, čímž říká, že se má použít XHR2 včetně závěrečného automatického zavolání send() nakonci. A odděluje obsloužení úspěšného a neúspěšného volání (to je již nyní v některých prohlížečích implementováno, ale nebude součástí specifikace XHR1). Ve výsledku je zapotřebí méně kódu a obsluha událostí je strukturovaná.

Pod Anneho příspěvkem se rozpoutala zajímavá diskuse. Terčem kritiky je zejména automatické volání metody send(). Pokud je programování AJAXu vaším denním chlebem a máte nápad, jak XHR vylepšit, napište Annemu do komentářů své připomínky.

BTW všimli jste si, že každá specifikace, kterou Anne píše, má v patičce
Please, keep bugging us with your issues!

Selector API - překonat omezení DOM

Document Object Model (DOM) je sada specifikací pro přístup k elementům a atributům HTML a XML dokumentů. Jedná se o celkem důležité specifikace, které vnesly řád tam, kde dříve panoval chaos.

Přesto je DOM v některých ohledech ne zcela vyhovující. Z pohledu programátorů se s ním někdy obtížně pracuje, a proto se jeho používání místy obchází např. pomocí vlastnosti innerHTML (innerHTML bude v HTML5 konečně standadizován!).

Často potřebujeme vybrat elementy splňující nějakou konkrétní podmínku, ideálně jedním příkazem. DOM nefinuje NodeIterator a TreeWalker, u kterých ale není splněna právě ona podmínka "ideálně jedním příkazem". Proto se poslední dobou rozmohlo používání JavaScriptových knihoven, které jednoduchý výběr elementů umožňují.

Například s knihovnou jQuery stačí zavolat funkci $("#prehled td.cena"), která v souladu se selektorovou syntaxí CSS vybere všechny buňky tabulky "prehled" se třídou "cena". Nevýhodou je nutnost includovat 20kB knihovnu do svého projektu.

Pravidlo jakmile začnou vývojáři obcházet API, je třeba API upravit, platí, a proto mě potěšilo, že W3C připravuje specifikaci Selectors API, která zmíněný problém řeší. Přidává možnost vyhledávání elementů právě pomocí CSS selektorů podobě, jako to dělá například jQuery.

Ve skupině WebAPI, která specifikaci připravuje, panovala dlouho neshoda co se týče názvu metod. Podrobněji o tom píše Lachlan Hunt v Selectors API Naming Debate.

Tento týden bylo rozhodnuto a připravovaná specifikace již obsahuje metody selectElement() a selectAllElements(), příklad jejich použití: document.selectAllElements("#prehled td.cena");.

Stránky w3.org právě nejedou a nepodařilo se mi zjistit, kdy je plánována finální verze specifikace, rád bych ji tu měl co nejdříve. Protože používat CSS selektory umí prakticky každý webový vývojář, myslím, že se připravované API rychle ujme.

O navigaci pomocí selektorů CSS psal loni i Petr Cimprich v seriálu Akta X.

úterý 19. června 2007

Nove a staré verze specifikací

Dnes mne zaujal e-mail Ian Hicksona zabývající se vztahy mezi verzemi specifikací. Tento spot je jen několik citací, které by neměly zapadnout (můžete si místo něj stejně tak přečíst i celý původní e-mail).
Do you really mean to suggest that once HTML 5 is done, there will never be a need to produce XHTML 1.1 documents or process documents according to that spec's requirements for UAs?


Exactly. The intend is for the HTML5 spec's requirements to be a complete superset of the XHTML 1.x, HTML 2, HTML3.2, HTML4, DOM1 HTML, and DOM2 HTML specs' requirements, and for the language to be a better version such that there should be no good reason to prefer an older language or API version over the one now defined.

This specification is intended to replace (be the new version of) what was previously the HTML4, XHTML 1.x, and DOM2 HTML specifications.

The relationship between HTML5 and XHTML 1.x and HTML 4 is the same as the relationship between DOM2 HTML and DOM1 HTML, or CSS2 and CSS1. The more recent version of the spec completely supplants the earlier version. You would never need to write a CSS1 stylesheet, or use the DOM1 HTML specification when referring to the DOM HTML APIs.

It implies that being a conforming HTML 4.x or XHTM 1.x document processor is irrelevant, but replacing those specs doesn't stop those specs from existing. You can implement CSS1 without miplementing CSS2, but CSS2 obsoletes CSS1, even if it doesn't say it explicitly.
Zajímavý pohled na verze specifikací přináší i Adamův příspěvek CSS 2 ještě stále není hotové. A ve stejném duchu se ptám. Myslí si některý ze čtenářů tohoto blogu, že HTML4 je hotové?

neděle 17. června 2007

Jak se bude jmenovat XHTML5?

Zajímavou debatu nedávno inicioval Jirka Kosek. Ačkoliv bylo schváleno, že se nová verze HTML bude jmenovat HTML5, nepadlo rozhodnutí o pojmenování její XML varianty. Již se začala používat označení (X)HTML5 a XHTML5, ale jak Jirka Kosek píše:
Zdá se mi nepatřičné používat termín XHTML5 bez schválení skupinou XHTML WG, zejména když víte, že nesouhlasí s označením XHTML5 pro XML serializaci HTML5.
Je pravda, že HTML5 navazuje na HTML4/XHTML1 a nikoliv na (byť dnes již prakticky odepsanou) XHTML2, takže označení XHML5 by mohlo někoho mást.

Karl Dubost k tomu dodává:
Steven Pemberton z XHTML 2.0 WG několikrát požadoval, abychom nepoužívali XHTML5, ale spíše html5x nebo html5/xml.
Jirka pokračuje:
Domnívám se, že použití jiného jména než XHTML by bylo matoucí, protože vztah mezi XHTML1.0 a XHTML5 je podobný jako HTML4.01 a HTML5.
V tomto případě se zdá logičtější použit XHTML1.5 místo XHTML5.
Předseda Dan Connolly k problému již dříve poznamenal:
Byl jsem žádán, abychom nepoužívali XHTML5 a vyhnuli se tak záměně s XHTML2. Odpověděl jsem, že XHTML2 by mělo používat název, který neobsahuje H-T-M-L v tomto pořadí.
Dan naráží na to, že XHTML2 bylo navrženo jako nový jazyk, nevychází z HTML (v podstatě jím dle původních plánů mělo být HTML pohřbeno) a není důvod, aby vůbec používalo v názvu HTML.

Dan po té poslal výzvu k vyjádření do mailing listu XHTML WG, kde se již rozeběhla debata rozličných názorů.

Jsem zvědav, jak debata dopadne. Zájemcům doporučuji přečíst celá vlákna v obou diskuzních skupinách.

sobota 16. června 2007

Přehled rozdílů mezi HTML5 a HTML4

Anne van Kesteren připravil dokument popisující hlavní rozdíly mezi připravovaným HTML5 a stávajícím HTML4.
Dokument popisuje rozdíly mezi HTML4 a HTML5 a zároveň poskytuje základní zdůvodnění pro tyto změny. Dokument nemusí poskytovat přesné informace, jelikož specifikace HTML5 je stále ve vývoji.
Dokument nebyl zatím pracovní skupinou oficiálně publikován (proto také jeho adresa ukazuje přímo do pracovního repository W3C), ale předpokládám, že v dohledné době se tak stane.

Specifikace HTML jsou psány pro výrobce prohlížečů a nikoliv pro webdesignéry (zajímalo by mne, jaké procento webdesignérů je schopno přečíst celou HTML5 specifikaci a správně jí porozumět, obávám se, že nebude příliš veliké). Pracovní skupina s tím počítá a klade si jako cíl i přípravu dokumentů orientovaných na webdesignéry. Tohle je první z nic. Jsem za něj rád, o potřebě takového dokumentu jsem již psal.

Pokud by vás zajímaly novinky HTML5 rozepsané podobněji, přečtěte si články Davida Majdy WHATWG - budoucnost webu? a Webové aplikace podle WHATWG.

úterý 12. června 2007

Element video už dnes

Nedávno jsem psal o podpoře nového elementu <video> v Opeře a o jeho připravované podpoře ve Firefoxu.

Teď jsem narazil na pro mne překvapivou novinku - <video> s Ogg Theora si můžete vyzkoušet už dnes v jakémkoliv prohlížeči podporujícím Javu, a to včetně Internet Exploreru. Podívejte se na ukázkovou stránku.

Vše je založeno na mv_embed skriptu projektu METAVID, který v případě, že nemáte prohlížeč s nativní podporou videa, nahradí element <video> Java appletem, který umí přehrát Ogg Theora.

Používá se metoda čistého unobstrusive JavaScriptu, takže do kódu stránky píšete <video> přesně podle HTML5 specifikace a do hlavičky vložíte skript, který se již o vše postará.

Jsme tak opět o krok blíže reálnému použití. A to má být specifikace HTML5 hotova až za tři roky 8-)

S HTML5 přichází SQL5 a XML5

Dnes mi vyšel na Lupě článek SQL si razí cestu do HTML5 popisující některé zajímavé události posledních týdnů, které jsem chvíli záměrně tak trochu tajil a čekal, kam se skutečně vyvinou. Budoucnost webových aplikací bude bohatší, než se nám ještě včera mohlo zdát.

Zkratky specifikací s pětkou na konci se nám množí, dnes už nemáme jen HTML5, ale i SQL5 nebo XML5 a možná to jenom jimi neskončí (ale to si nechám jako překvapení zas na jindy). Zřejmě budu muset aktualizovat svůj oblíbený wallpaper 8-)

Mezi čerstvé události, které by se ale určitě tajit neměly, patří, že Adam Hauner, člověk, kterého si od naší spolupráci v CZille velmi vážím, začal tak trochu, teda jen trošku, ale opravdu trošičku blogovat.

úterý 5. června 2007

Håkon o elementu video

Dnes se ke mně dostal záznam prezentace The <video> Element (Google Tech Talks, 29. březen). Prezentuje Håkon Wium Lie (Opera, WHATWG), hned na začátku je coby uvaděč vidět i Ian Hickson.

Håkon v půlhodinové prezentaci kromě elementu <video> představí experimentální verzi Opery s jeho podporou a připomene historii HTML, zejména jeho počátky v CERNu.

Zaujal mne záběr na soustavy propletených trubek v podzemních chodbách CERNu, u kterého Håkon říká:
Maybe this is the inspiration for the HTML specification.
Co se týče zahrnutí podpory videa do stabilních verzí Opery, mile mě překvapilo:
By the end of the year, I think, we can have several shipping browsers with support for this.
Takže ačkoliv specifikace se bude ještě vyvíjet, prvotní podpora videa v prohlížečích je již za dveřmi (vývojáři Firefoxu na ní rovněž pracují).

pátek 1. června 2007

Kdy začne revize HTML5?

Od 9. května, kdy proběhla adopce HTML5, uplynuly již tři týdny, ale slíbená systematická revize HTML5 ještě nezačala. V HTML WG probíhají jen volné debaty na témata, která někdo nadhodí bez toho, aby došlo k ujasnění výsledného názoru a úpravě specifikace. A tak zatímco WHATWG stále na specifikaci pracuje (a dále ji rozšiřuje), v HTML WG se zatím spíše jen mluví.

Očekával jsem rychlejší posun vpřed, již vzhledem k tomu, že tento pátek začíná červen, během kterého by podle zákládací listiny měla HTML WG zveřejnit první pracovní návrh (First Working Draft) specifikace. Již teď se můžeme vsadit, že to nestihnou.

Anne van Kesteren to nevydržel a v úterý do HTML WG napsal:
Are we still supposed not to discuss issues on this list? I hear conflicting opinions about this. Also, what exactly is the plan in moving forward? Are the chairs working on this? Someone else?
Onou první otázkou reaguje na původní mail předsedy Dana Connollyho z 11. května:
We're not quite ready to start the review of th HTML spec text. That leaves nothing to discuss. So please don't discuss anything on the public-html@w3.org mailing list, just for a few days.
Dan Connolly přišel s návrhem, jak začít revizi HTML5 v mailing listu. Ianu Hicksonovi se návrh příliš nezamlouval:
In my experience, this would result in the editors' time moving from editing the spec to just chatting in e-mail.
A navrhuje raději používat systém pro sledování požadavků (issue tracking system).

Po debatě na IRC přišel dnes Ian Hickson s příspěvkem:
In due course, I will be going through the issues on that list. If you want to have an issue raised on this mailing list be looked at by the editors, make sure to add it to the wiki page above, or it will be ignored.
Hyatt and I will be taking feedback from the wiki page above, as well as from other sources such as the WHATWG list, blogs, discussions with authoring tool implementors, browser vendors, etc, in editing the spec.
Doufejme, že se revize začne brzy, současný stav, kdy není jasné, která část specifikace revizi přežije, a která nikoliv, brzdí její další vývoj. Nebude jednoduché zajistit, aby se necelých 500 lidí společně shodlo, nějaký zkušený manager by se možná W3C hodil 8-)

HTML5 conformance checker jako diplomová práce

Henri Sivonen zveřejnil svou diplomovou práci na téma An HTML5 Conformance Checker.

Jejím tématem je vývoj nástroje umožňující kontrolu správné syntaxe HTML5 dokumentů. Henri takový nástroj vyvinul v Javě za pomoci XML Schémat a ve webové verzi může sloužit jako validátor. V současnosti je jediným takovým nástrojem pro HTML5. Zdrojový kód conformance checkeru je volně ke stažení.

Pokud vás zajímá, jaký je rozdíl mezi validátorem a conformance checkerem (nápady na překlad do češtiny?), pomůže jedna ukázka mluvící za všechno:
<ins datetime="blabla"> is valid but not conforming
Henriho práce zaujme nejen příznivce XML Schémat, ale i zájemce o HTML. Pokud jste nikdy neslyšeli o takovém HTML+, doporučuji přečíst druhou kapitolu History of HTML Leading to HTML5.

Henriho, který studuje na Helsinské univerzitě, můžete znát z projektu Mozilla a v současné době i z WHATWG.

Výsledky své práce nedávno prezentoval na konferenci XTech 2007 (PDF).