Názory k článku
Život s krvelačným X

... ale za sve jmeno asi ano. Mozna na svem webu standardy porusuje, ale na jinem pilne specifikace dodrzuje.

Z jeho postoju vyplyva, ze nema rad pokrok v podobe revoluce, ale rad by sel evolucni cestou. Taky moznost. To co z toho vznikne bude urcite funkcni a robustni, ale kdo tomu bude opravdu rozumet? Cekaji nas nove povolani? Chirurg webovych stranek? Bude klinika pro standardne chore prohlizece?

| porusovani standardu ale za sve jmeno asi ano.

Jako vtip dobre (no, spis prumerne), ale jako skutecna vytka je to kravina. Tohle je internet, vzdycky se tady pouzivaly predivky - i kdyz na to nejaka skupina nove se prihnanych vesnicanu neni zvykla.

„Autor se nestydi za porusovani standardu, ale za sve jmeno asi ano.“
Jsem patřičně hrdý na všechna svá jména. Zvláštní, že po napsání článku o Exploreru 7 mi nikdo do anonyma nenadával. Scházela motivace. Teď neschází — jsem zlosyn a na „neznámého pachatele“ se špatně plive.

„Mozna na svem webu standardy porusuje, ale na jinem pilne specifikace dodrzuje.“
Na jednom mám dokonce tu hnusnou žlutou ikonku XHTML 1.0 Valid! :-)

pokud jsou mu důvodem vlastní stránky, tak k úmyslnému porušování standardů moc nemá důvod, protože mi připomínají přesně stránky podléhající standardu xhtml 1.0 nebo 1.1... nevšiml jsem si tam žádných prvků, které by nebylo možné udělat validně, takže mi to spíš přijde jako takový výkřik nehorázného porušování, resp. mi to připomíná snahu o vytvoření vlastního rebelského standardu, protože ty kódy nejsou rozhodně žádná prasárna - má v nich jasno...

jinak je to ale těžkej frajer a pohodář, když ani nepíše </body> nebo </html>, možná na to taky najedu :)

osobně standardy taky nedodržuju, bavilo mě to asi tak 3 roky nazpátek, k vývoji přistupuju pragmaticky a moje kódy sou prasárna, a to nemluvím o phpčkách viz. ukazto.com

tohle mi to napsano při první pokusu o odeslání:

V XHTML, které je v textu použité, je chyba. Může se jednat o chybnou, neukončenou nebo zakázanou značku či její atribut. Chyba se pravděpodobně nachází poblíž tučného, barevného a podtrženého místa.
...dyž ani nepíše </body> nebo </html>, možná na to t...

:))

Co se ukonceni zpracovani po nalezeni fatalni chyby tyce: Po zkusenostech s aplikacemi (napr. MS-FrontPage), ktere zamerne generovaly chybny kod, ktery ale byl bez problemu zpracovatelny v MSIE, si neumim predstavit, ze by komise prijala nejaky jiny koncept.

Ze zamerneho generovani chyb se stala marketingova strategie minimalne jedne vyznamne firmy. Konsorcium na to muselo reagovat.

Líbilo se mi, jak se desítky pitomců porvaly pod předešlým článkem anonymního nadpitomce.

Přitom vůbec o nic nejde. Jenom všichni plkaji o syntaxi jednoho ze stovek jazyků.

Takže do toho! Další kolo je tu! Dnes jistě překonáte ne hranici 100, ale 200 stupidních příspěvků!

Jupí

díky za pomoc, už jen 199 stupidních příspěvků podobných tomu tvému a dvoustovka bude doma co nevidět. tak ještě jednou, díky moc, pitomče.

Nezačínejte zas s těmi urážkami !!

Nechápu, co mám být tak špatného a ničivého na požadavku striktnosti. Striktní syntaxi vyžadují všechny programovací jazyky, vyžadují ji i od svých dokumentů. 99_% všeho, s čím se v počítačích setkáváme, funguje právě tak, jak to autor "kritizuje" - pokud je na 89. znaku na řádce 1.547 syntaktická chyba, program zkolabuje. Všichni s tím počítají a zařídili se podle toho (ba i u toho XML už si na to zvykli). A dodržují to, protože vědí, že striktní přístup je vyvážen stoprocentní kompatibilitou a přenositelností.

To, že se HTML zvolilo "relaxed" parsování, je historický relikt, který se W3C právě snažilo odbourat, protože přinesl spoustu problémů a konfliktů. To, že toho automaticky začali zneužívat i autoři HTML a přistoupili i na "relaxed" kódování na vstupu, je logický důsledek (do každých otevřených dveří vždy někdo vstoupí, bez ohledu na velikost cedule). Že by kvůli lepší použitelnosti a snazší dostupnosti tvorby HTML pro veřejnost atd.? Mají snad nějaké problémy exporty do formátů PDF či JPG, které taky vyžadují striktní syntaxi a na chybě zkolabují? Nefungují snad stovky aplikací exportu do XML, kde se každý chybný znak rovněž trestá "smrtí"? Že by stejně nemohly fungovat WWW stránky, je úplně scestné tvrzení.

Mimochodem, všechny prezentace dělané ve Flashi právě tak fungují a nikomu to nevadí. Flash není blbuvzdorný a netoleruje jediný nekorektní bit. A i díky tomu flashe vypadají a fungují zcela stejně v každém přehrávači.

=== Spor mezi anarchistou a standardizátorem je z principu neřešitelný ===

Ale jinak souhlasím, že s tou zatuchlinou je třeba konečně zahýbat. Jestli to bude oživením HTML nebo vymyšlením nějakého rozumného vývoje jiným směrem, je celkem jedno. Hlavně, když to bude ku prospěchu věci a výsledek dobře použitelný.

Fleš funguje v každém přehrávači stejn? V jakém každém? Já měl pocit že je jen jediný od jedné společnosti.

Existuje například Gnash. Držme se ale prosím tématu, ať tu zase není stovka příspevků o něčem jiném.

Jo vytvoren revers ingeniringem maximalne pro verzi 7. Takze pouze 2 verze pozadu. Nezvlada vsecho to co zvlada ten od Adobe. Takze o tom, ze se vsechno zobrazuje ve vsech stejne, nejde mluvit.

Nie je nahodou na citanie Flash volna specifikacia ? Ja si myslim ze je. Proste je to podobne ako s PDF, citat ich moze kazdy, ale vytvarat nie.

Ne, je to právě naopak. Licence ke specifikaci SWF vám umožňuje vytvářet software, který SWF produkuje, tvorbu přehrávače však zakazuje.

http://www.adobe.com/licensing/developer/fileformat/license/

Není. Já mám například v počítači nejméně tři, každý jiný a od jiné firmy.

Kolik dnešních stránek se 100% drží specifikace? Kolik stránek by dnes přežilo nájezd "striktního" (a většinou weby vraždícího) prohlížeče? A jaké procento uživatelů by ho používalo?

Myslíš si snad, že kdyby již od počátku vývoje samotého HTML byl brán důraz na bez chybnost kódu, tak dnes vypadá internet tak jak vypadá?

Web je až moc dynamický na to, aby byl brát důraz na strikní kód.

Nedávno jsem mé stránky posílal jako "aplication/xhtml+xml" (tedy Opeře a Mozzile) - sám jsem si zvolil přesně tu cestu, kterou popisuješ. Cestu 100% bezchybnosti a 100% trestání. Jaké však bylo mé překvapení, když jsem zjistil, že mě web trestá za chyby ostatních (ne well-formed komentáře u článků), trestá mě za chyby, které nemůžu ovlivnit (přerušení stahování)... Takovej adrenalin už nikdy zažít nechci.

To že umožníte vkládat chyby prostřednictvím komentářů je vaše chyba.

Predpokladam, ze o problemech prenositelnosti zdrojoveho kody mezi kompilatory jste neslysel. Jinak byste nemohl tak autoritativne tvrdit, ze "pokud je na 89. znaku na řádce 1.547 syntaktická chyba, program zkolabuje". Zalezi to mnohdy na verzi kompilatoru, na platforme, na niz kompilator bezi, na platforme, na niz program bezi atd...

To, co pozadujete, nefunguje v zadnem programovacim jazyce - leda jako nedosazitelny ideal. A kazdy autor kompilatoru (vcetne GNU, prosim!) si do kompilatoru vesele pridava sva vlastni nekompatibilni rozsireni a interpretuje si standard po svem.

Krok k takto stritknim pozadavkum XHTML je predstava, ze od zeleneho stolu zmenite svet vydanim zakona. Idealisticke, nerealisticke.

„A dodržují to, protože vědí, že striktní přístup je vyvážen stoprocentní kompatibilitou a přenositelností.“
Ke stoprocentní kompatibilitě stačí jasně daná pravidla s minimem nedefinovaných stavů. Drakonismus netřeba. Pokud parser přelouská i Babičku, nic se neděje, pokud ji louskají všichni podle stejných pravidel. Bez drakonismu jsou mírnější důsledky, pochybí-li ten, kdo louská.

„Všichni s tím počítají a zařídili se podle toho (ba i u toho XML už si na to zvykli)“
Určitě? V červenci přestanou mnoha lidem fungovat některé RSS kanály (včetně toho na Pixy.cz), jelikož spousta čteček čte externí DTD ze serveru Netscapu. Ta zmizí.

Velmi často narážím na XML dokumenty s českými znaky, které jsou dodávány s MIME typem „text/xml“ (jako RSS kanál na Pixy.cz), jehož výchozí kódování „us-ascii“ jde přebít pouze běžně neuváděným parametrem charset v HTTP hlavičce a nejsou tedy správně sestavené. Je to zatím ta nejvíce tolerovaná fatální chyba.

„Mají snad nějaké problémy exporty do formátů PDF či JPG, které taky vyžadují striktní syntaxi a na chybě zkolabují?“
Nemají, protože jsou nástroje s nimi pracující takřka bezchybné. U minulého článku jste vy sám psal: „Myslím si, že zcela univerzální XML parser, který by byl bezchybný a zvládl všechny myslitelné obskurnosti syntaxe DTD, ani neexistuje.“ — V tom jste sice pravdu neměl, ale fakt je, že XML procesory v prohlížečích chybují. Nikoliv pouze na obskurnostech DTD.

„Že by stejně nemohly fungovat WWW stránky, je úplně scestné tvrzení.“
Mohly by fungovat. Přechod na toto fungování by však přinesl řadu problémů, kterými současná praxe netrpí.

„všechny prezentace dělané ve Flashi právě tak fungují a nikomu to nevadí“
Zotavení se z poškození bývá u binární směsi nemožné. Půlka programu je vždy k ničemu, půlka dokumentu nemusí být.

„Spor mezi anarchistou a standardizátorem je z principu neřešitelný.“
Minule jsem byl demagog, teď jsem anarchista, příště budu terorista :-)

Smysl standardizace chápu a nezpochybňuji.

pixy byl knockoutovan v druhem kole a nasledne prohlasen za uredne mrtveho...

uklidte ho nekdo, at tu nezapacha...

A jste si jist, že RSS čtečky čtou DTD?

Jste si jist, že vůbec někdo čte DTD?

Jo

Podle nadpisu článku bych čekal kritiku XHTML. A ony jsou to ve skutečnosti dva náměty na vylepšení XHTML.

První se týká přísnosti parseru – osobně si myslím, že vyžadování well-formed XML není na škodu, proč dělat parsery zbytečně složité. Navíc dnes se používají nejrůznější formuláře, skripty atd., které jsou velmi háklivé na chyby v objektovém modelu dokumentu (DOM). Dokumenty, které nejsou well-formed, nejspíš vznikly nějakou chybou (stránka se nenatáhla celá, nějaká část se na serveru vygenerovala špatně). Myslím, že je lepší v takovém případě přiznat uživateli, že došlo k chybě, než se pokoušet to ututlat. Pak se zblázní skripty, uživatel je zavalen chybovými hláškami, pomyslí si cosi o autorovi stránek – ale že před ním ve skutečnosti prohlížeč tají to, že nedostal stránku celou, se nedozví. A i kdyby se vývojáři dohodli na tom, že raději zobrazit něco, než nic – celá přísnost XHTML specifikace spočívá v jediném must v jedné větě, které by stačilo nahradit za may nebo should.

In order to be consistent with the XML 1.0 Recommendation, the user agent must [může být may, should] parse and evaluate an XHTML document for well-formedness.

Druhá věc se týká neznámých jmenných prostorů – byl by dobrý nápad dát do XHTML sémanticky neutrální tag, který bude fungovat jako podmínka – jeho obsah se vykreslí pouze v případě, že prohlížeč zná resp. nezná daný jmenný prostor. Tedy jakási zobecněná podoba microsoftích podmíněných komentářů. Každý prohlížeč se navíc dle své verze může přihlásit k tomu, že zná nějaký svůj jmenný prostor – a hned dokážeme na úrovni HTML rozlišit i jednotlivé prohlížeče (pro případ, že prohlížeč má např. nějakou chybu, kterou chceme obejít). Takže by se pak psalo např.:

<if known-namespace="http://www.w3.org/1998/Math/MathML"
 <math xmlns="http://www.w3.org/1998/Math/MathML">
 …
 </math>
</if>
<if unknown-namespace="http://www.w3.org/1998/Math/MathML">
(a + b)<sup>2</sup>
</if>

Po příslibu v diskuzi pod minulým článkem, že se v tomto pokračování dozvím, jak kombinovat MathML či SVG s HTML, se cítím poněkud zklamán a podveden. Autor v tomto díle totiž o HTML vůbec nehovoří. Tedy milý autore, jak mohu zkombinovat MathML či SVG s HTML?

Právě jsem částečně o tom dopsal článek. V HTML je možné využít element OBJECT, který je v praxi stejně dost často praktičtější. Rozšířit přímo HTML pochopitelně nejde.

Mohl by mi už konečně sdělit jeden jediný důvod, proč cpát BOM do UTF-8 dokumentu? Já o žádném nevím, dokonce jsem toho názoru, že je zásadní chybou tam BOM dát, ale kdykoli jsem se někoho, kdo použití BOM v UTF-8 považoval za správné, zeptal na důvod, nedočkal jsem se odpovědi. Třeba tentokrát budu úspěšnější…

Důvod pro to není, ale třeba aplikace od Microsoftu ho tam vkládají a používají ho pro automatickou detekci toho, zda je soubor uložený v UTF-8 nebo v nějakém windows-125x kódování.

Proboha a proč ty aplikace používáte?

Může to usnadnit určení toho, že je v dokumentu použito UTF-8 kódování, a ne nějaké jiné.

To bych označil za hodně slabý důvod pro to, aby se do textového souboru přidával znak, který tam nemá co dělat a který odporuje syntaxi…

BOM prece syntaxi neodporuje, navic mam pocit, ze zakladni duvod jeho zavedeni byla interoperabilita, aby bylo mozne urcit endianitu systemu, ktery soubor vygeneroval a spravne ho zpracovat. To predchozi normy neresily.

BOM se začal používat proto, aby bylo možné rozlišit UTF-16LE od UTF-16BE, takže je-li první znak souboru BOM (tedy nedělitelná mezera nulové délky nebo co to bylo původně), lze ho označit za UTF-16 a ten, kdo ho načítá, hned ví, zda je zbytek souboru little endian nebo big endian UTF-16. Před dalším zpracováním by ale měl tento znak vynechat, takže veškerá práce už by měla probíhat bez něj. UTF-8 je ale na endianitě nezávislé, takže neexistuje žádné UTF-8LE a UTF-8BE, ale jen jedno jediné UTF-8, a proto je nesmysl při ukládání v UTF-8 přidávat nějakou značku navíc.

Minuly clanek me moc neoslovil, ale tenhle semi opravdu libi. Prinejmensim mam ted namet k zamysleni - mam nebo nemam psat v XHTML? I ja chci byt v duchu Postelova zakona konzervativni v tom, co produkuji, a liberalni v tom, co prijimam - ale mam byt konzervativni i za cenu toho, ze pak vystup nebudou moci mnozi uzivatele vubec prijmout?

Dokud chceme dokument pouze zobrazovat, tak si do jisté míry můžeme dovolit ignorovat v něm chyby. Koneckonců ten text v tom najde i ten nejhloupější parser a vždycky se to nějak zobrazí. Mohli bychom asi diskutovat do nekonečna, jestli je lepší, když se zobrazí něco špatně, nebo když se to nezobrazí vůbec.

Z dlouholetého programování mám ale takovou zkušenost, že čím striktnější programovací jazyk, tím spolehlivější výsledný program. Je lepší, když se to kvůli chybě rovnou nespustí a programátor chybu opraví, než když se to tváří, jako že v pořádku a v tu nejhorší možnou chvíli to začne produkovat nesmysly. To je problém třeba JavaScriptu, kde zprávy o chybách většina prohlížečů dovedně skrývá a člověk pak může jen doufat, že se jeho data zpracovala, když vidí v rohu obrazovky ikonku že "stránka obsahuje chyby".

Stejně tak můžeme jásat, že si omezená množina nám známých prohlížečů s chybami poradí konzistentně. Ale to neznamená, že když si příští rok někdo zobrazí naši chybnou stránku na svém zánovním PDA ve v té době módním prohlížeči, že ji uvidí stejně. Autoři toho prohlížeče totiž sice možná vzorně implementovali všechny standardy, ale nikde nenašli, co s nestandardy. Proto je striktnost sázka na jistotu a je dobré k ní autory kódu nutit.

Ano, to je přesně to, o čem pořád mluvím.

Proto je striktnost sázka na jistotu a je dobré k ní autory kódu nutit.

A proč je k tomu nutit? Je přece v zájmu každého autora, aby generoval korektní HTML/XHTML kód bez chyb a měl tak jistotu, že jej prohlížeče budou správně načítat.

V zájmu? Proč? Když vím, že prohlížeč mi zobrazí i HTML s chybama? V situaci, kdy se nejznámější chyby dokonce používají úmyslně jako "vychytávky" (fungující pohříchu třeba jen v jednom prohlížeči)? A k tomu naopak v situaci, kdy i ten správný kód různé prohlížeče stejně zobrazují různě (často nejspíš kvůli té nejednotnosti parserů a přílišné vůli v rozhodování)?

Pokud nebude muset, tak to nikdo dělat nebude, nebuďme tak naivní...

„A k tomu naopak v situaci, kdy i ten správný kód různé prohlížeče stejně zobrazují různě (často nejspíš kvůli té nejednotnosti parserů a přílišné vůli v rozhodování)?“

Koľko takých situácii existuje?

Stale. Skus si spravit krkolomne riesenie a zobraz si ho prehliadaci. Nikdy nie je 100% iste, ze sa zobrazi vsade rovnako.
Ci Vy robite stranky len pre tri prehliadace ? Tak to ak by som mal web developersku firmu nikdy nezamestnal.
Sorry, ale to pravda.

Ak vsak robim vramci noriem tak mam najvacsiu istotu, ze sa to na kazdom prehliadaci, ktory tuto normu implementoval , zobrazi rovnako.

Ci o co ine islo XHTML ? Presne definovat co je nutnost. Urobit mantinely. Rozmyslat ma clovek, stroj ma len spracovavat.

Za dost velku slabinu povazujem vsak uplne odstavenie nefunkcnosti stranky aj pri malej chybe. Aj ked to je dvojsecne. Vyhoda je, ze nas to nuti pisat syntakticky spravne weby, ujma vsak je ta, ze kvoli neadekvatnemu pristupu uzivatela z vonku (fora, komentare) sa uplne nie mojim pricinenim nebude zobrazovat stranka.

Ocenujem na tom XHTML, ze priniesol cistotu do zapisu no vsak chybne sa definovala jedna podstatna vec. W3C zabudlo, ze XHTML != XML a tym padom sa na nom nedaju pouzit uplne vsetky pravidla. Je to predsa iny jazyk, presne definovany co XML z principu nie je.

„Stale. Skus si spravit krkolomne riesenie a zobraz si ho prehliadaci. Nikdy nie je 100% iste, ze sa zobrazi vsade rovnako.
Ci Vy robite stranky len pre tri prehliadace ? Tak to ak by som mal web developersku firmu nikdy nezamestnal. Sorry, ale to pravda.“

Denne robím niekoľko krkolomných riešení a nikdy to nemá nič spoločné so značkovaním. Koniec koncov, dobrý kóder nerobí nikdy krkolomné riešenie na strane štruktúry. Problémy a rozdiely vo vykreslení sú vždy spojené s chybnou a odlišnou implementáciou CSS.

A o tom bola aj moja pôvodná otázka. Týkala sa značkovania, nie CSS. Myslím, že ľudí čítajúcich tento článok, ktorí sa vôbec zaujímali rozdielmi v prehliadačoch na základe značkovania, by som spočítal na prstoch jednej ruky.

Hlavne je potrebné uvedomiť si, že hovoríme o značkovaní, štruktúre, nie o forme, CSS.

...ujma vsak je ta, ze kvoli neadekvatnemu pristupu uzivatela z vonku (fora, komentare) sa uplne nie mojim pricinenim nebude zobrazovat stranka.

Nedostatečné ošetření vstupů je chyba pouze a jen programátora. Používejte na komentáře Texy! a nemusíte mít obavy.

Samozrejme viem, ze to je chyba programatora, ktory ma overovat ci sa ukoncovaci tag vobec niekde nachadza a ked nie tak zruzi zaciatocny, ale to je trochu zlozite.

Texy poznam, nic proti, ale mam radsej klasicke bbTagy, tie vselijake hviezdicky a ine prkotiny su akurat neprehladne.

No ono je to v záujme majiteľa stránok, autorom kódu je väčšinou niekto iný, a potom to tak vyzerá:
1. autor kódu často nenesie žiadnu zodpovednosť za výsledný kód, zhrabne prachy a už nemá z webom nič spoločného
2. majiteľ stránok sa často nevyzná, nevie si skontrolovať výsledok a tak nevie že kúpil mačku vo vreci, prípadne rieši niektoré problémy sám a potom to dopadne často ešte horšie..
3. návštevník stránok je vystavený na pospas tomu čo 1+2 dali dokopy a je na ňom či z toho odíde zo všetkými vlasmi na hlave

..ale to už je iná rozprávka...

V okamziku, kdy zavedete standard tim, ze date k dispozici validator a reknete "je to spravne dle standardu tehdy a jen tehdy, pokud to validator schvali", fajn.

Jinak se dostavate - i u seberestriktivnejsi definice - do pasti toho, ze neco v kodu je spatne ale stavajici nastroje to skousnou a budouci na tom spadnou.

Opäť fajn článok, ktorý sa dobre číta. Tá snaha o (samo)trestanie mi príde tak trochu sadisticko/masochostická, možno to drieme v podvedomí časti wedesignérov... ktovie čím to je? :-) Inak články autora majú tradične nielen dobrú informačnú hodnotu, ale aj dobre pobavia. A tá správna zábava sa dá vždy čakať aj v komentároch, ale to už je iná pesnička. :) Tento štýl písania o technických témach je osviežujúci!