Přejít k navigační liště

Zdroják » Webdesign » Nové značky HTML5

Nové značky HTML5

Články Webdesign

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.

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é embedobject).

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.

Líbí se vám nové značky HTML5?

Komentáře

Subscribe
Upozornit na
guest
95 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Miro Hrončok

Co přijde mezi začáteční a koncový tag video?

Timy

Alternativní obsah pro klienty, kteří tag video neznají.

jos

případně odkaz na alternativního klienta

František Kučera

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.

petr_p

Jinak řečeno příklad v článku vůbec nedemonstruje kouzlo značky <video>.

pas

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).

Ifo

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 … .

František Kučera

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.

František Kučera

"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." :-)

pas

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.

pas

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.

pas

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.

František Kučera

Pokud to bude chodit i v gnashi, bylo by to celkem dobré řešení :-)

pas

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ý.

František Kučera

„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 :-)

pas

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.

pas

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.

pas

Mimochodem, jestli chcete, tak můžu napsat článek/tutorial na toto téma.

pas

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.

MD

Misto omezeneho <dialog> pro dva lidi mohli zavest univerzalnejsi <chat> pro libovolny pocet ucastniku :-)

MD

A jakyma znackama tedy vyznacite tech vice osob? Podle prikladu se na prvni osobu pouzije <dt> a na druhou <dd>

MD

Jo, uz to vidim… Moje chyba

trta

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…

František Kučera

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.

paranoiq

"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ží

František Kučera

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ů.

Radovan

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.

petr_p

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

<dl>
<tt>Losna<tt>
<tt>Mažňák<tt>
<td>Velkým vontem budu já!<td>
<tt>Červenáček<tt>
<td>Mně je to jedno.<td>
</dl>

vypadal takto:

Losna, Mažňák: Velkým vontem budu já!
Červenáček:    Mně je to jedno.

Kdyby jednotlivé „páry“ byly zařazeny do vlastního elementu, tak by to šlo.

František Kučera

To porušuje první normální formu :-)

František Kučera

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.

petr_p

Stačilo by to mít nepovinné, jako je tbody.

karf

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.

petr_p

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.

Peter Kahoun

> 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;}

Blc

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…

okman

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

xurpha

Tak se zdá, že z HTML5 se implementují nejdřív nejětší p*čoviny :-(

ivoszz

http://caniuse.com/

Odpovídám pozdě, ale pro případ reference…

tomaash

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…)? :)

Celer

To zas bude nějaká provokace :-D. Pěkný postřeh, já si toho nevšiml.

Anonymní

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,

František Kučera

+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.

pa3k

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.

František Kučera

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.

stoural

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.

stoural

maji tam byt odstavce – znacky P

Jakub D.

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…

MD

Proc je v dnesni dobe problem uzavirat tagy? To je tak tezke pridat </p>? Nechapu to…

pa3k

IMHO nič nebráni uzatváraniu tagov ktoré to nemajú povinné.

Jirka Kosek

HTML5 lze zapisovat v HTML i XML syntaxi — je na vás, co si vyberete.

Leinad

Snad v SGML/XML, ne?

Anonymní

jenze to neplati pro praci v teamu nebo pokud delate na necem po nekom..

Matěj

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ý.

pas

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…

smilelover

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

František Kučera

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é.

petr_p

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ň.

Martin Michálek

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 a footer 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ě :)

smilelover

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…?

La Coste

ty kokos, ludia to co tu riesite?

Martin Michálek

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:

<figure>
 <img src="obrazek.jpg" />
 <legend>Obrázek z dovolené</legend>
 <author>Fratišek Novotný</author>
 <licence>GPL 2.0</licence>
</figure>
Martin Michálek

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.

harvie

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…

harvie

mimochodem mobilní youtube se dá vyzkoušet i z pc: http://m.youtube.com/

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.