V nejbližší době by se na adrese www.w3.org/TR/html5 měl objevit druhý (aktualizovaný) draft specifikace HTML5. Začátkem května to navrhl Ian Hickson, s tím, že se od prvního (lednového) draftu řada věcí změnila a bude dobré tyto změny zveřejnit.
Michael Smith k tomu podotkl, že je to nejen vhodné, ale dokonce povinnost každé pracovní skupiny zveřejňovat aktuální verzi připravovaných specifikací jednou za tři měsíce.
Mike Smith zároveň přislíbil sepsat přehled změn, které by vyšly společně s novou verzí. To bude jistě užitečné, nikomu se nechce porovnávat mezi sebou dva dokumenty o rozsahu pěti set stran.
O vydání draftu se hlasovalo. Výsledky jsou celkem jasné (76 hlasů pro, 2 hlasy proti) a je vidět, že se od loňského roku názor pracovní skupiny pěkně sjednotil (připomeňme si tahanice okolo loňské adopce HTML5).
Každopádně doporučuji si ve výsledcích přečíst, kdo hlasoval proti a co uvádí jako důvod.
pátek 30. května 2008
pondělí 26. května 2008
ARIA v HTML5 na Standards Suck
Na nově založeném blogu Standards Suck (pěkný název pro blog) najdete video ARIA in HTML5, ve kterém Anne van Kesteren vysvětluje, co je to ARIA (Accessible Rich Interactive Applications) a o řešení její syntaxe pro HTML5.
BTW provokativní nápis "Standards Suck" najdete i na Annově blogu. Ačkoliv první dojem může svádět, nejedná se určitě o kritiku existence či zbytečnosti webových standardů. Anne je členem několika pracovních skupin W3C a editorem několika menších specifikací, a tráví tím jistě i nemalou část svého volného času na to, aby popíral smysl svého konání.
Cítím v tom spíš povzdech nad tím, že svět webových standardů často nefunguje, jak bychom si přáli (ať již na rovině teoretické nebo té implementační) a neexistuje cesta, jak z toho snadno ven.
V tomto ohledu se musím připojit. Ano, standards suck, bohužel. Můj obdiv mají všichni, kdo se snaží o změnu.
Já si každopádně dávám http://standardssuck.org do své čtečky a jsem zvědav, co dalšího se tam objeví.
BTW provokativní nápis "Standards Suck" najdete i na Annově blogu. Ačkoliv první dojem může svádět, nejedná se určitě o kritiku existence či zbytečnosti webových standardů. Anne je členem několika pracovních skupin W3C a editorem několika menších specifikací, a tráví tím jistě i nemalou část svého volného času na to, aby popíral smysl svého konání.
Cítím v tom spíš povzdech nad tím, že svět webových standardů často nefunguje, jak bychom si přáli (ať již na rovině teoretické nebo té implementační) a neexistuje cesta, jak z toho snadno ven.
V tomto ohledu se musím připojit. Ano, standards suck, bohužel. Můj obdiv mají všichni, kdo se snaží o změnu.
Já si každopádně dávám http://standardssuck.org do své čtečky a jsem zvědav, co dalšího se tam objeví.
středa 21. května 2008
Krůček po krůčku ke stejnému (X)HTML
Nedávno jsem na Slashdotu četl příspěvek Why Firefox 3 is Bad for Developers. Pisatel se v něm diví, proč následující zápis, ačkoliv fungoval ve Firefox 2, ve Firefoxu 3 nefunguje:
Zdůrazňuji neuzavřenou značku script, protože pokud pokud je výsledný kód posílán s MIME text/html jako v citovaném případě, nemá koncové lomítko žádný význam a značka je neuzavřená. To by bylo samo o sobě na delší povídání, mě teď zajímá onen fakt, že zatímco "jedna" verzi prohlížeče se chovala nějak, další verze se chová "nějak jinak", což je také důvod, proč se onen vývojář zlobí.
Všimněte si, že mezi agumenty pro změnu, které vývojář Gecka Boris Zbarsky uvádí, je, že HTML5 toto chování vyžaduje. Je to jeden z mnoha požadavků z té části HTML5, která nepřidává do HTML žádné nové vlastnosti, ale upřesňuje ty stávající až do (aspoň podle autorů) všech nutných detailů.
Noční můra webdesignerů aneb na co jsme si zvykli
V tomto případě jsou obě varianty (jak <script></script>, tak <script />) z pohledu XHTML správné, a jsou také obě validní, ovšem ta druhá v některých prohlížečích fungovat nebude. Svět prohlížečů je tak pro vývojáře noční můrou, protože ačkoliv píše podle učebnic, validuje svůj výsledek a podívá se na něj ve svém prohlížeči, nic mu nezaručí, že to celé bude fungovat i v některém z dalších prohlížečů. A výše zmíněný případ je jen jedním z mnoha.
A ačkoliv jsme si na to zvykli, někde uvnitř každého webdesignera určitě hlodá pochybnost, že to tak vlastně ani nemuselo být. Že se jen někde stala chyba a nikdo ji zatím neopravil.
A tím se od současné noční můry dostáváme k pohádce (ono se to zatím jinak než pohádka nazvat nedá).
Pohádka pro webdesignéry
Pokud se máme jednoho krásného dne probudit, otevřít okno (myšleno prohlížeče) a zjistit, že (X)HTML je ve všech prohlížečích interpretováno nachlup stejně (a tento pohádkový cíl skutečně je jeden z cílů HTML5), pak to znamená, že chování každého dnešního prohlížeče se musí trochu změnit. Tu více, tu méně. Při tom se nevyhneme tomu, že co včera v jednom prohlížeči fungovalo, v něm nemusí fungovat zítra (viz ten případ s Firefoxem 3). To je daň, které se nelze vyhnout.
HTML5 se snaží ono "jednotné chování (X)HTML" definovat tak, aby bylo pokud možno kompatibilní se stávajícím chováním většiny prohlížečů a stávajícím používáním (X)HTML na Webu. Tedy, aby ta daň byla co nejmenší. Jako vedlejší efekt se tak zároveň vzdaluje teoretickému návrhu ideálně čistého HTML, právě proto, že se tu a tam musí přizpůsobit (což je druhé zdanění).
A kdy že to bude?
Zatím se k pohádkovému cíli jednotného (X)HTML krůček po krůčku blížíme, viz ten případ s Firefoxem, který je jen jedním z mnoha. V nejbližších 5 letech se ho určitě nedočkáme, ale pokud se splní představy tvůrců HTML5, měl by nastat do ukončení vývoje specifikace, tedy odhadem někdy do roku 2022.
Pak se možná splní rčení Iana Hicksona
Tak a teď dobrou noc děti, ráno vás opět čeká vaše noční můra, aspoň prozatím.
<head>Firefox 2 si neuzavřenou značku script uzavře, zatímco Firefox 3 ji nechá otevřenou a výsledná stránka pak nefunguje (stejně se chovala i původní Mozilla Suite a stejně se chová třeba i Internet Explorer).
<script type="text/javascript" src="URL" />
</head>
Zdůrazňuji neuzavřenou značku script, protože pokud pokud je výsledný kód posílán s MIME text/html jako v citovaném případě, nemá koncové lomítko žádný význam a značka je neuzavřená. To by bylo samo o sobě na delší povídání, mě teď zajímá onen fakt, že zatímco "jedna" verzi prohlížeče se chovala nějak, další verze se chová "nějak jinak", což je také důvod, proč se onen vývojář zlobí.
Všimněte si, že mezi agumenty pro změnu, které vývojář Gecka Boris Zbarsky uvádí, je, že HTML5 toto chování vyžaduje. Je to jeden z mnoha požadavků z té části HTML5, která nepřidává do HTML žádné nové vlastnosti, ale upřesňuje ty stávající až do (aspoň podle autorů) všech nutných detailů.
Noční můra webdesignerů aneb na co jsme si zvykli
V tomto případě jsou obě varianty (jak <script></script>, tak <script />) z pohledu XHTML správné, a jsou také obě validní, ovšem ta druhá v některých prohlížečích fungovat nebude. Svět prohlížečů je tak pro vývojáře noční můrou, protože ačkoliv píše podle učebnic, validuje svůj výsledek a podívá se na něj ve svém prohlížeči, nic mu nezaručí, že to celé bude fungovat i v některém z dalších prohlížečů. A výše zmíněný případ je jen jedním z mnoha.
A ačkoliv jsme si na to zvykli, někde uvnitř každého webdesignera určitě hlodá pochybnost, že to tak vlastně ani nemuselo být. Že se jen někde stala chyba a nikdo ji zatím neopravil.
A tím se od současné noční můry dostáváme k pohádce (ono se to zatím jinak než pohádka nazvat nedá).
Pohádka pro webdesignéry
Pokud se máme jednoho krásného dne probudit, otevřít okno (myšleno prohlížeče) a zjistit, že (X)HTML je ve všech prohlížečích interpretováno nachlup stejně (a tento pohádkový cíl skutečně je jeden z cílů HTML5), pak to znamená, že chování každého dnešního prohlížeče se musí trochu změnit. Tu více, tu méně. Při tom se nevyhneme tomu, že co včera v jednom prohlížeči fungovalo, v něm nemusí fungovat zítra (viz ten případ s Firefoxem 3). To je daň, které se nelze vyhnout.
HTML5 se snaží ono "jednotné chování (X)HTML" definovat tak, aby bylo pokud možno kompatibilní se stávajícím chováním většiny prohlížečů a stávajícím používáním (X)HTML na Webu. Tedy, aby ta daň byla co nejmenší. Jako vedlejší efekt se tak zároveň vzdaluje teoretickému návrhu ideálně čistého HTML, právě proto, že se tu a tam musí přizpůsobit (což je druhé zdanění).
A kdy že to bude?
Zatím se k pohádkovému cíli jednotného (X)HTML krůček po krůčku blížíme, viz ten případ s Firefoxem, který je jen jedním z mnoha. V nejbližších 5 letech se ho určitě nedočkáme, ale pokud se splní představy tvůrců HTML5, měl by nastat do ukončení vývoje specifikace, tedy odhadem někdy do roku 2022.
Pak se možná splní rčení Iana Hicksona
Things that are impossible just take longer.A pak uvidíme, zda se tahle pohádka pro další generace webdesignerů stane skutečností nebo zůstane navždy jen pohádkou.
Tak a teď dobrou noc děti, ráno vás opět čeká vaše noční můra, aspoň prozatím.
Iframe dědičný a bezpečný
Před pár dny dostala značka iframe v HTML5 dva nové atributy seamless a sandbox. Oba jsou v HTML zcela nové - podívejme se, co přesně znamenají.
Pokud atribut seamless obsahuje hodnotu true, bude obsah iframe zobrazen jako skutečná součást rodičovské stránky (resp. bariéra mezi rodičovským dokumentem a obsahem iframu je o něco snížena) to značí zejména:
Sandbox - iframe, kterému nevěříme
O opak se snaží atribut sandbox, který naopak iframe omezuje a bariéru mezi rodičovským dokumentem a dokumentem v iframe zvyšuje. Sanbox může obsahovat kombinaci následujících hodnot oddělených mezerou: allow-same-origin, allow-forms, a allow-scripts.
Přítomnost atributu sandbox vždy zabrání dokumentu v iframe:
Více v oznámení v mailing listu.
interface HTMLIFrameElement : HTMLElement {Seamless - iframe součástí stránky
attribute DOMString src;
attribute DOMString name;
attribute DOMString sandbox;
boolean DOMString seamless;
};
Pokud atribut seamless obsahuje hodnotu true, bude obsah iframe zobrazen jako skutečná součást rodičovské stránky (resp. bariéra mezi rodičovským dokumentem a obsahem iframu je o něco snížena) to značí zejména:
- odkazy v iframu se budou otevírat v rodičovském dokumentu a nikoliv v iframu
- dojde k jistému dědění CSS pravidel z rodičovského dokumentu do iframu
Sandbox - iframe, kterému nevěříme
O opak se snaží atribut sandbox, který naopak iframe omezuje a bariéru mezi rodičovským dokumentem a dokumentem v iframe zvyšuje. Sanbox může obsahovat kombinaci následujících hodnot oddělených mezerou: allow-same-origin, allow-forms, a allow-scripts.
Přítomnost atributu sandbox vždy zabrání dokumentu v iframe:
- navigovat jiné dokumenty než je on sám (např. když dokument v iframu změnil URL rodičovského dokumentu)
- vytvářet nové kontexty prohlížeče (v orig. browsing context - myšleno např. otevírat nová okna)
- používat libovolné pluginy (ty se často řídí svými pravidly a mohly by tak pravidla sandboxu "nějak obejít").
- číst hodnoty cookies pokud není nastavena hodnota allow-same-origin (iframe se tak chová jakoby byl z jiné domény, i přesto že je ze stejné)
- odesílat formuláře pokud není nastavena hodnota allow-forms
- spouštět skripty pokud není nastavena hodnota allow-scripts
Více v oznámení v mailing listu.
úterý 6. května 2008
Canvas bude i s textem
Canvas je značka stará již čtyři roky. Prvně o ní u nás psal Petr Staníček v Průkopníci zítřka a vězni včerejška na Lupě v roce 2004. Její rozhraní je relativně usedlé a za poslední roky se zásadně nezměnilo (převážně jen kosmetické změny).
Jednoho rozšíření se ale canvas dočká. Hlavní kritikou canvasu bylo, že ačkoliv umí kompletně pracovat s 2D grafikou (3D je prozatím jen emulováno), neumí pracovat s textem. To canvas trochu degradovalo (jedno z jeho použití je třeba dynamická tvorba grafů).
Šlo to obejít buď vytvořením vlastní rutiny pro vykreslování písma (kdysi jsem na jeden takový projekt narazil), nebo šikovným pozicováním textových nodů přes canvas.
Ian Hickson včera oznámil, že canvas přeci jen bude o základní textové funkce rozšířen:
Pamatuju si, že další kritikou canvasu byla absence API pro kreslení přerušovaných čar (David Flanagan: Dashed lines in the <canvas> tag). To už není tak ožehavý problém (dá se emulovat mnohem snadněji než vykreslování písma), ale uvidíme, zda se do canvasu nakonec nedostane.
Jednoho rozšíření se ale canvas dočká. Hlavní kritikou canvasu bylo, že ačkoliv umí kompletně pracovat s 2D grafikou (3D je prozatím jen emulováno), neumí pracovat s textem. To canvas trochu degradovalo (jedno z jeho použití je třeba dynamická tvorba grafů).
Šlo to obejít buď vytvořením vlastní rutiny pro vykreslování písma (kdysi jsem na jeden takový projekt narazil), nebo šikovným pozicováním textových nodů přes canvas.
Ian Hickson včera oznámil, že canvas přeci jen bude o základní textové funkce rozšířen:
I have introduced the following APIs:
context.font
context.textAlign
context.textBaseline
context.fillText()
context.strokeText()
context.measureText()
They are defined here:
http://www.whatwg.org/specs/web-apps/current-work/#text
Pamatuju si, že další kritikou canvasu byla absence API pro kreslení přerušovaných čar (David Flanagan: Dashed lines in the <canvas> tag). To už není tak ožehavý problém (dá se emulovat mnohem snadněji než vykreslování písma), ale uvidíme, zda se do canvasu nakonec nedostane.
neděle 4. května 2008
Alt u obrázku (ne)povinný?
Už několikátý měsíc pokračuje debata na celkem banální téma. Týká se totiž jednoho jediného atributu. A přesto se výsledek zdá být v nedohlednu. Ano, bavíme se o tom, zda u obrázků má být atribut alt i nadále povinný či nikoliv.
Editor HTML5 Ian Hickson se spolu s dalšími snaží v pracovní skupině obhájit názor, že atribut alt by v HTML5 neměl být povinný. Výsledek? Pracovní skupina je stručně řečeno nejednotná.
Celá diskuse je již v tuto chvíli značně nepřehledná (vybírám jen několik vláken, ve skutečnosti je jich mnohem víc: alt and authoring practices, request for review of alt and alt value for authoring or publishing tools, testing the theory that required alt = bad, alt crazyness).
Cílem zastánců nepovinného altu je nejen odlišit situaci, kdy obrázek nese informaci a má mít svou textovou podobu (obrázek s altem) od obrázku, který tuto informaci nenese (obrázek bez altu), ale hlavně přiznat si, že se nejedná o věc strojově kontrolovatelnou, a že se tedy jedná o věc, která nespadá do základních vlastností (X)HTML jazyka jako takového, jako spíše do oblasti nástrojů pro kontrolu přístupnosti stránek. Tyto nástroje mohou validátor doprovázet (a HTML5 validátor jeden takový nástroj obsahuje, viz dále), ale měly by být jasně odděleny od syntaktické kontroly.
Ono se v (X)HTML nejedná o ojedinělý případ. Malé srovnání. Pokud na stránce použijete značku script, používáte něco, co jistě není přístupné, ale automaticky nelze určit, zda tím bude znepřístupněna celá stránka či nikoliv (až sem je asi podoba s obrázkem zřejmá). Specifikace vás ovšem nenutí vedle každé značky script povinně použít značku noscript (podobně jako alt u obrázku), ale místo toho jsou weboví vývojáři učeni používat skriptování tak, aby přístupnost stránek nebyla dotčena (a to se docela daří). Volitelná značka noscript je jen jednou z možností, jak toho dosáhnout.
Zastánci povinného altu jsou ovšem jiného názoru. Obě strany se tak snaží z webu udělat web přístupnější. Jen se nejspíš vzájemně nechápou. Jedni by rádi, aby webdesigneři byli nuceni psát atribut alt všude, zatímco ti druzí by rádi, aby webdesigneři používali atribut alt správně. Srovnání těchto dvou pohledů ponechám na čtenáři. Jsem sám zvědav, kdy se jim podaří nalézt společnou řeč.
Zkusil jsem si malý pokus. Vybral jsem si stránku, která je validní XHTML 1 Strict (první, která mě napadla, takže www.weblogy.cz, neberte si to nikdo osobně) a podíval jsem se na analýzu používání obrázků na této stránce. Použil jsem analýzu, která je součástí vyvíjeného HTML5 validátoru, ve výsledcích přeskočte HTML5 chyby (ty nás nezajímají, stránka není v HTML5 8-) a sjeďte až dolů k nadpisu Image report.
Jak sami můžete vidět, některé obrázky na stránce mají vyplněn atribut alt velmi vhodně, zatímco o řadě dalších se to říct nedá. Validátor (ne)vhodnost nerozezná. Otázkou (byť ne jednoznačnou) pak je, když i zkušení webdesigneři v tomto chybují, zda je stávající řešení altu vynucovaného specifikací a validátorem to správné.
Proto ať již debata na téma alt dopadne jak dopadne, jsem rád, že se tohle palčivé téma řeší. Byť bych byl mnohem radši, když by se neřešilo tak dlouho.
Související
Budu rád, pokud k problematice připojíte svůj odborný komentář, vyvarujte se ale prosím emotivních výjevů, stačí, že se na toto (zřejmě citlivé) téma občas objevují i u členů pracovní skupiny.
Editor HTML5 Ian Hickson se spolu s dalšími snaží v pracovní skupině obhájit názor, že atribut alt by v HTML5 neměl být povinný. Výsledek? Pracovní skupina je stručně řečeno nejednotná.
Celá diskuse je již v tuto chvíli značně nepřehledná (vybírám jen několik vláken, ve skutečnosti je jich mnohem víc: alt and authoring practices, request for review of alt and alt value for authoring or publishing tools, testing the theory that required alt = bad, alt crazyness).
Cílem zastánců nepovinného altu je nejen odlišit situaci, kdy obrázek nese informaci a má mít svou textovou podobu (obrázek s altem) od obrázku, který tuto informaci nenese (obrázek bez altu), ale hlavně přiznat si, že se nejedná o věc strojově kontrolovatelnou, a že se tedy jedná o věc, která nespadá do základních vlastností (X)HTML jazyka jako takového, jako spíše do oblasti nástrojů pro kontrolu přístupnosti stránek. Tyto nástroje mohou validátor doprovázet (a HTML5 validátor jeden takový nástroj obsahuje, viz dále), ale měly by být jasně odděleny od syntaktické kontroly.
Ono se v (X)HTML nejedná o ojedinělý případ. Malé srovnání. Pokud na stránce použijete značku script, používáte něco, co jistě není přístupné, ale automaticky nelze určit, zda tím bude znepřístupněna celá stránka či nikoliv (až sem je asi podoba s obrázkem zřejmá). Specifikace vás ovšem nenutí vedle každé značky script povinně použít značku noscript (podobně jako alt u obrázku), ale místo toho jsou weboví vývojáři učeni používat skriptování tak, aby přístupnost stránek nebyla dotčena (a to se docela daří). Volitelná značka noscript je jen jednou z možností, jak toho dosáhnout.
Zastánci povinného altu jsou ovšem jiného názoru. Obě strany se tak snaží z webu udělat web přístupnější. Jen se nejspíš vzájemně nechápou. Jedni by rádi, aby webdesigneři byli nuceni psát atribut alt všude, zatímco ti druzí by rádi, aby webdesigneři používali atribut alt správně. Srovnání těchto dvou pohledů ponechám na čtenáři. Jsem sám zvědav, kdy se jim podaří nalézt společnou řeč.
Zkusil jsem si malý pokus. Vybral jsem si stránku, která je validní XHTML 1 Strict (první, která mě napadla, takže www.weblogy.cz, neberte si to nikdo osobně) a podíval jsem se na analýzu používání obrázků na této stránce. Použil jsem analýzu, která je součástí vyvíjeného HTML5 validátoru, ve výsledcích přeskočte HTML5 chyby (ty nás nezajímají, stránka není v HTML5 8-) a sjeďte až dolů k nadpisu Image report.
Celý přehled: Analýza použití obrázků na weblogy.cz.
Jak sami můžete vidět, některé obrázky na stránce mají vyplněn atribut alt velmi vhodně, zatímco o řadě dalších se to říct nedá. Validátor (ne)vhodnost nerozezná. Otázkou (byť ne jednoznačnou) pak je, když i zkušení webdesigneři v tomto chybují, zda je stávající řešení altu vynucovaného specifikací a validátorem to správné.
Proto ať již debata na téma alt dopadne jak dopadne, jsem rád, že se tohle palčivé téma řeší. Byť bych byl mnohem radši, když by se neřešilo tak dlouho.
Související
Budu rád, pokud k problematice připojíte svůj odborný komentář, vyvarujte se ale prosím emotivních výjevů, stačí, že se na toto (zřejmě citlivé) téma občas objevují i u členů pracovní skupiny.
pátek 2. května 2008
Atribut target v HTML5
Na rozdíl od HTML4, které atribut target u odkazu ze své striktní verze vypustilo, HTML5 atribut target opět zahrnula dokonce i lehce rozšířila. Atribut target se dříve používal zejména na stránkách s rámci (framy) a pro otevření nového okna. HTML5 zavádí možnost odkazovat se atributem i na pojmenovanou značku object (není mi ale úplně jasný princip).
A dovolím si jednu citaci:
A dovolím si jednu citaci:
When a new window is desired, the benefit of using the target attribute over many of the other techniques is that it is actually more beneficial to the user because it is easier to override. Many browsers offer options to cause such links to open in a new tab instead of a window, and some even allow it open in the same tab.
Přihlásit se k odběru:
Příspěvky (Atom)
