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.