Komentáře k článku

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.

Zpět na článek

95 komentářů k článku Nové značky HTML5:

    1. Martin HassmanAutor příspěvku

      Re: Tag video
      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.

  1. František Kučera

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

    1. Martin HassmanAutor příspěvku

      Re: OBJECT
      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.

        1. Martin HassmanAutor příspěvku

          Re: OBJECT
          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.

          1. pas

            Re: OBJECT
            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).

    2. Ifo

      Re: OBJECT
      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 … .

      1. František Kučera

        Re: OBJECT
        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.

        1. Martin HassmanAutor příspěvku

          Re: OBJECT
          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.

          1. František Kučera

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

            1. Martin HassmanAutor příspěvku

              Re: OBJECT
              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ářů.

              1. pas

                Re: OBJECT
                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.

                1. Martin HassmanAutor příspěvku

                  Re: OBJECT
                  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.

                  1. pas

                    Re: OBJECT
                    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.

                    1. Martin HassmanAutor příspěvku

                      Re: OBJECT
                      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.

                      1. pas

                        Re: OBJECT
                        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.

                        1. Martin HassmanAutor příspěvku

                          Re: OBJECT
                          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.

                            1. pas

                              Re: OBJECT
                              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ý.

                          1. František Kučera

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

                            1. Martin HassmanAutor příspěvku

                              Re: OBJECT
                              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.

                              1. pas

                                Re: OBJECT
                                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.

                                1. Martin HassmanAutor příspěvku

                                  Re: OBJECT
                                  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.

                                  1. pas

                                    Re: OBJECT
                                    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.

                                    1. Martin HassmanAutor příspěvku

                                      Re: OBJECT
                                      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.

                          2. pas

                            Re: OBJECT
                            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.

    1. Martin HassmanAutor příspěvku

      Re: dialog
      Myslím, že ta poznámka není na místě, dialog se používá pro rozhovor dvou a více osob.

      1. MD

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

        1. Martin HassmanAutor příspěvku

          Re: dialog
          To rozhodně ne, pro všechny (obě) osoby se používají stejné značky, dt pro označení osoby a dd pro její text.

      2. trta

        Re: dialog
        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…

        1. Martin HassmanAutor příspěvku

          Re: dialog
          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.

          1. František Kučera

            Re: dialog
            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.

            1. paranoiq

              Re: dialog
              "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ží

              1. František Kučera

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

                1. Radovan

                  Re: XML
                  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.

            2. Martin HassmanAutor příspěvku

              Re: dialog
              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.

              1. petr_p

                Re: dialog

                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.

                1. Martin HassmanAutor příspěvku

                  Re: dialog
                  To zapíšu jednoduše, třeba: <dt>Losna, Mažňák</dt><dd>Velkým vontem….</dd>

                    1. Martin HassmanAutor příspěvku

                      Re: dialog
                      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.

                      1. František Kučera

                        Re: dialog
                        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.

                        1. Martin HassmanAutor příspěvku

                          Re: dialog
                          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.

                  1. karf

                    Re: dialog
                    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.

                  2. petr_p

                    Re: dialog

                    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.

                    1. Peter Kahoun

                      Re: dialog
                      > 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;}

  2. Blc

    Kdy to bude finální?
    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…

    1. Martin HassmanAutor příspěvku

      Re: Kdy to bude finální?

      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.

      1. okman

        Re: Kdy to bude finální?
        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

  3. tomaash

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

  4. Anonymní

    xhtml
    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. František Kučera

      Re: 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.

      1. pa3k

        Re: xhtml
        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.

        1. František Kučera

          Re: 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.

        2. stoural

          Re: xhtml
          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.

          1. Jakub D.

            Re: xhtml
            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…

    2. Martin HassmanAutor příspěvku

      Re: xhtml
      Mrzet vás to příliš nemusí, je na vás, zda budete používat HTML syntax nebo XHTML syntax, zavedeny jsou obě.

  5. Matěj

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

      1. pas

        Re: video
        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…

        1. Martin HassmanAutor příspěvku

          Re: video
          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čů.

  6. smilelover

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

    1. František Kučera

      Re: Semantika?
      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).

      1. František Kučera

        Re: Semantika?
        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é.

        1. petr_p

          Re: Semantika?

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

      2. Martin HassmanAutor příspěvku

        Re: Semantika?
        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ů.

        1. Martin Michálek

          Re: Semantika?

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

          1. Martin HassmanAutor příspěvku

            Re: Semantika?
            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ší).

    2. smilelover

      Re: Semantika?
      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…?

      1. Martin HassmanAutor příspěvku

        Re: Semantika?
        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ý.

  7. Martin Michálek

    autorská práva

    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>
    
      1. Martin Michálek

        Re: autorská práva
        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.

  8. harvie

    YouTube, tag video, titulky, javascript api, atd...
    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…

Napsat komentář

Přihlásit se

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: http://www.zdrojak.cz/?p=3000