Komentáře k článku

Polyglot aneb webovým kodérem pod obojí

Když se občas na přednáškách ptám, jakou verzi HTML posluchači používají, jsem vždy překvapen tím, že naprostá většina se hlásí k XHTML. Při bližším ohledání stránek tvůrců v XHTML však vyjde najevo, že káží víno a pijí špinavou vodu. Svůj validní XHTML kód podsouvají prohlížeči se špatným MIME typem text/html a nutí jej používat parser HTML. HTML5 přináší některé změny syntaxe, které konečně umožňují tuto praktiku dělat tak, abychom se za ni nemuseli stydět.

Zpět na článek

40 komentářů k článku Polyglot aneb webovým kodérem pod obojí:

  1. joy

    BOM je smetí

    Nesouhlasím s autorem v tom, že „v ideálním případě byste měli přidat BOM“. Pro mě je to binární smetí, které řada editorů zobrazí, které dokáže rozhodit PHP interpretr (neptejte se mě jak, uložil jsem si do paměti jen, že to zlobí, ale nenamáhal jsem se zapamatovat si jak to zlobí) a hlavně je to při UTF-8 zbytečné a nedoporučené. Dále viz http://en.wikipedia.org/wiki/Byte_order_mark.

    1. Jiří KosekAutor příspěvku

      Re: BOM je smetí

      Bylo by dobré odlišit obecné použití BOM od použití v polyglot dokumentech. Použití BOM (a konec konců celý polyglot dokument) není výmysl autora článku, ale nepěkná situace, která kumuluje různé chyby a okolnosti posledních 15 let, a snaží se z nich vybruslit. Pro podrobnosti můžete zapátrat v originální specifikaci HTML5 a Polyglot.

      Kromě svých problémů má BOM i své výhody:

      – umožňuje správně určit kódování editorům, které nic nevědí o HTML5 a nerozumí <meta charset=“…“/> a nepoužívají UTF-8 jako default – například Notepad

      – umožňuje vytvořit HTML5 dokument bez <meta charset=“…“/> – z historických důvodů a kvůli zpětné kompatibilitě s HTML4/HTTP je výchozí kódování v HTML5 US-ASCII a nikoliv UTF-8

      O problémech PHP a BOM viz strana 18 v http://www.kosek.cz/knihy/phpxml/php5xml-unicode.pdf

    2. Marax

      Re: BOM je smetí

      Když jsem začínal s PHP, BOM pro mě byl největší problém. Teda problém bylo to, zjistit, že ty znaky na konci souborů při include dělá BOM.

      1. Pavel Šimerda

        Re: BOM je smetí

        BOM je bordel, bez něj má UTF-8 všechny dobré vlastnosti ASCII kromě pevného počtu bajtů na znak. Autor myšlenky přenést tento bordel z UTF-16 i na UTF-8 by zasloužil nějaký pikantní trest.

        Pokud se používá BOM v UTF-8, kde mimochodem nemá co dělat, tak už nefunguje správně ani konkatenace řetězců/souborů, natož nějaký INCLUDE.

        1. Tomáš Herceg

          Re: BOM je smetí

          BOM by měl být všude a povinně, jinak musí každý to kódování většit. Na meta charset ani HTTP hlavičku se obecně spolehnout nedá, cca 10% webů kódování uvedené nemá, nebo ho má špatně, s překlepem atd.

          1. František Kučera

            Re: BOM je smetí

            To je ale přece chyba těch webů! A jestliže je někdo líný/neschopný posílat správnou HTTP hlavičku (nebo to zbastlit aspoň přes tu HTML meta značku), tak těžko od něj čekat, že bude do souborů vkládat BOM.

            Kromě toho BOM patří k těm horším řešením jak dát najevo použité kódování – protože musím soubor nejprve (částečně) načíst a až pak se dozvím, v jakém je kódování – ne jako když ho znám předem (z hlaviček, rozšířených atributů atd.) a můžu si jednoduše otevřít proud dat včetně správného dekódování.

            Navíc Pavlix má pravdu v tom, že BOM komplikuje spojování souborů pomocí příkazu cat nebo obecně spojování „slepením“ dvou posloupností bajtů – v podstatě takový soubor nelze považovat za prostý text, ale za určitý speciální formát.

            1. Pavel Šimerda

              Re: BOM je smetí

              „v podstatě takový soubor nelze považovat za prostý text, ale za určitý speciální formát.“

              Franto, ty mi snad čteš myšlenky.

          2. Pavel Šimerda

            Re: BOM je smetí

            „BOM by měl být všude a povinně“

            Tak snad nedostaneš infarkt, když ti řeknu, že unixové/linuxové editory samy od sebe BOM nedávají nikdy, a že tím pádem má většina linuxáků na disku hromadu souborů (včetně těch s html), které BOM neobsahují.

            Jinak implikací povinného BOM na začátku souboru je při includech BOM i uprostřed výsledných souborů, a existují prohlížeče, které ti rozbijou layout, pokud tam BOM máš, a je to naprosto v pořádku, protože tam nemá co dělat.

            PHP s BOM se rozbíjí taky (nevím, jestli už je na to nějaká náhrada), stejně libovolné skripty na linuxu (první znaky nejsou #!, ale BOM#!, taky nevím, jestli se to už nějak obchází).

            Přitom nastavit Content-Type včetně kódování je tak jednoduché.

  2. Franta

    Meta – charset

    Proč je nutné pro HTML parser uvádět kódování uvnitř dokumentu, když se posílá i v HTTP hlavičkách?

    1. Jiří KosekAutor příspěvku

      Re: Meta – charset

      Samozřejmě, když ho pošlete v HTTP hlavičkách, tak v dokumentu být uvedené nemusí. Jenže průměrný čtenář zdrojáku…

      … pravděpodobně bude stránky otevírat i z lokální disku, kde žádné hlavičky nejsou

      … má některé stránky na hostingu, kde nemůže ovlivnit jaké parametry se přidávají do hlavičky Content-type

      Ale samozřejmě, v článku jsou jistá praktická zjednodušení.

      1. Franta

        Re: Meta – charset

        ok, tak to chápu.

        BTW: je škoda, že se víc nepoužívají rozšířené atributy souborů – např. wget a curl do nich umí ukládat MIME typ a kódování (případně další věci) z HTTP hlaviček. Ono je obecně dobré vědět, jaký formát načítám a v jakém je kódování, ještě než si ten soubor (proud dat) otevřu a prokoušu se k nějakým meta značkám uvnitř.

        1. Pavel Šimerda

          Re: Meta – charset

          Ono by vůbec stálo za to, kdyby se pár lidí chytilo za hlavu a přestali by používat různé iso-8859, windows/msdos/ibm a jiná kódování a shodli by se na to, že se budou používat pouze kódování, která kódují celý Unicode.

          A v druhém kroku by bylo dobré, kdyby v naší osmibitové (bajt = 8 bitů) éře používali pouze osmibitovou variantu, tedy UTF-8, protože UTF-16 proti němu má jen samé nevýhody a UTF-32 se asi neuchytí kvůli plýtvání místem.

          1. František Kučera

            Re: Meta – charset

            To není zrovna reálné. A taky bychom se tím vlastně vrátili do doby, kdy se tiše předpokládalo „jediné správné kódování“ – tzn. 90. léta a věčné problémy s „češtinou“ – kdy někdo předpokládal cp1250 a o jiných kódováních neměl ani tušení a ten soubor byl jako na potvoru v ISO-8859-2.

            Že by se všichni dohodli na jednom kódování se nedá čekat – např. v některých malých zařízeních nebo nízkoúrovňových programech fakt nemusím chtít řešit vícebajtová kódování. Jinde zase dají přednost UTF-16 před UTF-8 atd. Prostě říct: „budeme všichni používat UTF-8“ by IMHO vedlo akorát k bordelu a chybám, protože stejně někdo bude používat jiné kódování – takhle je možné říct, jaké kódování se používá a podle toho se zařídit.

            Existují dobré způsoby, jak tuhle informaci sdělit: HTTP hlavičky, e-mailové hlavičky, rozšířené atributy souborů… horší ale použitelné způsoby: XML deklarace a v horším případě meta značky uvnitř HTML (tam už musíme načíst soubor a pak se nějak „za chodu“ přepnout do správného kódování nebo soubor načíst znovu). Ale úplně nejhorší je předpokládat nějaké implicitní kódování aniž by o tom byla nějaká jasná dohoda (ta u některých formátů je a pak není potřeba kódování explicitně uvádět, ale obecně taková dohoda napříč formáty nikdy nebude).

            1. Pavel Šimerda

              Re: Meta – charset

              No já osobně nevidím problém v UTF-8 jako jediném správném kódování, když je alespoň detekovatelné (téměř nepotkáš dokument, který by byl jako utf-8 špatně interpretován).

              Já nemám nic proti tomu, když někde na světě ještě existují stará kódování. UTF-16 je relativně náchylné na chyby a chybné předpoklady (jako třeba domnělá pevná bitová šířka znaků). Ve výsledku mi ale jako užitečná kódování vycházejí pouze UTF-8 a UTF-32 (pokud jo nutně potřebuju pevnou šířku znaku).

  3. Marek Knápek

    Pořádný standard

    Jó to kdybychom tu měli pořádný standard, který by všichni hráči respektovali..To bychom pak nemuseli řešit takovéhle krávoviny. Někde jsem četl, že standardizační autorita vydá standard teprve poté až jsou k dispozici dvě nezávislé implementace, WTF??

    1. Pavel Šimerda

      Re: Pořádný standard

      Kéž by. Vydávat standardy, které nikdy nikdo neimplementuje je nesmysl. Mimochodem W3C doporučení sama W3C za standardy neoznačuje.

    2. bauglir

      Re: Pořádný standard

      WTF?
      1/ Reálně (snad někdo s bližším vztahem k W3C potvrdí) se za standard již dá považovat Candidate Recommendation

      2/ A ano, do stavu Recommendation se dostane po 2 plných a nezávislých implementacích. Důvodem je to, že návrhy jsou obvykle extrémně komplexní a při nejlepší vůli při teoretickém návrhu může dojít k několika věcem:
      a/ v návrhu se může objevit chyba, prostě může, která se projeví až při implementaci a provozu
      b/ něco může v návrhu chybět, určitý postup, který není standardizovaný, v návrhu se mohou objevit formulace, které se při implementaci ukáží jako vágní a bude třeba je doplnit
      c/ může se ukázat, že návrh obsahuje zbytečnosti, zbytečné předepsané postupy, u kterých se ukáže při implementaci jednodušší cesta

      a tím, že W3C vyžaduje 2 nezávislé implementace by tyto problémy měli být eliminované -> návrh je implementovatelný a při implementaci se neobjevili závažné problémy a návrh je implementovatelný různými postupy/nástro­ji/knihovnami

  4. maryo

    Re: Polyglot aneb webovým kodérem pod obojí

    No vida. Uplne presne takhle to pisu od zacatku… Po predchozim clanku jsem myslel, ze je to nejvetsi hrich, ted mam konecne opet ciste svedomi :).

  5. noname

    takže to shrňme

    Takže to shrňme – polyglot je prostě XHTML 1.1 kde je jen jiná deklarace <html a můžu tam používat HTML5 tagy – tak v tom případě to takhle dělám už asi 2 roky. XHTML strict je pro mě hlavně kontrola, že jsem na nic nikde nezapomněl, taková best practice

    1. Jiří KosekAutor příspěvku

      Re: takže to shrňme

      Takže to shrňme – polyglot je prostě XHTML 1.1

      Není, XHTML 1.1 může používat veškeré prvky syntaxe XML, polyglot dokument pouze ty, které produkují stejný efekt při čtení parserem HTML.

      1. František Kučera

        Re: takže to shrňme

        BTW: Nebylo by lepší, kdyby prohlížeče měly pouze XML parser (klidně každý svůj vlastní) a v případě rozbitých dokumentů by zavolali HTML Tidy (knihovna společná všem prohlížečům)?

        1. Jiří KosekAutor příspěvku

          Re: takže to shrňme

          To musela být včera hodně divoká party :-D

          Dělat to takhle je nesmysl z mnoha důvodů, o některých by šlo i diskutovat. Ale o jednom diskutovat nejde — současné prohlížeče stránku vykreslují inkrementálně ať už se čte pomocí XML nebo HTML parseru — DOM se průběžně konstruuje a následně vykresluje. V případě použití externí knihovny, by se muselo čekat, až ta celý kód zpracuje a pak teprve by s ním šlo něco dělat — znovu naparsovat jako XML a začít renderovat.

          1. František Kučera

            Re: takže to shrňme

            A copak by ta knihovna nemohla pracovat inkrementálně? Jako filtr – z jedné strany bude přijímat HTML bordel a z druhé strany z ní půjde well-formed XML/XHTML. Stejně to funguje např. s kompresí nebo šifrováním – z jedné strany proud komprimovaných dat, z druhé nekomprimovaných (a nemusí se čekat na konec souboru, filtrovaná data se posílají průběžně).

          2. Pavel Šimerda

            Re: takže to shrňme

            Jestli je Tidy víceprůchodové, tak by šlo použít nějaké zjednodušené jednoprůchodové Tidy. Neříkám, že by to tak být mělo nebo nemělo, ale IMO si to rozhodně nezaslouží poznámku o divoké party.

            1. Jiří KosekAutor příspěvku

              Re: takže to shrňme

              A proč už teda nemít rovnou jen jeden prohlížeč? (Když může být společná jedna knihovna, tak proč ne více?)

              Současná specifikace HTML5 přesně popisuje, jak se zotavit z chyb v kódu a všechny hlavní prohlížeče už to mají implementované (některé zatím jen v beta verzích).

              Navíc cesta XML -> Tidy -> XML není zpětně kompatibilní se stávajícími stránkami, jak se ošetří třeba document.write?

              1. xerno

                Re: takže to shrňme

                Kdyby se takhle globalizovalo (jedna knihovna, jeden prohlížeč, atd…), není třeba ošetřovat document.write – jednoduše by se javascript začal vyhodnocovat až po načtení stránky nebo by se při prvním pokusu o manipulaci s DOMem pozastavil do doby, než se celý DOM načte (přičemž onload považujme jako protažení všech bajtů procedurou download->XML->Tidy>XML).

                Kéž taková doby nikdy nepřijde.

  6. Bedňa

    Re: Polyglot aneb webovým kodérem pod obojí

    Starý známy odporca XHTML sa nezaprie :) rovnako som mu nikdy neprišiel na chuť a prečo ho potom preháňať cez HTML parser aby to fungovalo všade, už úplne stráca zmysel. Pekný článok a dík za knihy s ktorých som čerpal prvé skúsenosti.

  7. maryo

    Re: Polyglot aneb webovým kodérem pod obojí

    Nekdy proste HTML nestaci. Napr. nejakej ten opengraph protokol apod. Proto pisu XHTML, protoze vetsinou nevim, jestli dokument nejaky XML obsahovat v budoucnu nebude. A kdyz jo, tak staci upravit hlavicku.

    1. Jiří KosekAutor příspěvku

      Re: Polyglot aneb webovým kodérem pod obojí

      A s jakým MIME typem posíláte XHTML+OpenGraph do prohlížeče?

      Jestli je to text/html, tak se zcela špatně interpretují jmenné prostory – schválně se podívejte co vám budou vracet vlastnosti localName a namespaceURI pro elementy jako fb:like

      Jestli je to application/xhtml+xml, co na to IE8-?

    1. Jiří KosekAutor příspěvku

      Re: Tabulátor/Tabelátor

      Nojo, tak dlouho jsem se o tom kdysi dávno s někým přel, až jsem to tu napsal špatně.

      Nicméně většina slovníků v současnosti obě slova považuje za synonyma. A opírat se v takovýchto případech o Wikipedii jako autoritativní zdroj mi připadá přinejmenším úsměvné.

  8. Jan Prachař

    Zlatá střední cesta

    Používáme striktnější syntaxi než HTML inspirovanou v XHTML (malá písmena, atributy v uvozovkách, uzavírací tagy apod.), ale ne tak striktní jako polyglot. Důvod je prostý: aby měl zdrojový kód nějakou kulturu, dobře se četl, byl přehledný.

  9. http://zee.cz/

    Parser

    Když použiji na webu HTML5 Polyglot, jaký parser se použije v moderních prohlížečích? Je to přece text/html, takže se vybere HTML parser, je to tak?

    1. Jiří KosekAutor příspěvku

      Re: Parser

      Záleží na MIME typu, který pošlete:

      S nástupem XHTML se do prohlížečů přidal ještě parser XML. Jakým parserem se stránka bude načítat, řídil MIME typ zasílaný do prohlížeče. Stránky označené pomocí text/html se zpracovávaly pomocí parseru HTML a stránky označené pomocí jednoho z MIME typů application/xhtml+xml, application/xml nebo text/xml se pak načítaly pomocí parseru XML.

  10. Lojza

    Článek je jen dalším argumentem pro HTML 4

    Prostě a jednoduše, nic nového to nepřináší, ale umožňuje to absurdně složité kostrukce. Bomba.

    Pominu zásadní faktickou chybu článku co se týče IE a datumu – více než polovina instalovaných IE verzi 9 jentak nepotká, neboť tato jaksi nefunguje pod stále oblíbenými a po těch deseti letech i celkem doladěnými win XP. IE9 navíc rozhodně neumí HTML5 tak, aby to dávalo smysl, tedy podpora jednoho mimetypu situaci rozhodně nezachrání. Alespoň je IE9 natolik rychlý a stabilní, že už uživatele nenutí instalovat jiné mamuty ala ff, chrome či opera.

    Čili jakékoliv novější pokusy než html4 stále znamenají, že uživatel stránky vůbec nemusí vidět korektně. Dokud se jedná o stránky zábavné, je to putýnka, ale pokud se v něčem novějším kóduje projekt, kde je hlavní obsah (nedejbože státní web, jehož využití je povinné), je to důkazem nedostatečné přemýšlivosti jeho autorů. No snad tak za 5-10 let bude HTML5 reálně použitelné, ale to bude web dávno přepaný polofunkčními implementacemi HTML6,7,8 a dalšími v mezičase vytvořenými úlety. Browsery budou z důvodu nutnosti podpory desítek nesmyslných formátů zas o neco náročnější a padavější, takže řada lidí bude preventivně používat starě, starší až archeologické verze – FF, resp tehdy ještě Firebird verze 0.7 je asi slušným etalonem toho, jak by měl být browser rychlý a stabilní.

    Tedy článek sice hezky kritizuje nekorektní modernistický postup, ale z úplně špatného úhlu.

Napsat komentář

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: https://www.zdrojak.cz/?p=3563