Nové značky HTML5

Nedávno byla uvolněna nová pracovní verze specifikace HTML5. Mezi novinkami, které přináší, najdeme i nové značky. Pojďme si představit ty nejdůležitější z nich, konkrétně section, article, aside, header, footer, nav, canvas, video, audio, dialog a figure.
Nálepky:
Detailní přehled novinek HTML5 najdete v dokumentu HTML 5 differences from HTML 4, jehož nová verze se objevila před několika dny. My se v článku soustředíme na ty nejdůležitější nové značky.
Strukturování dokumentu
Stávající HTML příliš možností k vyznačení struktury dokumentu neobsahovalo. Kde začíná stěžejní obsah stránky? A kde je navigace? Co je jen záhlaví a co patička? Nic z toho nešlo sémanticky vyznačit. Pokud jste chtěli uživateli pomoci, nezbývalo než vytvořit odkazy typu „Přeskoč na obsah“, „Přeskoč na navigaci“.
HTML5 několik takových značek nabízí. Jedná se o:
section
article
aside
header
footer
nav
Jejich význam je nejspíš patrný již z názvu, snad jen dodáme, že aside
vyznačuje boční panel (tedy obsah, který je poněkud méně vázán k hlavnímu obsahu stránky), značka nav
pak vyznačuje navigaci na webu.
Přínos budou mít jak pro vývojáře (snazší vyznání v dokumentu), ale hlavně pro stroje, ať už se jedná o prohlížeče nebo o roboty vyhledávačů (které tak snadno identifikují, kde je umístěn hlavní obsah stránky, které odkazy ve stránce jsou navigační atd.).
Mediální značky
HTML5 obsahuje tři značky zaměřené na média:
canvas
video
audio
Canvas
Značka canvas je jakési plátno, do kterého můžete generovat (kreslit) vlastní obsah. Nabízí se pro řadu použití, může zobrazovat vygenerovaný statický obrázek, interaktivní obrázek (graf reagující na ovládání uživatele) nebo třeba upravený výstup videa. Více se o této značce dočtete tady na Zdrojáku v článcích označených štítkem canvas.
Video
Vkládali jste někdy do stránky video? Pak jste se mohli setkat např. s takovýmhle kódem:
<embed type="application/x-shockwave-flash"
src="/static/cz/shared/app/MediaCenter.swf"
quality="high"
wmode="transparent"
allowfullscreen="true"
flashvars="media_id=431380&bit=1225473403624233743826&color=#000000&autostart=true"
width="440"
height="288">
Anebo také s kódem úplně jiným. Obecně téměř platí, že co jiný web, to jiný způsob vkládání videa. Čert aby se v tom vyznal. A nejenom čert – pro takový internetový vyhledávač to je stejný problém. Pokud by chtěl indexovat všechna videa na webu (což by jistě chtěl), nemá jak (zkuste najít způsob, jak z kódu uvedeného výše spolehlivě zjistit, že se jedná o vložení videa, a jaká je adresa onoho videa – nejde to).
Video na webu je doménou posledních několika let, není divu, že s ním nikdo při tvorbě HTML4 nepočítal. HTML5 proto zavádí novou značku, jejíž syntaxe je následující:
<video src="soubor.ogg"></video>
Oč by byla práce s videem na webu snazší, kdyby se na podobně značce výrobci prohlížečů dohodli už dávno.
Audio
Ze stejného důvodu HTML5 zavádí i značku pro přehrávání zvuku audio
. Její použití je analogické. Jak audio
, tak video
nabízí jednotné rozhraní pro práci s videm (audiem), ale jeho detailní popis by vydal na samostatný článek.
Rozhovory
Dalším často opakovaným prvkem na webu jsou rozhovory (minimálně na zpravodajských webech typu Zdroják). HTML5 pro ně zavádí novou značku dialog
, v rámci které recykluje značky z definičního seznamu. Ukázka použití:
<dialog>
<dt>Romeo</dt>
<dd>Má drahá Julie, jak se ti daří?</dd>
<dt>Julie</dt>
<dd>Romeo, ach můj Romeo, to jsem ráda, že jsi opět online.</dd>
<dt>Romeo</dt>
<dd>Vůbec si nedovedu představit, jak by náš vztah mohl po mém
vyhoštění z města pokračovat, kdyby nebyl internet.</dd>
</dialog>
Svazující značka figure
Značka figure
spolu svazuje mediální a textový obsah. Může se jednat o obrázek a jeho popis, nebo o video a jeho popis (podobně i o další značky, ať již nový canvas nebo klasické embed
a object
).
Podobný vztah jsme dosud vyznačit nemohli. Pro obrázek existoval pouze jeho alternativní popis (atribut alt), ale ten má specifický případ použití. Příklad použití značky figure:
<figure>
<img src="obr.png">
<legend>Mapa Středozemě</legend>
</figure>
V příkladu si všimněte jedné zajímavosti. U obrázku není použit atribut alt. To proto, že by v tomto konkrétním případě byl zcela zbytečný, alternativní obsah místo obrázku jsme totiž uživatelům nabídli, jen jiným způsobem. Jedná se o jeden z mála případů, kdy vynechání atributu alt specifikace povoluje.
Závěr
Uvedli jsme si jen ty nejdůležitější nové značky, které přinese HTML5 (ve skutečnosti je těch nových značek mnohem víc). Některé z výše uvedených značek můžete při troše opatrnosti používat na webu již dnes (např. canvas
). Ale obecně ovšem platí, že byste se jim zatím měli raději vyhnout, pokud si nejste jisti, co jejich použití udělá v tom kterém prohlížeči. Na podporu řady z nich si ještě chvíli počkáme.
Další informace
Obrázek v perexu pochází z Flickeru uživatele justinsomnia.
Co přijde mezi začáteční a koncový tag video?
Alternativní obsah pro klienty, kteří tag video neznají.
případně odkaz na alternativního klienta
Obvykle fallback content, čili "záchranný obsah" pro prohlížeče, které tuhle značku neznají (stejně se to používá i u embed, object), např. odkaz na přímé stažení videosouboru. Existuje jediná výjimka a tou je, když je nabízeno více variant zdrojového souboru, pak se obsah elementu využije.
nebo místo:
<video src="soubor.ogg"></video>
můžeme napsat:
<object data="soubor.ogg"></object>
Jenže to by už by nevypadalo tak senzačně, že? :-)
A že internetový vyhledávač nebude vědět, že se jedná o video? Ale bude:
<object data="soubor.ogg" type="video/ogg"></object>
dokonce včetně konkrétního MIME typu.
Z těch ostatních věcí mi přijde zajímavé to strukturování dokumentu – pokud se bude používat, může to pomoci k lepší výsledkům ve vyhledávání – dneska dává google často irelevantní výsledky, protože se např. hledané slovo vyskytuje v postranním panelu jako upoutávka na jiný článek nebo dokonce jako reklama.
můžeme napsat: <object data=“soubor.ogg“></object>
Jenže tohle řešení je jenom poloviční. Sice by pomohlo vyhledávačům videa rozpoznat, ale stále nenabízí jednotné rozhraní pro práci s videem a vývojářům by z ovládání videa, které se jim změní pod rukama, jakmile vymění formát videa, nadále vstávali vlasy na hlavě.
Kouzlo značky <video> totiž není jen v jejím zápisu, ale hlavně v rozhraní, který tahle značka nabízí pro práci s videem (a které bude na rozdíl od značky <object> zajišťovat prohlížeč, nikoliv plugin), tj. vývojáře při programování webu nemusí nezajímat, v jakém formátu video bude, zda jej přehraje nativně prohlížeč nebo si pro kodek sáhne do systému či k tomu zavolá externí aplikaci, protože ovládání videa bude mít vždy stejné rozhraní (tj. stejné události a metody) bez ohledu na formát videa, které přímo nabízí značka <video> (tedy prohlížeč).
Jde o jinou filosofii. Něco takového <object>, který jen zprostředkuje rozhraní pro externí plugin, nedokáže; tam se rozhraní pro práci s videem bude logicky měnit podle zvoleného pluginu a tedy i podle formátu videa.
Jinak řečeno příklad v článku vůbec nedemonstruje
.Ne, v celé kráse rozhodně ne, to je na samostatný článek. Už jsem o tom kdysi psal na blogu. Potíž je, že zatím kompletní rozhraní ještě nebylo naimplementované, resp. jsou v něm zatím chyby, tak je těžší vytvářet příklady, které to ukážou v celé síle.
To je právě ono. Tag video sám o sobě nemá smysl a uspěje teprve tehdy, když bude plně integrovaný do HTML/AJAX platformy a tato platforma jako celek (!) bude natolik výkonná a spolehlivá napříč browsery, že bude moct konkurovat Flashi nebo Silverlightu. Držím tomu palce, ale jsem velmi skeptický. Samotný fakt, že roboti díky tagu video poznají jednotlivá videa, není ohromující – využití videa v multimediálních prezentacích a aplikacích bude mít čím dál víc charakter drobných "assets", jejichž indexování nic moc zvláštního uživatelům nepřinese (v porovnání s dnešním stavem, kdy se prostě k videům, která opravdu nesou nějaký obsah, připojí textová informace).
No, s mojí zkušeností, jak funguje značka <object>, kdy na to, aby fungovala správně v MSIE musíte použít parametr classid a vyplnit do něj GUID COM komponenty, která bude obsah zpracovávat a naopak u jiných prohlížečů toto classid vyplnit nesmíte (minimálně u flashového obsahu jsem se s tímto setkal) budu rád za jakékoliv zjednodušení. Zase je na druhou stranu otázka, jestli si Microsoft neprosadí classid i pro tuto značku … .
Ale o tom to je, ani video značka v IE nefunguje, takže v tom pokrok nevidím. Přijde mi lepší se dohodnout na podpoře stávajících značek, než vymýšlet nové.
Na jednu stranu je hezké, že se hledá alternativa k flashovým videím, ale IMHO trochu nešťastným způsobem. Ono by stačilo, aby vznikl jeden plugin pro různé prohlížeče, který by podporoval jeden (nebo více) kodeků/kontejnerů pro video a vykresloval stávající značku OBJECT. Tento plugin by se stal podobným nepsaným standardem jako je dnes plugin pro Flash.
Nebo to nemusí být plugin, ale může to být přímo funkce prohlížeče, ale pořád na to nepotřebujeme HTML5.
značka v IE nefunguje, takže v tom pokrok nevidím
To už je obecný fakt, že novinky navrhované v nějaké specifikaci v prohlížečích zpočátku nefungují, na implementace se zpravidla musí chvíli čekat, argument „a z tohoto důvodu neznamenají pokrok“ není racionální.
Ono by stačilo, aby vznikl jeden plugin pro různé prohlížeče
V tom případě by nebylo třeba nic vyvíjet, takový plugin tu již dávno je a jmenuje se Flash.
"V tom případě by nebylo třeba nic vyvíjet, takový plugin tu již dávno je a jmenuje se Flash."
A v čem je problém? Většina lidí ho spokojeně používá a vůbec jim to nevadí.
Vadou je to, že u něj neexistuje konkurence — řešením jsou možná svobodné alternativy jako gnash.
Tenhle plugin není open source a občas padá, občas žere 100% CPU, konkurence by to spravila…
Stačil by jiný, jednodušší plugin, který by nedělal nic jiného než přehrával video. Jestli by to byl plugin nebo součást prohlížeče je celkem jedno (může to být i plugin dodávaný jako součást instalačního balíčku) a jestli bude interpretovat značku OBJECT s nějakým mime/typem nebo značku VIDEO bez mime/typu s tím, že bude nějaká domluva, v jakém formátu má video být… je také celkem jedno. Zásadní je tedy existence daného pluginu (nebo funkce prohlížeče), nikoli to, že máme novou HTML značku (bez ní bychom se totiž stejně dobře obešli).
Jak řekl jeden letec: „Konstrukční dokonalosti není dosaženo tehdy, když už není co přidat, ale tehdy, když už nemůžete nic odebrat." :-)
A v čem je problém? Většina lidí ho spokojeně používá a vůbec jim to nevadí.
Uživatelé s tím problém nemají, vývojáři ano. Flash totiž nemá rozhraní pro práci s videem z pozice webového vývojáře (jen z posice Flashového vývojáře, ale to je úplně jiná kapitola).
Zásadní je tedy existence daného pluginu (nebo funkce prohlížeče), nikoli to, že máme novou HTML značku
Zásadní je, aby existovala interoperabilní cesta pro přehrávání běžných typů médií na webu. Jak je realizovaná, to je již podružné.
Konstrukční dokonalosti není dosaženo tehdy, když už není co přidat, ale tehdy, když už nemůžete nic odebrat.
Jenže tohle není žádná snaha o nějakou estetickou dokonalost, ale snaha vytvořit řešení na dnešní potřeby vývojářů.
Není pravda, že "Flash nemá rozhraní pro práci s videem z pozice webového vývojáře". Flash má rozhraní pro JavaScript – takové, že z Flashe můžete manipulovat s DOMem stránky a naopak, z JavaScriptu můžete manipulovat s objektovým modelem uvnitř SWF. Úplně klidně můžete vložit prázdný SWF objekt jako "plátno" a začít do něj malovat JavaScriptem, vkládat video, atd. Takové řešení sice moc často vidět není, ale možné je. Stále častějším případem jsou SWF komponenty s dobře udělaným JavaScriptovým API.
Stále častějším případem jsou SWF komponenty s dobře udělaným JavaScriptovým API.
To určitě, ale ty už udělal ten flashový vývojář. Flash nabízí jen obecné prostředky k vytvoření takového API.
Ale ne, opravdu můžete do stránky vložit prázdné SWFko a začít s ním manipulovat JavaScriptem, čili vlastně "flashovou" aplikaci programovat JavaScriptem místo ActionScriptem. To, že se o tom neví a nikdo to asi reálně nedělá, to je jiná věc, každopádně je dobré vědět, že Flash platformu můžete používat i když nejste "flashový vývojář" (natož abyste si musel koupit nějaký konkrétní nástroj). Stejné je to tuším u Silverlightu.
To, že to nějak jde, pokud má vývojář jisté znalosti Flash platformy nepopírám. Ale to má stále stejně daleko do toho, co tvrdím, tedy že Flash nemá API pro práci s videem přímo z pozice webového vývojáře.
Samozřejmě musíte znát objektový model Flashe – že tam jsou nějaké objekty NetStream, Video, atd. Programujete ale v JavaScriptu. Flash poskytnul pouze "objekty navíc". Větší pohodlí už weboví vývojáři nemůžou mít, takže pořád nerozumím vašemu "má to daleko do toho…".
Jinak ovšem nepopírám, že by byl hezký ten ideální svět s tagem video, a spol.
musíte znát objektový model Flashe
Jenže tím už jsme se ale od klasických webových vývojářů posunuli někam jinam. Vůbec bych se nedivil, kdyby se ukázalo, že 99 ze 100 webových vývojářů o nějakém objektovém modelu Flashe nemá ani páru. Pro ně je potřeba přímý přístup k API a ten neexistuje.
Pokud to bude chodit i v gnashi, bylo by to celkem dobré řešení :-)
Pokud je gnash plně kompatibilní s Flash Playerem, tak samozřejmě bude fungovat to, co popisuju. Je to javascriptová knihovna, která obaluje Flash Player a umožňuje programovat v JavaScriptu vně SWF jako alternativu k programování v ActionScriptu uvnitř SWF. Objektový model je v obou případech stejný.
„99 ze 100 webových vývojářů o nějakém objektovém modelu Flashe nemá ani páru.“
On kolem nakonec toho nakonec stejně někdo udělá obalovou knihovnu a kodéři pak stejně budou jen bušit weby, které volají funkce této knihovny, takže nějaké API, které je pod tím je zajímat nebude :-)
To mohlo fungovat (tedy funguje, takové přehrávače už dávno existují), má to jedinou nevýhodu – vzniknou tucty přehrávačů s tucty různými API (což se přesně děje) a jsme tam, kde jsme byli. Žádný standard, žádná jednotnost. Škoda je, že samotný Flash takové API už dávno nenabídl.
To je nějak furt dokola… :) Flash takové API nabízí, chápete to? Otevřete si dokumentaci k ActionScriptu a tytéž třídy (Video, Sound, NetStream, …) můžete používat jak při programování v ActionScriptu, tak i přímo v JavaScriptu – při použití tzv. Flex-Ajax Bridge. Celý Flash Player tak můžou vývojáři chápat jako javascriptovou knihovnu.
To je nějak furt dokola
Doporučuji náhodně vybrat nějakého vývojáře, ukázat mu zmíněné řešení a… myslím, že rychle pochopíte, kde je problém.
Stalo se. Spíš jde o to, jestli takovou zkušenost máte i vy. Vy tady fňukáte, že Adobe něco mohlo pro vývojáře udělat a že to neudělalo. Tak já vás informuju, že to udělalo – veškeré API Flash Playeru je dostupné z JavaScriptu, jedna ku jedné, tečka. Udělali maximum, co mohli udělat při stávající pluginové architektuře. Můžete klidně kritizovat pluginovou architekturu jako takovou, ale příště si tedy předem rozmyslete, co vlastně chcete kritizovat.
Mimochodem, jestli chcete, tak můžu napsat článek/tutorial na toto téma.
Ten spor pramení mezi rozdílem "existuje cesta" (ano, existuje) a "existuje vhodná cesta" (v žádném případě).
Článek na práci práci s flashovými objekty z JavaScriptu uvítáme. Anotaci článku zašlete prosím na můj redakční mail.
Ano, 99 % vývojářů nemá páru o API Flashe. 99 % vývojářů nemá ani páru o API tagu video (a souvisejících věcech). Chtějí-li pracovat s videem, některé z těch API se holt budou muset naučit. Obě API jsou javascriptová. Tak já fakt nevím, jediný rozdíl vidím v tom, že jedno z nich je od Adobe a druhé od W3C. Chcete-li mě přesvědčit, že API od W3C je obecně lepší, tak to nemusíte, to já souhlasím, že to je víc v souladu s božím řádem světa. :) Ale o tom tahle diskuse snad nebyla.
Misto omezeneho <dialog> pro dva lidi mohli zavest univerzalnejsi <chat> pro libovolny pocet ucastniku :-)
Myslím, že ta poznámka není na místě, dialog se používá pro rozhovor dvou a více osob.
A jakyma znackama tedy vyznacite tech vice osob? Podle prikladu se na prvni osobu pouzije <dt> a na druhou <dd>
To rozhodně ne, pro všechny (obě) osoby se používají stejné značky, dt pro označení osoby a dd pro její text.
Jo, uz to vidim… Moje chyba
pouziti znacek dt a dd me taky prijde trochu zmatecne – zrejme nechapu, jak by vypadalo pouziti, pri dialogu vice jak dvou osob (kdy pouzit dt, kdy dd). chapal bych snad leda pouziti dt – otazka, dd – odpoved…
Staci si predstavit jakykoliv zapis z chatu nebo divadelni scenar, vypadaji podobne. Obsahuji oznaceni hovorici osoby (znacka dt) a text, ktery rika (znacka dd). Neni problem pak zapsat rozhovor neomezeneho mnozstvi osob.
Sémanticky hodnotnější by ale bylo, kdyby byla značka pro otázku a pak značka pro odpovědi s tím, že odpovídat může více osob. Nebo alespoň značka, která by svazovala (obalovala) jméno osoby a její text – takhle mezi nimi vazba není, jsou to jen dva elementy, které leží za sebou.
"Sémanticky hodnotnější by ale bylo…" a jaké by bylo využití krom FAQ? už si představuji, jak lidé v diskuzi zaštrtávají pole "toto je odpověď" (nebo nedej bože "toto je správná odpověď" ;-)
ale vždyť jsou svázány. ke každému dt náležejí všechny následující dd, dokud nepřijde další td. parsovat se to dá jednoznačně i bez explicitního označení. prostě na poloze záleží
Podobných věcí jako dialog je spousta — co třeba FAQ? Hodilo by se třeba mít jasně (sémanticky) označené otázky FAQu a odpovědi a pak bych třeba do googlu zadal otázku a řekl, že chci vyhledávat v otázkách a měl bych velkou šanci, že najdu relevantní výsledky.
Časem zjistíme, že je velmi mnoho případů, kde by se nám hodily vlastní značky. Jenže jak z toho ven? Budeme mít jedno nabubřelé HTMLx do kterého se postupem času protlačí všemožné značky z různých oblastí? A co takhle používat XML a jmenné prostory? ;-) To by umožňovalo velkou přizpůsobitelnost a zároveň by si ten základní formát zachoval svoji jednoduchost, nepřeplácanost.
Postupně by se ustálily určité jmenné prostory a vyhledávače by se ty nejpoužívanější naučily indexovat.
Jenže to by někteří lidé nesměli mít panickou hrůzu z XML a "striktních" formátů.
Menne priestory by neboli zle, ale lepsie to riesi XHTML 2. Atribut ROLE :) Zial nieco taketo sa do HTML 5 nedostalo. Je to dostatocne ohybne a ovela viac to zapada do mikroformatoveho principu. Holt, vyvoj si nevyberies.
takhle mezi nimi vazba není
Je tam logická vazba, úplně stejně to funguje u definičních seznamů (tuším už od HTML3, resp. 3.2). Ponechme HTML dokumentům jejich štíhlost; tam, kde to není nutné, nemusíme vkládat zbytečné značky.
Vazba tam je velmi slabá. Můžete mít libovolný počet tt i td. To, co vytváří vazbu, je pořadí a změna názvu elementu.
Takovýto způsob je sice uchopitelný parserem s dopředným vyhledáváním, ale už ne ostatními jazyky jako třeba CSS. Jak například uděláte, aby
vypadal takto:
Kdyby jednotlivé „páry“ byly zařazeny do vlastního elementu, tak by to šlo.
To zapíšu jednoduše, třeba: <dt>Losna, Mažňák</dt><dd>Velkým vontem….</dd>
To porušuje první normální formu :-)
O nic víc než jakýkoliv značkovací jazyk, který povolí vkládání celých vět nebo souvětí bez povinnosti vyznačení všech obsažených informací. Ne, psaní dokumentu opravdu není tvorba databáze.
To není, ale když připustíme, že dvě entity (Losnu a Mažňáka) můžeme nacpat do jedné, tak můžeme na tu sémantiku rezignovat úplně a jednoduše ten dialog jen zabalit do DIVů a nastylovat CSSkem.
sémantiku rezignovat úplně
V tom tvůrcům stránek v zásadě až tak moc nikdo nebrání. Ale není to důvod proč nemít jako možnost i rozumný sémantický zápis. To, že to jde ještě sémantičtěji neznamená, že to tak musí být povinně a komplikovat běžné používání – HTML byl vždy jednoduchý jazyk a nechť takový zůstane. Doporučuji se podívat na Paretův princip.
Stačilo by to mít nepovinné, jako je tbody.
Ten obal by se tam opravdu velmi hodil. Např. oddělit jednotlivé bloky DT/DD čarou nebo je podbarvit pomocí CSS je s takovýmhle kódem sakra problém.
Stále nemáte způsob, jak udržet osobu i řeč na jednom řádku a přitom zajistit, aby nová replika byla na novém řádku.
Kdyby tam ten mezielement byl, tak se to celé dá nastylovat přes display: table-row a table-cell.
Mohly bychom vylepšit selektory CSS, ale stejně tu zůstane problém, že gramatika je kontextová, takže třeba ani nemůžete adresovat jednu repliku jako fragment dokumentu.
> Stále nemáte způsob, jak udržet osobu i řeč na jednom řádku a přitom zajistit, aby nová replika byla na novém řádku.
Mohlo by fungovat něco na způsob…
dt:before {content:''; display:block;}
Jen tak mimochodem, kdy se předpokládá, že bude specifakace HTML5 hotová? Připravuje se už docela dlouho a mluví se o ní ještě déle…
Pro webové vývojáře je dnes celkem irelevantní kdy a jak je specifikace hotova, důležitá je podpora v prohlížečích (CSS dvojka taky pořád není hotova a nikoho to vlastně nezajímá, důležité, že funguje).
Odhadem tak 10-20% z HTML5 lze bez problému používat už dnes, protože již je buď plně podporovaná nebo částečně podporovaná a rozumně emulovatelná. Zbytek se implementuje postupně.
Všechny tyhle specifikace jsou dnes běh na dlouhou trať. CSS dvojka se už dělá 10 let (zrovna minulý týden vyšla další revize) a snad už konečně bude hotová, CSS trojka se už dělá taky skoro deset let a tak minimálně ještě 5-10 let se dělat bude (čili celkem 10-15 let), HTML5 se začala dělat asi před 5ti lety a s dokončením na tom bude určitě ještě hůř než než CSS3.
ok ok, ale, kde se na zdrojaku z tohoto clanku dozvim co presne muzu jiz pouzivat?
Pisete, že 10-10% ,ale co tedy?
Kdyz jdu psat html, tak jak mohu vedet, co mohu zacit do nej psat?
Asi si to musim jit zjistit sam na W3C?
Diky za odpoved
Doporucuji zacit canvasem, staci mrknout na clanky, co o nem na Zdrojaku jsou.
Prehled podporovanych znacek v prohlizecich se snazi udrzovat wikipedia, ale vetsinou je trochu pozadu, viz http://en.wikipedia.org/wiki/Comparison_of_layout_engines_(HTML_5).
Tak se zdá, že z HTML5 se implementují nejdřív nejětší p*čoviny :-(
http://caniuse.com/
Odpovídám pozdě, ale pro případ reference…
Ta pest co je v anotaci clanku, ma 6 prstu… Znamena to s nad, ze tomu, kdo zacne pouzivat HTML5 naroste sesty prst, nebo je to prorocka vize alegoricky znazornujici, ze tam zase neco prebyva (jako sveho casu znacky menu, dir apod…)? :)
To zas bude nějaká provokace :-D. Pěkný postřeh, já si toho nevšiml.
Jedná se o známou XHTML pěst z A List Apart, jen s jinými písmeny. Další prst dostala čistě z praktických důvodů, aby se na ní to XHTML vešlo.
Me jen mrzi, ze to neni ala xhtml teda ze vsechny znacky se neuzaviraji, z meho pohledu nove znacky super, ale deleni znaku na parove a neparove se mi nelibi zvyk sem si na xhtml,
+1 stavět na XML a jeho pravidlech by bylo určitě dobré, usnadní to parsování a editaci nějakými sofistikovanějšími nástroji než je notepad nebo vim.
To je riadna demagógia. V čom konkrétne to uľahčí parsovanie? :-D ROFL V parsovaní DTD a pramatrických entít? IMHO je dobre, že sa na XML stavať nebude, pretože by to mohlo dopadnúť ako s mŕtvym a nepoužiteľným XHTML.
Třeba to, že bych mohl použít již existující (a kvalitní) XML editor a pouze do něj nahrát nové Schéma/DTD pro nový formát. Tomu se říká znovupoužitelnost ;-)
Výhody, které pocítím, kdykoli se objeví nový formát založený na XML:
1) nebudu se muset učit novou syntaxi a řešit "jak je to tady sakra s těmi závorkami?"
2) nebudu se muset učit pracovat s novým editorem
3) nebudou se muset vytvářet nové editory, znovu vynalézat kolo, použijí se stejné odladěné parsery a knihovny, pouze se nahraje Schéma či DTD pro daný formát.
Takhle si představuji efektivitu a ušetření práce.
V cem?
Kdyz mate vytvorit parser pro nejaky kod, bude se programovat snadneji, kdyz budete vedet, ze kazdy
musi byt ukoncen
, nebo kdyz budete vedet, ze nemusi (ale muze) byt ukoncen vubec, takze budete muset osetrovat takove situace a zjistovat, kde vlastne onen odstavec konci?
Jediny demagog jsi tady ty.
maji tam byt odstavce – znacky P
Jde tady spis o to, ze na HTML nelze aplikovat XSLT, XPath, XQuery a dalsi vyborne XML-based technologie. Proste ve chvili, kdy chcete nejakou www stranku zpracovat strojove, tak s HTML jste v hajzlu. Ani RX nejsou vsemocne. Ale na druhou stranu chapu, ze tohle trapi hlavne vyvojare a nejaky koder, jehoz znamy svet konci s Firefoxem, tyto pohnutky nechape…
Proc je v dnesni dobe problem uzavirat tagy? To je tak tezke pridat </p>? Nechapu to…
IMHO nič nebráni uzatváraniu tagov ktoré to nemajú povinné.
HTML5 lze zapisovat v HTML i XML syntaxi — je na vás, co si vyberete.
Snad v SGML/XML, ne?
Mrzet vás to příliš nemusí, je na vás, zda budete používat HTML syntax nebo XHTML syntax, zavedeny jsou obě.
jenze to neplati pro praci v teamu nebo pokud delate na necem po nekom..
Tam je to už problém interní dohody, nikoliv nějaké specifikace.
To s tím videem mi pořád nějak není jasné. Je to ze strany autorů dobrý záměr, ale realita je už asi dávno předběhla. Jeden z hlavních důvodů pro použití Flashe nebo Silverlightu je přeci to, že autor webu může ovlivňovat chování přehrávače: přerušovat nebo překrývat video reklamou (to hlavně!), zvětšovat, zmenšovat atd. atd.. Pokud toho nebude tag video schopen (podle mě nemůže být), tak se mi zdá předem mrtvý.
Je toho schopen, více najdete např. ve specifikaci odkazované z článku.
Tag toho schopen je, teď ještě aby byly prohlížeče. ;-)
Když se podívám na desetiletou historii implementace CSS2/3, tak mě to optimismem vůbec nenaplňuje. A video (a nejen to – zvuk, pokročilá práce s grafikou, …) jsou větší sousto než CSS. Nemáte pocit, že výrobci browserů se tohoto sousta spíše dobrovolně zříkají ve prospěch pluginů (jinými slovy Flashe)? A to prostě proto, že je nereálné ten vývoj ukočírovat (tak, abychom se toho ještě dožili :))? Navíc Adobe není žádný satan – otevírá veškeré formáty, uvolňuje nástroje jako open source, umožňuje plnou integraci Flashe s JavaScriptem…
Nemáte pocit, že výrobci browserů se tohoto sousta spíše dobrovolně zříkají ve prospěch pluginů
To v žádném případě. Ostatně zrovna tahle značka vzešla právě na popud samotných výrobců prohlížečů.
article, aside, header, footer …a tolik proklamovana semantika je v haji. O article by se dalo jeste spekulovat, ale co ma do haje co delat pozice (i kdyz trba jen predpokladana) prvku v jeho nazvu? Za header a footer specialne bych sekal ruce, aside ma taky opravu uzasny nazev…
To same video a audio, jak uz nekdo psal vyse.
Atributy by se mely pouzivat mnohem vice, zvysilo by to flexibilitu.
Ja bych navrhoval separatni namespace, ktery by slouzil prave pro metadata tohoto typu. Jako
nebo
Shodou okolnosti se jedna zrovna o semanticke znacky 8-)
jj, header a footer jsou celkem zbytečné, smysl má označení obsahu — s tím, že všechno kolem může vyhledávač při indexování ignorova (není třeba značit, co je hlavička, co zápatí, zajímavý je ten článek).
hlavička a zápatí mohou být obyčejné DIVy
Obsah by měl být nějak označen. Nemusel by to být ani jeden element content. Docela zajímavé by bylo svázat nadpis + text nějak lépe, než že jsou prostě za sebou. Pak by se jako obsah bralo to, co je svázané s nějakým nadpisem a váha obsahu odstavců by odpovídala úrovni nadpisu, ke kterému jsou připojené.
Kdypak HTMListi přiznají, že chtějí HTML jako prezentační jazyk. Tenhle kočkopes, kdy se tam nejprve nacpe font, pak se slavnostně vyhodí, pak tam přidají article s aside, ale nepodchytí vztah mezi nadpisem a blokem nebo mezi tt a td. Nebo umožní rekurzivní section, ale už ne rekurzivní nadpis (přitom by stačilo zrušit head/title a přemístit jej do libovolného blokového elementu, s tím, že v něm jakožto přímý potomek může být nejvýše jednou).
Ze sémantického hlediska je HTML smrdutá zdechlina, do které se strkají další a další elementy, ale na vztahy mezi nimi se kašle. V podstatě to je pořád ta stará elementová polévka. Přitom by stačilo utáhnout gramatiku. Taková změna by nezbořila staré prohlížeče, přesto by sémantiku pozvedla na nevýdanou úroveň.
header a footer jsou celkem zbytečné
Zkuste si projet reálné weby a zjistíte, že většina z nich má hlavičku i patičku a také se je snaží nějak vyznačit (nesémanticky). Ono když nic jiného, tak minimálně už pro takovou přehlednost kódu se zavedení těch značek hodí. Navíc obě značky lze použít nejen ve vztahu k celé stránce, ale i v obsahu (např. uvnitř značky article). Lze tak označit záhlaví článku (např. nadpis a perex), což také najde své využití na řadě webů.
Martine, myslím že v článku třeba
aside
nepopisuješ přesně:..aside vyznačuje boční panel..
Dost mě zarazilo, že HTML5 se vrací k popisu vzhledu dokumentu, ale ve specifikaci je:
aside represents a piece of content that is only slightly related to the rest of the page.
Pokud
aside
,header
afooter
chápu správně, popisují obsah s určitým významovým vztahem k hlavnímu obsahu jakékoliv části stránky – poznámka stranou, záhlaví a zápatí.V tom případě je vše v pořádku – ty prvky jsou krásně sémantické a těším se na ně :)
On ten aside je dost typický pro boční panel (a ve většině případů tak asi bude použit), ale na umístění obsahu na stránce není ta značka skutečně nijak vázána, je definována dle sémantiky (byť si ten aside asi všichni představíme jako "něco vedle").
Pokud jsou tyhle značky použity na úrovni dokumentu, vztahují se k celé stránce, pokud jsou uvnitř značek section nebo article, vztahují se jen k této dané části (tam už bude použití aside různorodější).
Nejak mi to neodescapovalo ty tagy a ani nehodilo chybu… Chtel jsem uvest priklady:
<ul semantics:role="nav"></ul>
nebo
<p semantics:role="footer"></p>
IMHO by proste tagy mely byt maximalne semanticky neutralni. Pak neni potreba vymyslet dalsi, protoze role jsou o hodnotach atributu. Az se zjisti, ze se na neco zapomnelo, bude se do HTML pridavat dalsi tag…?
To je ovšem pohled maximalisty. Nejde přeci o to, abychom měli značení pro všechny případy. Cílem je mít dostatečné značení pro ty běžně používané případy. A z tohodle pohledu mi výběr připadá dobrý.
ty kokos, ludia to co tu riesite?
Líbí se mi značka figure, ale představoval bych si, že označování multimédií půjde ještě dál co se popisu autorských práv týká. V ideálním světě bych si to rýsoval třeba takhle:
A použití mikroformátu rel-license ti nestačí? http://microformats.org/wiki/rel-license
Rel-license jsem neznal, díky.
Každopádně neřeší všechno. Když budeš chtít u fotky zobrazovat jejího autora a odkázat na jeho web, musíš použít atributy, které jsou určeny pro jiný obsah. Sám aktuálně používám "title".
Autorská práva je jedna z věcí, ve kterých je na webu dost velký bordel. Když už HTML5 řeší header, footer a další, mohlo by pomáhat i tady.
Doufam, ze youtube a podobne portaly take zacnou tag video pouzivat, nebo alespon to umozni. Flash na linuxu totiz umi delat problemy… Jenomze to si pridelaj zas problemy, youtube bude muset nejak vyresit titulky, popisky,… (umi tag video titulky? nekdo by za to mel lobovat…). Taky by se hodilo javascriptovy api na ovladani videa (to doufam existuje).
treba mobilni verze youtubu funguje tak, ze se otevre stream v externim prehravaci…
mimochodem mobilní youtube se dá vyzkoušet i z pc: http://m.youtube.com/