Vlákno názorů k článku
Kam kráčí HTML?

Myslim, ze se zapomina na prafunkci XML+XHTML. A to sice, ze mam data ulozena v XML a nasledne je pomoci XSLT nebo neceho podobneho transformuji na neco jineho, napriklad XHTML, stejne tak z nich mohu vytvorit exporty ve forme strukturovanych XML, RSS apod.

Praxe ukazala, ze tudy cesta proste nevede. Prvni problem je v tom, ze data se neukladaji do XML, ale do relacnich databazi. Z databaze je taha nejaka aplikace, pro kterou je uz ten XML mezistupen zbytecna prace - jednodussi je, kdyz rovnou vytvori (X)HTML, RSS export atp. Jinymi slovy - pro drtivou vetsinou aplikaci je zbytecne delat mezivrstvu XML dat a pak jejich prezentaci resit pres XSLT, kdyz vse muze udelat mnohem jednoduseji primo aplikace pracujici s databazi. Nehlede na to, ze v XSLT jsou nektere operace s daty komplikovane, dalsi zhola nemozne.

Z tohoto pohledu mi vysvetlete, proc bych mel pouzivat XHTML misto HTML. Abych usetril praci vyvojarum prohlizecu??? To je fakt stupidni argument. Miliony lidi se maji trapit s XHTML aby si par stovek vyvojaru usetrilo praci? Ktera je uz beztak hotova?

A jaka je vlastne ta vyhoda XHTML? Oddeleni obsahu od formy? Coze? Oddeleni obsahu od formy je princip XML. XHTML neni v oddeleni obsahu od formy dale nez HTML!!! Ani o kousek! Pokud se nejaka data vymenuji, tak se tomu deje vzdy v XML, ktere je k tomu urcene. Jaky ma smysl hledat treba cenu v XHTML dokumentu? Stejne neni nijak oznacena! Ubohost oddeleni dat v XHTML jen potvrzuje treba XFN a dalsi mikroformaty.

Naopak budu s XHTML narazet na problemy. Budu mit problemy s pouzivanim pluginu, pri elementarni praci s vice okny budu potrebovat scripting a jediny zapomenuty ampersand mi zpusobi fatal error. Dekuji, nechci.

"jediny zapomenuty ampersand mi zpusobi fatal error."

toto je presne ten pristup amaterov k HTML o ktorom sa hovori ;)

Presne tak, kdyz clovek pise kod jako prase, tak mu vic bude vyhovovat html... Zaklad by mel byt solidni a cisty, jak se pise v clanku - na to mi xhtml staci

S temi chybami nemam problem ani tak ja, jako spis BFU. Vetsina vetsich webu dnes obsahuje nejaky CMS. Tim padem by bylo nutne delat zatracene narocnou kontrolu vsech dat, aby byl vysledek validni.

Ano, chyby by se vyskytovat nemely, ale na HTML je super prave ten princip zotaveni se. Kdyz nekdo urizne koncovy </strong> tag, tak se vysledek zobrazi tucne cely, ale jede. V XHTML se nezobrazi nic.

"jediny zapomenuty ampersand mi zpusobi fatal error"

strasny pristup, myslim ze ani u desktoptovych aplikaci nikdo nezvazuje moznost vyvoj jazyka smerem k "nejiste" forme, kde se ani prikazy nebudou oddelovat stredniky.. jiste naznaky tohotu typu predvedli starsi verze visual basicu a dopadlo to priserne...

"Ano, chyby by se vyskytovat nemely, ale na HTML je super prave ten princip zotaveni se. Kdyz nekdo urizne koncovy </strong> tag, tak se vysledek zobrazi tucne cely, ale jede. V XHTML se nezobrazi nic."

OMG tak tohle je drsnej pristup, spravne se to zobrazi protoze browsery maj zabudovany slozity mechanismus sebeopravnych algoritmu, ktere tyto programatorske neschopnosti resi, ale aplikace je pak robustnejsi a pomalejsi a to je duvod proc se sprasenym kodem budou mit mobilni prohlizece jeste nejakou dobu problemy...

XHTML je na rozparsovani prohlizeci na slabsich mobilnich zarizenich snazsi a je dobre kdyz te hned prasti do oci pri nejake zasadni chybe v kodu...

Neco malo pravdy je na nasledujici reakci "Většina lidí pořád mává XHTML a čistotou, ale přitom v HTML lze psát naprosto stejně čistě.", ale k psani takhle *** kodu uz asi nemam co rict...

strasny pristup, myslim ze ani u desktoptovych aplikaci nikdo nezvazuje moznost vyvoj jazyka smerem k "nejiste" forme, kde se ani prikazy nebudou oddelovat stredniky

Nezaměňujte programovací jazyk s jazykem pro přenos informace. "Fatal error na zapomenutém ampersandu" odpovídá spíš situaci, kdy vám browser odmítne zobrazit stránku, protože je na ní chyba v y/i.

Jasne, SQL je taky jazyk pro ziskavani informaci, takze je urcite jedno kam napisu co, at si s tim parser nejak poradi, je prece totez napsat a left join b jako b left join a. A nebo zeby to fugovalo uplne jinak ? Nj, ale parser by preci mel vedit jak sem to myslel.

Nie, nie nie! To je práve prístup profesionálov, pretože chybu nemusí spraviť kodér alebo programátor. Chybu môže spraviť BFU, ktorý edituje obsah (CMS, wysiwyg), alebo proxyserver po ceste. Skutočný profesionál napíše HTML rovnako čisto ako by ho napísal aj v XHTML. Prístup amatéra je to, keď niekto podľahne módnej vlne, bez kritického pohľadu na reálny prínos.

Tohle je zatím nejlepší příspěvěk, co jsem četl.

Většina lidí pořád mává XHTML a čistotou, ale přitom v HTML lze psát naprosto stejně čistě. Podle mě neexistuje žádný skutečný důvod proč preferovat XHTML kromě hype a módy, která se kolem něho vytvořila.

Podle mě není žádný skutečný argument pro XHTML, a naprosto souhalsím s tím postřehem kolem XML+XSLT, že je to krok stranou.

Presne tak, úplne s Vami súhlasím, toto je aj môj pohľad na vec.

Mýtus čistého XHTML a prasáckého HTML je nejspíš nezničitelný. Alespoň za poslední tři roky se nezměnilo nic: Bohové jsou šílení: Jiří Kosek nerad XHTML. Jen ten poslední odstaveček bych dnes napsal jinak. Dveře do "dalších dimenzí" se mi neotevřely, takže v XHTML píšu zásadně proto, že zásadně dodržuji "firemní" Coding Standard.

"pro kterou je uz ten XML mezistupen zbytecna prace"

mozna pro opravdu vytizene servery se vyplati prenechat prezentaci na klientovi. treba

http://eu.wowarmory.com/character-sheet.xml?r=Sunstrider&n=Ocultix

posle klientovi ciste XML a odkaz na staticke XSLT a browsere zformatuj si to sam. Zajimave reseni, nicmene to XSLT http://eu.wowarmory.com/layout/character-sheet.xsl je strasne necitelne, jak tu bylo napsano, snaha o "ciste" oddeleni dat je v tomto pripade krvave vykoupena hroznym kodem toho style sheetu.

pak je vzdy XSLT reseni pro rozsahle dynamicke aplikace neprijatelny bastl Hmm, na to jaký je to podle vás bastl se to v praxi celkem hodně používá. Nicméně souhlasím, že z mnoha důvodů není většinou vhodné transformaci nechat na klientovi, ale udělat ji na serveru a klientovi poslat již jen cílový formát (HTML, PDF, ...).

Evidentne nechapete, ze konveze se ma delat az u klienta = klientovi predlozim XML a (klidne nekolik) XSL sablon. Pripadne muze klient pouzit nejakou svoji. Podstatny je, ze klientovi nabidnu cista data, se kteryma si uz pak muze delat co potrebuje.

Jasne ze generovat XML z SQL databaze a zaroven to na serveru pomoci sablony parsovat do HTML je pitomost (tedy pokud to neni jedno z mnoha vyuziti).

A proc to vsechno ? Protoze preci chcete ty nove uzasne tagy, ktere budou delat nove uzasne veci a vyvojari pak budou muset u kazdyho tagu zkoumat, jaky vsechny chyby pomoci nej jdou vyrobit a jak to nejak osefovat, aby to fungovalo i snima. A tak to bude i nadale fungovat pokazde trochu jinak, protoze standard jak osetrit debila pisiciho kod jeste nikdo nevymyslel.

To je pravda, ale praxe tento pristup vylucuje - klientovi je potreba posilat XML data jen takova, ke kterym ma mit pristup a ktera potrebuje. V praxi je v datech ulozenych jeste spousta internich udaju, ktere se ke klientovi napoak dostat nesmi.

Dalsi problem je vykradani dat - pokud bych treba udelal server o pocasi a stavu snehu na horach a posilal data klientovi v XML a tam je nejak transformoval, za chvili je z mych stranek bude sosat deset dalsich serveru. Samozrejme je jde sosat i z HTML, ale neni to tak trivialni ani spolehlive.

Dalsi problem je vykradani dat - pokud bych treba udelal server o pocasi a stavu snehu na horach a posilal data klientovi v XML a tam je nejak transformoval, za chvili je z mych stranek bude sosat deset dalsich serveru.

Na to je jednoduchá odpověď: buď ta data zveřejnit chcete nebo ne. Jestli si myslíte, že když je budete posílat v HTML, nikdo je "vykrádat" nemůže, pak jste na omylu.

Vy menite kod webu kazdy den ? V opacnem pripade pro me neni rozdilu mezi tim vytahnout si potrebne informace z html nebo xml.

A ano, vitecne, pochopil jste spravne ze jednim z primarnich ucelu XML je automaticka vymena informaci mezi servery. nevidim na tom vubec nic spatneho.

Co se tyce zasilanych dat, kdyz je nekdo idiot a neumi odfiltrovat data ktera nechce zverejnit, je to jeho chyba, ale nechapu jakou to ma souvislost s XML ?

ne, nemenim. Presto trvam na tom, ze parsovat HTML (ale i XHTML) pro ziskavani dat je daleko slozitejsi a predevsim riskujete, ze i drobna zmena prezentace tech dat vam muze system odstavit. V pripade XML je daleko pravdepodobnejsi zmena XSLT a ne samotnych XML dat. Otazka neni, jestli se bojim vykradani dat, ale spis proc to nekomu dobrovolne zjednodusovat. A ano, tohle neni strasak. To se bohuzel skutecne deje.

Ten point s filtrovanim dat je prave v tom, ze pokud chci data filtrovat, tak je musim na serveru uz nejak zpracovavat. Tzn. bud to XML vytvaret aplikaci, nebo parsovat XML nasosane z databaze a klientovi posilat jine. V obou pripadech pak nevidim duvod, proc vytvaret znovu XML, kdyz mohu rovnou na serveru vytvorit (X)HTML.

Zkratka a dobre - ano, klientovi jde posilat data v XML a nasledne je pres XSLT zobrazit, ale v praxi nevim, k cemu je to dobre. Myslim, ze muj nazor celkem dobre podporuje, kolik serveru teto moznosti vyuziva...

Nehlede na to, ze v XSLT jsou nektere operace s daty komplikovane, dalsi zhola nemozne. V XSLT je z principu možné všechno. Otázkou samozřejmě zůstává, zda je na konkrétní problém použití XSLT tou nejlepší volbou.

Tak tak. Jak známo, XSLT je turingovsky úplné, ale to je i Intercal :-)