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

Zdroják » Webdesign » Vyhněte se nejobvyklejším chybám v HTML5

Vyhněte se nejobvyklejším chybám v HTML5

Články Webdesign

HTML5 je nový standard, a ačkoli vychází z toho, co už všichni webdesignéři a kodéři dobře znají, tak jeho novinky, zejména tzv. „sémantické“ tagy, nemusí být vždy a za všech okolností jasně srozumitelné. V článku si ukážeme nejčastější situace, kde se právě při práci s těmito elementy nejčastěji chybuje.

Tento článek napsal pro web HTML5Doctor  Richard Clark. Richard je Head of Interactive v KMP Digitata, Manchester, UK. Můžete jej sledovat na twitteru nebo na jeho  osobní stránce.

Originál článku vyšel na webu HTML5Doctor pod licencí CC-BY-NC.

Během hodnocení stránek pro HTML5 gallery a odpovídání na dotazy čtenářů na HTML5 Doctor jsem viděl spoustu stránek v HTML5 a jejich kódů. V tomto článku si ukážeme některé chyby a zlozvyky, které se často opakují, a vysvětlíme si, jak se jim vyhnout.

Nepoužívejte section jako obalový element pro stylování

Jedním z nejobvyklejších problémů, které ve stránkách v HTML5 vídáme, je mechanické nahrazování  <div> ů elementem pro vyznačování sekcí — konkrétně nahrazení obalových <div> ů (použitých při stylování) elementem <section>. V XHTML nebo HTML4 se běžně používá konstrukce:

<!-- HTML 4-style code --><div id="wrapper">
  <div id="header">  
    <h1>My super duper page</h1>
    <!-- Header content -->
  </div>
  <div id="main">
    <!-- Page content -->
  </div>
  <div id="secondary">
    <!-- Secondary content -->
  </div>
  <div id="footer">
    <!-- Footer content -->
  </div>
</div>

Místo ní nyní vídáme toto:

<!-- Tento kód nepoužívejte! Je špatně! -->
<section id="wrapper">
  <header>  
    <h1>My super duper page</h1>
    <!-- Header content -->
  </header>
  <section id="main">
    <!-- Page content -->
  </section>
  <section id="secondary">
    <!-- Secondary content -->
  </section>
  <footer>
    <!-- Footer content -->
  </footer>
</section>

Na rovinu – je to prostě špatně:<section> není obalový element. Element <section> označuje sémantický oddíl v obsahu, čímž pomáhá vytvořit document outline. Sekce může obsahovat nadpis. Pokud hledáte obalový element pro celou stránku (v HTML, HTML5 či XHTML), zvažte nastylování elementu <body>, jak popisuje Kroc Camen. Pokud potřebujete nějaký obalový element kvůli stylování, použijte <div>, který nenese sémantickou informaci. Jak vysvětluje Dr Mike, DIV není mrtvý, a pokud nemáte nic, co by bylo sémanticky vhodnější, je to stále dobrý způsob, jak aplikovat stylování.

Pokud si toto uvědomíme, dokážeme vytvořit správný kód pro předchozí příklad, včetně některých atributů ARIA. (Poznámka: možná budete potřebovat nějaký <div> navíc, podle použitého designu.)

<body>
  <header>  
    <h1>My super duper page</h1>
    <!-- Header content -->
  </header>
  <div role="main">
    <!-- Page content -->
  </div>
  <aside role="complementary">
    <!-- Secondary content -->
  </aside>
  <footer>
    <!-- Footer content -->
  </footer>
</body>

Pokud si nejste jisti, jaký element použít, odkazuji vás na HTML5 sectioning content element flowchart.

Používejte header a hgroup jen pokud jsou potřeba

Psaní tagů tam, kde nemusí žádné být, nedává smysl, že? Naneštěstí stále vídám <header> a <hgroup> v situacích, kde nemají žádné opodstatnění. Podrobnosti o jejich použití naleznete v článcích the <header> element a the <hgroup> element, ale zde si pravidla stručně shrneme:

  • Element <header> reprezentuje skupinu úvodních nebo navigačních prvků a obvykle obsahuje titulek sekce
  • Element <hgroup> seskupuje nadpisy <h1><h6> v situacích, kdy nadpis sekce má více úrovní, jako např. podtitulek, alternativní titulek nebo řádek s tagy.

Nadužívání header

Pravděpodobně víte, že element <header> může být použit v dokumentu několikrát – což přineslo populární vzor:

<!-- Nepoužívejte tento kód! Header je tu nadbytečný -->
<article>
  <header>  
    <h1>My best blog post</h1>
  </header>
  <!-- Article content -->
</article>

Pokud váš <header> obsahuje jen jediný nadpis, tak <header> vypusťte. Element <article> zajistí, že titulek bude zahrnut do struktury dokumentu, a protože <header> neobsahuje v tomto případě víc prvků (jak je popsáno v dokumentaci), tak není důvod psát kód, který je nepotřebný. Prostě napište toto:

<article>  
  <h1>My best blog post</h1>
  <!-- Article content -->
</article>

Nesprávné použití <hgroup>

Když je řeč o nadpisech, je na místě zmínit další častou chybu – nesprávné použití <hgroup>. Neměli bychom používat <hgroup> ve spojení s <header>, když:

  • obsahuje jediný nadpis, nebo
  • element <hgroup> bude fungovat i samostatně (tedy bez  <header> u).

První problém vypadá takto:

<!-- Nepoužívejte tento kód! Hgroup je tu nadbytečný -->
<header>
  <hgroup>  
    <h1>My best blog post</h1>
  </hgroup>
  <p>by Rich Clark</p>
</header>

V tomto případě odstraňte <hgroup> a nechte titulek samostatně.

<header>
  <h1>My best blog post</h1>
  <p>by Rich Clark</p>
</header>

Druhý problém je příkladem použití elementů, které nejsou nezbytné.

<!-- Nepoužívejte tento kód! Header je tu nadbytečný -->
<header>
  <hgroup>  
    <h1>My company</h1>
    <h2>Established 1893</h2>
  </hgroup>
</header>

Když jediným potomkem elementu <header> je <hgroup>, tak k čemu je <header>? Pokud v něm nejsou další dodatečné elementy („sourozenci“ <hgroup>), tak <header> vyhoďte.

<hgroup>  
  <h1>My company</h1>
  <h2>Established 1893</h2>
</hgroup>

Další příklady použití <hgroup> najdete v článcích o HGROUP na HTML5Doctor.

Nebalte každý seznam odkazů do <nav>

V HTML5 bylo představeno 30 nových elementů (stav v době psaní článku), což je množství, které může člověka zmást a ztížit výběr toho správného elementu pro určitou situaci. Jinými slovy – neměli bychom těmito super-sémantickými elementy plýtvat. Bohužel přesně to se často stává s elementem  <nav>. Specifikace o elementu <nav>  říká:

Element nav reprezentuje oblast stránky, která odkazuje na jiné stránky či části aktuální stránky, tedy sekci s navigačními odkazy.

Poznámka: Ne každá skupina odkazů na stránce musí být v elementu nav — tento element je primárně určen pro oddíly, které obsahují hlavní navigační bloky. Konkrétně bývá např. běžné, že patičky obsahují odkazy na různé stránky jednoho webu, jako jsou pravidla použití, domovská stránka nebo stránka s copyrightem. Pro takové případy je plně dostačující element footer; když je v takové situaci použitý nav, je nadbytečný.

WHATWG HTML spec

Klíčové slovo je ‘hlavní’ navigace. Můžeme celé dny diskutovat o tom, co je to ‘hlavní’, ale podle mého názoru to znamená:

  • Primární navigace
  • Prohledávání webu
  • Sekundární navigace (sporné)
  • In-page navigace (např. v dlouhých článcích)

Ačkoli není jednoznačně řečeno, co je dobře a co špatně, tak mi cit říká, že následující bloky by neměly být v  <nav>:

  • Stránkování
  • Odkazy na sociální sítě (i když mohou existovat výjimky, například stránky jako About me nebo Flavours)
  • Tagy u blogpostu
  • Kategorie u blogpostu
  • Terciární navigace
  • „Reklamní odkazy“ v patičce

Pokud si nejste jisti, kde <nav> použít, zeptejte se sami sebe: Je to hlavní navigace? Následující tipy mohou pomoci:

  • Nepoužívejte <nav> tam, kde si myslíte, že <section> s nějakým <hx> postačí  — Hixie on IRC
  • Dali byste odkaz na to do bloku „Přeskočit na…“ pro zlepšení přístupnosti?

Pokud je odpověď NE, pak odkaz pravděpodobně nepatří do  <nav>.

Běžné chyby u elementu figure

Ach, <figure>. Správné použití tohoto elementu, spolu s jeho spolupachatelem <figcaption>, je někdy obtížné i pro mistry. Pojďme se podívat na několik běžných problémů s  <figure>.

Ne každý obrázek je ilustrace (figure)

Výše jsem radil, abyste nepsali kód, který je nadbytečný. Tato chyba je podobná. Viděl jsem i weby, kde byl každý obrázek označen jako <figure>. Přitom není žádný důvod balit všechny obrázky do dalšího elementu, jen si tím přiděláváme práci a nepřidáváme k obsahu žádnou užitečnou informaci.

Specifikace popisuje <figure> jako obsah, volitelně s nadpisem, který je samostatný a je z hlavního textu odkazován jako jediná jednotka. V tom je krása elementu <figure>. Může být přesunut z primárního obsahu — například do postranního bloku — aniž by to narušilo tok dokumentu.

Pokud to je čistě ilustrační obrázek, který není v textu zmíněn, tak to rozhodně není <figure>. Případy použití se mohou lišit – pro začátek se zeptejte sami sebe: Je ten obrázek nezbytný k pochopení vlastního textu? Pokud ne, tak pravděpodobně nejde o <figure> (možná je to do <aside>). Pokud ano, zeptejte se znovu: Mohl bych to přesunout do Dodatků? Pokud jsou odpovědi na obě otázky ANO, pak jde pravděpodobně o  <figure>.

Vaše logo není ilustrace (figure)

Totéž co výše platí i pro vaše logo. Zde je pár ukázek toho, co lze v kódu někdy nalézt:

<!-- Tento kód nepoužívejte! Je špatně! -->
<header>
  <h1>
    <figure>
      <img src="/img/mylogo.png" alt="My company"class="hide" />
    </figure>
    My company name
  </h1>
</header>
<!-- Tento kód nepoužívejte! Je špatně! -->
<header>  
  <figure>
    <img src="/img/mylogo.png" alt="My company" />
  </figure>
</header>

K tomu není co dodat. Je to prostě špatně. Můžeme se dohadovat až do úpadu o tom, jestli by logo mělo být v <h1>, ale to není důvod, kvůli kterému si tento příklad ukazujeme. Opravdový problém je zneužití elementu <figure>. Element <figure> by měl být použit pouze tehdy, když je zmiňován v textu nebo v okolních elementech. Myslím, že lze tvrdit že firemní logo bývá jen málokdy zmíněno v obsahu stránky. Prostě a jednoduše – nedělejte to. Místo toho použijte:

<header>  
  <h1>My company name</h1>
  <!-- More stuff in here -->
</header>

Figure nemusí být jen obrázek

Další častý omyl a nepochopení smyslu <figure> je přesvědčení, že může být použit pouze pro obrázky. To není pravda, <figure> může být video, audio, graf (třeba pomocí SVG), citace, tabulka, ukázkový kód, ukázka z knihy, tohle všechno dohromady nebo cokoli jiného, co ilustruje obsah. Neomezujte se s <figure>  pouze na obrázky. Naší prací je popsat co nejpřesněji obsah pomocí k tomu určených značek.

Před časem jsem popisoval <figure> do hloubky.

Neuvádějte nepotřebné atributy

Toto je pravděpodobně nejčastější problém, který se v HTML5 vyskytuje. Ačkoli nejde o vyslovenou chybu, tak bude nejlépe se podobným konstrukcím vyhnout.

V HTML5 není zapotřebí uvádět atribut type u elementů <script> a <style>. Může být leckdy obtížné se těchto atributů zbavit, obzvlášť když je generuje CMS, ale není žádný důvod, proč je nechávat v ručně kódovaných stránkách. Protože všechny prohlížeče očekávají, že skript bude JavaScript a styl CSS, tak takovéhle konstrukce nejsou potřeba:

<!-- tento kód nepoužívejte, není dobře -->
<link type="text/css" rel="stylesheet"href="css/styles.css" />
<script type="text/javascript" src="js/scripts.js"></script>

Místo toho použijte prosté:

<link rel="stylesheet" href="css/styles.css" />
<script src="js/scripts.js"></script>

Nesprávné použití atributů u formulářů

Asi víte, že HTML5 přineslo mnoho nových atributů u formulářů. Jejich podrobnější popis naleznete jinde (např. v článku na Zdrojáku – pozn. překl.), zde si ukážeme, čemu se vyhnout.

Booleovské atributy

Booleovské atributy existují i u multimediálních elementů a dalších, nejen u formulářů. Pravidla ale platí i pro ostatní booleovské atributy u jiných elementů.

Booleovské atributy mají tu vlastnost, že jejich uvedení v kódu znamená, že jsou „zapnuté“ („on“, „true“, „yes“…) Příklady takových atributů:

  • autofocus
  • autocomplete
  • required

Po pravdě jsem špatné použití v tomto případě viděl málokdy, ale např. u  required jsem nalezl:

<!-- Tento kód je špatně -->
<input type="email" name="email" required="true" />
<!-- a tento taky -->
<input type="email" name="email" required="1" />

Ve skutečnosti takováto chyba nezpůsobí žádnou škodu. Prohlížeč vidí atribut required v kódu, takže funkce je zapnutá. Ale co když chceme zapsat opak, tedy funkci „vypnout“, a napíšeme  required="false"?

<!-- Tento kód je taky špatně -->
<input type="email" name="email" required="false" />

Parser vidí atribut required a považuje jej za zapnutý, ačkoli se snažíme říct, že má být vypnutý. Tedy něco, co jsme nechtěli.

Existují tři platné způsoby, jak v HTML říct, že booleovský atribut má být použitý. (Druhá a třetí možnost je určena pro zápis v syntaxi XHTML.)

  • required
  • required=""
  • required="required"

V příkladu výše bychom tedy napsali (v HTML):

<input type="email" name="email" required />

Shrnutí

Je nemožné vypsat všechny podivné zvyky a konstrukce, které se ve stránkách v HTML5 objevují – výše uvedené jsou pouze ty, co se objevují nejčastěji. Znáte také takové příklady, které jste zahlédli na webu? Které části HTML5 potřebují ujasnit? Svěřte se v komentářích.

Poděkování: Ian Devlin, Derek Johnson, Tady Walsh, kurátor HTML5 Gallery a lidé z HTML5 Doctor za materiál k článku.

Komentáře

Subscribe
Upozornit na
guest
69 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
asdasd

Některé novinky v HTML5 se mi líbí, ale mít padesát jednoúčelových tagů pro každou kokotinu mezi ně určitě nepatří.

Nox

Přijde mi, že celé HTML5 je poměrně orientované na praktické použití a spousta z tagů má odpodstatnění… a jejich přítomnost ničemu neuškodí, není nutné je používat

Bubák

Obalovači stejně jen zmodernizují své osvědčené XHTML konstrukce za HTML5:

<div id ="menu">
  <div id="leftmenu">
    <ul class="menu">
      <li>....</li>
      <li>....</li>
    </ul>
  </div>
</div>

Akorát teď tam začnou prát moderní SECTION a NAV.

Díky za článek.

johan

Jo, článek dobrej. A HTML5? Ještě jsem na něj nepřešel, takže v něm chyby nedělám :-) Čekám, až se trochu „usadí“…

jiri.pudil

Staré a nemoderní tagy B a I se v HTML5 vrací s novým sémantickým významem a význam u EM se posouvá (http://html5doctor.com/i-b-em-strong-element/). Řekl bych, že v tomhle se taky bude často chybovat.

Jakub Vrána

Slovo „vrací“ není úplně přesné, protože <b> ani <i> nikdy zastaralé nebyly.

Martin Soušek

K čemu ty nové tagy vůbec jsou, když pořádně nikdo netuší, kde se mohou a kde nemohou použít?

Výsledek? Devadesát procent lidí je bude používat špatně a deset procent dobře (optimistický odhad). Jaký to potom bude mít přínos oproti nánosu DIVů?

Rdm

A je snad chyba těch tagů, že s nimi hromada rádobykodérů neumí zacházet?

Jiří Šoman

Ano máte pravdu = k ničemu.

Ovšem předpokládá se, že kodéři jsou odborníci v tom co dělají. A jako odborníci by měli věci rozumět, nemyslíte? V takovém případě bude vše OK.

stope32

Když u elementů <script> a <link> odstraníte atribut Type, projde vám taková stránka validátorem? Mně ne…

<section id=“wrapper“> může být špatně, ale ostatní užití toho tagu bude v pořádku, pokud např. v <section id=“main“> budou už jen nadpis a paragrafy? Vaše informace je pak poněkud zavádějící.

Jaký jiný, než sémantický, význam má <nav>, pokud jsou odkazy v menu stejně baleny do seznamu

    Rdm

    tak pokud ji posíláte s DOCTYPE XHTML, tak se nedivte, že vám ji validátor nesežere…

    stope32

    To bych byl asi trochu debil, ne? Předpokládejme určitou úroveň inteligence =)

    Jiří Šoman

    Potom je to tedy dosti divné. Stránka samozřejmě validátorem projde.

    j

    Odstranovat type je samozrejme pitomost, nebot script muze byt i jiny nez javascript, stejne tak stylovani nemusi byt jenom CSS a je slusnost uvest o co jde. Ze tomu nekdo nerozumi, nebo netusi ze se pouzivaji i jiny veci a ze prohlizec to prevazne skousne neznamena, ze to tak je dobre.

    BTW: v tom clanku me nejvic pobavilo zhruba toto:

    V příkladu výše bychom tedy napsali (v HTML):
    <input type=“email“ name=“email“ required />

    Coz je samozrejme chyba jako svin, nebot /> v HTML neni definovano a byt to tam nesmi, naopak to tam byt musi pro Xhtml.

    bauglir

    K poslednímu odstavci:
    1/ protože seznam říká pouze, že se jedná o seznam, neříká, že se jedná o menu
    2/ protože v elementu nav nemusí být pouze seznam… element říká, že se jedná o menu, neříká, že v něm musí být seznam.

    Jiří Šoman

    Je mi trochu smutno, když pročítám diskusi, která zde pod článkem vzniká. Článek má za cíl donutit ty, kteří opravdu použivají většinu elementů špatně k zamyšlení nad významem daného elementu a jeho správného použití.

    Pro ty co nevědí k čemu ty elementy vlastně jsou (použití je věc druhá) doporučuji prostudovat specifikace, nebo seriál o HTML 5 zde na lupě.

    Přidám zde informaci k zamyšlení:
    Nové elementy v HTML 5 vznikly hlavně pro zjednodušení a upřesnění struktury dokumentu. Nás jako normální zdravé lidi to asi nějak nevytrhne, web uvidíme tak i tak pořád stejně – nicméně i pro nás je to výhoda. Ale nastává otázka co lidé s různým postižením (zrak, sluch a podobně). Ano jednotná struktura (konečně) umožní různým načítačům, braillským řádkům a podobným zařízením lépe pochopit strukturu (a stím i obsah) daného webu případně aplikace. Nehledě na různé vychytávky v browserech, které díky těmto elementům mohou poznat co je na webu hlavní obsah, který nadpis patří k tomu a tomu textu atd.

    Lidi, proboha přemýšlejte…

    asdasd

    Což o to, já se s tím srovnám celkem v pohodě, navíc z 90% nedělám obsahové weby. Ale je mi docela líto začátečníků, těm se z toho asi pěkně protočí panenky. U spousty webů to taky nakonec může mít přesně opačný dopad, než bylo původně zamýšleno.

    Jiří Šoman

    Souhlas. Začátečníci to nebudou mít lehké, ale jak je vidět ani pokročilý si s tím v mnoha případech nevědí rady. Bohužel (konečně) už kodéři nemohou jenom slepě bušit kód jako cvičené opice, ale musejí u toho i přemýšlet…

    Aleš Roubíček

    Aha, oni doteď nemuseli? :)

    Jiří Šoman

    Myslím to tak, že nemuseli přemýšlet na významem… Prakticky jenom u pár elementů. Ve většině případů převažoval div, span atd. Teď už musíš tušit čemu chceš dát jakej význam, jinak to budeš dělat špatně jako ti kterých se týká tento článek.

    TomasZmek

    Trosku to odhlecim. Pred nekolika miliony lety nas predek nemusel premyslet nad vyznamem jednolitvych slov a skladani vet. Stacilo mu neco jako „agrr, huhuhu, ehehehe“ a podobně a dokázal se s ostatními domluvit. A pak nějaký ňouma vymyslel jazyk, strukturu věty a slovosled a šlo to do hajzlu. Museli jsme začít přemýšlet nad významem slov a jejich správné používání. Vedlejší efekt jsou úžasná psaná díla a to, že Člověk je tak nějak na jiné úrovni, než opice.

    Nox

    Je ovšem otázka nakolik se začátečník vůbec s těmito tagy setká, myslim že toto nijak horké nebude protože než vůbec proniknout k většímu množství začátečníků, bude to více podchycené a vychytané

    Petr

    To je for ne: „doporučuji prostudovat specifikace, nebo seriál o HTML 5 zde na lupě“? Zde: http://zdrojak.root.cz/clanky/webdesigneruv-pruvodce-po-html5-nova-semantika/

    <article> <header> <h1>Webdesignérův průvodce HTML5</h1> </header>

    Chytrý článek o tom, jak začít používat HTML5.

    <aside> <dl> <dt>HTML5</dt> <dd>značkovací jazyk, nástupce HTML 4</dd> </dl> </aside> </article>

    je vidět vúuka, kterou vy v článku kritizujete. Co si má tedy čtenář vybrat?

    j

    Potiz je, ze vetsina masticu nevyuziva ani ty nastroje ktery ma. Uz sem videl i „profesionalni“ weby, kde nebyly jiny tagy nez div. Kupodivu vetsina amateru umi stvorit daleko semanticky kvalitnejsi web nez spousta firem za velky prachy.

    John

    Nebo nemusíte programovat, stačí někomu říct ať udělá stránky zdarma za Vás.
    http://www.zadnefronty.cz

    František Kučera

    Když tak strašně vadí „zbytečné“ atributy, je škoda, že soudruzi nezařídili, aby se místo

    <script src="js/scripts.js"></script>

    psalo:

    <script src="js/scripts.js"/>
    asdasd

    To taky moc nechápu :-). Stejně tak nechápu, proč musí být u tagu <link> uveden atribut rel, pokud je z přípony jasné, že jde o styly – stejně ho k ničemu jinému než ke vkládaní stylů v podstatě nikdo nepoužívá.

    František Kučera

    Ten <link/> se používá k víc věcem (třeba RSS/Atom). Řídit se příponou je blbost – ta tam třeba nemusí být vůbec žádná (dynamicky generovaný soubor nebo hezká url), ale mohlo by záležet na MIME typu poslaném v HTTP hlavičkách. Je to trochu podobný problém jako (ne)uvádění velikosti obrázků v <img/> značce – rozměry jsou uvnitř souboru s obrázkem, takže na stránce je teoreticky není potřeba duplikovat – přesto je někdy dobré je i tam uvádět.

    asdasd

    Myslel jsem to jednoduše tak, že v případě chybějícího rel se bude brát v potaz přípona. Jinak největší smysl by stejně dávalo vkládání stylů na způsob <style src=“styl.css“ />, stejně jako u skriptů.

    j

    Pripona je widlowsi nesmysl, o obsahu souboru nerika absolutne vubec nic.

    maryo

    HTML5 je v urcitejch vecech kompromis. Oni nemuzou zmenit standardy jen tak aby to v nekterejch prohlizecich prestalo fungovat… Ale treba to odstraneni povinnyho atributu type zadnymu prohlizeci neublizi, tak je kontraproduktivni mit ho ve specifikaci jako povinnej.

    Patrik Votoček

    řekl bych že to bude z důvodu zpětné kompatibility :-)

    asdasd

    Ono je občas místo udržování a záplatování překonaných pozůstatků lepší se na zpětnou kompatibilitu jednoduše vys*rat a místo kompromisů volit to nejlogičtější řešení. Rozdělení na HTML5 transitional/strict by nebylo od věci :-).

    juraj

    Bolo by to odveci. Prehliadače nikdy nerozlišovali verzie HTML; z toho dôvodu nemá zmysel niečo rozdeľovať. Ak by si chcel takéto rozlišovanie zaviesť, znamenalo by to pridávanie ďalších zobrazovacích módov do prehliadačov. A po tom asi fakt nikto netúži.

    František Kučera

    Ad „Existují tři platné způsoby, jak v HTML říct, že booleovský atribut má být použitý. (Druhá a třetí možnost je určena pro zápis v syntaxi XHTML.) required required="" required="requ­ired"

    Proč se potom všechno ostatní (včetně required="false") nepovažuje za „nepravdu“?

    asdasd

    Hlavní je to, že je v elementu ten atribut uvedený, jeho hodnota není podstatná, ta je tam jenom „aby se neřeklo“. Jinak si myslím, že používat booleovské hodnoty v podobných atributech by bylo podstatně logičtější, což bude asi důvod, proč je tam hodně lidí intuitivně píše.

    František Kučera

    Navíc by to bylo i praktičtější při používání různých šablon nebo generování – vložit někam true/false je jednodušší, než atribut vkládat nebo vůbec nevkládat.

    Ale narážel jsem spíš na to, že v článku se píše o tom, že jsou tři platné způsoby – pak bych očekával, že všechny ostatní budou neplatné, resp. že budou vyhodnoceny jako false.

    asdasd

    Byrokracie :-)

    Srigi

    A prave tu je velky nesulad u atributu autocomplete – tato funkcia je vsade (vo vsetkych browseroch) implicitne zapnuta nad textinput-mi. Ak ju kcete vypnut, tak minimalne v gecko browseroch je platny zapis

    <input type="text" autocomplete="of­f">

    co yrochu odporuje tomu co sa tvrdi v clanku.

    bauglir

    Protože tento atribut nedefinuje logickou hodnotu, ale jednu z hodnot výčtového typu

    bauglir

    Ahoj, není tam „aby se neřeklo“, ale aby se jednalo o platnou XHTML serializaci

    asdasd

    Tady ale byla řeč o html5, kde ta hodnota opodstatnění nemá(až na kompatibilitu s xhtml) ;-). Navíc jsem měl na mysli to, že logika „je atribut = true / není atribut = „false“ je nekonzistentní se zápisem ostatních atributů, což vede k nejasnostem.

    bauglir

    samozřejmě, že hovořím o HTML5, kde v HTML serializaci zapíšete required, v XHMLT serializaci zapíšete required=“requ­ired“, HTML5 je název specifikace, pak rozhoduje, jakou serializací budete dokument psát.
    a jak jsem psal výše, toto je naprosto konzistentní se všemi boolean atributy (z těch starých například selected, chcecked), nepleťte si boolean atribut (required) s boolean hodnotu (on/yes off/no)

    bauglir

    jen dodám, tady nejde o „nějakou kompatibilitu“, XHTML serializace je součástí jazyka HTML5

    David Grudl

    Asi přesnější by bylo říct, že XHTML serializace vůbec logické atributy nezná, jen je pomocí jednotné konvence imituje.

    bauglir

    Boolean a enumerated atributy jsou definované bez ohledu na způsob serializace.

    asdasd

    „a jak jsem psal výše, toto je naprosto konzistentní se všemi boolean atributy (z těch starých například selected, chcecked), nepleťte si boolean atribut (required) s boolean hodnotu (on/yes off/no)“

    Ale já se přece proboha nebavím o jednom konkrétním atributu, ale i o způsobu zápisu všech ostatních, včetně selected, checked, … Tou nekonzistencí jsem myslel to, že když se většina atributů zapisuje atribut=“hodnota“, tak nevidím důvod, proč by se těch pár nemohlo zapisovat taky jako atribut=“true“ nebo atribut=“false“. To je celý.

    bauglir

    Takto ano, jsem Vás asi přesně nepochopil….
    ono by to možná dávalo smysl, ale bohužel z historických důvodů….

    předpokládám, že původní idea byla default missing value u boolean atributů bude false, potom není potřeba ji vůbec definovat, buď atribut je, nebo není… a pokud je, potom je true bez ohledu na hodnotu…

    bauglir

    + předpokládám, že autocomplete si vymysleli do MSIE nebo NN a ten druhý to zkopíroval…. zase historická zátěž…

    Miki

    Jde mi o to, že nějaký generátor obsahu, který jinak vyhovuje, mi generuje například <img src=“…“ /> nebo
    . Co se stane když kolem budu mít stránku postavenou na HTML 5?

    Aleš Roubíček

    Záleží, zda volíte XML serializaci či nikoli.

    Miki

    Díky, a ta se tedy přepíná, jak jsem vygooglil pouhou přítomností namespace v tagu <html> respektive <html xmlns=“http:/­/www.w3.org/1999/xhtml­“>. Je to vše?

    bauglir
    gondo

    nie, nieje to chyba
    bez ohladu na zvolenu serializaciu (ktoru v HTML5 vobec nieje potrebne definovat)
    v HTML5 mozes pouzivat HTML aj XML syntax

    1. Defines a single language called HTML5 which can be written in HTML syntax and in XML syntax.
    http://dev.w3.org/html5/html4-differences/

    Jakub Vrána

    Poslední příklad je kočkopes – používá zároveň syntaxi HTML a XHTML (která je v tomto případě v rozporu). Je to špatně i v původním článku.

    bauglir

    Mohl byste upřesnit, kde je v kódu

    <input type=“email“ name=“email“ required />

    chyba?

    Jakub Vrána

    Ukázka je v XML (což lze poznat podle />), kde musí mít atribut uvedenou hodnotu. Tu atribut required nemá.

    bauglir

    Sekce je nadepsaná
    V příkladu výše bychom tedy napsali (v HTML):
    ….

    Jakub Vrána

    V HTML ale zase nemá smysl koncové lomítko.

    bauglir

    v HTML5 je u void elementů povolené, daná ukázka je validní HTML5 v HTML serializaci

    Jakub Vrána

    To jsem nevěděl, díky za rozšíření obzorů. Je to tedy jen zbytečně krkolomné :-).

    bauglir

    Rádo se stalo.
    Ano bohužel je… void elementy jsou vyjmenované a bohužel třeba nelogicky nelze zapsat <script src=““ /> apod…
    ale u pár elementů to jde…
    http://www.w3.org/TR/html-markup/syntax.html#syntax-elements

    opět IMHO historická zátěž a potřeba zpětné kompatibility

    Petr

    To co zde autor kritizuje (nadbytečnost header) je v jiném článku zda ne serveru doporučeno používat: http://zdrojak.root.cz/clanky/webdesigneruv-pruvodce-po-html5-nova-semantika/
    <article>
    <header>
    <h1>Webdesignérův průvodce HTML5</h1>
    </header>

    Chytrý článek o tom, jak začít používat HTML5.
    <aside>
    <dl> <dt>HTML5</dt> <dd>značkovací jazyk, nástupce HTML 4</dd> </dl>
    </aside>
    </article>

    Co si má tedy čtenář vybrat? Nechtělo by to spíš nějakou korekci vycházejících článku?

    Jatan

    Článek ani dosavadní diskuse se nezabývá otázkou (ne)podpory HTML5 ve výstupních zařízeních, což je ovšem věc řádově důležitější než akademická debata o sémantice.

    Také doufat v kvalifikaci kodéra se mi jeví bláhové. Denně vznikají kvanta webů, jejichž autoři jsou rádi, že jsou vůbec schopni jakýkoli kód napsat a neřeší ani sémantiku <b><big>nadpi­su</big></b>, natož desítek nových tagů v HTML5.

    bauglir

    Tak bylo by poněkud zvláštní, pokud by se článek s názvem „Vyhněte se nejobvyklejším chybám v HTML5“ věnoval podpoře HTML5…

    Jatan

    Nevím, zda nezabývat se reálnou podporou je mezi kodéry HTML5 chyba nejobvyklejší, ale nejzávažnější je zcela jistě.

    pdturnov

    Hlavním problémem je naprosto nejasná a nejednotná specifikace významu nových tagů v HTML5. Zejména tag „section“. Má-li tvůrce webu hloubat hodiny nad tím, má-li obrázek vztah k hlavnímu článku nebo ne a má-li použít figure nebo ne, je kontraproduktivní. Těžko chtít po kodérovi, aby nedělal chyby (které jsou ale jen formální), když ani tvůrci v tom nemají jasno.
    Nicméně jakékoliv, byť nesprávné, použití nových tagů kód zpřehledňuje, a pokud to projde validátorem, tak oč jde?
    Bohužel se mi zdá, že autoři se stále drží klasického způsobu tvorby stránek v jistém rozporu s moderním trendem dynamické změny obsahu (Ajax) a stylu Web 2.0.

    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.