Názory k článku
Polyglot aneb webovým kodérem pod obojí

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.

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.

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.

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

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

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

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

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

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

Veď existuje. HTML.

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

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

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

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

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?

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.

Tak by document.write nebylo :))))

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.

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.

Asi vám to bude připadat jako malichernost, ale já se přiznávám, že mě trochu vytáčí, když někde čtu slovo "tabelátor". Vytvářím přece tabUlky a ne žádné tabElky! Tabelátor je stroj na snímání děrných štítků. Viz http://cs.wikipedia.org/wiki/Tabulá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é.

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

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?

Aha, už to chápu. Díky! Nedošlo mi, že můžu HTML5 poslat s MIME application/xhtml+xml.

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.