Značka time a mikroformáty

Nedávno se znovu rozhořela diskuse na téma vkládání data pomocí mikroformátů (viz BBC nasadilo a opět odstranilo mikroformáty). Stávající syntaxe využívající značku <abbr> a atribut title totiž snižuje v současných čtečkách použitelnost stránek, a proto se hledá alternativní řešení.

Do diskuse nad možným řešením napsal Henri Sivonen, podílející se na tvorbě HTML5, připomínku, proč není jako náhrada znažována značka <time> z HTML5.

Zájemci si mohou přečíst celé vlákno (stručně: značka <time> zatím nebude zvažována jako náhrada <abbr>, protože není validní v HTML4 a XHTML1 a mikroformátové komunitě se HTML5 zdá dosud příliš nezralé). A já rychle využiju situace k představení této značky.

<time>
Značka <time> je jednou z nových sémantických značek HTML5. Používá se jednoduše:

<p>Nahý exhibicionista s transparentem "HTML5 rules" proběhne Václavským náměstím <time datetime="2008-07-01 10:00 +2">zítra v 10 hodin</time>.</p>

Slouží k sémantickému vyznačení času, data případně obojího dohromady (značku <date> v HTML5 tedy nehledejte, vystačíte si s <time>).

Její jediný atribut datetime obsahuje strojově čitelnou variantu času (data) k lidsky čitelnému (human readable) údaji v obsahu značky.

Skrze DOM atributy date, time a timezone jsou přístupné jeho jednotlivé složky v podobě DOMTimeStamp (ušetří se tak krok s parsováním textové hodnoty).

Je vidět, že pro zápis časových údajů je značka <time> jako stvořená. Vlastně si nedovedu představit, že by mikroformátová komunita mohla přijít s něčím lepším (a že jsem moc zvědav, s čím nakonec příjdou).

Součástí HTML5 specifikace je <time> již hodně dlouho (odhadem několik let). Chce se mi spekulovat, že tam byla vložena, právě proto, aby časem vyřešila problém mikroformátů, ale okolnosti jejího vzniku budou hluboko v historii WHATWG mailinglistu a zatím jsem se k nim nedostal, takže kdoví.

Parsování URL součástí HTML5

Ian Hickson nedávno do HTML5 zařadil sekci o parsování URL obsahující i zpracování těch neplatných zápisů adres, které prohlížeče všeobecně akceptují. Což je v souladu s myšlenkou HTML5: cokoliv je všeobecně akceptováno, mělo by být specifikováno, i pokud se jedná o zpracování neplatného stavu.

Ian se snažil zmapovat stávající zpracování adres v prohlížečích, ať již se jedná o adresy s mezerou:
http://example.com/hello world/
nebo o adresy obsahující znaky s diakritikou:
http://cs.wikipedia.org/wiki/Čeština

Ian poslal do mailing listu uri@w3.org dotaz, zda by se uvedené zpracování nemělo stát součástí URI specifikace namísto HTML5 specifikace, kam tak úplně nepatří.

Reakce byla negativní. Nikdo nechce specifikovat to, co není v původních specifikacích povolené. Proto tato část pravděpodobně zůstane součástí HTML5. Celou diskusi najdete ve vlákně Error handling in URIs.

(via URI error-handling in HTML5, and documenting the (real) Web vs. reinventing it)

Co přináší druhá pracovní verze HTML5

Minulý týden W3C vydalo druhou pracovní verzi specifikace HTML5. Pojďme se letmo podívat, co se od první lednové verze změnilo. Na úvod ještě malé vysvětlení.

Co je to pracovní verze?

Pracovní verze (working draft) nevychází, jak by se někdo mohl domnívat, v momentech, kdy je dokončena některá ucelená část specifikace. Pracovní skupiny u W3C mají povinnost vždy po několika měsících pracovní verze zveřejňovat.

To je dobře, protože veřejnosti se tak nabízí stabilní dokumenty, které mohou studovat aniž by se jim měnily pod rukama (např. HTML5 specifikace se jen od tohoto pondělí do pátku změnila 14krát), odkazovat na ně a diskutovat je.

Na druhou stranu pracovní verze je pouhý otisk specifikace k určitému datu. Obsahuje body rozdělané (možná i rozepsané) a může obsahovat i konfliktní tvrzení (protože se změnila jedna část a nestihl ještě zaktualizovat zbytek specifikace).

Teprve, jakmile se u dokumentu objeví slůvko recommendation (existuje více jeho podob: Candidate Recommendation, Proposed Recommendation, Recommendation), lze chápat celý dokument jako konzistentní.

HTML5 specifikace a další

W3C vydalo 10. června tyto dokumenty:

• HTML 5 - vlastní specifikace
• HTML 5 differences from HTML 4 - souhrn novinek od HTML4
• HTML 5 Publication Notes - změny od lednové verze
  

A co zde nenajdete:

• WebForms2 specifikaci, protože o jejím osudu není dosud rozhodnuto
  

Pokud se o HTML5 teprve začínáte zajímat, podívejte se na HTML 5 differences from HTML 4, kde najdete to nejdůležitější a detaily pak můžete konzultovat se specifikací.

Pakliže vývoj HTML5 sledujete a zajímá vás, co se změnilo, pak dokument HTML 5 Publication Notes obsahuje detailní soupis veškerých změn. Jedná se de facto o čitelnější podobu diffu obou verzí specifikace. Uvedu stručný přehled.

Hlavní změny od lednové verze

• Zaveden atribut reversed pro značku ol
• Zavedeny atributy seamless a sandbox pro iframe
• Zavedeny události beforeprint a afterprint
• Zavedeny metody showModalDialog() a showNotification()
  
• Zavedena kolekce document.scripts
  
• Zavedení ruby anotací
• Zavedena onload událost pro značku script
  
• Vrácen atribut style
• Značka font je nevalidní
  
• Vrácen atribut target
  
• HTML5 se vypořádává se začleněním MathML
• Zavedeny datové atributy data-
  
• Canvas je rozšířen o textové API
• Rozšířeno API pro contenteditable
  
• Změnilo se API pro DOM storage.
• Přejmenováno globalStorage na localStorage
  
• Změnilo se API pro zprávy mezi dokumenty
• Změnilo se API pro event stream
  

Tolik asi základní změny. Kromě nich došlo k řadě úprav detailního popisu parsování HTML (většinou jen upřesnění reverzního inženýrství současných prohlížečů), a k řadě dalších drobností, které zde nerozepisuji.

(via HTML 5 Publications)

První zmínky o testu Acid4

Dosud plně neodezněl rachot okolo testu Acid3, ještě jím žádný prohlížeč se zcela čistým štítem neprošel a už se objevují první zmínky o testu Acid4.

Tedy zmínky, spíš bych to nazval únik informací.

Jedná se o adresu http://www.hixie.ch/tests/evil/acid/004/, kam si Ian Hickson začal psát své poznámky ohledně testu Acid4. Někdo ji objevil a zveřejnil na Ajaxian.com. Docela by mne zajímalo, kde to objevili, protože tohle mým zdrojům zcela uniklo.

Následné informace proto berte s rezervou, a jen pro ty opravdu zvědavé (a ty, co se nestydí nakukovat do soukromých poznámek). Vy ostatní honem huš pryč!

Acid4 bude převážně vizuální test bez výrazného skriptování. Zaměří se na SVG, CSS a míchání jmenných prostorů, hlavní dokument pravděpodobně bude XML soubor s SVG kořenovou značkou.

Ian se v Acid4 tedy nejpíš zaměří na XHTML a další XML formáty.

Na jeho vznik si podle všeho ještě pár let počkáme:

Práce na Acid4 začne jakmile budou existovat buildy tří ze čtyř hlavních renderovacích jader, které testem projdou a bude ukončen a oznámen, až výrobci čtyř renderovacích jader oznámí, že opravili chyby nalezené v Acid3 (to může nastat mnohem dřív než se tato jádra skutečně dostanou do prohlížečů).

Pozn.: V první větě je zřejmě myšleno "jakmile 3 jádra projdou Acid3 testem", ačkoliv z přesné formulace vyplývá "jakmile 3 jádra projdou Acid4 testem", což nezní moc pravděpodobně.

A bez zajímavosti není ani seznam bodů, kterých se Ian chce u Acid4 vyvarovat (vychází zřejmě z některých kritik testu Acid3).

Poučení z Acid3

• nezahrnovat minoritní chyby
• nevyžadovat testy od jiných, psát všechny testy sám
• zjišťovat feedback již od začátku od (t=0) bodu, jak veřejně, tak osobně od konkrétních lidí
• zjišťovat feedback, které věci testovat
• nevystavovat test v prvních fázích, aby se zabránilo lidem v odkazování, zatímco se řeší, co se má vlastně testovat
• nezahrnovat do testu výkonností složku (ačkoliv jako zvláštní soutěž je to možné, pokud všichni odsouhlasí, že je to fér)
• ať se jedná o pěkný obrázek
  

Toliko z poznámek člověka, jenž se pomalu ale jistě řadí mezi lidi, kteří nejvíce ovlivnili vývoj Webu a webových prohlížečů.

Je zajímavé, že se Ian, ačkoliv se veřejně nebojí vyjadřovat svou skepsi k XHTML, v testu Acid4 zabývá právě XML.

Já Iana trochu podezřívám, že se snaží vše načasovat, aby test, který bude vytvářet po tom, tedy Acid5, mohl vyjít společně s HTML5 specifikací a testovat tak HTML5 a XHTML5. Potom není s podivem, že se mezi tím věnuje XML. Na HTML není do té doby moc co dalšího testovat.

Co z HTML5 je ve Firefoxu 3

Vyšla trojková verze Firefoxu a oproti své předchozí verzi kromě uživatelských novinek obsahuje i novinky v podpoře vnikající HTML5 specifikace.

Pokud čtete tento blog pravidelně, tak o většině novinkách nejspíš už víte. Pokud ne, můžete si buď zpětně projít příspěvky se štítkem Firefox nebo nahlédnout do následujících třech příruček.

Field Guide to Firefox 3

V oficiální příručce Field Guide to Firefox 3 najdete stručnou zmínku o hlavních vývojářských novinkách. Zmíněn je HTML5 canvas s jeho textovým API (pozor to je zatím nekompatibilní s HTML5), offline webové aplikace a registrace protokolů k webovým aplikacím.

Zajímavé jsou ale i novinky v podpoře CSS a API pro mikroformáty.



Firefox 3 Revealed

Druhou příručkou je Firefox 3 Revealed, kterou připravil server SitePoint. Napřed musíte registrovat svou mailovou adresu, na tu vám přijde odkaz pro stažení třicetistránkového PDF s krásnou liškou na titulní stránce (je to skutečně liška na rozdíl od pandy, která je v logu Firefoxu, zřejmě malý vtípek SitePointu):

I tato příručka se soustředí hlavně na uživatelské rozhraní, najdete v ní ale i část zaměřenou pro vývojáře nazvanou A Developer’s Dream, která stručně popisuje tvorbu offline webových aplikací. Následuje vyjmenovaný přehled podpory HTML 5 (canvas, contentEditable, drag&drop API, atribut ping a posílání zpráv mezi dokumenty) a dále novinky v podpoře CSS, JavaScriptu a SVG.

Firefox 3 for developers

Mnohem víc informací, často i s detailně popsaným API a příklady, pak najdete na oficiální stránce Firefox 3 for developers.

CSS exploit aneb proč na webu nemáme soukromí

Tvorba specifikací je odpovědná věc. Jednou vytvořené specifikace budou platit roky a s každou chybou, která se do nich dostane, se můžou potýkat celé generace.

Chyby se do specifikací skutečně dostávají a často jsou neškodné, že si jich všimnou jen vývojáři prohlížečů, ale běžný webdesigner si s nimi hlavu neláme.

Jen opravdu výjimečně se objeví chyba, která má dopad až na koncového uživatele. Toho, který sedí v teple u svého prohlížeče, pohodlně si kliká a o zkratkách CSS nebo HTML nemá ani potuchy.

Největší chyba webových specifikací

Mluvím teď o chybě všech chyb, o tzv. CSS exploitu. Popravdě si myslím, že se jedná o historicky největší chybu, která se kdy do webových specifikací dostala. A přitom základní myšlenka vypadá zcela nevině, citujme z původní specifikace CSS1, odstavec 2.1:

User agents commonly display newly visited anchors differently from older ones. In CSS1, this is handled through pseudo-classes on the 'A' element:

A:link { color: red } /* unvisited link */
A:visited { color: blue } /* visited links */

Myslíte, že zavedení pseudotříd link a visited nemůže mít pro uživatele neblahé následky? Pokud ano, tak se šeredně mýlíte. Stejně tak se zmýlili i tvůrci CSS1. I když těžko jim to mít za zlé, v letech 1994-1996, kdy kaskádové styly přicházely na svět, ještě Web nebyl plný bezpečnostních problémů, a jak by taky mohl být, když samotný JavaScript byl teprv v plenkách (objevil se koncem roku 1995).

Dnes mi o CSS exploitu vyšel článek, pokud jste o CSS exploitu dosud neslyšeli a pokud si myslíte, že na Webu existuje soukromí, doporučuji si ho přečíst:

Pokud si myslíte, že stránka, kterou právě čtete, o vás nemůže nic zjistit, tak se mýlíte. S jistou pravděpodobností by pomocí tzv. CSS exploitu dokázala odhadnout, jaké vyhledávače používáte, které e-shopy navštěvujete (včetně kategorií, které vás zajímají), zda používáte internetové bankovnictví nebo PayPal, jestli nenavštěvujete politicky nekorektní stránky a mnohem víc.

Více se dočtete v článku CSS exploit a neexistující soukromí na webu.

Namočte se do HTML5 (prezentace)

Lachlan Hunt a James Graham na @media 2008 v Londýně prezentovali Getting Your Hands Dirty with HTML 5 (nechtěl jsem to do nadpisu překládat doslovně).

Slidy z hodinové prezentace si můžete prohlédnout ve formátu PDF (30 MB). Shrnují základní principy vývoje HTML5 a některé hlavní myšlenky specifikace. Časem bude zveřejněn i záznam celé přednášky.

Offtopic: říkám si, zda někdy taky dokážu vytvořit tak vtipné slidy jako Lachlan s Jamesem, protože ty jejich se mi moc líbí.

(Via @media 2008 Presentation Slides a HTML5 Presentation at @media 2008)

Nastavení komprese exportu z canvasu do JPEG

Rozhraní canvasu obsahuje metodu pro export svého obsahu do obrázku (ukázka). Jedná se o metodu toDataURL() s volitelným parametrem, který určuje typ vygenerovaného obrázku. Specifikace vyžaduje, aby prohlížeče implementovaly export do formátu PNG, další formáty jsou volitelné.

Prohlížeče, které canvas implementovaly (S.O.F = Safari + Opera + Firefox), export do PNG již podporují, Firefox navíc podporuje export do formátu JPEG.

Anne van Kesteren včera oznámil, že Opera rovněž plánuje podporovat JPEG a hledá možnost, jak by mohli vývojáři nastavit kompresní poměr vytvořených obrázků, více viz příslušné vlákno, ve kterém se řeší, zda by se to mělo dít pomocí atributu canvasu nebo pomocí dalšího argumentu metody toDataURL.

Canvas se tak postupně zdokonaluje a stává stále mocnějším nástrojem (viz např. nedávné začlenění funkcí pro renderování textu). S tímto přístupem se stávající hračky jako je kupříkladu Pixastic prototype online nástroje pro editaci fotografií pomocí canvasu časem stanou skutečně použitelnými aplikacemi pro práci s obrázky (aplikaci grafických filtrů již zvládají, chyběl právě ten kvalitní export).

O HTML5 na TechCrunch

Na serveru TechCrunch nedávno vyšly dva články zabývající se HTML5.

Ten první The Next-Gen Web: Browser Storage Support se zabývá offline úložišti a soustředí se na jejich podporu v prohlížečích. Většina obsahu článku nebude pro čtenáře tohoto blogu velkou novinkou. Na konci ve shrnutí autor Nik Cubrilovic píše:

Je velmi neobvyklé, aby se nová technologie jako lokální úložiště v prohlížečích dočkala tak široké pozornosti a byla převážně založena na jediné specifikaci.

Což je hezké, ovšem zatím se ještě nesjednotily rozdíly mezi implementacemi v Google Gears a v blížícím se Internet Exploreru 8, byť se na obojím snad pracuje.

U lokálních úložišť a cachování (pozn. překl. myslí tím offline aplikace) je tak zatím vítězem otevřený standard. Alternativní řešení pravděpodobně vymizí nebo se přizpůsobí a implementují stejné API.

Druhý článek se jmenuje The Next-Gen Web: HTML5 - Will We Ever See A Real Standard?, vrací se do historie a spekuluje nad tím, zda HTML5 náhodou nepotká stejný osud jako HTML3 (to je historická verze HTML, která zcela propadla, nikdy se nedokončila a neimplementovala).

Ačkoliv se předpověď autora článku může vyplnit, přesto zde vidím několik rozdílů. Snaha o vytvoření HTML3 neprošla, protože ho v zásadě nikdo nechtěl implementovat, prohlížeče (hlavně ty dva) mezitím válčily mezi sebou a nějaká standardizace je zas až tak nezajímala.

Dnes je situace jiná, prohlížeče HTML5 implementovat chtějí a nejenom že chtějí, oni ho již pomalu implementují. Není náhodou, že odhadem více než polovina celé HTML5 specifikace se dočkala nějaké implementace alespoň v jednom prohlížeči, byť průnik zatím není příliš velký (myšleno průnik jako část implementovanou komplet všemi prohlížeči).

Ve zbylých bodech (rozsáhlost specifikace, trvání její přípravy) lze dát článku pravdu. Je ovšem otázkou, zda pro neúspěch HTML3 byly klíčové právě tyto body nebo naopak to, co jsem popsal já výše.

A citace ze závěru článku:

Historie Webu nám ukazuje, že je tu obvykle jen jeden vítěz, uživatelé pravidelně migrují k jedinému vyhrávajícímu řešení, které se samo prohlásí za standard.

Je pro mne zajímavé sledovat, jak se zprávy o HTML5 pomalu přestávají objevovat jen na stránkách určených pro "technologické hračičky" a HTML5 je pomalu objevováno i v bussiness prostředí (slovo pomalu jsem ztučnil, protože ten posun v povědomí bude trvat dlouho; určitě neproběhne v tomto roce nejdříve tak v roce příštím).

Tisk v HTML5

Včera do specifikace HTML5 přibyla krátká sekce Printing. V té se podrobně definuje, jak se má prohlížeč zachovat při volání metody window.print() nebo vyvolání tisku z uživatelského rozhraní prohlížeče, a zavádí události beforeprint a afterprint.

Pro mne jsou tyto události novinkou, ale podle všeho jsou již implementované v Internet Exploreru, tak je možná někdo znáte. V mailing listu WHATWG bylo jejich začlenění již kdysi navrhováno.

Tyto události mohou připravit dokument k tisku tam, kde kaskádové styly pro tisková média nestačí. Jako jednoduchý případ je uvedeno např. zobrazení aktuálního času při tisku ve stránce. Já bych byl rád, kdyby nás dokázaly zbavit i odkazů à la Vytiskni mapu na www.mapy.cz (a nejspíše i na většině dalších map a podobných aplikací), resp. ať tam ta tlačítka třeba i zůstanou, ale nechť vyvolání tisku z prohlížeče vyvolá stejný efekt jako tyto odkazy.

Během vyvolaného dialogu k tisku musí prohlížeč po proběhnuté události beforeprint buď zastavit všechny změny stránky (tedy JavaScript, animace obrázků, pluginy etc.) anebo si zapamatovat jejich podobu v momentu, kdy uživatel vydal pokyn k tisku (aby prohlížeč nakonec nevytiskl neco jiného, než co uživatel chtěl).

Firefox 3 a canvas s textem

Rozhraní canvasu ve Firefoxu 3 bylo rozšířeno o funkce pro zobrazování textu. Píše o tom Vladimir Vukičevič v příspěvku HTML Canvas in Firefox 3 na svém blogu.

Pokud používáte trojkovou řadu Firefoxu, uvidíte na příkladu Path text velký nápis Mozilla, okolo kterého se "plazí" první odstavce z Mozilla Manifesto.

V jiných prohlížečích text neuvidíte. Je to proto, že Mozilla přišla s vlastním API pro vykreslování textu. Canvas žádné API pro text neměl a původně se o něm ani neuvažovalo. Mozilla proto implementovala čtyři funkce označené vendor specific prefixem moz (mozDrawText, mozMeasureText, mozPathText, mozTextAlongPath).

Teprve nedávno se začalo pracovat na oficiálním textovém API pro canvas. Jeho příprava a implementace ještě nějaký čas potrvá.

Mezitím vývojářům nic nebrání používat nové API Firefoxu 3 (pokud dobře zváží fakt, že není v jiných prohlížečích podporováno), prefix moz zajistí, aby se tyto funkce do budoucna nedostaly do konfliktu se vznikajícím standardizovaným textovým rozhraním, které se dostane až do některé z dalších verzí Firefoxu.

Chceme jednotné výchozí CSS pro všechny prohlížeče?

Včera se v HTML WG objevil zajímavý návrh. Justin James v e-mailu s předmětem Proposal: Default style definitions for elements navrhuje, aby se součástí HTML specifikace stalo i ustanovení výchozích kaskádových stylů pro všechny prohlížeče.

Myšlenka je to určitě zajímavá (snad každý webdesigner se minimálně jednou podivil, proč má každý prohlížeč výchozí styly jiné), otázkou je, zda by byla v dnešním spektru různých platforem a zařízení se svými zvyklostmi a omezeními rozumně realizovatelná.

Vývojář Gecka Boris Zbarsky ji odmítá, Anne van Kesteren tvrdí, že Ian Hickson má v úmyslu se tomu věnovat.

Jsem zvědav, jaké další názory se v diskusi ještě objeví. Pokud vás to zajímá, sledujte příslušné vlákno, přečtěte si i loňské vlákno na stejné téma a wiki stránku HTML Issue: Default Style Sheet, kde se mají sbírat náměty k řešení.

BTW jistý předpis již existuje jako součást CSS specifikace, ovšem nejedná se o žádné nařízení (prohlížeče se podle něj chovat nemusí a ani tak nečiní).

Offline webové aplikace v kostce

W3C včera vydalo dokument shrnující základní informace o offline webových aplikacích. Autory Offline Web Applications jsou Anne van Kesteren a Ian Hickson.

Dokument je velmi krátký (vytištěný se vejde na čtyři A4 stránky) a neobsahuje nic, co by nebylo součástí HTML5 specifikace. Jeho hlavním účelem je představit základní myšlenky tohoto nového konceptu (SQL5, offline manifest, online/offline události).

Očekávám, že do budoucna se podobných dokumentů objeví více. Přeci jen každý nemá čas číst celou dlouhou specifikaci, a tak jsou taková shrnutí velmi přínosná.

(Via blog.whatwg.org)

Univerzální odkaz?

Eric Meyer si ve svém článku The Missing Link stěžuje, že součástí HTML5 se nestal univerzální atribut href, který by umožnil udělat odkaz z libovolného elementu na stránce (jedná se o vynález XHTML2).

Eric není s tímto požadavkem první a (odmítavá) odpověď se již před časem dostala do seznamu často kladených otázek. Eric se domnívá, že uvedené argumenty nejsou správné a ve svém článku se snaží vysvětlit proč.

Předpokládám, že to není poslední debata na tohle téma. On problém není zcela triviální. Netýká se jen povolení atributu v HTML, ale i všech dalších technologií, které na to navazují, ať již CSS nebo DOM. Otázka tedy není jen zda ano či ne, ale také proč a - to nejdůležitější - jak.