Názory k článku
Mix posvátné validity a X

Myslim, ze o smeru, kterym se bude W3C po nejblizsi 3 roky ubirat, se rozhodlo a XHTML 2.0 na webu to neni. Viz udalosti minuleho tydne:

http://digiweb.ihned.cz/c6-10053280-20606190-i00000_d-w3c-chce-nove-html-6-0
http://interval.cz/clanky/w3c-zaklada-nove-pracovni-skupiny/

+ dnes vysly clanek, ktery odkazovat nebudu, pac bych si delal reklamu 8-)

"+ dnes vysly clanek, ktery odkazovat nebudu, pac bych si delal reklamu"

Jen na něj odkažte ;o)

http://www.root.cz/clanky/html-vracime-se-ke-korenum/

dík za hezký článek.

Jinak já jsem ve skrze parktický člověk, takže mě zajímá spíš jak to funguje než jak je standard. Jestliže to všechny prohlížeče a validátor podporují jinak než píše standard, neznamená to, že jsou chybné, možná je chybný ten standard ;)
Je pak samozřejmě pravda, že by validátor měl kontrolovat validitu se standradem, tomu tak není a teď se s tím půjde horko těžko něco dělat.
Nejde ani tak o prohlížeče, i kdyby to teď nakrásně začali všichni prohlížeče podporovat, přesto bych se použití bál, protože nepochybuji, že vyhledavače stránku dekódují také nějakým html/xml parserem a ten pravděpodobně také počítá se současným, byť chybným, řešením. Takže by najednou stránky nemusely být indexovány a to by byl pro mnohé větší problém než nekompatibilita v nějakých prohlížečích.
Takže imho jediný možný postup je povýšit de-facto standard na de-iure standard, a tedy i "validovat validátor". A pak někdy v budoucnu se můžeme bavit o nějaké kriplizaci ;)
Osobně mi ale současný striktní xml zápis kde je na první pohled jasné co je začátek, co je konec atd. vyhovuje mnohem lépe.

Dolezite je, ze vsetci genialny kritici z Ciech aj Slovenska maju sancu dokazat, ze su machri. Staci im pridat sa do W3C HTML WG - a navod najdu v http://interval.cz/clanky/w3c-zaklada-nove-pracovni-skupiny/, ak by nahodu nevedeli po anglicky :]

malokdo chce mrhat svym casem....

preji vam mnoho uspechu

On takovy pomlouvacny clanek se napise za par minut, anonymni autor shrabne svych tricet stribrnych a redakce se raduje, protoze cim je ten blabol rozporuplnejsi, tim vic lidi ho bude cist a kvokat kolem nej. Kdyby zucastneni misto toho meli vzit za poradnou praci, nejspis by tezce onemocneli. Konstruktivni spoluprace je zbytecne mrhani casem, ale prazdne kritizovani vasim casem nemrha, ze?

jsou momenty - a tento je IMHO jednim z nich - kdy je potreba se odriznout, boli to , ale udrzovani statusu quo je horsi

ale mozna jste zastancem vegetativniho stavu za kazdou cenu..

to vubec nezminuji bezzubost podobnych "standardizacnich" organizaci mistrne maskujici x-znacne definice casto jdouci proti sobe za pozadavky na komentar.

je zvlastni jak lidstvo se snazi stale bojovat proti evoluci(neviditelne ruce trhu, nazyvejte to jak chcete)

Kto už písal nejaký odborný článok samozrejme vie, že čo ste napísali, nie je ani zďaleka pravda. Za takýmto článkom sú hodiny práce, testovania, štúdia špecifikácii, čítania mailing listov, štúdia odborných zdrojov, atď.

A ?

Autor pise velmi putavym sposobom, aby sa zdalo, ze hovori pravdu. No vsak dosiel do urovne kedy nevidi nic ine len, ze W3C je naprd. Prajem mu hodne zdaru v psychologickej liecebne, dufam, ze mu tie jeho webofobicke stavy aspon trochu vyliecia. Ja si dalej budem pachtlit normalne HTML stranky a vyuzivat moznosti, ktore mi odporucanie dava (schvalne som nenapisal norma, aby niekto neslovickaril) a nebudem sa chovat spiatocnicky v tomto smere.

Taktiez nevidim co zle na tom prispevku na ktorom reagujete. Radsej nez by mal nieco konstruktivne vytvorit a podlielat sa na vytvarani specifikacie tak bude robit hlupu kritiku. Ked to vie nech sa pripoji do tymu, no mam obavu, ze v nom sa nachadzaju inak dobre hlavicky a toho pana, ktory sa radsej prezentuje pod prezyvkou ako menom, by zotreli ani by nevedel ako.
Prskat vie kazdy, tvorit vie malokto.

Prskat umi kazdy, ale ne kazdy konstruktivne. Konstruktivni kritika standardu je stejne dulezita jako jejich tvorba.

Respektive místo obrázku je v textu článku umístěn text:

obrazek valid3.png

Prosím, abyste ho doplnil (asi přidal opomenutou značku pro vložení).

Předem děkuji.

Diky za upozorneni, obrazek uz by se mel v clanku zobrazovat.

I když se tváříte, že XHTML je zlo, tak není. Na serveru je XHTML nezastupitelné kvůli snadnému spojení s dalšími X technologiemi. Je zbytečné, aby stejná tematika byla pokrývána dvěma různými doporučeními, proto si myslím, že by HTML mělo být označeno za překonaná ve prospěch XHTML.

Bohužel pokroku bezdůvodně brání některé webové prohlížeče a jejich tvůrci. Posílání s XHTML se špatným MIME považuji v těchto případech za vyhovující a funkční kompromisní řešení. Na takto poslané stránce by se pochopitelně měla objevit výzva k upgradu prohlížeče.

Stále mně dlužíte odpověď, jak chcete HTML kombinovat s SVG (vektorovou grafikou) či MathML (matematickými vzorci).

Za prvy kdo potrebuje nejaky SVG, kdyz je flash a kdo potrebuje MathML, kdyz je gif/jpeg/... A za druhy, jak si pak kazdy BFU vytvori validni stranky pomoci produktu toho, jehoz jmeno se nevyslovuje? Jo a ze to par procent lidi (postizeni) neni schopno vubec pomoci asistivnich technologii zpracovat, to je prece jen detail.

Váhám, jestli svůj příspěvek myslíte ironicky nebo vážně. Na otázky „kdo potřebuje“, s klidným svědomím mohu odpovědět, že já.

Pro vkládání matematického textu jako obrázku je prakticky použitelné pouze PNG. Jenže takový obrázek má spoustu nevýhod – nelze jej jednoduše editovat, vzhled nebude v souladu se zbytkem textu, nelze jej zvětšovat jako okolní písmo, není strojově zpracovatelný, není interní součástí stránky… (Pro generování matematických vzorců jako PNG obrázků doporučuji imgTeX. Mimochodem JPEG je na matematické vzorce naprosto nevhodný.)

SVG lze do HTML vložit pomocí elementu object, což je vhodné pro použití SVG jako vektorového obrázku. (Nyní jsou takto vytvořeny např. vlajky na wikipedii.) Jenže SVG má mnohem více možností, které lze použít jen pokud bude součástí XHTML stránky.

Flash se ani zdaleka nevyrovná SVG. Namátkou provázání se zbytkem stránky přes DOM, strojové zpracování (zejména indexování ve vyhledávačích a generování na serveru), jednoduchá editace, podpora 64b prohlížečů…

Když o tom teď přemýšlím, asi jste svůj příspěvek myslel vážně. Omluvou vám budiž nedostatečný rozhled, že jste se s řešením těchto problémů ještě nesetkal.

Netuším, jaký produkt myslíte, takže mohu psát jen obecně. Vytváří tento produkt validní HTML? Pokud ne, je další diskuze o validitě bezpředmětná. Gramatiku XHTML považuji za jednodušší než gramatiku HTML, takže si myslím, že pro stroje i pro lidi je XHTML stravitelnější.

Opravdu Vám přijde stravitelnější pro lidi muset například psát uvozorky na místa, kde jsou evidentně zbytečné?

Jistě, gramatika XHTML je jednodušší, ale text pomocí ní zapsaný určitě není čitelnější, alespoň co se lidí týká.

A pokud jde o optimalizaci pro stroje, je XHTML sice jednodušší, ale téhož lze dosáhnout ještě řádově jednoduššími prostředky, třeba pomocí s-expressions.

Opravdu Vám přijde stravitelnější pro lidi muset například psát uvozorky na místa, kde jsou evidentně zbytečné?
Martine, pro průměrného člověka je jednodušší psát uvozovky všude, a ne si pamatovat, kdy je nemusí psát a kdy zase musí.

Jistě, ale to přeci neznamená, že k tomu má syntaxe jazyka každého nutit.

A proč by neměla? Člověk, který neumí napsat validní XHTML, to nemá a skoro určitě nebude psát ručně. Proč by, koneckonců, měl jazyk někoho nutit psát < a >, když v některých případech by si browser mohl tyto znaky domyslet, že?

A proc me ty osklive jazykarky na zakladni, stredni skole a vyskoe skole, dokonce pod hrozbou nutily dodrzovat syntaxi ruznych jazyku? Proc Vas prekladace tak strasne omezuji syntaxi pri programovani?

Ehm, přečtěte si, prosím, můj příspěvek ještě jednou. Neříkám nic o tom, že se syntaxe nemá dodržovat, nýbrž, že syntaxe nemá předepisovat zbytečnosti, které pouze ztěžují psaní a čtení.

Když už jste nadhodil syntaxi u programování, ta dává docela hezkou analogii: čísla či jména proměnných se v běžných programovacích jazycích také zapisují přímo a není důvod je psát do závorek nebo do uvozovek, i když by to zajisté bylo systematičtější a zjednodušilo by to parser :-)

Nejlepsi syntaxi ma python:

def mojeFunkce():
    if  neco:
        delejNeco1()
    else:
        delejNeco2()

Zadne zbytecne slozene zavorky, zadne kulate zavorky v podminkach, zadne stredniky. Jeste by nemusel mit ty dvojtecky. Vsechny ostatni jazyky maji syntaxi prisernou, protoze predepisuji pouzivat spoustu zbytecnosti. mimochodem cestina je taky blby jazyk ma zbytecna diakriticka znamenka - vsak je mi rozumet i bez nich a bez velkych pismen a interpunkcnich znamenek bychom se taky obesli v naproste vetsine pripadu Tim chci rict, ze nemate pravdu. Nezalezi co gramatika predepisuje, ale jak jsou gramaticka pravidla slozita a kolik maji vyjimek. Kdo neni s to pochopit a naucit se syntaxi XHTML, nedokaze to ani u HTML. Na opak to vsak neplati, je spousta lidi, ktera jednoducha XML pravidla chapou a umi rozpoznat co je spravne a co ne, kdezto u HTML diky spouste vyjimek to rict nedovedou. Jednotnost zapisu cteni rozhodne neztezuje, naopak, dela text prehlednejsi. A myslim ze pro tech par znaku navic ani psani neni slozitejsi, jen je ho nepatrne vic, ale jen teoreticky, protoze vyvojove nastroje, treba editory nam praci zjednodusuji a naopak jednoduchost a jednotnost syntaxe umoznuje editorum a spol. nam praci ulehcovat mnohem lepe. Viz treba syntax hyglighting, ktery je mnohem snazsi implementovat u jednoduche XML syntaxe nez slozite HTML syntaxe.

Ve chvíli, kdy jste prohlásil, že čeština je špatně navržený jazyk, protože Vám je rozumět i bez velkých písmen, diakritiky a interpunkce, jsem přestal číst a Váš názor zařadil do kolonky bezvýznamných.

Chcete důkaz, že nemáte ani v jednom případě pravdu, nebo se nad tím zamyslíte?

Děkuji vám za informaci, že jste se zařadil do skupiny bezvýznamných hlupáků nechápajících ironii.

Python predepisuje povinne zarovnani. IMHO mnohem vetsi opruz nez slozene zavorky.

Tim zarovnanim myslite asi odsazeni. To neni opruz, protoze to stejne kazdy programator dela. Zavorky jsou pro stroj, odsazeni pro cloveka. Proc by se stroj nemel prizpusobit cloveku? Python tak cini, stejne jako clovek se orientuje podle odsazeni. Je to super vec.

Ne, python se neprizpusobuje cloveku. Clovek je nucen vec, kterou pouzival pro vlastni prehled (tedy odsazeni) pouzit misto toho pro informovani stroje, tedy prizpusobuje se clovek. Odsazeni, ktere vytvari clovek, totiz nejen neni presne stejne jako to, ktere potrebuje python, ale ve skutecnosti ani nedava jednoznacne uzavorkovani, takze neni ani teoreticky mozne aby se prekladac orientoval pouze podle "prirozeneho" odsazeni, tedy toho jak clovek sam od sebe (a pro sebe) odsazuje.

Samozrejme, jak ktery clovek. Mozna, ze vy osobne odsazujete cirou nahodou tak jako python porad (a ne jen ve vetsine pripadu) a nevadi vam to.

V php je nazev promenne uvozeny znakem $. Patrne to zjednodusuje parser.

Těmi X technologiemi myslíte X-ray? Tedy rentgen? Ne nevím jak vy, ale já dávám na server webové stránky a nemám potřebu je propojovat s rentgenem ;-)

Na všelijaké importy-exporty dat je 'X technologie' použitelná, ale ve většině případů lze data přetáhnout jednodušeji, rychleji a s menší potřebou strojového času i jinak - CSV, SQL, klidně i TXT.

Nejedná se o importy a exporty dat, ale o jejich zpracování, což je činnost podstatně složitější. Již po několik let není nutné hlídat náročnost na strojový čas, ale na čas programátora. X technologie jsou v tomto ohledu k programátorům velice přátelské.

Co se mě týče, tak kdokoliv prohlásí, že není potřeba řešit strojový čas serveru si okamžite zaslouží pár facek...

No suhlasim, ze je dolezite sledovat strojovy cas. Ale teraz mi povedz co ti strojovy cas skrati. Jazyk s presnymi pravidlami alebo s velkou volou ?
Ja hlasujem za presne pravidla. Menej overovania, nie je nutnost sledovat vynimky, pretoze ti to hned vyhodi chybu. (Nemyslim teraz parsovanie XML, lebo niektori ludia na to radi kladu doraz, ktory chcu vypichnut do oci, lebo na lepsie sa nezmozu)

Malá otázka. Je rýchlejšie parsovanie značkovania s presne stanovenými pravidlami alebo parsovanie značkovania s presne stanovenými pravidlami? :)

Samozrejme moznost jedna je spravna :)

Uz sa to tu raz preberalo, nechcite aby som zopakoval niekoho ineho nazor. Ale budiz

XHTML je ovela menej ohybnym jazykom co sa tyka spraskania hnusneho kodu. HTML pouzivalo slovo SHOULD, XHTML pouziva MUST. Vidite tam ten rozdiel ? Co som si v HTML mohol dovolit si v XHTML nedovolim a vyhodi mi chybu. Prave toto dava moznost lahkeho parsovania, pretoze je definovana presna postupnost, kde co ma byt a nie kde co moze byt.

Na to jak je HTML ohybny musim pocitat so vsetkymi vynimkami, ktore mi tento jazyk ponuka. XHTML ma tychto vynimiek ovela menej, co sa Vam teda bude lahsie parsovat ?

Nehovorte mi ze HTML, to by bolo slovo na flamewar a zbytocne utocenie na veci v ktorych sa mylite :)

A prosim vyhnite sa tomu ze spomeniete, ze ved napisem si pekne HTML. To je obycajna vyhovorka.

Spomenuli ste pravidla, tak som o nich hovoril. Nespominali sme nic o tom ako si napisem stranku, ale v com je cela "norma" zlozitejsia, pretoze mi ponuka "volnost".

Doporučuji pročíst až do konce, parsování už se tady probíralo a nemyslím si, že by jednoznačným výsledkem bylo, že parsování XHTML je jednodušší než parsování HTML.

Ja ta odkazem na kometare Pixyho v predchadzajuich a aj v tomto clanku. Myslim, ze on v tychto veciach ma vacsi prehlad ako my dvaja dohromady.

To nie je až také isté.

kdyz je tech dat opravdu hodne, hlida se strojovy cas i dnes

(zvlast kdyz se v ramci setreni zmrazi rozpocet na obnovu serveru)

Vsichni jste vedle :-). Sledovat narocnost na hw neboli vykon je bylo a bude nutne vzdycky. Co se meni je vyhodnoceni ziskanych poznatku. Kriteriem jsou penize. Je levnejsi upgradovat hw (treba upgrade z 1GB na 2 GB ram) nebo vyvijet program o tyden dele z duvodu pametovych optimalizaci? Na kolik prijde tyden prace tymu programatoru a na kolik unen upgrade? A budou mit ty programatori kdyz tak na praci neco jineho, nebo je budu platit tak jako tak? A jak na to specham? Co pro me bude mit nejvetsi ekonomicky prinos?

Abych na to jako manager dovedl zodpovedne odpovedet, musim mit relevantni udaje a tedy i znat vykon/pozadavky aplikace.

A provádíte u CSV, SQL a TXT test, že jsou well-formed? Předpokládám, že nikoliv. Pro aplikace, kde zpracovávaná data putují mezi mnoha systémy různých dodavatelů je výborné vědět, že to co mi poslal systém XY je skutečně well-formed XML datový výstup a ne snůška chybových hlášení. A to nemluvím o tom, že by snad šlo SQL, CSV nebo TXT nějak rozumně validovat, tak abyste měl jistotu, že si do systému nezavlečete nějakou nepříjemnou chybu z důvodu nekonzistence či invalidity zasílaných dat. Můžete se na to dívat tak, že XML tu je jako univerzální jazyk výměny dat implementující standardní mechanismy kontroly jejich konzistence a validity. Tedy to, co by horko těžko v případě jeho neexistence programoval každý dodavatel samostatně a pravděpodobně ne zcela kompatibilně (potom, co by se analytici po mnoha měsících analýz domluvili na jednotné dokumentaci k formátu předávaných dat).

Ehm, obvykle kdyz validujete XML, tak mate k dizpozici informace o polich, ktera obsahovat musi, o tech ktera muze, o jejich formatu .... a kdyz vam prijde snuska chybovych hlaseni, tak sice wellformed byt muze, ale asi tezko bude mit stejny format jako data, ktera ocekavate.

Komunikaci mezi ruzny systemy se castecne zabyvam a muzu vam garantovat, ze co fungovalo vcera bez problemu nebude dnes fungovat vubec. Trebas vas partner aktualizoval svuj IS, ktery ma novou genitalni funkcnost, a vam zacnou chodit data tak, ze v poli A je cislo a v poli B text, ac to jeste vcera bylo opacne.

IMHO je snazsi napsat wellformed chybovou hlasku nez spravny wellformed dokument ...

Nesouhlasím. Není přeci problém výstup v XML pár pravidly překonvertovat do korektního HTML4.

Na obrázek v SVG se přeci mohu odkázat jako na každý jiný.

A MathML? Darmo mluvit ... příšernější způsob zapisování formulí jde už sotva vymyslet.

To problem je, xslt je pomerne narocny a slozity na pochopeni, tohle laicti tvurci webu rozhodne pouzivat nebudou. A stoji tu predevsim otazka, proc bych mel ty sloite a narocne konverze vlastne delat, kdyz prohlizec muze to xml zobrazit primo? To ze je prohlizec obecny xml klient nevazany na jeden konkretni jazyk je preci uzasna vec. Proc to chcete omezovat?

Na SVG obrazek ano, ale pracovat s obrazkem pomoci DOM muzete uz jen u toho SVG. A DOM je velmi silna a oblibena technologie, kterou weby intenzivne vyuzivaji. Proc to ale omezovat jen na dokument? Proc to neaplikovat i na obrazky? Proc to chcete omezovat?

Ad MathML, to je jen vas nazor, imho hloupy. Ostatne, cokoli je lepsiho, nez nutnost generovani desitek bitmapovych obrazku s nakreslenymi vzorci a vkladani je do html. Jestli vam tohle opravdu vyhovuje, protsim, generator MathML vzorecku neni problem. Proc ale chcete vsechny omezovat na nutnost generovani obrazku, kdyz tu jsou mnohem prijemnejsi moznosti?

Poslyste, nejste vy nejaky omezeny?

A stoji tu predevsim otazka, proc bych mel ty sloite a narocne konverze vlastne delat, kdyz prohlizec muze to xml zobrazit primo?

Pretože značky v obecnom XML nemajú absolútne žiadnu sémantiku. Sú to obyčajné zátvorky bez akéhokoľvek špeciálneho významu. Ak budeš mať v XML značku trebárs <nadpis>, a naformátuješ si to pomocou css na bold veľkosti 16pt, tak je to niečo úplne iné ako keď v HTML použiješ značku <h1>. V HTML má väčšina značiek sémantický význam, kdežto v obecnom XML nemá žiadna značka žiadny význam.

Díky za článek, o některých věcech jsem dosud nevěděl.

Nicméně myslím, že nemáte tak zcela pravdu s NET notací. V sekci 3.2 specifikace HTML 4.01 se píše:

3.2 SGML constructs used in HTML

The following sections introduce SGML constructs that are used in HTML.

The appendix lists some SGML features that are not widely supported by HTML tools and user agents and should be avoided.

Volně přeloženo:

3.2 Konstrukty SGML použité v HTML

Zde říkáme, co z SGML se používá v HTML.

V příloze najdete vlastnosti SGML, které HTML nástroje běžně neimplementují a neměli byste je používat.

V seznamu konstruktů SGML, které HTML používá, není NET notace uvedena. Naopak, odkazovaná příloha uvadějící SGML konstrukty, které by se neměly používat, je právě tou přílohou, kterou odkazujete ve svém článku jako důkaz o používání NET notace v HTML.

Můj závěr: Specifikace HTML 4.01 nedoporučuje používat NET notaci SGML, tedy <p/text odstavce/ se nedoporučuje používat místo <p>text odstavce</p>. Tvůrci IE, Firefoxe i Konqueroru si to zřejmě vyložili úplně stejně.

Problém myslím spočívá především v ne úplně jasném vztahu mezi HTML a SGML.

Problém je spíš v tom, že co je jen nedoporučované, to není zakázané.

To, že se (důrazně) nedoporučuje zkrácenou notaci v HTML dokumentu používat, neopravňuje autory prohlížečů chovat se, jako by neexistovala. Je to totéž, jako by prohlížeč ignoroval elementy, které jsou v HTML 4 označeny jako zastaralé.

Vztah mezi HTML a SGML je naprosto jasný: HTML je jednou z aplikací SGML, stejně jako je XHTML jednou z aplikací XML. Právě proto XHTML vzniklo: ne kvůli buzeraci autorů webových stránek, ale kvůli zjednodušení syntaxe a strojového zpracování dokumentů - XML, i když se proti němu spousta lidí z neznalosti bouří, je podstatně jednodušší a praktičtější než SGML. Bohužel většina těch protestujících nemá o nějakém SGML (a jeho vztahu k HTML) ani ponětí a místo formální specifikace HTML je zajímají jen empirické poznatky o tom, co jak zobrazí pár známých prohlížečů (v lepším případě, v horším MSIE).

Jak se pozná prohlížeč, který podporuje NET tagy a <br/> zpracuje tak, že <br/ bude považovat za prázdný tag a > za přebývající znak (neukončuje žádný tag) který zahodí, od prohlížeče, který nepodporuje NET syntaxi (specifikace jí nevyžaduje) a lomítko uvnitř tagu považuje třeba za neznámý tag, a ignoruje ho? Tedy jinak, než pohledem do zdrojového kódu.

hlavně tuším můj validátor takové <code><br/></code> považuje za nevalidní a opravuje jej na <code><br /></code>, tak nevím, jestli je to tento případ.

To ale plyne z toho, že prohlížeč znak > na místě, kde žádné > nečeká, zobrazí. Klidně ten znak ale místo zobrazení může ignorovat (standard nic neříká o tom, co s přebytečným > dělat).

Prosím? Podle vás může prohlížeč jen tak svévolně vynechávat některé znaky?

Zkuste si do elementu body vložit jen "<text" (bez uvozovek). WIE7, FF 2.0 i Opera nezobrazí nic – protože po < očekávají název tagu. Stejně legitimní je považovat > za konec tagu, a pokud aktuálně prohlížeč nemá žádný tag, který by mohl ukončit, prostě znak ignoruje.

To je právě problém HTML specifikace, že sice říká, že tag je ohraničen < a >, ale už neříká, co dělat, když na tyto znaky prohlížeč narazí někde jinde.

A ještě jeden detail – specifikace povoluje atributy (možná nechtěně) pouze u tagů ukončených >:

Attribute/value pairs appear before the final ">" of an element's start tag.

Jakmile má tag atributy, nemůže lomítko na konci považovat prohlížeč za NET notaci, ale musí jej považovat za vnitřek tagu – nejspíš tedy za neznámý atribut. Takže problém s NET notací se zužuje na tagy <br /> a <hr /> – a těm stačí doplnit nějakou neutrální třídu, třeba <br class="br" />. A je po problému, žádné > nikde nepřebývá.

V HTML je „>“ znak jako každý jiný, pokud je uvnitř obsahu elementu nebo atributu.

„sice říká, že tag je ohraničen < a >, ale už neříká, co dělat, když na tyto znaky prohlížeč narazí někde jinde“
Pokud za „<“ není znak povolený v názvech, je to obyčejné menšítko. Totéž platí třeba i pro ampersand.

„specifikace povoluje atributy (možná nechtěně) pouze u tagů ukončených >“
To je dost zjednodušená formulace, ono totiž i to ukončovací většítko je někdy nepovinné. Na NET nemají atributy vliv.

To je ta výhoda přesné specifikace HTML. Na jednom místě je napsáno, že atributy jsou mezi názvem tagu a ukončovacím většítkem, z něčeho jiného pak možná vyplyne, že atributy mohou být i něco jiného. Jinde zase – je to SGML, ale tohle se moc často nepoužívá, tak to možná radši taky nepoužívejte…

Problém myslím spočívá především v ne úplně jasném vztahu mezi HTML a SGML.
Ne ten vztah je zcela jasný. Chybou bylo spíše to, že se ve specifikaci HTML 4.01 nezakázala minimalizace značkování. V té době již bylo jasné, že nejpoužívanější prohlížeče nebudou pro čtení HTML používat skutečné SGML parsery. Kdyby se v SGML deklaraci změnilo "SHORTTAG YES" na "SHORTTAG NO" přiblížilo by se načítání HTML pomocí skutečného SGML parseru chování prohlížečů s "tagsoup" parserem. Navíc by odpadl problém nekompatibility s XHTML při zápisu <tag/>.

Problém je v tom, že normy si vzájemně odporují. IANA má typ text/html registrovaný pro HTML, ale XHTML 1.0 říká, že jde použít i pro XHTML. Článek předpokládá, že číselník IANA je závaznější než specifikace XHTML 1.0 a proto validátor obviňuje ze lži. Pro validátor je zjevně důležitější XHTML, nicméně vnitřní rozpor v tom, že z dokumentu nemusí být jednoznačně poznat, zda jde o HTML nebo XHTML, validátoru odpárat nejde.

Řekl bych, že co se významu media typů používaných v internetových protokolech týče, je evidentně IANA daleko větší autorita než W3C :-)

Zjevně jak pro koho. Pro Validátor W3C je větší autorita norma W3C než "nějaká" IANA :-).

Otázka pak je, pro koho má být autoritou Validátor W3C :-)

IANA má typ text/html registrovaný pro HTML, ale XHTML 1.0 říká, že jde použít i pro XHTML.

Vynechal jste ovšem dost podstatnou část: "…i pro XHTML dokument, který splňuje požadavky ze sekce HTML Compatibility Guidelines". Tedy dokument, který je - až na XML deklaraci a deklaraci typu dokumentu - platným HTML dokumentem (přehlédneme-li problém se zkráceným značkováním, který podle všeho přehlédli i autoři specifikace).

Pořád to ale musí být především XHTML dokument (takže musí otevírat a uzavírat všechny značky, obalovat hodnoty atributů do uvozovek nebo apostrofů, atd.). Validátor ho může zkontrolovat podle HTML, to autor dokumentu ale obvykle nechce - chce vědět, jestli XHTML dokument, který vytvořil (a poslal se zpětně kompatibilním typem), je skutečně XHTML dokumentem.

Tenhle serial od Tutarchamona neni spatnej, ale uz mi to prijde porad na jedno brdo. Nicmene chci podekovat za odkaz na statistiku googlu (nekde pobliz osmiprocentni mensine), to je pro me zajimave cteni.

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.

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

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.

Tak ono kódování znaků textových dokumentů je také lepší posílat v HTTP hlavičce. Ostatně podle HTTP/1.1 specifikace je to ten jediný možný způsob. To v HTML 4 zavedli tu pochybnou detekci na základě obsahu souboru.

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.

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

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.

Ksakru, zapomněl jsem připsat na co reaguji. Šlo o reakci na
Ano, RFC 2854 vám dovoluje posílat i nevalidní HTML dokument.

Asi bych už měl jít spát, vypadávají mi části textu. Ještě jedna oprava:
...uvažovat jako ho HTML 4.01 dokumentu...

Zcela zasadni je zde problem "klic od truhly v truhle". Co udelate s dokumentem, ktery diky kreativnimu pouziti komentaru XHTML parser vyhodnoti jako XHTML a HTML parser jako HTML ? Nebo hur, naopak ?

Čas běží a voda teče. Měl jsem pocit, že boj zarputilých XHTMListů a radikálních HTMListů skončil už před rokem. Zjevně nikoliv..

V každé specifikaci jsou chyby (a v každém programu taky). Jsem rád, že je Chamurappi odhalil, a že je jistě předá příslušné skupině W3C. Jinak by to byl jen ztracený čas - prohlížeče i validátor totiž budou nadále stejně "špatné" a my je budeme nadále používat stejně jako předtím.. :-)

A že by si některý výrobce prohlížečů lajzl praktickou aplikaci chyb zmíněných v článku? Ťažko..

btw. kdybychom vzali vývoj v posledních letech - kolik přibývá XHTML webů a kolik jich je HTML? Je to stále jen 8%?

"prohlížeče i validátor totiž budou nadále stejně "špatné" a my je budeme nadále používat stejně jako předtím.. :-)

Ne tak docela... :-)

Trochu zamrzí, že na validator.w3.cz není jediná kontaktní informace. Tak snad si popisu chyby někdo všimne zde.

Asi nemá smysl nějak polemizovat o změněném algoritmu detekce validačního režimu SGML nebo XML. Nicméně autor této změny jaksi opomněl, že jazyky HTML a XML používají jinou deklaraci SGML. Pokud se čte XML DTD s aktivní deklarací SGML pro HTML, není DTD syntakticky v pořádku a validace by proběhnout neměla. Tažke opravený validátor si lže stejně do kapsy jako ten od W3C, akorát v jiných věcech.

Myslím, že je nejvyšší čas přiznat si, že:

1. DTD jsou pro validaci zcela nedostačující technologie

2. Určení použitého DTD/schématu pomocí odkazu na něj z dokumentu je velice nepraktické

3. Typ dokumentu by měl být rozpoznáván podle MIME typu, ale je pochopitelné, že se vzhledem k odlišnému chování dominantního prohlížeče často používají různé heuristiky

Kontakt tam byl, ale doposud jen v nápovědě.

Validace proběhne, protože se SGML parser umí z chyb v DTD zotavit. Nepraktikuje drakonismus, validuje, dokud to jde. Přestože se úspěšně zotavuje, chyby neodpouští, takže dokumentu s vadnou DTD nikdy nedovolí spatřit zelenou hlášku. Stejně jako oficiální validátor i ten český ukazuje ve výjezdu chyb pouze chyby v dokumentu samotném.

O tom, že XML DTD není syntakticky korektní HTML DTD, se zmiňuji i v tomto článku, takže jsem to neopomněl.

„Takže opravený validátor si lže stejně do kapsy jako ten od W3C, akorát v jiných věcech.“
Opravený validátor se chová až na tu opravu identicky.

S těmi třemi „přiznáními“ souhlasím.

Kontakt tam byl, ale doposud jen v nápovědě.

S touhle pomocí jsem ho již našel, ale přeci jen jsem zvyklý na to, že nějaký funkční kontakt je dole na každé stránce. Nápovědu přece lidé od IT nečtou ;-)

Přestože se úspěšně zotavuje, chyby neodpouští, takže dokumentu s vadnou DTD nikdy nedovolí spatřit zelenou hlášku.

Jak by tedy mela vypadat nevadne DTD? Moc rad bych videl tu zelenou hlasku :-) Dekuji za odpoved.

Cenním si toho, že mezi námi jsou tak moudří muži jako Chamurappi. Jen by bylo fajn, kdyby ponejprv publikoval pod svým jménem a za druhé se alespoň pokusil pochopit, proč se věci třeba v XHTML mají tak jak mají. Bylo by fajn, kdyby alespoň zkusil opustit svůj pohled striktního kodéra líného zjišťovat proč se věci mění a co ty změny znamenají a alespoň na chvíli se vžít do pozice programátora, jež výsledný kód analyzuje. Bylo by báječné kdyby pochopil, že na světě není jen jeho a webových prohlížečů, ale spousty dalších aplikací jež s XML pracují a pro něž je bezvadné mají li vstup z webových prezentací ve formátu kompatibilním, jednotném a velmi snadno strojově zpracovatelném.

Vůbec by nevadilo, kdyby ve svých příspěvcích přestal předkládat odsuzující tvrzení postrádající jakékoliv zdůvodnění. Kdyby přestal cíleně zamlčovat pozitivní přínosy XHTML a zdůrazňovat na něm jen jeho negativní rysy a naopak vynášet pozitivní přínosy HTML a zamlčovat jeho negativnívlastnosti. To totiž nezapadá do jeho bojové ideologie.

Autor neví o zpracování dat nic. Ale píše články. Bez pochopení základních principů toho, o čem mluví. Bez základního teoretického i praktického rozhledu a přehledu. Velmi připomíná někoho, kdo se naučil metodu, a ač ještě nezískal povědomí o důvodech, má pocit, že vše umí a zvládá a že může soudit svět. Už jsem potkal mnoho takových, zřejmě příznak dnešní doby. A to ani nemluvím o tom, že se pokouší, byť skrytě, urážet přímo v článcích své oponenty. Jeho články jsou vlastně flamem nechtě oficializovaný serverem Lupa.cz. Jejímu šéfredaktorovi klobouk dolů za projevenou odvahu.

Autorovi neberu jeho názor, ale bylo by fajn, kdyby si zjistil všechny informace a ne jen ty, které chce vidět. Kdyby si přestal myslet, že jen to co on říká je správně a že všechno ostatní je zlo. A kdyby především alespoň nepublikoval na takto důvěryhodném serveru. Netuší, jak těžké je vysvětlit méně informovaným, že existují i další strany pohledu když si tu "jedinou správnou pravdu" přečtou právě na Lupě.cz.

Celému oboru tím zasazuje ránu pod pás jen vinou své vlastní nevědomosti, nenávisti a ješitnosti. Nevím, proč to má zapotřebí. Ale je to škoda.