Na Standards Suck vyšel krátký rozhovor s Ianem Hicksonem. Poslechněte si v něm mj. jak a kde všude Ian sbírá feedback při své práci editora HTML5 (myslím, že je to docela zajímavé).
Hixie on Editing HTML5 from Standards Suck on Vimeo.
neděle 7. prosince 2008
pátek 5. prosince 2008
Parser HTML5 experimentálně i v Mozille
O několika HTML5 parserech jsem se již zmiňoval (viz příspěvky se štítkem parser). Henri Sivonen vytvořil experimentální build Mozilly používající právě HTML5 parser. Jedná se o zajímavou ukázku. V době, kdy žádný prohlížeče neobsahuje HTML5 kompatibilní parser (na to je ještě brzy) tu máme alespoň experimentální verzi.
Sam Ruby tento zajímavý počin komentuje:
Sam Ruby tento zajímavý počin komentuje:
Henri’s approach is interesting. He starts from a single source, in Java. The Java code can be compiled to Java byte codes, JavaScript source, or C++ presumably making use of Mozilla libraries for things such as memory management. If he can do that, it seems to me to be a rather small leap from there to producing C++ using, say, either Ruby or Python libraries for memory management, as well as a thin binding to the language. C# would also be a reasonable target.
If this could be done, and made available under a liberal license, it could go a long way towards making available consistent and performant implementations of the HTML5 parser algorithm everywhere.
neděle 30. listopadu 2008
Slidy z přednášky Představení HTML5
Před týdnem jsem měl na semináři Junior Internet přednášku Představení HTML5.
Pro zájemce vystavuji slidy.
Předváděl jsem i několik online ukázek, jejich přehled najdete v mých Del.icio.us záložkách.
Pro zájemce vystavuji slidy.
Předváděl jsem i několik online ukázek, jejich přehled najdete v mých Del.icio.us záložkách.
pondělí 17. listopadu 2008
Formulářové prvky dostanou placeholder
Všimli jste si, že řada webů dnes používá v hledacích polích malou nápovědu? Jedná se o text, který se zobrazuje, když je textové pole prázdné. Jakmile do pole umístíte kurzor, abyste začali psát, nápověda zmizí. Typicky se jedná o text "Zadejte hledaný výraz", "Váš e-mail", "www.example.cz", který jednak uživateli s psaním pomůže a také upoutá pohled uživatele k formuláři.
V poněkud sofistikovanějším provedení takové řešení můžete vidět vpravo nahoře na www.weblogy.cz (tam je kromě textu zobrazeno i logo Googlu). Prázdné textové pole je nevyužitá plocha, proč ji nevyužít (v případě Googlu dokonce k propagaci značky).
K realizaci takové nápovědy je ovšem nutný JavaScript. Podle moudrého pravidla úkoly, které se dělají často, by se měly dát dělat jednoduše textovým formulářovým prvkům nově přibude atribut placeholder, který výše uvedenou funkcionalitu zastane. Použití je snadné:
<input type="email" placeholder="jan@example.cz">
Atribut placeholder dostane nejen input s type="text", ale i nově zavedené značky z WebForms2, např. type="email", type="url" apod.
Specifikace říká, že placeholder má obsahovat krátkou nápovědu sloužící uživateli k vyplnění pole. K delší nápovědě může být použit např. atribut title. Prohlížeče text atributu placeholder zobrazí pouze v případě, kdy je formulářové pole prázdné a nemá focus.
Více najdete v příslušném diffu specifikace (musíte odscrollovat až téměř nakonec).
V poněkud sofistikovanějším provedení takové řešení můžete vidět vpravo nahoře na www.weblogy.cz (tam je kromě textu zobrazeno i logo Googlu). Prázdné textové pole je nevyužitá plocha, proč ji nevyužít (v případě Googlu dokonce k propagaci značky).
K realizaci takové nápovědy je ovšem nutný JavaScript. Podle moudrého pravidla úkoly, které se dělají často, by se měly dát dělat jednoduše textovým formulářovým prvkům nově přibude atribut placeholder, který výše uvedenou funkcionalitu zastane. Použití je snadné:
<input type="email" placeholder="jan@example.cz">
Atribut placeholder dostane nejen input s type="text", ale i nově zavedené značky z WebForms2, např. type="email", type="url" apod.
Specifikace říká, že placeholder má obsahovat krátkou nápovědu sloužící uživateli k vyplnění pole. K delší nápovědě může být použit např. atribut title. Prohlížeče text atributu placeholder zobrazí pouze v případě, kdy je formulářové pole prázdné a nemá focus.
Více najdete v příslušném diffu specifikace (musíte odscrollovat až téměř nakonec).
pátek 14. listopadu 2008
Přehledný dokument jazyka HTML5
Jelikož specifikace HTML5 je relativně dlouhá a primárně určená pro implementátory nikoliv webdesignery, pokouší se Michael Smith z ní připravit jednoduchý výtah, který by byl pro designery a kde by šlo přehledně nalézt pouze informace o jazyce HTML (bez informaci o DOM apod.).
Pracovní návrh je tohoto dokumentu vám k dispozici.
Pracovní návrh je tohoto dokumentu vám k dispozici.
úterý 4. listopadu 2008
Libo být editorem budoucnosti HTML?
Specifikace HTML5 není zrovna malá. Když se jejího editora Iana Hicksona někdo zeptá, proč některé části nevyčlení do zvláštních specifikací (protože by z logických důvodů lépe fungovaly zvlášť, jmenujme například canvas) odpoví, že by mohl, ale není po ruce editor, který by si vzal vyčleněnou specifikaci na starosti. Ve výsledku by to proto znamenalo nikoliv onu část vyčlenit, ale zahodit. Proto některé části setrvávají (a nejspíš i navěky setrvají) uvnitř HTML5.
Nedávno si dal Ian práci a zmíněné části zveřejnil včetně odhadu, kolik by zabraly editorovi času. (Velmi doporučuji, abyste se na ten čas podívali, ať máte představu, jak dlouho může vytvoření pořádné specifikace trvat a vzpomeňte si na to, až si budete někdy stěžovat, že specifikace XY není tak dokonalá, jak byste si přáli!)
Zároveň Ian přidal nápady, které se do HTML5 už nedostanou, ale které by stáli za realizaci (např. 3D mód canvasu).
Vypisuji jednotlivá témata, pro podrobnější popis se podívejte do původního mailu:
Nedávno si dal Ian práci a zmíněné části zveřejnil včetně odhadu, kolik by zabraly editorovi času. (Velmi doporučuji, abyste se na ten čas podívali, ať máte představu, jak dlouho může vytvoření pořádné specifikace trvat a vzpomeňte si na to, až si budete někdy stěžovat, že specifikace XY není tak dokonalá, jak byste si přáli!)
Zároveň Ian přidal nápady, které se do HTML5 už nedostanou, ale které by stáli za realizaci (např. 3D mód canvasu).
Vypisuji jednotlivá témata, pro podrobnější popis se podívejte do původního mailu:
- HTML5 Rendering and UA behavior
- Interaction events
- 3D Canvas
- UndoManager
- Stylesheet DOM
- URL
- Common DOM interfaces
- Content-Type handling and content sniffing
- 2D Canvas
- Platform Core
středa 29. října 2008
Dvě přednášky o HTML5 už brzy
Pokud jste náhodou z Brna, tak tuhle sobotu 1.11. mám na konferenci LinuxAlt (vstup zdarma) přednášku Média v HTML5 věnovanou zejména novým značkám video, audio a canvas (viz program konference).
Pokud jste náhodou z Prahy, tak hned další čtvrtek 6.11. mám v rámci akcí PROWAS (taktéž zdarma) v Praze přednášku HTML5 is happening věnovanou zejména těm částem HTML5, které již byly implementovány (viz pozvánka).
Rád tam uvidím nejen čtenáře tohoto blogu.
A pokud to máte daleko jak do Prahy, tak do Brna, tak se omlouvám 8-)
Aktualizace: Slidy z přednášky Média v HTML5.
Pokud jste náhodou z Prahy, tak hned další čtvrtek 6.11. mám v rámci akcí PROWAS (taktéž zdarma) v Praze přednášku HTML5 is happening věnovanou zejména těm částem HTML5, které již byly implementovány (viz pozvánka).
Rád tam uvidím nejen čtenáře tohoto blogu.
A pokud to máte daleko jak do Prahy, tak do Brna, tak se omlouvám 8-)
Aktualizace: Slidy z přednášky Média v HTML5.
úterý 28. října 2008
Zdroják a proč sem teď tak často nepíšu
Pokud se divíte, proč na HTML456 poslední dobou tak často nepíšu, je to proto, že jsem nedávno pod křídly Internet Infa spustil nový magazín Zdroják, který je určený pro webdesignery a webové vývojáře.
HTML456 míním psát i nadále, ale řadu informací teď najdete přímo na Zdrojáku, který vám doporučuji začít sledovat, protože ne vždy budu texty o HTML5, které vyjdou na Zdrojáku, linkovat i z tohoto blogu.
Jsou snadno k nalezení, protože jsou všechny označeny nálepkou HTML5 (už teď jich na Zdrojáku najdete skoro deset!). A ke sledování můžete použít i RSS zpráviček a RSS článků.
HTML456 míním psát i nadále, ale řadu informací teď najdete přímo na Zdrojáku, který vám doporučuji začít sledovat, protože ne vždy budu texty o HTML5, které vyjdou na Zdrojáku, linkovat i z tohoto blogu.
Jsou snadno k nalezení, protože jsou všechny označeny nálepkou HTML5 (už teď jich na Zdrojáku najdete skoro deset!). A ke sledování můžete použít i RSS zpráviček a RSS článků.
středa 15. října 2008
Předvolba pro vypnutí autoplay videa
Když jsem nedávno předváděl podporu videa ve Firefoxu a o něco dříve podporu videa v Safari, stěžoval jsem si, že oba prohlížeče umožňují spustit video i s vypnutým JavaScriptem (to specifikace nařizuje - jedná se o autribut autoplay), ale neumožňují uživateli tuhle funkci vypnout (o tom se specifikace nijak nezmiňovala).
Velmi mě potěšilo, když včera do HTML5 specifikace přibyl odstavec, který doporučuje prohlížečům nechat uživatele tuhle funkci vypnout. Podobně autorům stránek je doporučováno automatické spouštění řešit atributem autoplay a nikoliv skriptováním:
Velmi mě potěšilo, když včera do HTML5 specifikace přibyl odstavec, který doporučuje prohlížečům nechat uživatele tuhle funkci vypnout. Podobně autorům stránek je doporučováno automatické spouštění řešit atributem autoplay a nikoliv skriptováním:
User agents are not required to autoplay, and it is suggested that user agents honor user preferences on the matter. Authors are urged to use the autoplay attribute rather than using script to force the video to play, so as to allow the user to override the behavior if so desired.Už se těším, až se v prohlížečích takové funkce objeví. Přeci jen uživatel má být vždy tím, kdo má svrchované právo rozhodnout, jak se prohlížeč bude chovat.
neděle 28. září 2008
Ian Hickson: vlastnosti, které zoufale chcete, ale ještě nemůžete použít
Editor HTML5 specifikace, Ian Hickson měl minulé pondělí přednášku o HTML5, na které předváděl již hotové nebo probíhající implementace klíčových částí HTML5. Záznam celé přednášky nalezenete na Youtube.
Přednáška trvá hodinu a podává pěkný přehled o celé šířce záběru HTML5. Pokud vás zajímají jen některé části, tady je osnova přednášky:
Online najdete i všechny příklady z přednášky a komentáře k nim.
(Zdroj: Whatwg.org)
- Úvod
- <video> (00:35)
- postMessage() (05:40)
- localStorage (15:20)
- sessionStorage (21:00)
- API pro Drag and Drop (29:05)
- onhashchange (37:30)
- Formulářové prvky (40:50)
- <canvas> (56:55)
- Validace (1:07:20)
- Dotazy (1:09:35)
Online najdete i všechny příklady z přednášky a komentáře k nim.
(Zdroj: Whatwg.org)
čtvrtek 25. září 2008
Proměnné v CSS - lesk a bída standardizace
Řada webdesignerů se těší na brzké zavedení proměnných do CSS. Návrh specifikace vznikl velice rychle, WebKit je již implementoval a ačkoliv někteří s jejich zavedením nesouhlasí, vše se zdálo být na rychlé a bezproblémové cestě (což je ve světě webových standardů dosti neobvyklé!).
K jejich rychlému zavedení je třeba, aby byla včas specifikace prohlášena za stabilní, a aby prohlížeče CSS promněnné implementovaly. Obojí spolu souvisí. Čím dříve bude specifikace hotová, tím dříve se může objevit v prohlížečích a naopak čím dříve se objeví v některých prohlížečích, tím dříve může být hotova. (Že by kruh? Ale tak to prostě je.)
Ovšem od úterý probíhá v diskusní skupině CSS WG debata, ze které vyplývá, že nic není tak růžové. Dave Hyatt píše, že implementaci z WebKitu odstranil, protože ačkoliv všichni proměnné v CSS chtějí, nedaří se dohodnout, jak má jejich implementace vypadat:
Na druhou stranu i ostatní prohlížeče obsahují vlastnosti, které sice jsou naprogramované, ale z nějakých důvodů se do veřejných verzí nedostávají (ať již nejsou dost otestované nebo by mohly být kontroverzní, případně se čeká na specifikaci), takže Davův postup není nijak výjimečný.
Pro designery to znamená jediné: CSS proměnných se sice dočkáme, ale možná přijdou ještě o něco později.
Pro zájemce celé vlákno [Css Variables] Variable Declaration Blocks.
Lesk a bída standardizace
Standardizace je pomalý proces. Sejde se vám kupa odborníků, každý má na věc jiný názor, no a teď standardizujte. Hlavně ale nepočítejte s tím, že se během pár měsíců na něčem dohodnete! Dejte si raději rezervu jednoho roku. Minimálně! Jen několik měsíců může trvat výběr správného názvu jednotlivých funkcí!
V HTML5 funguje (ano, skutečně to funguje!) metoda osvíceného diktátora. Všichni se pár týdnů o podobě nové vlastnosti hádají, pak si Ian Hickson sedne, sepíše návrh specifikace a zveřejní ji (tedy de facto rozhodne sám a za sebe, byť na základě návrhů ostatních). Následně se všichni hádají o jeho návrhu a objeví se pár blogpostů, že Hickson celou skupinou manipuluje a nikdo kromě něj nemá na specifikaci vliv, nebo někdo ze skupiny protestně odejde.
Hickson ty nadávky igronuje a podívá se na kritiku návrhu, vybere z ní nejlepší myšlenky a svůj návrh podle nich přepíše. Tohle kolečko se ještě dvakrát zopakuje a ve výsledku tu je specifikace, se kterou naprostá většina zúčastněných souhlasí a je s ní spokojená.
Existuje i další "standardizační" proces, kdy se výrobci jednoho prohlížeče pro něco rozhodnou, rychle to naimplementují a vydají. Druhý prohlížeč to naimplementuje taky (někdy trochu jinak, protože ten první prohlížeč k tomu nedal pořádnou specifikaci) a než se nadějeme, používáme to všichni. Je to sice plné problémů, je to návrh, za který se někde i vyhazuje od zkoušky, ale světe div se, vývojáři jsou rádi, že aspoň něco mají.
Tak a teď si vyberte!
Máme tu několik špatných cest. Jenže tu dobrou cestu nikdo nezná, a tak se vývoj webu často odehrávách na těch cestách, které jsou zrovna v tu chvíli z těch všech špatných ty nejméně špatné.
Vzpomeňte si na to, až zas někde uslyšíte, že Ian Hickson je diktátor, nebo že prohlížeč XY implementoval cosi svého. Netvrdím, že je to správné, ale někdy to může být to nejlepší řešení.
K jejich rychlému zavedení je třeba, aby byla včas specifikace prohlášena za stabilní, a aby prohlížeče CSS promněnné implementovaly. Obojí spolu souvisí. Čím dříve bude specifikace hotová, tím dříve se může objevit v prohlížečích a naopak čím dříve se objeví v některých prohlížečích, tím dříve může být hotova. (Že by kruh? Ale tak to prostě je.)
Ovšem od úterý probíhá v diskusní skupině CSS WG debata, ze které vyplývá, že nic není tak růžové. Dave Hyatt píše, že implementaci z WebKitu odstranil, protože ačkoliv všichni proměnné v CSS chtějí, nedaří se dohodnout, jak má jejich implementace vypadat:
It's off pending a decision of any kind. :) The feature works well, but it seems everyone has his/her own idea of how this feature should work, and nobody has the same opinion. I'm basically disgusted at this point and giving up on the whole feature.A dodává, že nechce, aby se do ostré verze Safari (nebo Google Chrome) dostaly CSS proměnné v podobě, která není dosud jistá, protože tak dlouho očekávaná novinka by se začala rychle používat a WebKit by ji pak musel podporovat navěky, i přestože by oficiální implementace vypada úplně jinak:
The problem with leaving CSS variables turned on in WebKit is that if the feature ships, it is going to be hugely popular. We know this. Whatever we ship, we will have to support on OS X forever, because apps on the platform will scramble to use this feature.Já sice chápu Davevovu opatrnost, ale myslím si, že přesně takovéhle nejisté oblasti jsou doménou vendor prefixů. Je to vlastně jeden z důvodů, proč se vendor prefixy používají a Dave toho (dle mě zbytečně) odmítá použít.
Na druhou stranu i ostatní prohlížeče obsahují vlastnosti, které sice jsou naprogramované, ale z nějakých důvodů se do veřejných verzí nedostávají (ať již nejsou dost otestované nebo by mohly být kontroverzní, případně se čeká na specifikaci), takže Davův postup není nijak výjimečný.
Pro designery to znamená jediné: CSS proměnných se sice dočkáme, ale možná přijdou ještě o něco později.
Pro zájemce celé vlákno [Css Variables] Variable Declaration Blocks.
Lesk a bída standardizace
Standardizace je pomalý proces. Sejde se vám kupa odborníků, každý má na věc jiný názor, no a teď standardizujte. Hlavně ale nepočítejte s tím, že se během pár měsíců na něčem dohodnete! Dejte si raději rezervu jednoho roku. Minimálně! Jen několik měsíců může trvat výběr správného názvu jednotlivých funkcí!
V HTML5 funguje (ano, skutečně to funguje!) metoda osvíceného diktátora. Všichni se pár týdnů o podobě nové vlastnosti hádají, pak si Ian Hickson sedne, sepíše návrh specifikace a zveřejní ji (tedy de facto rozhodne sám a za sebe, byť na základě návrhů ostatních). Následně se všichni hádají o jeho návrhu a objeví se pár blogpostů, že Hickson celou skupinou manipuluje a nikdo kromě něj nemá na specifikaci vliv, nebo někdo ze skupiny protestně odejde.
Hickson ty nadávky igronuje a podívá se na kritiku návrhu, vybere z ní nejlepší myšlenky a svůj návrh podle nich přepíše. Tohle kolečko se ještě dvakrát zopakuje a ve výsledku tu je specifikace, se kterou naprostá většina zúčastněných souhlasí a je s ní spokojená.
Existuje i další "standardizační" proces, kdy se výrobci jednoho prohlížeče pro něco rozhodnou, rychle to naimplementují a vydají. Druhý prohlížeč to naimplementuje taky (někdy trochu jinak, protože ten první prohlížeč k tomu nedal pořádnou specifikaci) a než se nadějeme, používáme to všichni. Je to sice plné problémů, je to návrh, za který se někde i vyhazuje od zkoušky, ale světe div se, vývojáři jsou rádi, že aspoň něco mají.
Tak a teď si vyberte!
Máme tu několik špatných cest. Jenže tu dobrou cestu nikdo nezná, a tak se vývoj webu často odehrávách na těch cestách, které jsou zrovna v tu chvíli z těch všech špatných ty nejméně špatné.
Vzpomeňte si na to, až zas někde uslyšíte, že Ian Hickson je diktátor, nebo že prohlížeč XY implementoval cosi svého. Netvrdím, že je to správné, ale někdy to může být to nejlepší řešení.
středa 24. září 2008
Budou HTML formulář přímo přistupovat ke kameře?
Brad Lassey ve svých úvahách o mobilní verzi Firefoxu dospěl k zajímavému nápadu:
<input type=”camera” />
Posílání videí (nebo i fotek) pořízených z kamer připojených k počítači roste. (A to už vůbec nemluvím o mobilních telefonech!) Proč celý proces neusnadnit a neintegrovat do webového prohlížeče? Potřebujete nahrát do svého profilu na Facebooku fotografii? Stačí kliknout na input, vyfotit se a prohlížeč výsledek odešle. Když prohlížeče dokážou přehrávat <video>, proč by jej neměli umět také vytvářet?
Daniel Glazman zdůrazňuje několik bezpečnostních aspektů, ale s nápadem souhlasí a navrhuje začlenit ho do HTML5.
V HTML5 konferenci (resp. ani v jedné z těch dvou konferencí) se návrh zatím neobjevil. Jsem zvědav. Já bych pro něj hlasoval všemi deseti. Bylo by nutné zajistit, aby mohl být ve starších prohlížečích emulován klasickým <input type="file">, ale to je tak všechno.
BTW Jistě není náhodou, že se tento nápad objevil krátce po virální akci blogerů Mozilly.
<input type=”camera” />
Posílání videí (nebo i fotek) pořízených z kamer připojených k počítači roste. (A to už vůbec nemluvím o mobilních telefonech!) Proč celý proces neusnadnit a neintegrovat do webového prohlížeče? Potřebujete nahrát do svého profilu na Facebooku fotografii? Stačí kliknout na input, vyfotit se a prohlížeč výsledek odešle. Když prohlížeče dokážou přehrávat <video>, proč by jej neměli umět také vytvářet?
Daniel Glazman zdůrazňuje několik bezpečnostních aspektů, ale s nápadem souhlasí a navrhuje začlenit ho do HTML5.
V HTML5 konferenci (resp. ani v jedné z těch dvou konferencí) se návrh zatím neobjevil. Jsem zvědav. Já bych pro něj hlasoval všemi deseti. Bylo by nutné zajistit, aby mohl být ve starších prohlížečích emulován klasickým <input type="file">, ale to je tak všechno.
BTW Jistě není náhodou, že se tento nápad objevil krátce po virální akci blogerů Mozilly.
neděle 21. září 2008
Když si Firefox zapingá
Firefoxu 3 implementoval atribut ping z HTML5. Možná jste si toho ale vůbec nevšimli. To proto, že podpora pingání je po instalaci vypnuta. Pokud ji chcete zapnout, nastavte na stránce about:config předvolbu browser.send_pings na hodnotu true.
K čemu je takové pingání dobré? Pokud se pozorně podíváte prakticky na jakýkoliv vyhledávač, zjistíte, že na stránce s výsledky hledání pečlivě monitoruje, na které nalezené odkazy klikáte a na které ne.
(Úkol pro zvídavé: Podívejte se, jak takový monitoring dělá Google, jak Seznam a zamyslete se, proč je způsob zvolený Seznamem rychlejší, byť méně přesný. A také proč oba vyhledávače zapomněly na uživatele nepoužívající myš.)
Monitoring klikání na odkazy se ovšem nehodí jen pro vyhledávače. Když jsme kdysi v CZille přemýšleli, jak udělat počitadlo stažených Firefoxů z našich stánek, došli jsme také k pingacímu řešení. Prosté logování hitů na stahovaný soubor nelze použít, v tom se vám projeví i roboti.
Pingání tak není jen pro velké firmy s vyhledávači, ale prakticky pro každého, kdo monitoruje pohyb uživatelů na svých stránkách. Předpokládám, že nástroje jako Google Analytics budou atribut ping po jeho zavedení také využívat.
Proč zavést ping atribut?
Pokud se některá technologie hojně používá a její použití (správný zápis) je zbytečně komplikované, mělo by se zjednodušit. Pokud jste se dívali, jak mají pingání implementováno i Googlu a Seznamu, asi uznáte, že o jednoduchosti se nedá hovořit. Jenže ono to zatím o moc líp udělat nejde.
A přesně to řeší atribut ping u odkazu (nebo u značky area). Jeho použití je snadné:
<a ping="http://www.example.cz/ping" href="http://www.example.cz/">Odkaz</a>
Pokud uživatel přejde na odkaz, je zároveň poslán požadavek na adresu uvedenou v atributu ping. Pokud je v atributu ping uvedeno více adres oddělených mezerou, pošle prohlížeče požadavek na všechny uvedené adresy.
Požadavek je zaslán metodou POST a pokud adresa v atributu ping a adresa aktuálního dokumentu jsou ze stejné domény, pošlou se v požadavku i další hlavičky: Ping-From a Ping-To (obsahuje adresu odkazu, na který uživatel přechází).
Výhody
Atribut ping byl zatím implementován jen ve Firefoxu 3. Jedná se spíše o implementační experiment sloužící pro zpětnou vazbu při tvorbě HTML5 specifikace a ve výchozí instalaci je vypnut.
Všiml jsem si, že Firefox posílá požadavek pouze na první adresu v atributu ping. Pokud je jich víc, ponechá ostatní bez odezvy (to je chyba v implementaci).
Soukromí uživatelů
A co na to uživatelé? Co když se jim takové sledování nebude líbit? Pokud byli paranoidní, pomohl jim vypnutý JavaScript, atribut ping ale funguje i bez JavaScriptu.
Myslím, že uživatelé můžou klidně spát. Pravděpodobně každý prohlížeč nabídne možnost atribut ping vypnout. Ať již pro běžné používání nebo v soukromém módu (přezdívaném porno mód), který se dnes již stal standardem a dříve či později jej budou obsahovat všechny prohlížeče.
Přesto se nemůžu zbavit pocitu, že se prohlížeče tomuto atributu vyhýbají. Jeho implementace je velmi jednoduchá, ale kromě Firefoxu se do ní zatím nikdo jiný nepustil. Že by byly opatrní a nechtěly být označeni za prohlížeč omezující soukromí uživatele? Kdo ví!
K čemu je takové pingání dobré? Pokud se pozorně podíváte prakticky na jakýkoliv vyhledávač, zjistíte, že na stránce s výsledky hledání pečlivě monitoruje, na které nalezené odkazy klikáte a na které ne.
(Úkol pro zvídavé: Podívejte se, jak takový monitoring dělá Google, jak Seznam a zamyslete se, proč je způsob zvolený Seznamem rychlejší, byť méně přesný. A také proč oba vyhledávače zapomněly na uživatele nepoužívající myš.)
Monitoring klikání na odkazy se ovšem nehodí jen pro vyhledávače. Když jsme kdysi v CZille přemýšleli, jak udělat počitadlo stažených Firefoxů z našich stánek, došli jsme také k pingacímu řešení. Prosté logování hitů na stahovaný soubor nelze použít, v tom se vám projeví i roboti.
Pingání tak není jen pro velké firmy s vyhledávači, ale prakticky pro každého, kdo monitoruje pohyb uživatelů na svých stránkách. Předpokládám, že nástroje jako Google Analytics budou atribut ping po jeho zavedení také využívat.
Proč zavést ping atribut?
Pokud se některá technologie hojně používá a její použití (správný zápis) je zbytečně komplikované, mělo by se zjednodušit. Pokud jste se dívali, jak mají pingání implementováno i Googlu a Seznamu, asi uznáte, že o jednoduchosti se nedá hovořit. Jenže ono to zatím o moc líp udělat nejde.
A přesně to řeší atribut ping u odkazu (nebo u značky area). Jeho použití je snadné:
<a ping="http://www.example.cz/ping" href="http://www.example.cz/">Odkaz</a>
Pokud uživatel přejde na odkaz, je zároveň poslán požadavek na adresu uvedenou v atributu ping. Pokud je v atributu ping uvedeno více adres oddělených mezerou, pošle prohlížeče požadavek na všechny uvedené adresy.
Požadavek je zaslán metodou POST a pokud adresa v atributu ping a adresa aktuálního dokumentu jsou ze stejné domény, pošlou se v požadavku i další hlavičky: Ping-From a Ping-To (obsahuje adresu odkazu, na který uživatel přechází).
Výhody
- Již zmíněná jednoduchost.
- Přesnost - mechanismus funguje i pro uživatele bez myši, dokonce i pro uživatele bez JavaScriptu. (Přesnost pochopitelně bude platit jen v případě, že všechny prohlížeče atribut ping implementují.)
Atribut ping byl zatím implementován jen ve Firefoxu 3. Jedná se spíše o implementační experiment sloužící pro zpětnou vazbu při tvorbě HTML5 specifikace a ve výchozí instalaci je vypnut.
Všiml jsem si, že Firefox posílá požadavek pouze na první adresu v atributu ping. Pokud je jich víc, ponechá ostatní bez odezvy (to je chyba v implementaci).
Soukromí uživatelů
A co na to uživatelé? Co když se jim takové sledování nebude líbit? Pokud byli paranoidní, pomohl jim vypnutý JavaScript, atribut ping ale funguje i bez JavaScriptu.
Myslím, že uživatelé můžou klidně spát. Pravděpodobně každý prohlížeč nabídne možnost atribut ping vypnout. Ať již pro běžné používání nebo v soukromém módu (přezdívaném porno mód), který se dnes již stal standardem a dříve či později jej budou obsahovat všechny prohlížeče.
Přesto se nemůžu zbavit pocitu, že se prohlížeče tomuto atributu vyhýbají. Jeho implementace je velmi jednoduchá, ale kromě Firefoxu se do ní zatím nikdo jiný nepustil. Že by byly opatrní a nechtěly být označeni za prohlížeč omezující soukromí uživatele? Kdo ví!
čtvrtek 18. září 2008
Ukázka podpory videa ve Firefoxu 3.1
Vývojová verze Firefoxu 3.1 Alfa 2 podporuje značky video a audio z HTML5. Já se jí podívám trochu na kobylku podobně jako jsem to před půl rokem udělal se Safari. Implementace sice není kompletní a obsahuje chyby (jednou se mi podařilo prohlížeče dokonce shodit), ale pro základní popis obou značek prozatím postačí.
Pokud chcete vidět rovnou celý výsledek, zobrazte si testovací stránku, já zde jednotlivé možnosti značek <video> a <audio> rozeberu podrobněji.
Video
Začneme videem, protože je zajímavější. Firefox v tuto chvíli podporuje pouze formát OGG Theora, v budoucnu by se mohlo spektrum rozšířit, ale to není zajím ještě jasné. Diskusi o formátech nechám na jindy, dnes se soustředím na kód HTML a JavaScriptu, kterým se video vkládá a ovládá.
Vzal jsem HTML5 trailer (krátké video, které jsem loni vyrobil) a převedl jej pro účely výkladu do OGG formátu. Má asi 5MB, proto pokud máte pomalé spojení, vydržte, až budete zkoušet příklady níže, než se poprvé načte. Pro další zobrazení by už měla zafungovat cache.
A můžeme udělat první pokus: zobrazit video v prohlížeči. Tady Firefox trochu zklamal, pokud mu video předložím přímo, nabídne mi stažení, ale netváří se, že by je uměl zobrazit (na to jsem se těšil). Škoda, takže pro zobrazení videa musíme vytvořit webovou stránku, do které video vložíme. (Pro srovnání u obrázků to není nutné, ty prohlížeč dokáže zobrazit i přímo, nepotřebuje k tomu webovou stránku).
Audio
Firefox podporuje opět jediný kodek a to OGG Vorbis. Podobně jako u značky video není zatím ani podpora značky audio kompletní. Postačí nám proto jen jedna ukázka
Malé zamyšlení. Jak se poslední příklad zachová, pokud budete mít vypnutý JavaScript?
Podobně jako v Safari se obsah značky audio spustí, i když je vypnutý JavaScript (to je správně) a toto chování nejde změnit (to je špatně).
Doufejme, že než se podpora audia dostane do ostré verze, tak se nějaké nastavení objeví. Jinak by to totiž znamenalo konec poslední tiché bašty. Dosud jste měli možnost, pokud jste chtěli prohlížet web v tichosti, vypnout JavaScript, pluginy a měli jste celkem jistotu, že vás prohlížeč nevyruší. S příchodem značky audio tato jistota padá. Doufejme, že se v prohlížečích objeví aspoň možnost i tento mediální obsah vypnout.
A tím končí dnešní stručné představení značek <video> a <audio>. Více najdete v HTML5 specifikaci v sekcích Video Element, Audio Element, Media Elements a Source Element.
Jak vytvářet OGG Theora
Dotatek pro ty, kdo chtějí vytvořit video s kodekem OGG Theora a neví jak. Stačí když:
Pokud chcete vidět rovnou celý výsledek, zobrazte si testovací stránku, já zde jednotlivé možnosti značek <video> a <audio> rozeberu podrobněji.
Video
Začneme videem, protože je zajímavější. Firefox v tuto chvíli podporuje pouze formát OGG Theora, v budoucnu by se mohlo spektrum rozšířit, ale to není zajím ještě jasné. Diskusi o formátech nechám na jindy, dnes se soustředím na kód HTML a JavaScriptu, kterým se video vkládá a ovládá.
Vzal jsem HTML5 trailer (krátké video, které jsem loni vyrobil) a převedl jej pro účely výkladu do OGG formátu. Má asi 5MB, proto pokud máte pomalé spojení, vydržte, až budete zkoušet příklady níže, než se poprvé načte. Pro další zobrazení by už měla zafungovat cache.
A můžeme udělat první pokus: zobrazit video v prohlížeči. Tady Firefox trochu zklamal, pokud mu video předložím přímo, nabídne mi stažení, ale netváří se, že by je uměl zobrazit (na to jsem se těšil). Škoda, takže pro zobrazení videa musíme vytvořit webovou stránku, do které video vložíme. (Pro srovnání u obrázků to není nutné, ty prohlížeč dokáže zobrazit i přímo, nepotřebuje k tomu webovou stránku).
- Nejjednodušší příklad vložení - k vložením nám stačí značka video s nastaveným atributem src. Musíme pamatovat na přístupnost a pro prohlížeče, které značku video nepodporují, vložíme tzv. fallback obsah, který zobrazí místo videa. V našem případě postačí, když dovnitř značky video vložíme odkaz ke stažení. JENŽE video nám jaksi nefunguje že? Po načtení ze zobrazil první snímek, ale ne a ne se spustit. Inu zatím jste ho zobrazili, ale ještě nespustili.
- Vložení s ovládacími prvky - přidáme atribut controls. Prohlížeč nám má nyní nabídnout ovládací prvky. A můžeme si video spustit. Video nám krásně běží a můžeme si je i zastavit. Všimněte si, že ovládací prvky jsou vykresleny plně v zobrazované oblasti videa, nijak nezasahují do okolní stránky (webdesigner tedy nemusí řešit který problížeč jak prvky vykreslí, nezajímají ho). BTW doufám, že je stávající podoba jen dočasná, protože se Safari, které zobrazí kompletní ovládací prvky včetně pozastavení videa, timeline, rychlého převinu a vypnutí zvuku, se nedá srovnat. Aktualizováno: Pracuje se na zlepšení.
- Malá varianta s autoplay - předchozí příklad, ale s přidaným atributem autplay, jehož význam jste jistě odhadli.
- Ovládáme video sami - pokud nechceme, aby ovládání zajišťoval prohlížeč, žádný problém. Když ale nevložíme atribut controls, musíme ovládací prvky nabídnout uživateli sami (jinak video nedokáže ani spustit, natož již spuštěné video zastavit). V tomto příkladu uvádím tu nejjednodušší možnost (kliknutím na video je spustíte nebo naopak zastavíte), v reálu bychom zvolili nějakou intuitivnější metodu, např. umístění pěkných tlačítek pod videem.
- Nastavení rozměrů - video je klasický blok, můžeme mu vnutit jakékoliv rozměry (a za pomoci SVG nebo CSS transform jím dokonce otáčet).
Audio
Firefox podporuje opět jediný kodek a to OGG Vorbis. Podobně jako u značky video není zatím ani podpora značky audio kompletní. Postačí nám proto jen jedna ukázka
- Ukázka audia - na zobrazené stránce sice nic neuvidíte, zato uslyšíte hudbu na pozadí. To proto, že jsem přidal atribut autoplay. Bez něj byste mohli hudbu spustit (a opět zastavit) JavaScriptem. Dalším řešením by bylo přidat atribut controls, který by měl podobně jako u videa uživateli zobrazit ovládací prvky. Ten ovšem ve Firefoxu zatím nefunguje.
Malé zamyšlení. Jak se poslední příklad zachová, pokud budete mít vypnutý JavaScript?
Podobně jako v Safari se obsah značky audio spustí, i když je vypnutý JavaScript (to je správně) a toto chování nejde změnit (to je špatně).
Doufejme, že než se podpora audia dostane do ostré verze, tak se nějaké nastavení objeví. Jinak by to totiž znamenalo konec poslední tiché bašty. Dosud jste měli možnost, pokud jste chtěli prohlížet web v tichosti, vypnout JavaScript, pluginy a měli jste celkem jistotu, že vás prohlížeč nevyruší. S příchodem značky audio tato jistota padá. Doufejme, že se v prohlížečích objeví aspoň možnost i tento mediální obsah vypnout.
A tím končí dnešní stručné představení značek <video> a <audio>. Více najdete v HTML5 specifikaci v sekcích Video Element, Audio Element, Media Elements a Source Element.
Jak vytvářet OGG Theora
Dotatek pro ty, kdo chtějí vytvořit video s kodekem OGG Theora a neví jak. Stačí když:
- stáhnete ffmpeg2theora
- zkonvertujete jím existující video (z příkazové řádky takto: ffmpeg2theora video.avi)
- výsledek můžete přehrát třeba ve Firefoxu 8-) nebo si stáhněte přehrávač VLC, případně samotný kodek
úterý 16. září 2008
WebForms2 migrují do HTML5
Ian Hickson nedávno zahájil migraci specifikace WebForms2 do HTML5.
WebForms2 je samostatnou specifikací (z historických důvodů) a ačkoliv Ian dříve přislíbil její začlenění do HTML5, dosud neproběhlo. Pravděpodobně, protože John Boyer, předseda Forms WG, k ní měl loni vážné námitky. Za tím účelem byla vytvořena Forms Task Force, která měla problémý vyřešit. Nevšiml jsem si žádného veřejného výstupu, jejich mailová skupina za celý rok poměrně zeje prázdnotou.
Jsem zvědav, jak bude specifikace po začlenění vypadat, Ian v ní nyní provádí drobné úpravy a v nedávném rozhovoru naznačil, že dojde k vypuštění některých částí. Předpokládám, že tak za měsíc budeme moudřejší.
WebForms2 se poslední rok nacházela v patové situaci. Tím, že k ním měl předseda Boyer vážné připomínky, se z ní stal černý Petr, kterého nikdo nechtěl implementovat. No, implementovali byste něco, co se možná zítra změní a vy nevíte, zda kompletně nebo jen trochu?
Začleněním do HTML5 se situace vyjasní a prohlížeče budou mít volnou cestu k implementaci WebForms2. V tuto chvíli jsou WebForms2 implementované pouze v Opeře.
WebForms2 je samostatnou specifikací (z historických důvodů) a ačkoliv Ian dříve přislíbil její začlenění do HTML5, dosud neproběhlo. Pravděpodobně, protože John Boyer, předseda Forms WG, k ní měl loni vážné námitky. Za tím účelem byla vytvořena Forms Task Force, která měla problémý vyřešit. Nevšiml jsem si žádného veřejného výstupu, jejich mailová skupina za celý rok poměrně zeje prázdnotou.
Jsem zvědav, jak bude specifikace po začlenění vypadat, Ian v ní nyní provádí drobné úpravy a v nedávném rozhovoru naznačil, že dojde k vypuštění některých částí. Předpokládám, že tak za měsíc budeme moudřejší.
WebForms2 se poslední rok nacházela v patové situaci. Tím, že k ním měl předseda Boyer vážné připomínky, se z ní stal černý Petr, kterého nikdo nechtěl implementovat. No, implementovali byste něco, co se možná zítra změní a vy nevíte, zda kompletně nebo jen trochu?
Začleněním do HTML5 se situace vyjasní a prohlížeče budou mít volnou cestu k implementaci WebForms2. V tuto chvíli jsou WebForms2 implementované pouze v Opeře.
pátek 12. září 2008
Debata o atributu alt se snad chýlí ke konci. A říká...
Máme tu pokračování seriálu, jehož hlavním hrdinou je atribut alt a zápletka se náramně podobá filosofické otázce "Být či nebýt". (Můžete si připomenout předchozí díly.)
Ian Hickson pečlivě prošel všechny diskutované připomínky a nabízená řešení. Slovo "pečlivě" jsem zdůraznil, protože prostudování Ianova e-mailu vám chvíli potrvá. Obsahuje detailní rozbor problematiky a více jak 20 (!) možných řešení (ne)povinné existence altu. Nevěříte, že jich tolik existuje? Jen si to celé přečtěte, pokud máte čas. Ian ovšem také analyzuje jejich nedostatky a postupně je jedno po druhém zavrhuje.
Až na jedno!
Ian se pokusil najít kompromis a podařilo se mu získat větší příznivou odezvu než kdykoliv před tím. Než onen kompromis přednesu, zkusím vysvětlit, proč byl problém nepovinného altu vůbec otevřen. Jsou tu dva důvody, Web ani HTML už nejsou totéž co kdysi.
Důvod první
Web dnes není stejný jako v devadesátých letech, kdy se obrázky a alt zaváděly. Uživatelé na web nahrávají své fotky, přibývá počet fotogalerií. Kdo ví, možná se už dokonce fotka z víkendu nebo dovolené stala převažujícím typem obrázku na celém webu (podklady pro to nemám, ale pokud to nenastalo dnes, je asi jen otázkou času, kdy to přijde). Většina těchto fotek nemá atribut alt vyplněn a pokud ho vyplněn má, tak genericky (alt="Photo 45678").
Autor webu (fotogalerie) s tím nemůže nic dělat. Vlastními silami není schopen popisky desetitisícům fotografií doplnit. Museli by je doplňovat uživatelé. Ovšem, který z nich by chtěl po krásně prožité dovolené dopisovat popisky k desítkám nebo stovkám fotografií? Kdo ho může nutit?
To znamená, že možná již nejrozšířenější použití značky img se úvahám původních HTML specifikací trochu vymyká. Jasně, může se všude použít alt="", ovšem co když jednou budou fotogalerie čítat 90% obrázků na webu (a k tomu může dojít)? Bude i pak povinný alt správné a optimální řešení?
Přemýšlím dokonce, zda nevidomý člověk nutně potřebuje alternativní informaci u fotogalerií. Teď se vrhám na tenký led, ovšem myslím, že některé bariéry prostě překonat nedokážeme. Má pro nevidomého člověka smysl, aby při procházení fotogalerie četl: "já na mostě", "já nasedám do autobusu", "já jsem si koupila nový klobouk", "já...".
Jiný případ je, pokud vezmeme fotografii a použijeme ji jako doplnění nějakého textu. Tam jistě alternativní popis fotografie smysl má, obzvlášť, pokud text doplňuje nejen esteticky, ale i informačně, např. v textu píšu o veselé náladě na oslavě narozenin a na fotografii je vidět, že během zábavy si někteří pánové nasadili klaunské nosy, namalovali klaunskou pusu a vesele spolu tančí. Nenapsat to do popisku obrázku, pak nevidomý člověk přijde o část celého sdělení. A to byla škoda. Ovšem pokud vystavím fotogalerii všech 100 fotek z narozenin, zřejmě k nim nebudu přidávat takto podrobné popisky a asi by to ani nemělo velký smysl. Mnohem lepší bude, když o průběhu narozenin prostě něco pěkného napíšu. (Teď mě napadlo, že nejlepším alternativním obsahem fotogalerie asi nejsou popisky, ale článek. Nicméně neodbíhejme.)
Tento první důvod by sám o sobě ke zrušení povinného altu nestačil, ale je to dobrý důvod k zamyšlení. Pokud hrozí, že dnes nebo za pár let nebude mít smysl u většinového použití značky img vyplňovat alt, máme na altu stále trvat?
Hlavní protiargument zrušení povinného altu je, zda by to neohrozilo jeho používání tam, kde je nutný. Aneb alt se webdesigneři často naučí používat, protože jim vynadá validátor. Když jim nadávat přestane, kdo je to naučí?
Důvod druhý
Důvod druhý souvisí nikoliv s evolucí Webu, ale s evolucí HTML. HTML5 obsahuje nové konstrukce, které umožňují poskytnout alternativní obsah obrázku jinak, pro některé případy vhodnějším způsobem. Příkladem je značka figure, která propojí text s obrázkem:
<figure>
<img src="DSC_0399.JPG">
<legend>Tanečník u tyče s tričkem <a href="http://www.google.cz/">Googlu</a> vábí nové klienty</legend>
</figure>
Na rozdíl od altu, který je ALTERNATIVNÍM obsahem obrázku, je obsah značky legend jak alternativním obsahem obrázku, tak popisem obrázku pro všechny čtenáře. U obrázku v takové formaci nedává atribut alt smysl. Mělo by vůbec cenu značku figure zavádět, když by bylo nutné stejně alt (byť prázdný) vkládat? Neříkal by prázdný alt čtečkám, že alternativní informace neexistuje, místo aby je navedl na obsah značky legend?
Takže ten kompromis
Jak Web, tak HTML se nám vyvíjí a u atributu alt je třeba hledat řešení, které bude tento vývoj respektovat, ale zároveň neohrozí přístupnost Webu. A Ian po měsících debatování v HTML WG přišel s tímto kompromisním řešením:
Atribut alt může být vynechán pouze a jen v případě, že je alternativní obsah obrázku nabídnut jiným způsobem (např. značkami figure+legend nebo atributem title). V ostatních případech je alt povinný.
Možná vám tohle řešení připadne komplikované, ale jednodušší se už zřejmě nedá nalézt. A já mám takový pocit, že tohle řešení by už do finální specifikace mohlo projít. I když, raději si ještě počkáme.
Jo a řvaní validátoru nad absencí alternativního popisku se nezbavíme, protože jak alt, tak i ty alternativní způsoby si dokáže pěkně pohlídat.
Další čtení:
Ian Hickson pečlivě prošel všechny diskutované připomínky a nabízená řešení. Slovo "pečlivě" jsem zdůraznil, protože prostudování Ianova e-mailu vám chvíli potrvá. Obsahuje detailní rozbor problematiky a více jak 20 (!) možných řešení (ne)povinné existence altu. Nevěříte, že jich tolik existuje? Jen si to celé přečtěte, pokud máte čas. Ian ovšem také analyzuje jejich nedostatky a postupně je jedno po druhém zavrhuje.
Až na jedno!
Ian se pokusil najít kompromis a podařilo se mu získat větší příznivou odezvu než kdykoliv před tím. Než onen kompromis přednesu, zkusím vysvětlit, proč byl problém nepovinného altu vůbec otevřen. Jsou tu dva důvody, Web ani HTML už nejsou totéž co kdysi.
Důvod první
Web dnes není stejný jako v devadesátých letech, kdy se obrázky a alt zaváděly. Uživatelé na web nahrávají své fotky, přibývá počet fotogalerií. Kdo ví, možná se už dokonce fotka z víkendu nebo dovolené stala převažujícím typem obrázku na celém webu (podklady pro to nemám, ale pokud to nenastalo dnes, je asi jen otázkou času, kdy to přijde). Většina těchto fotek nemá atribut alt vyplněn a pokud ho vyplněn má, tak genericky (alt="Photo 45678").
Autor webu (fotogalerie) s tím nemůže nic dělat. Vlastními silami není schopen popisky desetitisícům fotografií doplnit. Museli by je doplňovat uživatelé. Ovšem, který z nich by chtěl po krásně prožité dovolené dopisovat popisky k desítkám nebo stovkám fotografií? Kdo ho může nutit?
To znamená, že možná již nejrozšířenější použití značky img se úvahám původních HTML specifikací trochu vymyká. Jasně, může se všude použít alt="", ovšem co když jednou budou fotogalerie čítat 90% obrázků na webu (a k tomu může dojít)? Bude i pak povinný alt správné a optimální řešení?
Přemýšlím dokonce, zda nevidomý člověk nutně potřebuje alternativní informaci u fotogalerií. Teď se vrhám na tenký led, ovšem myslím, že některé bariéry prostě překonat nedokážeme. Má pro nevidomého člověka smysl, aby při procházení fotogalerie četl: "já na mostě", "já nasedám do autobusu", "já jsem si koupila nový klobouk", "já...".
Jiný případ je, pokud vezmeme fotografii a použijeme ji jako doplnění nějakého textu. Tam jistě alternativní popis fotografie smysl má, obzvlášť, pokud text doplňuje nejen esteticky, ale i informačně, např. v textu píšu o veselé náladě na oslavě narozenin a na fotografii je vidět, že během zábavy si někteří pánové nasadili klaunské nosy, namalovali klaunskou pusu a vesele spolu tančí. Nenapsat to do popisku obrázku, pak nevidomý člověk přijde o část celého sdělení. A to byla škoda. Ovšem pokud vystavím fotogalerii všech 100 fotek z narozenin, zřejmě k nim nebudu přidávat takto podrobné popisky a asi by to ani nemělo velký smysl. Mnohem lepší bude, když o průběhu narozenin prostě něco pěkného napíšu. (Teď mě napadlo, že nejlepším alternativním obsahem fotogalerie asi nejsou popisky, ale článek. Nicméně neodbíhejme.)
Tento první důvod by sám o sobě ke zrušení povinného altu nestačil, ale je to dobrý důvod k zamyšlení. Pokud hrozí, že dnes nebo za pár let nebude mít smysl u většinového použití značky img vyplňovat alt, máme na altu stále trvat?
Hlavní protiargument zrušení povinného altu je, zda by to neohrozilo jeho používání tam, kde je nutný. Aneb alt se webdesigneři často naučí používat, protože jim vynadá validátor. Když jim nadávat přestane, kdo je to naučí?
Důvod druhý
Důvod druhý souvisí nikoliv s evolucí Webu, ale s evolucí HTML. HTML5 obsahuje nové konstrukce, které umožňují poskytnout alternativní obsah obrázku jinak, pro některé případy vhodnějším způsobem. Příkladem je značka figure, která propojí text s obrázkem:
<figure>
<img src="DSC_0399.JPG">
<legend>Tanečník u tyče s tričkem <a href="http://www.google.cz/">Googlu</a> vábí nové klienty</legend>
</figure>
Na rozdíl od altu, který je ALTERNATIVNÍM obsahem obrázku, je obsah značky legend jak alternativním obsahem obrázku, tak popisem obrázku pro všechny čtenáře. U obrázku v takové formaci nedává atribut alt smysl. Mělo by vůbec cenu značku figure zavádět, když by bylo nutné stejně alt (byť prázdný) vkládat? Neříkal by prázdný alt čtečkám, že alternativní informace neexistuje, místo aby je navedl na obsah značky legend?
Takže ten kompromis
Jak Web, tak HTML se nám vyvíjí a u atributu alt je třeba hledat řešení, které bude tento vývoj respektovat, ale zároveň neohrozí přístupnost Webu. A Ian po měsících debatování v HTML WG přišel s tímto kompromisním řešením:
Atribut alt může být vynechán pouze a jen v případě, že je alternativní obsah obrázku nabídnut jiným způsobem (např. značkami figure+legend nebo atributem title). V ostatních případech je alt povinný.
Možná vám tohle řešení připadne komplikované, ale jednodušší se už zřejmě nedá nalézt. A já mám takový pocit, že tohle řešení by už do finální specifikace mohlo projít. I když, raději si ještě počkáme.
Jo a řvaní validátoru nad absencí alternativního popisku se nezbavíme, protože jak alt, tak i ty alternativní způsoby si dokáže pěkně pohlídat.
Další čtení:
úterý 9. září 2008
Canvas a pěkné obtékání obrázku
Obtékání obrázků (a čehokoliv jiného) je v kaskádových stylech řešeno na úrovni bloků. Na papírovém médiu se ale můžeme setkat i s jemnějším obtékáním, které respektuje nepravidelný tvar obrázku.
Jacob Seidelin se pokusil jemný druh obtékání nasimulovat pomocí běžného HTML+CSS s pomocí JavaScriptu a canvasu. Stačí, abyste do stránky vložili obrázek s průhledným pozadím, nastavili mu správnou třídu (v našem případě "sandbag-left") a jednoduchý skript PrettyFloat se o zbytek postará.
Výsledek je celkem přesvědčivý (zatím jen ve Firefoxu a Opeře).
Jak to funguje? Canvas umožňuje přistupovat k obrázkům na úrovni jednotlivých pixelů. Skript zanalyzuje obrázek a nahradí jej sadou divů o výšce cca jednoho řádku textu, každému z nich nastaví adekvátní šířku a na pozadí napozicuje původní obrázek tak, aby jednotlivé divy daly vizuálně dohromady obrázek původní. Vše proběhne při onloadu a rozumně rychle. Mechanismus je postaven na metodě, která byla prvně popsána na Alistapart.
Vše se řídí pravidlem graceful degradation (v ostatních prohlížečích uvidíte klasické obtékání).
Nejedná se o jediný způsob zpracování obrázku pomocí canvasu, našli bychom knihovny na zaoblování rohů, vytváření zrcadlových obrazů atd. Přemýšlím, zda se podobné metody jednou ujmou stejně jako je dnes běžný SIFR.
Pozn.: Nejedná se o univerzální způsob, prohlížeč totiž povolí v canvasu zpracovávat jen obrázky ze stejné domény. Porušit toho omezení je nežádoucí (na pozadí by prohlížeč mohl např. lámat cizí captchy a uživatel by o tom neměl ponětí).
(Zdroj: nihilogic.dk)
Jacob Seidelin se pokusil jemný druh obtékání nasimulovat pomocí běžného HTML+CSS s pomocí JavaScriptu a canvasu. Stačí, abyste do stránky vložili obrázek s průhledným pozadím, nastavili mu správnou třídu (v našem případě "sandbag-left") a jednoduchý skript PrettyFloat se o zbytek postará.
Výsledek je celkem přesvědčivý (zatím jen ve Firefoxu a Opeře).
Jak to funguje? Canvas umožňuje přistupovat k obrázkům na úrovni jednotlivých pixelů. Skript zanalyzuje obrázek a nahradí jej sadou divů o výšce cca jednoho řádku textu, každému z nich nastaví adekvátní šířku a na pozadí napozicuje původní obrázek tak, aby jednotlivé divy daly vizuálně dohromady obrázek původní. Vše proběhne při onloadu a rozumně rychle. Mechanismus je postaven na metodě, která byla prvně popsána na Alistapart.
Vše se řídí pravidlem graceful degradation (v ostatních prohlížečích uvidíte klasické obtékání).
Nejedná se o jediný způsob zpracování obrázku pomocí canvasu, našli bychom knihovny na zaoblování rohů, vytváření zrcadlových obrazů atd. Přemýšlím, zda se podobné metody jednou ujmou stejně jako je dnes běžný SIFR.
Pozn.: Nejedná se o univerzální způsob, prohlížeč totiž povolí v canvasu zpracovávat jen obrázky ze stejné domény. Porušit toho omezení je nežádoucí (na pozadí by prohlížeč mohl např. lámat cizí captchy a uživatel by o tom neměl ponětí).
(Zdroj: nihilogic.dk)
středa 3. září 2008
Firefox implementuje drag & drop z HTML5
Poslední noční buildy Firefoxu obsahují podporu pro drag & drop z HTML5. Naprogramování drag & drop bylo dříve v prohlížečích poněkud komplikované (bylo nutné odchytávat události myši, detekovat, že uživatel chce s prvkem vůbec hýbat, vykreslovat jeho posunování a znovu detekovat, kam byl spuštěn).
Specifikace HTML5 obsahuje API, které je mnohem jednodušší. Rozhraní nenavrhli autoři specifikace, nýbrž vývojáři Internet Exploreru. Jedná se o další případ, kdy se HTML5 snaží standardizovat prohlížečem zavedené rozšíření. Nové rozhraní po Internet Exploreru implementovalo Safari a nyní došlo i na Firefox.
Rozhraní definuje nové události:
- drag
- dragstart
- dragenter
- dragleave
- dragover
- dragend
- drop
a řadu obslužných metod např. setDragImage nastaví obrázek, který bude uživateli zobrazovat, že právě "něco myší tahá".
Nedaří se mi najít najít žádné funkční demo, leda tento příklad, který nevím proč nefunguje. Navíc whatwg.org je dnes nedostupný (všichni zkouší nový prohlížeč od Googlu, chtějí testovat na acidtests.org a přetížili tak Hixieho server). Větší rozbor tedy necháme na jindy, zatím si můžete přečíst dokumentaci u Mozilly.
Aktualizace: Našel jsem příklad, který funguje (zatím alespoň v IE a Safari).
Aktualizace: Našel jsem příklad, který funguje (zatím alespoň v IE a Safari).
(Zdroj: Xulplanet.com)
neděle 31. srpna 2008
Přehled HTML5 značek na W3schools
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.
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.
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.
středa 16. července 2008
PersistJS pro překonání cookies
PersistJS je JavaScriptová knihovna uchovávající (perzistentí) data na straně klienta. K tomu používá všechny možné prostředky od úložišť HTML5, přes Google Gears po Flash.
Knihovna nabízí jednotné rozhraní, programátor tedy nemusí řešit, jaké úložiště se ve výsledku použije, zda běží v prohlížeči s podporou HTML5 nebo zda se prostě použije Flash. Data se ukládají v jednoduché formě klíč + hodnota:
Autorem knihovny je Paul Duncan. Verze 0.1 je první vývojovou verzí a autor přiznává, že se v ní ještě mohou objevovat chyby.
Knihovny jako je PersistJS pomohou elegantně překlenout období, ve kterém novinky HTML5 budou v některých prohlížečích podporovány a v jiných nikoliv. Pokud cookies pro vaše aplikace nestačí, doporučuji vývoj PersistJS sledovat.
Knihovna nabízí jednotné rozhraní, programátor tedy nemusí řešit, jaké úložiště se ve výsledku použije, zda běží v prohlížeči s podporou HTML5 nebo zda se prostě použije Flash. Data se ukládají v jednoduché formě klíč + hodnota:
// create a new client-side data store
var store = new Persist.Store('MyDataStore');
// pretend data
var data = "pretend this is really long data that won't fit in a cookie";
// save data in store
store.set('saved_data', data);
Autorem knihovny je Paul Duncan. Verze 0.1 je první vývojovou verzí a autor přiznává, že se v ní ještě mohou objevovat chyby.
Knihovny jako je PersistJS pomohou elegantně překlenout období, ve kterém novinky HTML5 budou v některých prohlížečích podporovány a v jiných nikoliv. Pokud cookies pro vaše aplikace nestačí, doporučuji vývoj PersistJS sledovat.
(via Notes about PersistJS)
úterý 15. července 2008
Značka video ve stromu Firefoxu, zatím ne v oficiálních verzích
Podpora značek video a audio, kterou programuje Chris Double, se po měsících vývoje dostala do zdrojových kódů Firefoxu. Oficiální verze (ani noční buildy) podporu zatím neobsahují (je nutné provést vlastní kompilaci s parametrem '--enable-media'), ale jedná se o důležitý mezikrok pro začlenění do oficiálních verzí.
Pro ty, kdo se nemohou dočkat, připravil Chris Double pěkné video, ve najdete zajímavé ukázky spojení videa např. s SVG (zrcadlení a další efekty):
Pro ty, kdo se nemohou dočkat, připravil Chris Double pěkné video, ve najdete zajímavé ukázky spojení videa např. s SVG (zrcadlení a další efekty):
čtvrtek 3. července 2008
Lachlan Hunt v podcastu o HTML5
Lachlan Hunt (Opera Software) poskytl rozhovor o HTML5 v podcastu severu Boagworld.
V rozhovoru přijde řeč na WHATWG, jeho spolupráci s W3C, na nové značky, které HTML5 přináší, zejména ty sémantické, dále na audio, video, canvas a také, které části HTML5 jsou již implementovány v prohlížečích.
Lachlan také vysvětluje, jaký je vztah HTML a XHTML v rámci HTML5:
V rozhovoru přijde řeč na WHATWG, jeho spolupráci s W3C, na nové značky, které HTML5 přináší, zejména ty sémantické, dále na audio, video, canvas a také, které části HTML5 jsou již implementovány v prohlížečích.
Lachlan také vysvětluje, jaký je vztah HTML a XHTML v rámci HTML5:
So instead of having two distinct language which you can use we have combined them into a single language which share the same elements and attributes and everything and as much a possible and when the browser reads those file it produces and internal representation called the DOMMůžete si stáhnout celý podcast (MP3, 27MB) nebo, pokud preferujete čtení (a nechcete poslouchat omáčku v podcastu okolo), si můžete celý rozhovor přečíst.
pondělí 30. června 2008
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:
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í.
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í.
středa 25. června 2008
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.
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.
pátek 20. června 2008
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:
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
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
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
(via HTML 5 Publications)
čtvrtek 19. června 2008
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č!
Na jeho vznik si podle všeho ještě pár let počkáme:
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).
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.
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 Acid3Toliko 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čů.
- 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
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.
středa 18. června 2008
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.
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.
pondělí 16. června 2008
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:
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:
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: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).
A:link { color: red } /* unvisited link */
A:visited { color: blue } /* visited links */
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.
pátek 13. června 2008
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í.
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í.
pátek 6. června 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).
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:
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:
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).
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).
Přihlásit se k odběru:
Příspěvky (Atom)