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.
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.
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
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.
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.
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.
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
catnebo 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.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.
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é.
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?
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í.
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ř.
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.
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).
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).
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??
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.
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ástroji/knihovnami
Re: Pořádný standard
Veď existuje. HTML.
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 :).
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
Re: takže to shrňme
XHTML 1.1 nemá rozlišení na strict variantu a jiné, ne?
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.
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)?
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.
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ě).
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.
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?
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.
Re: takže to shrňme
Takhle jednoduše to nejde, document.write() přímo zapisuje do streamu, který se právě parsuje a vyhodnocuje.
Jestli si chcete zkazit večer, můžete se podívat na odpovídající část specifikace: http://dev.w3.org/html5/spec/Overview.html#dynamic-markup-insertion
Re: takže to shrňme
Tak by document.write nebylo :))))
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.
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.
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-?
Tabulátor/Tabelátor
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
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é.
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ý.
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?
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.
Re: Parser
Aha, už to chápu. Díky! Nedošlo mi, že můžu HTML5 poslat s MIME application/xhtml+xml.
Č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.