Názory k článku
Kam kráčí HTML?

Podle mne by kazdy, kdo to s tvorbou webovych stranek mysli vazne, mel pouzivat validator. Plugin do Firefoxu je idealni. Profesional by nemel vzit penize treba za to, co je na strance s timto clankem: nejake unescaped ampersandy atd celkem 9 warningu. I kdyz je zrejme, ze s takovyma blbostma si poradi kazdy prohlizec. Omluvit se da jedine prohresek nutny k potlaceni zname chyby nektereho z prohlizecu.

Môžeš nejaký Plugin do Firefoxu doporučiť?

Asi jsi nekoukal na stranku na niz odkazuje autor clanku :) Prohlidni si zdrojovy kod, zda Ti prijde validni.
Stranka
Potom zkus stranku predhodit validatoru.
Validace stranky
Mozna tomu nerozumim, ale s Validatorem moc nesouhlasim ;)

On ten validátor má ale pravdu. Jako XML dokument to je validní. Je tam totiž použit trik. Téměř celý dokument je součástí instrukce pro zpracování (která začíná <? a končí ?>). Když toto odstraníme, tak nám kromě XML deklarace a určení DTD, zbude jenom <q/>, což zcela odpovídá tomu, co je v určení DTD.
Jenže stránka je poslána s hlavičkou text/html, takže je prohlížečem interpretována jinak (jako HTML). Pokud ji pošlete jako application/xhtml+xml, výsledek bude poněkud jiný.

V opera browseru lze nakonfigurovat odesilane hlavicky tak, aby USER_AGENT vypadal jako od uzivatele M$IE (napriklad) a pote uz jen prave tlacitko -> volba Validate.

To ze vy jste uzivatelem zaostaleho browseru, ktery tuto funkci nenabizi neznamena, ze chyba je na strane validatoru, prave naopak.

Ale pokud se vam validator nelibi, muzete hledat chyby manualne, (pokud bych reagoval na nekoho jineho, pravdepodobne bych mu rekl ze muze napsat lepsi, ale clovek s vasimi nazory ani neumi vyuzit jiz hotove - ready-to-use reseni).

Ke google: pokud si představíš miliardy požadavků denně na stránku google.com, tak si asi dokážeš představit kolikrát se ty 4 znaky navíc (pokud bychom escapovali např. 1 ampersand) musí stahovat. No a teď si všimni příšerně nevalidního kódu google.com. Víš, proč tomu tak je? Správně, je to kvůli tomu, že každý B navíc v kódu děla mnoho GB v trafficu na servery google. Proto mají nevalidní, extrémně úsporný kód kde jsou neescapované entity. Prosím nekritizovat, i díky tomu je google tak rychlý ...

nevim jak je tomu dnes, ale kdysi nedavno kdosi delal test na homepage vyhledavacu a nejuspornejsi kod mel prekvapive Windows Live, zrovna Google mel balast snad pres 50%... Ale jinak souhlas, escapovani ampersandu je opravdu zbytecnost. Z kontextu je vzdy naprosto zrejme, co autor zamyslel.

Ale jinak souhlas, escapovani ampersandu je opravdu zbytecnost. Z kontextu je vzdy naprosto zrejme, co autor zamyslel.

Člověku to obvykle jasné je. Ale kód stránky obvykle nezpracovává člověk.

Naprostá zbytečnost? Tak co třeba znamená tohle:

"www.example.com?param=abc&image"

Podotýkám že &image je entita. Entita nemusí být zakončena středníkem. Vážně je to zřejmé? A kdyby byla zakončena středníkem, bylo by to zřejmější? Asi těžko...

Pokud se nebudou důsledně escapovat ampersandy, není pak možné zjistit, jestli &image je součást parametru "param" nebo samostatný parametr.

Musim, uznat, ze za tenhle priklad mate bod.

Nechce se mi hledat, jestli entita musi byt zakoncena strednikem nebo ne. Podle mne musi, protoze treba Opera to vyzaduje. Ale i kdyby ne - parser bud rozpozna a najde &image v seznamu entit a nahradi ji, nebo ji nanahradi. Pokud si chci byt jisty, ze ji nebude nahrazovat, tak ji vyescapuju, samozrejme. To je ovsem pripad, kdy potrebuji poslat parametr, jehoz nazev se rovna nejake entite. Za temer deset let, co delam web, jsem se s podobnym problemem nesetkal a to pouzivam parametry zasadne s anglickymi nazvy.

A třeba parametr "lang" jste nikdy nepoužil? Entita &lang; totiž taky existuje. Podstatné je, že strojově zpracovávaný kód by měl být jednoznačný, takže souhlasím s vaším "pokud si chci být jistý, tak ji vyescapuju", ale s dodatkem, že jistý si chci být vždycky (mimochodem, v XHTML je možné definovat vlastní entity).

Ad středník: In SGML, it is possible to eliminate the final ";" after a character reference in some cases... - nedám ruku do ohně, jestli do "some cases" patří i uvozovky na konci atributu, nebo je potřeba vložit ještě zalomení řádku, každopádně je to fuk. V uvedeném případě by středník mohl být i součástí názvu druhého parametru.

pokud si představíš miliardy požadavků denně na stránku google.com, tak si asi dokážeš představit kolikrát se ty 4 znaky navíc (pokud bychom escapovali např. 1 ampersand) musí stahovat

Jestli to měl být vtip, tak se moc nepovedl. Jestli ne, zírám v němém úžasu. Zkuste si rozmyslet, kolik procent provozu by těch pár bytů navíc znamenalo.

Ačkoliv kód homepage Google prošel vývojem, prasácký byl vždycky. Ale pokaždé se našlo dost lidí, co by byli ochotni dát ruku do ohně za to, že ten kód je takový, aby byl úsporný / všude fungoval / měl jiné magické schopnosti. A rádi svůj názor podpořili argumentem: "si myslíš, že jsi chytřejší než kodéři z Google?" případně "si myslíš, že si Google nemůže zaplatit ty nejlepší kodéry?".

V absolutních číslech je sice každý bajt na stránce Googlu znát, ale absolutní čísla nejsou všechno: Gigabajt navíc mě bude trápit na ADSL s FUP 5 GB, ale mezi těmi terabajty, co přenáší Google, se to ztratí. Čísla jsou samozřejmě vymyšlená, ale obsah stránky tuto moji teorii potvrzuje - pokud by opravdu záleželo na každém bajtu, tak Google sice možná nevyhodí obrázkové logo, ale určitě se může zbavit komentářů kolem stylů a javascriptu, zbytečných atributů v body a samozřejmě onload skriptu jako takového, vedle spousty dalších zbytečných bajtíků...

Pana boha, copak nikdo nevite, ze data se prenasi v paketech a ze je jedno jestli je v paketu 1 nebo 1000 byte dat? Na prenos je to stejne narocne. Nikoli uz na zpracovani, nejednoznacne veci jsou na zpracovani narocnejsi, zere to vykon, zvysuje spotrebu, u mobilnich zarizeni zkracuje zivotnost. Bylo by zajimave spocitat, jakou spotrebu energie zpusobuje prasackost google a dalsich stranek.

Neviem či to tu už bolo spomenuté, ale Opera má funkciu "Validate" priamo v sebe. Táto funkcia uploadne dokument na stránky validátora - takže vždy sa kontroluje to, čo máte práve zobrazené u seba. Vlastnosť meniť User-Agent string v Opere uz bola spomenutá.

Co myslite temi dynamicky menenymi strankami? At uz ty stranky delaji cokoliv, jejich vystupem vzdy bude HTML kod. A ten je predmetem validace, nikoliv JavaScript ci jine programovaci technologie.

Proc by mel validator simulovat ruzne klienty? K cemu by to bylo? Validator kontroluje pouze formalni stranku kodu, syntaxi. Nikoliv to, jak stranka vypada v danem prohlizeci. Priznam se, ze absolutne nechapu tyto vase pozadavky.

narazi se zrejme na to, ze server muze vratit ruzne stranky a predevsim ruzne HTTP hlavicky podle toho, co prijde v HTTP pozadavku. Banalni priklady jsou accept-language, accept-encoding atp. Taky treba muze vracet trochu jiny kod podle toho, jaky je na vystupu prohlizec, i kdyz to uz se dnes snad ani nedela.

Díky, lépe bych to napsat nedokázal. Už jsem si skoro myslel, že to furóre věčného zatracení XHTML a adorace HTML5 jsou bezbřehé a všeobecné.

Připojuji se k díkům. Konečně jeden článek na toto téma postavený na faktech a argumentech a ne na ideologii.

"Jako termín dokončení této nové specifikace se předpokládá rok 2010."

Takze si pockame MINIMALNE tri roky? Kdyby takto pracovaly firmy a komercni organizace, uz davno by zkrachovaly.

Dokončení specifikace neznamená zavedení do praxe (tzn. podpora v prohlížečích). Reálné použití závisí na prohlížečích. Takže to může být dřív nebo i později. Viz např. http://html456.blogspot.com/2007/08/jak-je-to-s-terminem-dokonceni-html5.html (CSS2 taky není dokončená specifikace).

Nesmysl. Pletete si pojmy s dojmy. CSS 2 je hotova specifikace, alespon z hlediska prace na ni. A o to jde. To, ze mozna neni dokoncena oficialne, je vec uplne jina, a nikoho to nezajima.

HTML 5 bude z hlediska prace dokonceno v roce 2010 (alespon tak to chapu ja), a to je neuveritelne pomaly postup prace. A nemuzete implementovat neco, co neni dokonceno (opet z hlediska prace).

Takze asi tak.

> CSS 2 je hotova specifikace, alespon z hlediska prace na ni. A o to jde. To, ze mozna neni dokoncena oficialne, je vec uplne jina, a nikoho to nezajima.
A to je přestě to, o čem píšu. De jure není dokončená, de facto je.

> HTML 5 bude z hlediska prace dokonceno v roce 2010 (alespon tak to chapu ja),
Chápete to blbě. De jure bude dokončená 2010. De facto o několik let dříve.
Problém je, že na to nenaskočí výrobci prohlížečů.
Takže asi tak.

Myslim, ze za drivejsi neutesenou situaci kolem bujiciho html mohli "obycejni uzivatele", kteri meli snahu se prezentovat, ale nebyla jina moznost, nez proniknout do taju jazyka, naucit se par tagu a spatlat si vlastni stranku.

Dnes jsou ale moznosti daleko sirsi a k seberealizaci na webu uz zadnou znalost html nepotrebuji, existuji sluzby, ktere vse obstaraji za ne a lepe.

Takze se zajem o html pomalu presouva z rukou obycejnych lidi do rukou koderu, kteri snad budou trosku uvedomilejsi a budou stat o nejaky posun k lepsimu. Nebo k nemu budou donuceni, protoze samotne html je dnes uz davno prekonano, dulezite je jenom jako vstup a vystup k nejakemu systemu na serveru, ktery bude radeji pracovat s prehlednym a usporadanym zobrazenim dat, neze nejakou zprehazenou polivkou.

Nadějí jsou možná mikroformáty. V podstatě nahrazují myšlenku modularizace, o kterou se snaží XHTML, ale nepotřebují ke své existenci žádnou zastřešující organizaci a tím pádem jsou mnohem pružnější. Sice asi časem vznikne nechutná směs navržených a nikým nepodporovaných mikroformátů, věřím ale tomu, že evoluce z nich ty nejlepší vybere a ty se ustálí. Pro řešení záhlaví, zápatí a podobných věcí mi to připadá ideální.

Mikroformaty jsou pakvil. Proc by se proboha mel pro strukturovani dat vyuzivat atribut class? Nechapu, proc XHTML a HTML proste nezavede nove tagy pro strukturovani obsahu. Zrovna pro adresu, telefon atp. je to naprosto trivialni vec. Proc se treba nerozsiri uz existujici tag ADDRESS?

Ani nejstarsi prohlizece s tim problem mit nebudou, protoze vsechny tagy, ktere jejich parsery neznaji, musi ignorovat.

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 :-)