Vlákno názorů k článku Mix posvátné validity a X od Chamurappi - „V Dodatku C doporučení XHTML 1 se celkem...
-
„V Dodatku C doporučení XHTML 1 se celkem jasně říká, že uvedená pravidla slouží k zajištění zobrazení XHTML dokumentů v existujících HTML prohlížečích.“
V kapitole 1 jsou ovšem dvakrát zmíněné vyhovující HTML prohlížeče. To očividně pravda není.„Pokud autor ví o dokumentu od W3C, který tvrdí, že XHTML 1.0 při dodržení pravidel kompatibility je syntakticky kompatibilní s HTML 4.01, sem s odkazem.“
RFC 2854 pochází částečně od W3C. Tvrdí: „XHTML 1.0 defines a profile of use of XHTML which is compatible with HTML 4.01“ — poznámka o kompatibilitě se stávajícími prohlížeči tam chybí. Můžete tomu říkat „zavádějící terminologie operující s nepravdivými tvrzeními“.„… zajímá mne, na základě čeho autor článku dovozuje, že se to nesmí“
Říkám pouze, že takový dokument nebude validní.„… a že validátor W3C je proto vadný“
1) Oficiální validátor se snaží uhodnout, jaký má užít parser, podle deklarace <!doctype>. Jenže značkovací jazyk musí znát před prvním zakousnutím se do dokumentu, aby vůbec tu deklaraci našel.
2) Veřejný identifikátor v <!doctype> nevypovídá o syntaxi. Normativně jen usnadňuje nalezení DTD, nic víc. Kupříkladu návrh druhého vydání XHTML 1.1 ani FPI nevyžaduje.
3) Pokud validátor při „text/html“ zvolí XML procesor, pak může vidět zcela jinou reprezentaci dat než HTML prohlížeč. Takové chování popírá smysl validace a neopírá se o žádnou autoritativní definici.„W3C si už navíc pomocí Web SGML Adaptations Annex pojistilo cestičku, jak z toho ven, takže předpokládám, že v nějaké příští HTML specifikaci se objeví EMPTYNRM YES“
Zmíněný Annex K vyšel dva roky před dokončením HTML 4.01. EMPTYNRM je přepínač v SGML deklaraci, která se do HTML dokumentů nepíše, takže minimálně u validátoru by problém částečně přetrval. -
„Jednou jsou tam zmíněné vyhovující prohlížeče, jednou existující prohlížeče, je tam odkazován dodatek C, kde je to řečeno dostatečně výmluvně“
Existující a vyhovující se vzájemně nevylučují. Dodatek C počítá pouze s existujícími nevyhovujícími, což ale nikde nepřiznává. Z kontextu to není zřejmé, naopak je v této souvislosti dvakrát užit pojem „vyhovující HTML 4 prohlížeč“. Mysl neposkvrněná znalostí HTML 4 musí po přečtení tohoto doporučení dojít k jednoznačnému (nepravdivému) závěru: XHTML je při dodržení Dodatku C zpětně kompatibilní a HTML prohlížeče ukončující počáteční značku lomítkem jsou chybné.„Proč? RFC2854 říká, že s mime typem "text/html" můžete dostat jak dokument s HTML syntaxí, tak dokument s XHTML syntaxí“
Ano, RFC 2854 vám dovoluje posílat i nevalidní HTML dokument.„A jak to chcete prakticky zajistit? Z mime typu to prohlížeč/validátor může zjistit v případě http komunikace.“
Pokud MIME typ mám, syntaxi znám. Pokud ho nemám, hledám jiná vodítka.„Bude tedy pro stejný kód, který jednou dostane pomocí http, jednou vložením do formuláře, dávat odlišné výsledky?“
Jistěže. Tak to samozřejmě funguje i v oficiálním validátoru. MIME typ má značný vliv na výsledek validace, akorát u „text/html“ je v jednom speciálním případě přebit. Správně by měl mít validátor u přímého vstupu přepínač parserů.„Stejně tak si může pamatovat, jaká syntaxe odpovídá určitému DTD (byť samotná DTD syntaxi neurčuje).“
Bez znalosti syntaxe deklaraci typu dokumentu nenajde.„Prakticky jsou dnes jak prohlížeče, tak validátor v situaci, kdy na mime typ mohou těžko spoléhat“
V případě HTML/XHTML se prohlížeče na MIME typ spoléhají stoprocentně a až na ten hack z března 1999 se na něj spoléhá i validátor. -
Vladimír Saur (neregistrovaný)
V kapitole 1 jsou ovšem dvakrát zmíněné vyhovující HTML prohlížeče. To očividně pravda není.
Jednou jsou tam zmíněné vyhovující prohlížeče, jednou existující prohlížeče, je tam odkazován dodatek C, kde je to řečeno dostatečně výmluvně: "This appendix summarizes design guidelines for authors who wish their XHTML documents to render on existing HTML user agents. Note that this recommendation does not define how HTML conforming user agents should process HTML documents." Možná bychom našli ve specifikaci více vět, které bez kontextu lze úspěšně zpochybnit a napsat o tom článek s hezkým bulvárním titulkem a perexem.RFC 2854 pochází částečně od W3C. Tvrdí: „XHTML 1.0 defines a profile of use of XHTML which is compatible with HTML 4.01“ — poznámka o kompatibilitě se stávajícími prohlížeči tam chybí. Můžete tomu říkat „zavádějící terminologie operující s nepravdivými tvrzeními“.
Ano, souhlasím, je to zavádějící formulace. Je užita v odkazu na dokument, kde je ovšem dostatečně vysvětlena. Myslím, že o předchozích dvou bodech je zbytečné dále diskutovat - je to o tom, jak chápeme některé anglické fráze, jak je pro nás důležitý kontext, tedy do značné míry o osobních pocitech. Já si nemyslím, že si ty (osamoceně) nejasné formulace zaslouží takový humbuk, ale názory na to můžeme mít samozřejmě různé.„… zajímá mne, na základě čeho autor článku dovozuje, že se to nesmí“ Říkám pouze, že takový dokument nebude validní.
Proč? RFC2854 říká, že s mime typem "text/html" můžete dostat jak dokumet s HTML syntaxí, tak dokument s XHTML syntaxí.1) Oficiální validátor se snaží uhodnout, jaký má užít parser, podle deklarace doctype. Jenže značkovací jazyk musí znát před prvním zakousnutím se do dokumentu, aby vůbec tu deklaraci našel.
A jak to chcete prakticky zajistit? Z mime typu to prohlížeč/validátor může zjistit v případě http komunikace. Validátor i prohlížeč ovšem si ovšem poradí i se soubory z disku, validátor se samotným kódem vloženým přes formulář. Bude tedy pro stejný kód, který jednou dostane pomocí http, jednou vložením do formuláře, dávat odlišné výsledky?2) Veřejný identifikátor v doctype nevypovídá o syntaxi. Normativně jen usnadňuje nalezení DTD, nic víc. Kupříkladu návrh druhého vydání XHTML 1.1 ani FPI nevyžaduje.
Mime typ samotný také nic sám o sobě nevypovídá o syntaxi. Prohlížeč/validátor si musí pamatovat, jaká syntaxe odpovídá určitému mime typu. Stejně tak si může pamatovat, jaká syntaxe odpovídá určitému DTD (byť samotná DTD syntaxi neurčuje). Prakticky jsou dnes jak prohlížeče, tak validátor v situaci, kdy na mime typ mohou těžko spoléhat.Zmíněný Annex K vyšel dva roky před dokončením HTML 4.01. EMPTYNRM je přepínač v SGML deklaraci, která se do HTML dokumentů nepíše, takže minimálně u validátoru by problém částečně přetrval.
Praktický význam by ten přepínač neměl víceméně žádný. Víceméně by se poupravila syntaxe shorttags v místě, kde je to stávajícím HTML prohlížečům stejně putna. -
Mám pocit, že vaše diskuse je asi tím nejzajímavějším, co se pod Chamurappiho články objevilo. Nebo možná to jediné zajímavé ;)
Ale k MIME typům.
Obecně vždy bylo nutné mít nějaký způsob, jak identifikovat typ toho kterého souboru. Před desítkami let kdosi přišel s nápadem přidávat za jméno souboru tečku s příponou, která typ charakterizuje (.jpg, .html, .txt) a tento způsob přetrval od dob CP/M až k současným Windows.
Do jisté míry má však přípona informativní charakter. Grafický editor běžně otevře PNG obrázek mylně pojmenovaný jako ABC.GIF, protože skutečný typ detekuje z obsahu souboru. K detekci někdy stačí pár prvních bajtů, jindy je složitější. Třeba při detekci kódování u textových souborů.
Zmíněný MIMETYPE je pouze jiným způsobem identifikace, který má uplatnění právě tam, kde se nepoužívají názvy a tudíž ani přípony souboru. A to je případ třeba obrázku v emailu nebo právě webových stránek.
Ale opět jde jen o informativní pomůcku. Webový server posílající soubor také mimetype hádá. Buď z přípony souboru nebo podle jeho obsahu (viz soubory mime.types a magic v Apache).
Tedy mimetypy nebo přípony souborů jsou velmi laxní stránkou technologií a proto bych na nich argumentaci nestavěl. Nakonec i HTML soubor s určeným mimetypem text/html může nabývat různých vzájemně kolidujících podob jen proto, že neznáme jeho kódování a snažíme se je pouze detekovat. A tady ani přesně určený typ text/html nic nezmůže. -
ee (neregistrovaný)Výborně, stoprocentní souhlas, něco takového jsem chtěl napsat sám.
Autor článku staví na vodě a tou vodou je, že mimetype je důležitější než doctype. Přitom doctype je součástí dokumentu, vkládá jej do něj autor, který ví, jaký dokument vytvořil.
Mime type posílá server, který jej často hádá jen podle přípony a který není součástí dokumentu. Po uložení stránky na disk se tato informace ztrácí, doctype zůstává.
Takže tu máme dva různé informační mechanismy o tom, co je ten soubor zač, jeden poměrně spolehlivý a trvalý, druhý nikoli. Navíc jsou na sobě nezávislé a mohou být navzájem v rozporu. Jako tvůrce prohlížeče bych se v takovém případě spolehl na věrohodnější doctype. Tak se tomu děje i v praxi a proto všechno klidně funguje. -
OB (neregistrovaný)Ale to tam není. Je tam, že s tímto mime typem může být odeslán jak HTML, tak XHTML dokument. Pokud RFC2854 tvrdí, že může jít (v závislosti na obsahu) i o XHTML 1.0 dokument, je nesmysl o datech s příslušným DOCTYPE uvažovat jako ho HTML dokumentu. Vaše úprava českého validátoru, kterým nyní neprojdou ani oficální stránky W3C, je v tomto kontextu evidentním močením proti větru.
-
Vladimír Saur (neregistrovaný)Máte pravdu, je třeba ty západní pořádky pořádně proprat a vytvořit si vlastní, domácím validátorem podporované. Měl bych k článku pár otázek a připomínek:
1. V Dodatku C (http://www.w3.org/TR/xhtml1/#guidelines) doporučení XHTML 1 se celkem jasně říká, že uvedená pravidla slouží k zajištění zobrazení XHTML dokumentů v existujících HTML prohlížečích. O formální kompatibilitě HTML 4.01 a XHTML 1.0 tam není ani zmínka. W3C sice v několika dokumentech používá nejasný termín "profile of use of XHTML which is compatible with HTML 4.01", vždy je ovšem v dokumentu uvedeno, že se míní kompatibilita se stávajícími HTML prohlížeči. Dalo by se tedy mluvit o zavádějící terminologii, ale o lhaní asi těžko - W3C se nijak netají, že se smyslem pravidel kompatibility je pouze podpora zobrazení XHTML pomocí současných HTML parserů v prohlížečích, a v praxi to kupodivu (jak autor článku sám uvádí) funguje bez problémů - že se využívá nedostatků v HTML parserech, je věc druhá.
Pokud autor ví o dokumentu od W3C, který tvrdí, že XHTML 1.0 při dodržení pravidel kompatibility je syntakticky kompatibilní s HTML 4.01, sem s odkazem.
2. Definici mime typu "text/html" u IANA najdeme v RFC2854 (http://www.rfc-editor.org/rfc/rfc2854.txt). Explicitně se tam uvádí, že mime typ "text/html" mohou používat HTML dokumenty i (za jistých podmínek) XHTML 1.0 dokumety. Dokument je ovšem pouze informativní, je možné, že někde existuje autoritativnější dokument, který tvrdí, že dokument s mime typem "text/html" musí mít pouze HTML syntaxi a nesmí mít v žádném případě XHTML syntaxi, byť je W3C jiného názoru.
Jelikož autor článku chce měnit v tomto duchu chování českého validátoru, jistě o nějakém autoritativním dokumentu ví a jen ho zapomněl v článku odkázat - mě by opravdu zajímal, protože se mi nepovedlo jej nalézt.
Nechci se teď bavit o tom, nakolik je možnost posílat dokument s XHTML syntaxí jako "text/html" vhodná či nevhodná, koncepční či nekoncepční - zajímá mne, na základě čeho autor článku dovozuje, že se to nesmí a že validátor W3C je proto vadný.
3. Ještě poznámka k NET syntaxi - souhlasím s tím, že využití její nepodpodpory v prohlížečích ke korektnímu zobrazování XHTML není koncepční řešení. V praxi ovšem funguje a to, zcela kacířsky, považuji za podstatné. W3C si už navíc pomocí Web SGML Adaptations Annex pojistilo cestičku, jak z toho ven, takže předpokládám, že v nějaké příští HTML specifikaci se objeví EMPTYNRM YES a na tento problém se zapomene, aniž by komukoli způsobil praktickou újmu.
ČLÁNKY DO MAILU