Vlákno názorů k článku Ian Hickson o nové verzi HTML od Keson - Chtěl bych položit otázku lidem, kteří trochu vidí...
-
Keson (neregistrovaný)Chtěl bych položit otázku lidem, kteří trochu vidí do vývoje (majoritních) prohlížečů. Proč neudělat tu "tlustou čáru", tedy nevyžadovat striktní kód u nového (X)HTML?
Výhody jsou, myslím, zřejmé: snadnější psaní webů, které půjdou zobrazit všude, snadnější psaní aplikací, které HTML zpracovávají.
Jak psal p. Neubauer,- hlavním autorem není koncový uživatel, ale programátor blogu/rs/editoru.
- hlavním klientem nejsou, nebo výhledově nebudou prohlížeče.
- základním problémem webu není "jak zobrazit nevalidní dokumenty", ale "jak konečně donutit uživatele psát validní dokumenty".
- Je snad výrazně složitější napsat parser pro (X)HTML5, který v sobě nebude mít "tag soup" heuristiku, než rozšířit současný "heuristický" parser o nové vlastnosti?
- Nebo se výrobci majoritních browserů nedokáží dohodnout, aby žádný browser nekorektní X/HTML5 nezobrazoval?
- Nebo je tak složité mít přidat do prohlížeče k těm současným (aby fungoval dnešní webový guláš) další striknější mód?
- Nebo prostě jen nepovažují současný stav za tak špatný? (kód, co jakš-takš zvládne zobrazit současné web stránky, už pčeci existuje, tak o co jde, že?)
-
anonymníhlavnim autorem _muze_ byt i (zkusenejsi) koncovy uzivatel, pokud toto vypustime, dosteneme se s XHTML nekam, kam se dostalo XMLSchema, ktere je pro cloveka neco naprosto neprehledneho (oproti treba relax-ng)
i pro toho programatora nastroje pro tvorbu webu je snazsi, kdyz je specifikace co nejjednoduzsi a prakticka
Hlavnim klientem jsou desktopove prohlizece. Pokusy s alternativnimi nonHTML technologiemi pro snadnejsi zpracovani se prilis nuchytily (jako wap& wml) a na ruznych jinych zarizenich (PDA, mobily, herni konozle...) se s rustem jejich vykonu spise priklanime k implementaci nejake jednoduzsi verze desktopovych prohlizecu
Pokud je 70-90 % aktualnich dokumentu nevalidnich, pak otazkou pak jak zobrazit nevalidni dokumenty je jiste velkym problemem.
--------------
1) jestli je slozitejsi pridat vlasnosti do neceho, do ceho se poslednich X let pridavaly vlasnosti, nez napsat neco uplne noveho, do ceho se dalsich X let budou pridavat dalsi vlastnosti?
2) pokud nektery browser nebude zobrazovat nekorektni xhtml (ktere existuje a existovat nejsbis v nejake mire bude), pak ho bud uzivatele nebudou pouzivat (pokud je minoritni) nebo tvurci nebudou pouzivat xhtml (pokud je majoritni)
3) a pak jeste jeden a jeste jeden a pak nejaky dalsi, ktery bude opravovat to, ze nekdo posila jinou hlavicku, nez ma mit dle specifikace (jako application/xhtml+xml) a pak je vsechny udrzovat, ladit a vyvijet...
4) ano soucasny stav neni ani zdaleka tak spatny, jako byval v dobach MSIE4 a 5, MS tehdy silene dohanel sve zaspani na webu a odstavil ostatni prohlizecem zdarma a nalakal spouty lidi na vlastni implementaci DHTML. Potom zase usnul a ostatni se prizpusibili, dohnali ho a predehnali v novych a pozadovanych webovych technologiich.
Temer vsechny prohlizece dnes drtivou vetsinu webu zobrazi pomerne dobre, nyni je hlavnim problemem to, ze HTML neni delano pro aplikace a v soucasnosti se masivne nasazuje prave jako aplikacni rozhrani. Po dlouhem cekani na to, co vypadne v teto oblasti z W3C (vypadlo nekompatiblni XHTML2 s minimem novych vlastnosti, ale za to krystalicky cistym navrhem = zacit psat sve prohlizece a nastroje temer znovu aniz budou mit nove funkce) se do toho proste vlozili prakticky. -
Franta (neregistrovaný)"Pokud je 70-90 % aktualnich dokumentu nevalidnich, pak otazkou pak jak zobrazit nevalidni dokumenty je jiste velkym problemem.
"
Proč by to proboha měl být problém??? Pro staré HTML přece už existují staré parsery. Pro nové (X)HTML napíšeme nový parser, resp. obohatíme stávající XML/XHTML a zobrazovač o nové funkce. Staré ničemné HTML se postupem času přestane používat a po nějaké době bude možné z prohlížečů vyřadit starý parser. Stejně jako dnes už nemusíme kupovat kazeťáky, stačí nám CD přehrávače. -
a) Nepsalo by se to současně. HTML by se prostě zmrazilo, maximálně by se opravovaly chyby, a rozvíjel by se pouze nový parser/vykreslovač. A kdo by dělal nové stránky a chtěl nové funkce, tak by prostě použil modernější XHTML.
b) Cena konverze? Znáš HTML Tidy? (http://www.w3.org/People/Raggett/tidy/) Staré stránky jde převádět automatizovaně a zcela bezpracně. V principu to není složité, protože WWW prohlížeč musí HTML kód načíst a nějak interpretovat, aby ho mohl zobrazit, a z této interpretace se dá odvodit čistý XHTML kód. Další důležitá věc je, že největší význam mají aktuální informace. -
anonymnía) ano to by sice bylo idealni reseni (podobne jako se design prenesl na css - stale muzete psat element font, ale pokud chcete pokrocile formatovani prejdete na css) jenomze problem XHTML2 je v tom, ze ty nove funkce a tedy motivace pro prechod tam proste nejsou.
b) mozna to je snadne lokalne, ale kdo bude tohle delat u vsech webu vsech instituci a jednotlivcu? kdo jim bude psat ty automatizovane skripty pro prevod vseho pres htmltidy? co s temi miliony automaticky generovanych dokumentu (ktere nedejboze navic nemaji oddelene sablony) kdo bude prepisovat treba ty prasacke javascripty s document.write a pochybnym pristupem k elementum, ktere ale v soucasnosti funguji a v XHTML2 proste nemuzou. S tim si za htmltidy asi neporadi. Ne kazdy cisty (X)HTML dokument na vystupu je totiz cistym XHTML i dokumentem na vstupu.
Aktualni (nove) informace maji vetsi vyznam nez neaktualni (stare) pouze v pripade, ze se s casem neco zmenilo na jejich aktualnosti :) Kdy se narodila Queen Elizabeth II muze byt dulezite, ale asi nikdo nebude mit motivaci to psat znova - aktualne :) Stejne tak napriklad popisy algoritmu -
1. Samo o sobě to není až tak složité, ale málo věcí v prohlížečích funguje samostatně, vše je provázané. To je při implementaci předpokládám největší problém.
2. Nedokáží, není to pro ně výhodné. Viz teorie her a vězňovo dilema.
3. Ano, je. Zvyšuje to složitost kódu, náklady na jeho údžbu, atd. A proč by výrobce prohlížeče měl investovat do nového módu/parseru, když bude použitelný pro mizivé procento obsahu webu, zatímco konkurence bude místo toho vynakládat prostředky na funcke přímo užitečné pro uživatele a zvyšující podíl jejich prohlížeče?
4. Nejde o to, zda je stav špatný nebo dobrý, ale o to, že se těžko ve velkém změní. -
Ad 3) Pokud bude můj prohlížeč jako jediný schpný zobrazit novou internetovou stránku se skvělým obsahem a zároveň zobrazí i všechny ostatní, budou na něj uživatelé masově přecházet. Takže pro vývojáře prohlížeče nový parser smysl má. Musí ale přinést nějakou praktickou novinku pro uživatele stránek. -
Přesně tak...
Celý (stále dokola omílaný) problém současného Webu podle mě vychází z absence podpory XHTML v MSIE...Dokud Microsoft nepřestane ignorovat jeho existenci, není podle mě valná šance na jakoukoli technologickou změnu...Protože kdokoli se v současnosti rozhodne držet krok s dobou a používat mnohem snadněji validovatelný a parsovatelný XMLkový formát, musí chtě nechtě poskytnout ještě text/html verzi pro těch 50% uživatelů, používajících IE (jasně, podpora XHTML v KHTML má také do dokonalosti daleko, ale KHTML jednak webem nehýbe, a jednak kdyby se XHTML masově začalo používat, dopsání podpory by na sebe nenechalo dlouho čekat)...
Jen si představte ten krásný okamžik, kdy IE konečně zavede XHTML a celý svět bude moci přestat se schizofrenií HTML/XHTML...HTML zůstane jen ve starých (a tím pádem odumírajících) webech a po několika letech bude moci být jeho podpora z prohlížečů zcela vyřazena...Možná utopie, ale to záleží na pánech v Redmondu... -
anonymníWeb a HTML se ale nepouziva kvuli validaci ale kvuli tomu, co na jeho zaklade zobrazuji prohlizece. XHTML2 skutecne vypada, ze jeho cilem je pokrocila validace (a to i nekolika ruznych modulu s ruznymi schematy v jednom dokumentu).
A parsovani XML se vsemi jeho zaludnostmi neni zase tak snadne, jak by se mohlo zdat.
Tech lidi s MSIE je porad jeste urcite vic nez 50% :)
A ted myslite tim XHTML kterou verzi? 1 nebo 2? -
Já ale netvrdím, že se HTML používá k validaci...Jde jen o to, že parsování XML je (i "se všemi jeho záludnostmi") poměrně jednoduchá práce - XML jasně stanovuje logickou strukturu a například libxml2 je pro někoho až překvapivě jednoduchá...Nejsou totiž potřeba žádné komplikované heuristiky pro odhadování "co chtěl tímhle básník říci"...Zkrátka např. překřížené elementy <=> chybný kód...Jakékoli XML prostě rozparsujete jednoduše rekurzivně stylem (pokud pro jednoduchost opomenu parsování DOCTYPE a podobně):
0) dokud nenarazím na "<", jedná se o text, kterým prostě plním aktuální element
1) detekuji "<" == začátek elementu
2) název elementu - pokud obsahuje ":", má určenou NS
3) dále dokud nenarazím na ">" nebo "/>": mezerou oddělené atributy, každý rozseknu na znaku "=" na název a hodnotu
4) pokud nebyla detekována sekvence "/>", následuje obsah elementu...na něj zavolám rekurzivně tuto parsovací funkci, konec obsahu poznám podle "</název_elementu>"
5) skok zpět na 0
-pokud cokoli nesedí, není kód well-formed XML a nebudeme se jím zabývat
Možná se tím někoho dotknu, ale podle mě jednoduchý XML parser napíše kdokoli, kdo má alespoň primitivní znalosti jakéhokoli programovacího jazyka...Narozdíl od toho HTML parser je monstrum (téměř) s umělou inteligencí, nebo minimálně tisíci podmínek pro "detekován ten a ten prohřešek proti specifikaci => uděláme to tak, jak to dělá konkurence, případně tak, jak zrovna programátora parseru napadlo"...
Uživatelů MSIE je víc než 50%, uznávám, že tady jsem lehce zjednodušoval...Podle statistik jednoho mnou spravovaného webu asi MSIE všech verzí používá cca 54% návštěvníků, dále následuje Firefox s 35% a Opera s 9%...
Tím XHTML myslím jak první, tak i druhou verzi...Implementace druhé verze je trochu běh na delší trať, ale XHTML 1.1 se dá implementovat snadno (na základech HTML 4.01) a přechod mezi verzemi XHTML nedá zdaleka tolik práce, jako přechod mezi verzemi HTML... -
anonymníHm ale takhle jednoduche to parsovani opravdu neni. Pokud by bylo, tak neni az takovy problem, ale XML je o dost slozitejsi, nez se na prvni pohled zda.
Doctype je ale v XML vemi dulezite (podle ceho jineho chcete validovat nez podle DTD, pripadne jak jinak poznat co to je vubec za dokument nez pomoci identifikatoru) a navic muze obsahovat vlastni entity!
Nejak jste pritom zapomnel prave na entity (interni, externi, parametricke) a to muze byt poradny humus (v entitach mohou byt take znacky).
Atributy mohou obsahovat take znaky mezera a = a mohou byt oddeleny stridave apostrofy i uvozovkami a obsahovat tytez znaky odescapovane. A oo teprve blok CDATA, ktery muze obsahovat temer cokoliv. A to nejsem zadny XML guru a spousta zaludnosti mne ani nenapadlo.
HTML prece take definuje, jak se ma pracovat s neuzavrenymi tagy, ktere smeji byt neuzavreny a ktere ne. Ty, ktere jsou neuzavrene spravne neni potreba nijak odhadovat a ty, ktere jsou uzavreny spatne nejsou well-formed HTML :) Ze nektere prohlizece nejak prectou i non-well-formed HTML prece neni chyba specifikace HTML :)
Vami spravovany web, odhaduji, bude nejak technologicky specializovany tj. ne obecny web, ktery navstevuje vetsinova populace cili ta cisla jsou v techto pripadech obecne u MSIE nizsi, ale to je jedno. -
V žádném případě jsem nechtěl nějak snižovat význam DOCTYPE deklarací a entit, ale tohle všechno jsou vlastnosti SGML, takže stejné pro HTML i XML...Parsování řetězců je zase velmi jednoduchá operace (zapamatuji si, jaká uvozovka byla na začátku a hledám druhou stejnou, přičemž escape sekvence přeskakuji)...CDATA se neparsují dokonce vůbec...(Dobře, máme ještě PCDATA, ale to není o moc víc práce)...
Každopádně na HTML je nutno vždy mít speciální parser, kdežto na XHTML stačí jeden univerzální XML...Speciální parser pro HTML je třeba např. kvůli tomu, že některé elementy mohou být jak jednodílné, tak i dvoudílné (např. element IMG)...V případě XML je věc jasná, ale u HTML z otevíracího tagu parser nemá šanci poznat, jestli následující data jsou obsah elementu IMG, nebo elementu rodičovského...
Zmiňovaný web navštěvují převážně studenti středních škol, o nichž nepředpokládám, že by byli nějak významně "osvícení"... -
anonymníTo neni az tak jednoduche. HTML je velmi omezena podmnozina SGML. V HTML, pokud se nemylim, nemate moznost definice vlastnich entit. XHTML je kompletni implementace XML (coz je o neco vetsi podmnozina SGML) a tam vlastni entity definovat muzete.
V XML mohou byt take neparove tagy, cili s ni mi musite v parseru pocitat. Konkretne IMG nesmi mit v HTML4 koncovy tag, podobne i jine. Nezamenujte pomerne jasnou specifkaci HTML s tim, v jak prasacke podobe se HTML mozna muze nekde taky vyskytovat a prohlizece ho i tak prectou.
Ale opet: problem neni v tom, ze by neexistoval vyhovujici parser HTML - pokud pouzivate libovolny prohlizec, mate HTML parser a to dokonce takovy, ktery toleruje velkou cast chyb. -
Omlouvám se za drobný přehmat, ohledně toho IMG máte pravdu, jako vhodný příklad elementu, který může být v HTML 4.01 párový i nepárový jsem měl zvolit spíše element P...V XML mohou být také nepárové tagy, ale jsou snadno rozpoznatelné podle syntaxe <tag/>...
V HTML skutečně nemáte možnost definovat vlastní entity, čili další plus pro XHTML... -
anonymní
No plus mozna pro uzivatele (i kdyz v dobe dynamicky generovaneho webu rozhodne nijak vyznamne plus). Zato ale poradne minus pro implementatora parseru.
S P neni v HTML problem. Staci k tomu dve veticky ve specifikaci:
The P element represents a paragraph. It cannot contain block-level elements (including P itself). We discourage authors from using empty P elements. User agents should ignore empty P elements.
Tedy P konci bud koncovym tagem, nebo pred pocatecnim tagem prvniho nasledujiciho blokoveho tagu (vcetne P). -
anonymníA i kdyby se XML parsovalo snadneji, co to meni na tom, ze XHTML2 neresi ty soucasne pozadovane funkce?
Neni problem v tom, ze by neexistovaly parsery HTML nebo ze by byly pomale a nespolehlive - kazdy prohlizec ho v sobe jiz samozrejme ma.
A musel by ho mit i nadale - drtiva vetsina webu neni (a v dohledne dobe nebude) v XML. Forma XML sama o sobe neni ani nahodou vyhoda, pokud nenabizi nic dalsiho. Pokud chci psat web v cistem XML, muzu pouzit XHTML1.
Nejde o to napsat primitivni XML parser, ale kdyz uz tak parser XML podle specifikace. A to zase tak primitivni neni. I proto se na cteni XML pouzivaji standardizovane (a ne zrovna primitivni) knihovny a nikdo se s tim nepise sam. -
Jedna věc je obsah specifikace, navrhované elementy a podobně, kdežto celková filozofie je věc druhá...XHTML2 je stejně jako XHTML1 pokus zavést konečně řád do současného (s odpuštěním) bordelu...To mi právě přijde nejhorší, že WHATWG si místo konstruktivní diskuze o tom, co by mělo být v novém (a perspektivním) XML-based webu, vytvoří vlastního "následovníka" starého chaotického systému; aneb "provizorium fungovalo doteď, proč by nemohlo fungovat dál, stačí přisypat pár funkcí"...
Forma XML je sama o sobě zásadní výhoda třeba kvůli XSLT transformacím...
Rozhodně jsem neměl v úmyslu navrhovat tady parser, jen jsem chtěl ukázat, jak důležité je mít jasně stanovená jednoduchá pravidla... -
anonymníJaky je ten soucasny chaoticky bordel v HTML4 a XHTML1? Co je v tech specifikacich spatneho? Nebo je spatne to, ze prohlizece vetsinou celkem dobre prectou i to, co presne neodpovida specifikaci?
Web neni perspektivni tim, jakou ma filosofii (zvlaste pokud ta neni sdilena jeho uzivateli - tj. tvurci webu, tvurci prohlizecu, tvurci nastroju...), ale tim, co poskytuje za funkcionalitu.
Pokud chcete pracovat s XML na webu, mate tu XHTML1. XSLT chcete pouzivat na zobrazovani nebo zpracovani webu? Pokud na zobrazeni, pak nepotrebujete XHTML - vystup XSLT nemusi byt XML. Vstup ano, ale ten nemusi byt 'vseobecne' XHTML2, ale libovolne XML, ktere se transformuje pomoci specifickeho XSLT stylu do ceho chcete. Neco jineho je, pokud chcete obsah webu pomoci XSLT prevadet na neco jineho. Popravde nedovedu si ted predstavit moc na co, ale prosim i tak vam ale staci XHTML1.
Ale opakuji - moje vyhrady vuci XHTML2 nejsou ani nahodou vuci XML syntaxi. XML syntaxi melo uz XHTML1. Vyhrady jsou proti tomu, ze to je nekompatibilni a ze to je zbytecne slozite aniz to prinasi novou (pozadovanou) funkcionalitu. Tvari se, jako by web slouzil porad pouze k publikovani dlouhych vedeckych textovych dokumentu. Web ale uz dela dost dlouho hlavne neco jineho. Objevuji se fora, diskuse, multimedia, rozhrani k pomerne komplikovanym aplikacim...
XHTML2 proste zaspalo dobu a neodpovida pozadavkum soucasneho webu. -
Narozdíl od toho HTML parser je monstrum
Kdyz jsem se dival na zdrojaky plneho HTML parseru http://code.google.com/p/html5/, tak jsem mel pocit ze to o slozitosti HTML parseru bude nejaka poradne rozlezla fama. Stahnete si to a presvedcte se sami. -
aha utekl mi odkaz, mate pravdu, spravne to je http://code.google.com/p/html5lib/. Co vam na tomhle parseru pripada slozite? (odmyslim profilovaci a podobne funkce, ktere jsou soucasti proto, ze se pouzivani pro testovani implementace).
-
Složité mi připadá to, že každý HTML parser musí obsahovat logiku dané specifikace HTML (aby dokázal rozhodnout, kdy má např. čekat u nějakého elementu obsah). Pokud nahlédnete do kódu, přesvědčíte se sám, že je dočista prošpikován názvy jednotlivých elementů a odkazy na HTML5 specifikaci. Naproti tomu XHTML (resp. XML) parser nemusí o tom, co vlastně parsuje, vědět vůbec nic; stačí mu základní pravidla XML.
-
Specificka prace s elementy tam jiste je, ale ani to zdaleka tak strasne, jak se v kritikach html parseru dozvidame. Pokud se na to divam metodou neco za neco, tak bych si stale vybral o neco slozitejsi parser, ktery dokaze zpracovat >90% soucasneho webu, nez nedokonaly xml parser (stale vynechavame validaci apod.), ktery si poradi s ... rekneme nekolika malo procenty?
Desiva vypraveni o slozitosti HTML parseru a obtiznosti kohokoliv zapojit se do trhu webovych prohlizeci mi pri pohledu na dvoutisiceradkovy kod zakladni tridy (vynechavam tokenizer a veci okolo, jeste bychom tak jednu tisisovku nasbirali) pripadaji jako zbytecny mytus. -
anonymníNerad bych se mylil, zas tak do toho nevidim, ale osobne bych povazoval parser za jednu z nejsnadnejsich casti takoveho zgruntu psaneho prohlizece.
Mnohem vetsi problem bych videl v implementaci (ne parsovani ale korektnim vykreslovani a zpracovani) takovych lahudek jako vsemozne CSS, DOM a JS lahudky.
Tedy textovy (nebo i podporujici pouze staticke primitivni formatovani na urovni HTML3) prohlizec (tj. hlavne parsovani (X)HTML) povazuji za ulohu minimalne radove jednoduzsi, nez plnohodnotny HTML4 (pripadne XHTML1 i 2) browser s podporou CSS2 prip. 3, standardniho JS...
Navic pokud by kdokoliv chtel v nejblizsich peti letech vstupovat na trh prohlizecu, odhaduji, ze by stejne musel implementovat krome XHTML2 i predchozi standardy aby se uchytil. -
Tou složitostí jsem neměl na mysli objem kódu, ale spíše provázanost parseru se specifikací a tím jeho komplikovanou správu...
XHTML od 1.1 přináší jednolitou platformu pro další vývoj...Verze 2 k tomu přidává něco nové funkčnosti (a pokud někomu pořád něco schází, měl by se tento problém řešit přidáváním modulů/elementů XHTML a ne smetením slibné platformy se stolu a návratem k prehistorii zvané HTML)...
Variantou by mohlo být XHTML5, ale...Sami autoři dávají najevo, jaký mají názor na každého, kdo používá XML větou (cituji z HTML5 specifikace) "Generally speaking, authors are discouraged from trying to use XML on the Web, because XML has much stricter syntax rules than the "HTML5" variant described above, and is relatively newer and therefore less mature."...Aneb "lepší kontrolu správnosti kódu přece nikdo nechce; všichni píšou radši prasečiny a tak to má být"... -
Ano, v rozhovoru se v té souvislosti píše "Někteří lidé budou XML s HTML5 používat, ať už uděláme cokoliv.", z čehož mi vstávají vlasy hrůzou...Možná se pletu, ale já z toho prostě cítím averzi k pokroku ve formě XML...Pokud se v nějaké specifikaci objevuje něco takovéhleho, tak třeba mě osobně to zcela odrazuje od jejího používání kvůli obavě, že v další verzi se může autor rozhodnout podporu XML zcela zrušit...
-
anonymníNo prominte, ale HTML5 je nasledovnikem HTML4 a je zpetne kompatibilni minimalne az k HTML3.2 a v principu i dale. Nedovedu si moc v praxi predstavit to zruseni podpory XML.
Nekompatibilni tu je XHTML2. To mi nahani mnohem vetsi obavy, pokud uvazim, ze pro XHTML3 se muze zase kdosi rozhodnout, ze filosofie XHTML2 neni az tak skvela a mohlo by byt super ji konecne vyresit a zgruntu predelat.
Averzi vuci XML a vsemu X vidim spise v tom, ze W3C cca od roku 2000 hlasala neco ve smyslu, ze XML spasi web a vrhla se snad na desitky X jazyku zalozenych na XML. V praxi se snad ujalo jenom RSS a to jeste pro neco trochu jineho nez bylo puvodne urceno a, pokud se nemylim, tak ne az tak uplne v rezii W3C.
Nedokazu si vzpomenout na zadnou jinou X technologii, ktera by se za 7 a vice let na webu ujala. (Myslim na beznem uzivatelskem webu, ale ani webservices nejsou az takovy hit i kdyz se v konercni sfere obcas pouzivaji.) -
anonymníNapsat nevalidujici xml parser nemusi byt az tak obtizne, ale validujici xml parser je hodne slozita zalezitost (uz kvuli parsovani DTD atd. - ostatne prectete si http://www.w3.org/TR/2006/REC-xml-20060816/).
-
anonymníPokud chcete korektne zpracovavat XML (tedy XHTML2), musite zpracovat i DTD (kvuli entitam). Pokud chcete zpracovavat XHTML univerzalnim XML parserem, pak ten by mel byt zrejme co nejlepsi a nejkompletnejsi. Mel by asi umet validovat ruzne casti (moduly) pouzite nebo vlozene do XHTML2 relativne nezavisle (tj. rozpoznat, ze HTML je OK, ale chyba ('logicka' tedy je to well-formed) je ve formulari v XForms, nebo v SVG, nebo v nejakem z tech mnoha X jazyku, ktere zrovna pouzivate).
Specialni HTML parser v browseru validaci nepotrebuje. Jak jste psal vyse, ma kompletni logiku toho jazyka integrovanu v sobe (pripadne ve svych modulech). To neni az tak na skodu, protoze stejne ji tam musi mit na nejake urovni kvuli spravne reprezentaci znacek. -
To, že by měl být parser co nejuniverzálnější, je svatá pravda. V tom tkví právě hlavní výhoda XHTML - XML parser nemusí vědět vůbec nic o tom, co parsuje, stačí mu znalost základní syntaxe "nadjazyka" (XML)...Pokud má jít o validující parser, potřebuje ještě přístup ke schématům (nebo RELAX NG, pokud je někdo preferuje), ale tím to končí...Výhody jsou snad zřejmé - snadná správa a rozšiřitelnost + prohlížeči stačí jeden parser na všechno...Právě ve vkládání XForms, SVG, XUL nebo MathML (pokud by bylo XMLizováno) vidím hlavní přínos XHTML...Přináší modularitu a rozšiřitelnost a jako bonus i snadněji zpracovatelné dokumenty...
Naproti tomu HTML (a zvláště navrhované HTML5, v jehož specifikaci je dokonce výslovně zmíněno, že vyžaduje speciální parsování) se nedá zpracovávat jinak, než jednoúčelovým parserem...To s sebou přináší ztrátu modularity tím, že se do specifikace "natvrdo" začleňuje např. formulářová funkčnost; a problematickou rozšiřitelnost - na všechno "nové" potřebujete upravit specifikaci, zavést speciální element a upravit všechny existující parsery...Zkrátka a dobře, základní pravidla softwarového návrhu dostávají značně na frak, když je celá specifikace natvrdo zakódována v parseru... -
anonymníHTML hlavne bylo a je uspesne proto, ze bylo vzdy zpetne kompatibilni, proto, ze bylo vyvijeno vicemene soucasne s jeho implementaci v hlavnich prohlizecich (resp. dokonce trochu pomaleji - ano nejdriv byl bordel a spousta novinek, pak standardizace nekterych a pak se dohanelo to, kdo co nemel).
To take souvisi s tim, proc je podporovano vsude. -
Vzpomnel jsem si na clanek Petra Cimpricha o jmennych prostorech Úskalí XML (2). Rekl bych, ze jejich spravna aplikace xml parsovani jeste zkomplikuje.
-
anonymníNe nepovazuji. Jasna pravidla existuji (specifikace HTML4 a XHTML1).
Nektere prohlizece jsou benevolentnejsi a toleruji (ne nuti k) prekroceni techto pravidel.
Obsah webu se na klientske strane nezpracovava pomoci XSLT ale renderovacim modulem prohlizece. XSLT muzete pouzit na libovolne XML (tedy nejen na XHTML2, ale i na XHTML1 a jakekoliv jine).
XHTML2 dopadne jako dopadlo HTML3.0 - specifikace, ktera byla mc ambiciozni a nikdo ji nechtel implementovat. Rozdil je ale v tom, ze HTML3.0 obsahovalo na svou dobu az moc funkci (vcetne treba tech pro zapis matematickych vzorcu), ale XHTML2 obsahuje na svou dobu naproste minimum funkci.
Tahle diskuse je treba v XHTML1, ale nevim, jestli je snadno zpracovatelna pres XSLT - je tvorena zmeti DIVu a SPANu. Pro zobrazeni to je jedno (a bylo by uplne stejne, pokud by byla v HTML4). Pro zpracovani temer take - pokud budu chtit zpracovat obecne diskusi, nepovede se mi to. Budu muset pro kazdy web napsat vlastni XSLT styl. To nejsou jasna pravidla. To neni semanticke.
