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

Zdroják » Webdesign » Webdesignérův průvodce po HTML5 – nová sémantika II

Webdesignérův průvodce po HTML5 – nová sémantika II

Články Webdesign

Další týden, další porce informací o HTML5. Dnes dokončíme přehled nových elementů, povíme si o několika změnách u některých starých známých a ukážeme si pár zjednodušení, které HTML5 vnáší do běžně používaných věcí.

Na úvod

Začněme tam, kde jsme minule skončili. Probrali jsme strukturální elementy <article>, <aside>, <nav>, <section> a navíc jsme přibrali <header> a <footer>. Začali jsme s nimi schválně, protože tyto nové elementy jsou to, s čím si lidé často HTML5 pojí (ač jsou jen malou částí specifikace).

Pokud jste sledovali komentáře, tak jste si jistě všimli, že Jirka Kosek (který je mj. podepsán pod základními principy tvorby HTML5, které jsme probírali v nultém díle seriálu) psal, že tyto elementy se možná nedostanou se do finální specifikace. A takový komentář určitě zaslouží pár slov na vysvětlenou.

HTML5 se neustále vyvíjí a pochopitelně okolo nových elementů je stále dost kontroverze. Vždyť i HTML5 Super Friends se přimlouvali například za vypuštění elementu <article> v obavě, že webdesigneři nepoznají rozdíly a nové elementy budou pro sémantiku spíše danajský dar (což je stále dost dobře možné, pozn. aut.). Od té doby už uplynula spousta času a elementy zůstaly. Jirka Kosek měl tedy pravděpodobně na mysli nedávné (květen 2010) návrhy na vypuštění několika nových elementů ze specifikace (mj. také <aside>). Rychle se ale objevily naopak hlasy pro zachování těchto elementů. Jak to dopadne, nikdo neví, autor článku by si ale celkem vsadil, že zůstanou.

Proč to vůbec takhle rozebíráme? Protože to dobře demonstruje situaci kolem celého seriálu. Píšeme o něčem, co se neustále vyvíjí. Je možné, že vydáme článek a druhý den se specifikace změní. Tato nejistota by vás však neměla zastavit v testování a používání HTML5. Akorát prosíme – používejte zdravý rozum. Pokud se vám nějaká část současného HTML5 líbí a pomůže vám v práci, použijte ji a netrapte se tím, že zítra se specifikace změní. Vždyť vám to přece pomohlo. A pokud se vám naopak nějaká část nelíbí, tak ji prostě nepoužívejte. Třeba se bude zdát podivná i dalším lidem a ještě s tím autoři specifikace něco provedou. (Proaktivně se můžete také zapojit do diskuse ve veřejném mailing listu W3C a změnu iniciovat.)

Další zajímavé a užitečné elementy z HTML5

Nebudeme zde v seriálu rozebírat všechny nové elementy v HTML5 (minimálně do doby, než budou opravdu kodifikované), dovolíme si vybrat pouze ty, které nás nějak zaujaly. Pokud vás zajímají všechny, můžete se podívat na HTML: The Markup Language. A pokud jsme zapomněli váš oblíbený, určitě jej zmiňte v komentářích. Na případné dotazy a dohady je pak místo na fóru.

Pozn. aut.: Část vysvětlení elementů jsem znovu převzal z HTML5Doctor.com, odkaz na konkrétní článek, stejně jako na specifikaci, najdete vždy u konce vysvětlení konkrétního elementu.

<hgroup>

Označuje skupinu souvisejících nadpisů. Pokud bychom pak dělali outline (například pomocí HTML5 outliner) stránky, tak by se v něm objevil jen ten nejdůležitější nadpis z celé skupiny. <hgroup> tak má použití hlavně u článků s podnadpisy.

Tipy

  • Pokud máte jen jeden nadpis <h1><h6>, tak <hgroup> nepotřebujete.
  • Naopak pokud máte nadpis a podnadpis (oboje <h1><h6>), tak je slučte dohromady pomocí  <hgroup>.

Příklad použití

<hgroup>
    <h1>HTML5</h1>
    <h2>aneb chaos v hlavách webdesignérů</h2>
</hgroup>

Dále čtěte

<time>

Označuje buď údaj o čase nebo přesné datum na Gregoriánském kalendáři, volitelně s údajem o čase a časovém pásmu.

Pamatujete na náš seriál o Mikroformátech a problémy s abbr design pattern? Element <time> nedělá nic jiného, než řeší všechny ty problémy a nabízí jasně specifikovaný formát času a data pro stroje a zároveň nám ponechává volnost nabídnout návštěvníkům webu jakýkoli formát data a času chceme.

Příklady

<time datetime="2009-11-13">13 listopadu 2009</time>
<time datetime="010-11-13T020:00+01:00">Narozeninová párty v Praze</time>

Použití

Jasně se nabízí využití v kombinaci s Mikroformáty/RDFa/Mi­crodata například pro označení toho, kdy se koná jaká akce. V kombinaci s Mikroformátem hCard by to mohlo vypadat například takto:

<div class="vevent">
    <a class="url" href=">http://www.web2con.com/">http://www.web2con.com/</a>
    <span class="summary">Web 2.0 Conference</span>:
    <time class="dtstart" datetime="2007-10-05">October 5</time> -
    <time class="dtend" datetime="2007-10-20">19</time>,
    at the <span class="location">Argent Hotel, San Francisco, CA</span>
</div>

Pubdate

Další možné použití je v kombinaci s novým atributem „pubdate“ (typu boolean). Ten označuje publikování nejbližšího nadřazeného elementu <article>. V takovém případě je samozřejmě vyžadováno, aby element <time> obsahoval datum. Atribut „pubdate“ nesmí být použit ve chvíli, kdy neexistuje žádný nadřazený element <article>.

Například to může vypadat takto:

<p>Tento článek byl publikován <time datetime="2010-06-08" pubdate>8 června 2010</time>.</p>

Dále čtěte

<figure> a <figcaption>

Definice by zněla asi tak, že <figure> označuje doplňkový obsah k hlavnímu obsahu, který je teoreticky možno vyjmout bez ovlivnění významu hlavního obsahu. Tento obsah může mít popisek ( <figcaption>).

Řečeno jednoduše pomocí příkladu – je to obrázek v článku, který může mít volitelně popisek ( <figcaption>). Další použití by mohlo být třeba u článku s ukázkou zdrojového kódu.

Problém, jak tento často se vyskytující obsah označit, měl v průběhu tvorby specifikace mnoho řešení a vedly se okolo toho bouřlivé debaty. Nedávno se to trošku ustálilo právě na tomto řešení, ale nikde není zaručeno, že se to zase rychle nezmění.

Příklad

<figure>
    <img src="/hixie.jpg" alt="Hixie je napaden bandou HTML5 Super Friends">
    <figcaption>Záběr z nového akčního filmu o vzniku HTML5</figcaption>
</figure>

Čtěte dále

<embed>

Určitě znáte element <embed>, který se často používá pro vkládání pluginů (typicky Flash) do stránek. Ale víte, že <embed> není součástí ani HTML 4.01 ani XHTML 1? HTML5 tento nedostatek jednoduše opravuje. Netřeba rozvádět.

Spec  – the embed element

<video>, <audio> a <canvas>

Když mluvíme o nových elementech, nelze tyto tři opominout. Ale protože jsou skutečně velmi zajímavé, budeme jim věnovat samostatné články, o <video>  a <audio> si povíme již příští týden, <canvas> přijde někdy potom (ostatně články o základech Canvasu a jeho používání už na Zdrojáku v minulosti vyšly).

Změny v sémantice existujících tagů


Foto: laffy4k. Publikováno pod licencí CC-BY

Autoři HTML5 elementy jen nepřidávali, ale také občas měnili význam těch stávajících. Pojďme se podívat na některé důležité či zajímavé změny.

<i>, <b>, <em>, <strong>

Pamatujete, jak se říkalo, že <i> a <b> nejsou sémantické elementy a neměly by se používat? Tak to zase zapomeňte, HTML5 redefinuje <i> a <b> a dává jim sémantický význam.

Podívejme se na jednotlivé elementy v porovnání mezi sebou:

<i>  – část textu, která by měla být čtena jinak, než okolní text. Například tedy cizí slova.

<b>  – část textu, která je stylisticky odlišná od zbytku textu. Například tedy klíčová slova a typograficky tučný text.

<em>  – část textu, na kterou byste při čtení dali důraz.

<strong>  – část textu, která je prostě důležitá.

Čtěte dále

<small>

Element, který dříve označoval text, který prohlížeče vykreslovaly menším písmem, nyní dostal také nový význam a označuje poznámky k textu. Obvykle se používá pro různé legální poznámky, jako třeba odkazy na licence obrázků, použitých fontů aj. Pozor – jedná s o inline element, nepoužívejte jej tedy místo <p>  apod.

Příklad

<p><small><a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative Commons Attribution Share-alike license</a></small></p>

Čtěte dále

<hr>

Označuje tématickou pauzu v textu. V podstatě to znamená konec jedné sekce a začátek jiné, tedy to samé jako </section> <section>. Používat <hr> se tedy doporučuje hlavně pro oddělení tématických pauz v textu, jako například části básně či jednotlivé scény v románu.

<cite>

Nově označuje titulek díla, ze kterého je citováno. Pro zájemce proč a jak, doporučujeme článek The Cite Element In HTML 4.01 and HTML5.

<a>

Nebojte, HTML5 nikterak nemění význam ani funkci odkazů. Nově nám ale umožňuje obalit elementem <a> celé odstavce, sekce a jiné blokové elementy. Takže například takováto konstrukce je nyní již korektní. Hurá!

<a href="http://zdrojak.root.cz">
    <section>
        <h1>Webdesignérův průvodce HTML5</h1>
        <p>Vychází již třetí díl seriálu a vypadá to, že se povede udržet týdenní periodicitu.</p>
    </section>
</a>

<script>

U elementu <script> proběhlo několik změn. Nově nemusíme uvádět type="text/javascript", přibyl atribut „async“, který má zajišťovat asynchronní zpracování skriptu a atribut „defer“, který naopak pozdrží vykonávání až na okamžik, kdy byl dokument zparsován. Atribut „type“ můžete přestat uvádět již dnes, s ostatním to bude chtít počkat na podporu v prohlížečích.

Spec – script

<link rel=„stylesheet“ …>

Další drobné zjednodušení, které přináší HTML5, spočívá v tom, že rel stylesheet má nyní defaultní hodnotu type="text/css", takže ji není třeba zadávat. Prohlížeče to již dnes umí, takže atribut type můžete vyhodit ze svého HTML ještě dnes.

Zavržené elementy: <big>, <tt>

HTML5 neobsahuje dnes stejně již prakticky nepoužívané prezentační elementy <big><tt>.

<meta charset>

V našich krajích určitě všichni víme co to je kódování, všichni jsme s ním měli problémy a můžeme vyprávět veselé historky z vyvíjení, kde kódování hraje hlavní roli. A pokud celý život neposíláte kódování v HTTP hlavičce dokumentu, tak určitě znáte následující zápis v HTML4.01:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

Pěkná věc, jedna z těch, kterou člověk pokaždé zkopíruje a inepamatuje si, kam ty zatracené uvozovky napsat. A tak nám někteří začátečníci (ale nejen oni) dělají třeba tohle:

<META HTTP-EQUIV=Content-Type CONTENT=text/html; charset=ISO-8859-1>

Vidíte rozdíl? Chudák webdesigner zapomněl na uvozovky! A najednou to vypadá, jako bychom tu měli samostatný atribut charset. Jak z toho má prohlížeč zjistit kódování? Nebo by ho snad měl tipnout? Tvůrci prohlížečů usoudili, že raději implementují charset jako samostatný atribut, aby tuhle častou chybu ošetřili.

A hurá – tvůrci HTML5 to vědí, a tak nám zkrátili celý ten zdlouhavý zápis na jednoduchý:

<meta charset="utf-8">

Není to nádhera? A nejlepší na tom je, že to z výše uvedených důvodů funguje již dnes. Pokud nevěříte, tak se podívejte na testy.

Závěrem

Tak si to shrňme. Spousta nových elementů (a to jsme ještě pořádně nemluvili o atributech, ale to si nechme na někdy jindy, už takhle je tenhle článek příliš dlouhý), změny u některých starých (hlavně návrat <b> a <i> některé jistě zaskočí) a mnoho drobných zjednodušení, které nám umožní napsat rychle základy dokumentu a pak dlouze přemýšlet nad tím, jaká část má jaký sémantický význam. Autorovi článku se to takhle docela zamlouvá. Co vám?

Příště přijde řada na <audio> a hlavně <video>. Povíme si, o čem se vedou spory, jaká je podpora a ukážeme si možnosti, jak uživatelům prohlížečů podporujících <video> ukázat video v něm a zbytku přehrát video ve flashovém přehrávači.

(Skoro se stalo hezkou tradicí, že na závěr článku jsem vždy zmínil nějaké zajímavé odkazy k dalšímu studiu. Dneska žádné nemám, a tak doufám, že místo toho si vyzkoušíte napsat nějaký webík v HTML5. Pozn. aut.)

Komentáře

Subscribe
Upozornit na
guest
37 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Radek Hulán

„Tato nejistota by vás však neměla zastavit v testování a používání HTML5“ – proč? Nechci „prudit“, jen mě fakt zajímá, jaký může mít někdo důvod použít [ARTICLE] namísto [DIV class=„ARTICLE“], když to první podporuje minorita prohlížečů, stylování pro ostatní jen Javascriptem, na SEO to nemá vliv, a může se to změnit.
Psát o HTML5 je fajn, informačně, ale JAK to může být užitečné prakticky? Článek pořád říká že ano, osobně to ale nevidím.

Martin Michálek

Konkrétní srovnání article vs. div class="article" je samozřejmě argumentem pro HTML4 a divutvorný kód.

Nejde opravdu o konkrétní elementy, ale o celkové zjednodušení HTML kódu.

Mě osobně stačilo srovnat hlavičky:

HTML4:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
  "http://www.w3.org/TR/html4/strict.dtd">
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> 

HTML5:

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8"> 

Jsem jen člověk a ta druhá se mě čte lépe. Lépe se bude číst také kolegovi programátorovi, který se do šablony po mě bude dívat.

Ale zkuste si opravdu v HTML5 pár webů napsat. Dobře, ono je to teď úplně nejvíc pro early-adopters a milovníky hezkého kódu mezi kodéry, ale myslím, že už nyní můžou z používání nových HTML5 elementů profitovat všichni kódeři. Nové elementy HTML5 používám už nyní, protože dělají kód srozumitelnějším, a skutečně se netrápím tím jestli za rok ve specifikaci budou nebo ne. Vždyť webdesign je jedna velká změna.

Radek Hulán

„Nové elementy HTML5 používám už nyní, protože dělají kód srozumitelnějším“ – hlavička webu se nadefinuje v CMS, pokud tam bude o pár bajtů méně či více, je to irelevantní. Toto prostě není skutečný a významný přínos. Je to jako předchozí „úžasná“ změna z HTML na XHTML ;)
Zjevné negativum je nekompatibilita. [ARTICLE] se nedá 100% stylovat, [DIV class=„article“] ano. Abych to obešel, musím tam plácnout Javascript, takže to stejně nepoběží všude.
Já jsem rád za články o HTML5, protože ukazují, že je to jen přetření starého šedého kabátu na jiný odstín … šedé.

Martin Michálek

hlavička webu se nadefinuje v CMS, pokud tam bude o pár bajtů méně či více, je to irelevantní.

Samozřejmě, pokud máte kusy HTML4/XHTML nadefinované v nějakém chytrém CMS a s HTML jako programátor nepřicházíte do styku, docela dost vám věřím, že HTML5 vám nepřipadá až tak výhodné.

Myslím, že Honza Sládek to v článcích nikde nezmínil, ale zrovna pro tvůrce CMS má HTML5 výhodu v tom, že v jednotlivých sekcích dokumentu není potřeba myslet na to, zda použít nadpis H1, H2 nebo H3. Všechny sekce začínají znovu H1.

To myslím usnadní práci právě těm, kdo pracují jen s kousky HTML kódu.

To nové pojetí outline dokumentu je hodně důležité a ve srovnání s ním je problém article vs. div class="article" naprosto marginální.

Viz znovu ten Pilgrim: http://diveintohtml5.org/semantics.html#header-element

Autore článku, měl bys to zdůraznit v nějakém pokračování :-)

bauglir

Občas webdesigneři zapomínají, že i když není HTML programovací jazyk, přesto má teoretické základy, které se hodí, ty pak odlišují kodéra od „člověka, který umí napsat tag“.
Jinak čistě HTML5 weby s novými elementy už vznikají a je to dobře, bude to jenom další hřebíček do rakve některých nepřizpůsobivých uživatelů :)

Martin Malý

Já vím že tam byl na konci smajlík, ale někdo by ho tam vidět nemusel, takže rovnou připodotknu: Webdesignér není ten, kdo by měl určovat uživatelům, aby se přizpůsobili jeho oblíbené technologii, ale přesně naopak. (Ti inteligentnější to samosebou vědí a ctí, takže… jen aby to nezapadlo…)

bauglir

Ten smajlík nakonci není ironický, je vyjádřením radosti :). Samozřejmě, že webdesigner nesmí nutit uživatele a ani k tomu nemá prostředky. Dokonce ani zadavatel/maji­tel/ten kdo platí (není-li to zároveň webdesigner) nemá prostředky k tomu nutit uživatele něco používat, ale má právo se rozhodnout určitou část uživatelů odstřihnout, protože jejich browser prostě některé věci nepodporuje :)
Inteligenci bych do toho netahal, pokud někdo nechce investovat prostředky kvůli některým potenciálním návštěvníkům, nebo nechce omezovat funkčnost, nebo prostě jenom o takové návštěvníky nemá zájem, jeho volba…
Mám-li Vás parafrázovat, uživatel není ten, kdo by měl určovat majiteli, aby se přizpůsobil jeho podmínkám, není-li o takového uživatele zájem.
S inteligencí to nemá co dělat, je to svobodná volba a právo majitele :)

Martin Malý

Pokud tedy přijmeme model tří stran – majitel, webdesigner a uživatel, tak tím, kdo určuje použité technologie, je uživatel. Když uživatel nedokáže stránky otevřít, není to uživatel. Na majiteli je, aby se rozhodl, jaké uživatele na webu chce, a na webdesignérovi pak aby použil takové technologie, které ti uživatelé umí přijmout. Takže v důsledku je tím, kdo určuje, jakou technologii webdesignér použije, právě uživatel (o kterého majitel stojí). Byť to určuje nepřímo, svou volbou použitého prohlížeče a/nebo ochotou jej změnit.

bauglir

Není co dodat, rozhoduje majitel a v největší míře na základě rozhodnutí uživatelů. Jen mě tam zmátlo ono slovo „určovat“ :)

František Kučera

„To nové pojetí outline dokumentu je hodně důležité“
Souhlas. Ale proč je proboha potom tak odfláknuté? Vždyť stejně aby tomu novému pojetí někdo (prohlížeč, vyhledávač, editor…) rozuměl, musí být na nový formát upraven. Proto to šlo udělat rovnou pořádně a nedržet se starých elementů jako h1, h2 atd. – používat stejné názvy ale dávat jim jiný význam, v tom opravdu kompatibilitu nevidím, to je akorát bordel.
Proč se místo zmatených h1 nepoužívá něco jako tohle?

<section>
    <title>Nadpis</title>
    <para>odstavec</para>
    <para>další odstavec</para>
</section>

A místo:

<hgroup>
    <h1>HTML5</h1>
    <h2>aneb chaos v hlavách webdesignérů</h2>
</hgroup>

raději tohle:

<section>
    <title>Nadpis</title>
    <subtitle>Případný podnadpis</subtitle>
    <para>odstavec</para>
    <para>další odstavec</para>
</section>

Kde je jasná vazba – „kapitola má nadpis a podnadpis a odstavce“. Ne, že nadpis 1. úrovni a nadpis 2. úrovně jsou v jakési „skupině“ (co to je skupina nadpisů?), která se (možná náhodou, možná ne, to nikdo neví), nachází před nějakými odstavci. Možná uvnitř nějakého <article/>, ale to není jisté, nemusí to tak být. Všechna tahle volnost mi přijde na škodu a kontraproduktivní – obecně je volnost dobrá, ale když jde o nějaké exaktní věci jako jsou protokoly a formáty, platí, že čím víc volnosti, tím víc práce – někdo to musí implementovat, ošetřovat všechny možné případy, které někdo možná použije. V tomhle jsem zastáncem minimalismu – to neznamená, že by toho formát měl umět málo, ale že by měl být jednoduchý a nenabízet tisíc způsobů, jak to „něco“ napsat. XHTML je co do volnosti minimalistické a co do funkcí velice flexibilní – stejně jako se do něj přes jmenné prostory dají napojit SVG nebo MathML, dá se do něj dostat cokoli jiného. HTML5 přináší nějakou novou funkčnost oproti HTML4, ale hlavně je megalomanské co se týče volnosti a možností různých zápisů.

bauglir

Samo, že by to šlo udělat lépe, ale kouli 20 let za sebou táhneme, browsery musí být zpětně kompatibilní (resp. samozřejmě nemusí, ale který nebude, nebude používán), tudíž se vyšlo z evoluce, ne revoluce. Revoluci připravovalo W3C 10 let… vendory nezajímala, developery nezajímala… protože je nekompatibilní.
Nepřemýšlejte v intencích h1, h2… co tahle h1, h2 a h3 (napis, slogan, moto), co takhle h1 a p jako nadpis a hlavní myšlenku. Navíc tento element je nepovinný, není potřeba ho používat pro nadpisy. Všecha „háčka“ jsou ze sémantického hlediska stále důležitější než prostý odstavec, ale netvoří samostatný nadpis, ale jsou jeho částmi.
Neplatí žádné „možná ano, možná ne“, specifikace hovoří jasně http://dev.w3.org/html5/spec/sections.html#headings-and-sections. A samozřejmě že nejenom v elementu article, copak to je jediný element, který může mít napis?
Ano, XHTML umožňuje modularitu, ale pokud se vydáte za hranice SVG a MathML, můžete si další namespace strčit za klobouk, prohlížeče neví, co s nimi, jdou jen akademickou možností.
Megalomanské? Nevím, přečetl jsem celou specifikaci, je dlouhá jak týden před vejplatou, ale těch změn, které by byli nejasné tam zase tolik není :)

Jan Kodera

Přínos patrný nyní není, nicméně už se pomalu ukazuje co s tím. Ona totiž práce s textem bez těchto značek není žádný med a víceméně je to kodifikace toho co už vyhledávače dělají teď (Google a jeho kradení trafficu) tak aby to bylo možné použít i pro práci s textem. Co můžete dělat dnes? Žádný kancelářský balík nemá podporu pro práci se zdroji na netu. Maximálně copy paste. To je produktivita? HTML5 tohle může změnit, tedy bude se na co spolehnout. Od webdesignerů(nebo spíše od copywriterů) se bude jen chtít, aby se to naučili používat, protože jinak jejich stránky, texty nebudou použitelné.

František Kučera

Co se týče úspornosti kódu:
Tato XHTML stránka je validní a nepřijde mi nějak zbytečně ukecaná:

<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title>Jednoduchá stránka</title>
  </head>
  <body>
    <p>ahoj.</p>
  </body>
</html>

Dokonce se to dá i napsat z paměti :-)

tomaash

Možná jsem krapet natvrdlý, ale proč se z jinak inline tagu <a> stal těžkoříctcotoje (takže patrně inline-blokový) tag? Jaký má význam dávat do odkazu celý odstavec včetně nadpisu (potažmo za situace, kdy něco takového můžu udělat de facto již dnes)? Mohl by mi to prosím někdo vysvětlit?

Zbytek změn vnímám spíše k lepšímu, obzvláště pak rekodifikace významu <b>, <i>, <small> a podobných exotismů. Vypuštění type ze <script> s potleskem vítám, připadalo mi to jako archaismus v situaci, kdy je možné určit Content-Script-Type pro celý dokument (a dokonce je někde i vyžadováno).

Martin Michálek

Pes bude zakopaný ve větě „potažmo za situace, kdy něco takového můžu udělat de facto již dnes“.

S použitím HTML4 to přeci bez javascriptu udělat nelze. Můžete samozřejmě vytvořit nevalidní dokument, stejně jako můžete vařit jako pejsek a kočička. Osobně se ale snažím hledat dobrodružství mimo svět webových technlogií. :-)

Osobně vítám, že větší „proklikávací“ celky je možné takhle obalit. Tvůrci HTML5 v tomto sledují webdesignérskou praxi, což je dobře.

bauglir

Už jsem to psal v jednom komentáři u předchozího článku :), zapoměňte na inline a block elementy z hlediska HTML, HTML5 má jiné paradigma
http://www.w3.org/TR/html5/dom.html#content-models
doporučuji pročíst celou kapitolu 3.2.5

Martin Michálek

Pozor, vlastnost display s hodnotami inline/block je způsob jakým se element zobrazuje a specifikuje se pomocí CSS.

Typy obsahu pro elementy v HTML5, na které odkazujete, jsou něco jiného.

bauglir

Ano, ale to přesně vysvětluje moji pointu, HTML5 už nemá s inline a block nic společného, to je teď prostě a jenom otázka CSS, takže nejsme ve sporu, naopak děkuji za doplnění :)

juraj

Veľmi to poniektorí prežívate. Aj keby nebolo žiadne HTML5, myslím, že by sa nič také strašné nestalo. Ako čítam vaše komentáre – netreba žiadne HTML5, aby ste mohli písať <!doctype html>, aby ste nemuseli používať zbytočný atribút type na <script>e, aby ste mohli do odkazu vložiť <div>, aby ste mohli použiť atribút charset. Všetko to tu bolo dávno možné pred nejakým HTML5, stačilo nepridržiavať sa tých zle napísaných a starých špecifikácii.
Neviem, načo je komu nejaké hgroup (ale vážne, k čomu je tento element?), a tiež neviem, čo je také úžasné na article a podobných elementoch. Podpora týchto vecí je zatiaľ mizivá a písať #header miesto header do CSS nie je ťažké.
A okolo toho úžasného videa a audia je to fakt fail, keďže nikde nie je povedané, aké kodeky má prehliadač podporovať, a aha aký chaos je z toho.

bauglir

Jasně! na co novou specifikaci! Budeme psát jako prasata bez ohledu na validitu, vendoři budou rozvíjet nové možnosti webdevelopmentu jak se jim zlíbí, každej trošku jinak, každej něco jinýho… pryč se starými pořádky! svobodu! svobodu!
to už tu myslím bylo :)

juraj

Ale veď to sa aj deje :-) v prípade HTML5 sa o žiadnej validite hovoriť ani nedá. Čo funguje v prehliadačoch, o tom pochybujem, že bude nevalidné.
Je zaujímavé, ako niektorí „experti“ vychvaľovali do nebies XHTML, ako ich núti písať čistý a pekný kód, a zrazu nikto nemá problém používať HTML5, ktoré, čo sa týka syntaxe, sa pridržiava všetkého, čo funguje.
Za posledných niekoľko rokov sa ukázalo, že čo má možno nejakú budúcnosť alebo je pre kóderov užitočné, sa dá implementovať aj bez špecifikácii, či už hovoríme o relatívne veľkých veciach ako canvas, alebo drobnostiach ako <input autocomplete>, niektoré fajn propertiálne vychytávky z JS v Exploreri, atď. A niektoré veci si vendori rozvíjajú bez ohľadu na ostatný svet, Firefox XUL, Explorer ActiveX… presne ako v tvojom katastrofickom scenári.

bauglir

Ale prosím Vás, ta první věta ani nedává smysl :). Je-li HTML5 „specifikací“, potom se o validitě samozřejmě hovořit dá, buď to splňuje sémantické předpoklady HTML5 a potom to je validní, nebo nesplňuje a potom to není validní (ale to ještě neznamená, že to je konformní z hlediska sémantiky, ale ta se testovat nedá). A co se druhé části věty týče tak teď nevím, to skoro vypadá, jako byste snad ani weby nedělal :). Naprostá většina stránek na internetu je nevalidních :). Naštěstí/bohužel (záleží na úhlu pohledu) si s tím prohlížeče poradí.
Co se XHTML týče, k těmto expertům nepatřím, XHTML oproti HTML přináší pouhopouhé 3 výhody: SVG, MathML a pro programátora jednodušší parsování (víc namespaců není široce podporováných a existuje více profi XML parserů, než HTML profi parserů, i když napsat vlastní HTML parser je jednodušší). To je jen ohledně té adorace XHTML (neuvěřitelná propaganda :)). Ale kdybyste se do té specifikace podíval, tak zjistíte, že pod názvem HTML5 se skrývá popis struktury, kterou lze serializovat pomocí HTML a XHTML, tzn. kdo chce používat XHTML a HTML5 technologie, tak může a vše bude validní. Mimochodem, i když to tu vypadá, že adoruji HTML5, tak věřte tomu, že si dokáži představit mnohem lepší markup, ale zpětná kompatibilita je prostě problém a tohle vypadá, jako krok kupředu.
Ano, samozřejmě, že spousta technologii se dá implementovat bez specifikace, určitě netvrdím, že prohlížeče nesmí mít proprietární technologii, ale pokud mají nějakou společnou, měla by fungovat všude stejně. Tak, aby v případě, že dělá developer web pro veřejnost se měl o co opřít a mohl předpokládat, že technologie bude fungovat cross-browser. A ano v případě, že předpokládám homogenní prostředí (např. firemní intranet), můžou mi specifikace vlézt na záda, opřu se o runtime enviroment (rendering engine).

Makovec

„pro programátora jednodušší parsování“
tahle pouha jedina vec by za to bohate stala… bohuzel se mnoho webdesigneru stale domniva ze standard je tu pro ne na proto aby se ho drzeli, ale aby jim vychazel vstric, a browsery jsou neco jako prirodni jevy. Co jineho se proboha s html na strane klienta dela nez ze se nejdriv naparsuje? Kdyby se ty desetitisice programatoru atd. co se snazi z te html pismenkove polivky vydojit nejakou informaci zpracovatelnou jinak nez metodou „kouknu a vidim, ne?“ mohly zabyvat vyvojem nejakych sluzeb na tech infomacich zalozenych byli bychom o poradny kus dal.

bauglir

Ano, máte pravdu, svět by byl jednodušší, kdyby všichni psali vadně a prohlížeče byli drakonické v tomto směru, také bych se za to přimlouval. Je pravda, že (X)HTML je takový prazvláštní jazyk, na jednu stranu prostý markup, na druhou stranu sémanticky popsaná datová struktura. Parsery jsou.
Jenže na revoluci narazilo XHTML2. Zkuste si představit, že by se udělal nekompatibilní jazyk nebo by prohlížeče byli drakonické i k HTML a vedle toho si postavte současný internet… Nehoňme bycha, věci jsou, jaké jsou, (X)HTML bude těžko jiné. Já za sebe jsem rád, že se HTML specifikuje více do hloubky, dopodrobna, že se vytvářejí nové elementy, které mají smysl (v globále) a že přichází aplikační API.

František Kučera

To má řešení – jádro prohlížeče bude umět vykreslovat pouze validní XHTML a pokud uživatel bude chtít zobrazit nějakou zmršenou stránku, prožene ji to nejdřív nějakým filtrem, který z toho hnoje vyrobí validní XHTML – něco jako HTML Tidy. Prohlížeče budou jednoduché a ten filtr může být nějaká knihovna, jejíž kód mezi sebou klidně bude sdílet víc prohlížečů. Nové funkce pak stačí přidávat do nových striktních formátů, není potřeba se moc ohlížet na zpětnou kompatibilitu a přesto staré (nebo zmršené) stránky půjde pořád prohlížet.

bauglir

Na první pohled to není špatný nápad, ale co bychom tím získali? Ok, byla by možná reformulace některých elementů. I když zrovna v případě nadpisů, které jsou zmíněny výše si to nemyslím. Obecně by mě zajímalo, co vylepšit, kromě přejmenování některých elementů? Ale to je tak všechno. Ke zjednodušení specifikace by to nevedlo, ta se nevalidnímu zápisu moc nevěnuje a ke zlepšení kvality webů také ne, prasata by stále psala jako prasata… protože filtry :)
Ano, dokáži si představit lepší markup, ale jako teorii, nestálo by prakticky za to zahodit (X)HTML.
A nakonec, historie (X)HTML je i historii zahazování některých koncepcí a elementů, ale kvůli zpětné kompatibilitě existují takové „filtry“ v prohlížečích, a díky tomu je někteří „webdesigneři“ používají znova a znova dokola. Specifikace se čistí a zpřehledňuje, web zůstává zprasen.

František Kučera

V první řadě by mohly existovat odlehčené prohlížeče (jednoduché, relativně málo kódu, menší nároky), které by zobrazovaly jen moderní – správně napsané – stránky. Na desktopu by se stejně asi dál používaly těžkopádnější prohlížeče se zapnutým filtrem, ale byla by to volba uživatele (mohl by klidně používat odlehčený prohlížeč s tím, že se mu některé stránky nezobrazí*).
Nejde jen o specifikaci ve smyslu podporovaných funkcí, ale i o specifikaci formátu – je dost velký rozdíl, jestli stačí umět parsovat XML (XHTML) nebo je potřeba umět parsovat HTML s velkou variabilitou, možností jednu věc zapsat několika způsoby atd.
S vymřením starých zprasených webů (až/pokud jednou přijde) by bylo daleko snadnější odstřihnout ten zbytečný kód v prohlížečích – prostě by se ten filtr vypnul.
A v neposlední řadě by bylo vidět, kolik kódu v prohlížeči dělá něco skutečně užitečného, přináší funkcionalitu – a kolik kódu je tam jen kvůli napravování chyb po „prasatech“. Třeba by to někoho trklo.
*) např. pokud by to byl terminál, tenký klient, k firemnímu intranetu resp. k nějakému uzavřenému okruhu aplikací, tak to není vůbec problém – stačí jednoduchý prohlížeč a odpadne spousta kódu, který je v dnešních prohlížečích jen kvůli „legacy“ webům.

bauglir

Přání otcem myšlenky :)
1/ Nic teď nebrání tomu, aby vznikali odlehčené prohlížeče podporující pouze standart a nejsou proto, protože nejsou zákazníci (uživatelé, kteří by prohlíželi pouze validní stránky). Ano, odpadl by kód v prohlížečích, prohlížeč by neměl 12M, ale 11M, startoval o 30ms rychleji a renderoval o 50ms rycheji…
Máme tu 2 velmi kvalitní otevřená jádra, už hotové produkty, které by stačilo pročistit, a ani to nestačí k tomu, aby takové prohlížeče vznikli.
2/ mezi parsováním XML a validací XHTML je rozdíl, můžete mít XML dokument obsahující pouze elementy z XHTML prostoru a validní atributy u těch elementů, kam patří a stejně to nemusí být XHTML validní dokument. Specifikace vyžaduje konstrukce, které nelze vyřešit jinak, než jenom výčtovým řešením (XML ani DTD neumí popsat specifikované XHTML, prostě to nestačí). A co se týče parsování HTML s velkou variabilitou… Těch variabilních věcí je zoufale málo v objemu toho, co byste musel implementovat (neobhajuju HTML, i když používám HTML serializaci HTML5, tak zapisuji elementy i atributy XHTML způsobem :), vystačil bych si jenom s XHTML, jen se bráním nepochopení toho, co je v HTML možné, co ne (i když je otázka, co jste myslel tou velkou variabilitou, nechci Vás obviňovat z neznalosti, toho jsem dalek, jen mě se zdá variabilita dost titěrná))
3/ pokud by ty filtry byli, k vyměření nevalidních dokumentů nedojde… Vždyť k tomu by nic nemotivovalo…
4/ a bod, který jste uvedl „v neposlední řadě“, tak věřte, že to je v poslední řadě :), neexistuje důvod, který by nutil pro www stránky používat nevalidní kód, přesto ho používá kde kdo… a skutečně si myslíte, že by si někdo řekl „jee kdybych nepsal nevalidně, třeba by byl prohlížeč o 2% výkonnější“? Opět, co tomu brání teď?

peter

Keby tvorcovia programovacich jazykov, ich interpretrov a kompilatorov mysleli ako tvorcovia html5 (ako popuisujete), dodnes by neexistoval pouzitelny programovaci jazyk.
Zachovat spatnu kompatibilitu v prehliadaci pre vsetky varianty starych HTML a aj nevelidnych, jednoducho nie je mozne.
HTML musi by presne specifikovane validovatelne a pri procesingu ak nastane syntakticka alebo semanticka chyba nesmie by prezentovane.
Bud vidim presnu informaciu zapisanu korektne vo formate HTML (danej verzie podla konkretnej specifikacie) so 100% istotou, alebo v opacnom pripade nechcem vidiet nic!
Nezaujima ma co si prehliadac do stranky domysli. Moze to niekoho stat zivot!

bauglir

Vizte níže, tam jsem myslím odpověděl.

František Kučera

„Nezaujima ma co si prehliadac do stranky domysli. Moze to niekoho stat zivot!“
Zrovna na webu je ten poměr mezi robustností a přesností nakloněný spíš k té robustnosti – zobrazit stránku třeba i rozbitou (vizuálně), ale zobrazit ji vždycky. S tím celkem souhlasím, jen bych rád, kdyby se jasně oddělily dvě věci: 1) oprava špatných stránek, tzn. to domýšlení si a věštění, jak to vlastně autor myslel a 2) vlastní vykreslování – už exaktní, na základě striktního formátu, 100% validní, bez jakéhokoli domýšlení a nepřesností. U dobře napsaných webů ta 1) odpadne a přejde se rovnou 2). U špatně napsaných se ta 1) provést musí, to je daň za to, že chceme zobrazit i špatně napsané stránky. Ale je dobré 1) a 2) oddělit.

peter

Ano, mas pravdu.
Ale pokial prehliadac prechadza do rezimu domyslania, vestenia a nepresnodti nech to razne oznamy a necha si to potvrdit od pouzivatela.
Chcem predsa vediet, ze stranku pisalo prasa a podla toho sa k informaciam na sprasenej stranke budem stavat.
Web vyvojari budu prasata, pokial im to prehliadace budu tolerovat.

bauglir

Zkusím to celé napsat jinak. Kdybych si uměl představit realizaci, byl bych pro. Kromě webu dělám i desktopové aplikace a kompilery neodpouštějí :). Neměl bych nic pro draconic handeling markupu, css a zpřísnění syntaxe JS. Klidně i zahodit HTML a používat pouze XHTML serializaci, vytvořit novou, klidně i nekompatibilní verzi, která by vedla k přehlednějšímu jazyku. Dokáži si to představit, protože právě v kompilovaných jazycích se tak děje, tam to jde, pouštíte binárku, je buřt v jaké verzi jazyka to napíšete, kompilátor se postará, ale v případě takto rozšířené a interpretované technologie si to nedokážu představit :(

ic

… Se dají (aktuálně) v javascriptu použít pouze v kombinaci s atributem src, tedy jen na scripty v externích souborech. Možná by se hodilo tohle doplnit. Pokud si pamatuji tak se mluvilo o tom že i scripty v těle budou vytrženy z kontextu stránky (stejně jako by byly v hlavičce) pak by měl smysl atribut defer ale asi to tak v html5 není.

frankiex

Může mi někdo vysvětlit, v čem konkrétně je výhodný tento druh sémantiky? Můj subjektivní pocit z toho je ten, že webdesignéři jásají z toho, že budou mít hezký kód, ale přece to musí mít reálný základ. Pro vyhledávače to podle mě nemá až tak velký význam, protože je mnohem důležitější pro ty algoritmy propojení komplexnosti celé sítě a ne to, že má stránka patičku a hlavičku. Pro ty algotitmy to až takové zlepšení není, to si odvodí i bez toho. A na závěr – v čem je to lepší než mikroformáty? I v tom příkladu v článku je vidět, že sémanticky to popisují mnohem výrazněji.

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.