80 komentářů k článku Webdesign po deseti letech. Dělat weby je zase radost:

  1. Jan Sládek

    RE: Webdesign po deseti letech. Dělat weby je zase radost
    Moc hezký rozbor toho, jakou dlouhou cestu web během let ušel. Velké díky Pixymu za napsání a Martinovi za vydání.

  2. juras

    Co bue s SVG a MathML
    Když je XHTML mrtvé, tak jak budeme zapisovat na webových stránkách vzorce a vektorovou grafiku? Nebo se snad v HTML5 chystá možnost vkládání MathML a SVG stejně jednoduše, jako v XHTML?

    1. Anonym

      Re: Co bue s SVG a MathML
      To je záležitost prohlížečů. Jeden pomězně málo známý prohlížeč to zvládne, v aktuální verzi 11 jsem ověřil zobrazení takto vloženého SVG obrázku, že to jde jsem se nedávno dočetl od Chamurappiho.
      Opera a Webkit a výše zmíněný prohlížeč umí i školácky jednoduchou konstrukci <img src=obrazek.svg>, prohlížeči Opera "chutná" SVG i v CSS jako backgound nebo list-style-image.

      1. František Kučera

        Re: Co bue s SVG a MathML

        Ano, ale do XHTML jde vkládat SVG rovnou do stránky díky jmenným prostorům – ne jen jako odkaz na externí dokument. Totéž ta matematika.

    2. Martin Hassman

      Re: Co bue s SVG a MathML
      Nebo se snad v HTML5 chystá možnost vkládání MathML a SVG stejně jednoduše, jako v XHTML?

      Ano, autoři HTML5 ve spolupráci s tvůrci MathML a SVG o něčem podobném uvažují, ale zda najdou nějakou schůdnou cestu, zatím těžko říct.

    3. Jáchym

      Re: Co bue s SVG a MathML
      Ono SVG je už dost dobře podporované i dneska a knihovny jako OpenLayers (viz příklad) s tím počítají. Na IE to zatím funguje přes obezličku VML, ale ohlašovaný IE9 by to měl (konečně) změnit.

    4. Filip Jirsák

      Re: Co bue s SVG a MathML
      Bude to nejspíš úplně stejně, jako u současného HTML. Použije se tam něco velmi podobného XML, co se bude lišit jen v některých okrajových detailech — tak, aby to znemožnilo pracovat s tím jako s XML. Vzor si můžeme vzít ve jmenných prostorech v HTML, které na tomhle principu fungují. Hlavně že odpůrci XML budou spokojeni, že "uhájili" HTML.

      1. next_ghost

        Re: Co bue s SVG a MathML
        Bejt tebou, tak bych do matfyzáků moc nerejpal. Mohlo by se ti stát, že budeš do konce života počítat na abakusu a psát na psacim stroji. ;-)

    5. Jirka Kosek

      Re: Co bue s SVG a MathML
      HTML5 má dva způsoby serializace — HTML a XML. Takže pokud potřebujete vkládat fragmenty XML do HTML5 dokumentů, můžete použít XML serializaci (někdy se jí také říká XHTML5).

      Navíc se pracuje na tom, aby se práve MathML a SVG dalo přímo vkládat i v HTML syntaxi. Ale jak to nakonec dopadne, není úplně jasné.

  3. Anonym

    delat weby je zase radost ?
    Nechcem Vam brat to nadsenie ale ja teda taky "radostny pocit" z toho nemam.Stale je dost IE6 na trhu, ale s tym sa nic nenarobi to chce cas.Frameworky na strane serveru su bud prehnane mohutne alebo su to len hlupe kniznice kde vsetko treba to toho zlozito narvat.Dnesne az nebezpecne nadsenie nad Javascriptom ma zaraza.Jednak frameworky (pripadne aj s gui/grafikou) ktore su strasne rozsiahle (Extjs a pod) ktore sa ale zle ohybaju/upravuju takze paradoxne sa hodia na jednoucelove veci, alebo potom ostatne ako jquery a pod. kde aj tak treba vecsinu veci si doroboti.Ostatne mam pocit ze pre vecsie projekty sa aj tak oplati naspisat si vsetko sam na mieru.A tiez vykonnostna nenazranost javascriptu s domom je nechutna.Dalej z predchadzajuceho boja o standardy sa teraz stava zasa boj o rychlejsi jscriptovy interpreter google vs mozilla.Ako tak pouzitelny je flex a silverlight ale ani to neni ono.No a prave tej vasej vety ze je mozne spravit hocijaky design mam strach.Dost ludi si to vyklada ze nie len design je mozne spravit hocijaky ale aj rovno aplikaciu.Priznam sa nechapem preco sa tlaci office na web, bitmapove editory na web a dalsie aplikacie.Uz beztak je dost humus ze na desktope zacina vladnut ten podivne interpretovany kod (java/.net).
    Zaver je skor ze sa web akurat tak viac znasilnuje.

    1. Standa

      Re: delat weby je zase radost ?
      Souhlas, velmi dobře popsáno. Až na tu poznámku "java/.net" – ty už jsou tak daleko, že co do rychlosti jsou skoro na úrovni nativního kódu (s pamětí už je to horší, ale koho to trápí).

      1. Anonym

        Re: delat weby je zase radost ?
        no s tou vykonnostou je to vzdy problem ale fakt pri beznych aplikaciach je to asi jedno,budu to nejake jednotku percent.To pomalsie startovanie a vyssia pametova narocnost "java/.netu" to sa este da zvladnut, ale fakt netusim ake plusy to ma pre dnesny sw.Interportabilita pri jave skoncila a je to len fikcia a .net ani s niecim takym neratal.Jazyky su to dobre (java,c#), objektovy model a rozsah kniznic to vsetko beriem ale preco to nemoze byt kompilovany kod ? A vyhody typu ze je to bezpecnejsie a aplikacia bezi v sandboxe su blbost.Bezpecnost sa da dosiahnut aj beznymi prostriedkami os a dovolim si tvrdit ze 90% beznych uzivatelov na desktope ani netusi kde si moze nastavit napriklad parametre pre .net app.
        A co sa tyka vykonnosti tak si skuste povedzme v MS SQL management studio zobrazit nejaku vecsiu tabulku v gride.Len skrolovanie je otrasne aj na dual masine.Cele je to napisane v .NETe.Pritom hocijaky sql klient ktory je klasicky kompilovany a nepouziva .net je v pohode.

        1. Anonym

          Re: delat weby je zase radost ?
          Tak si ty javovský zdrojáky kompiluj. Kompilátory do strojového kódu existují.

          1. benzin

            Re: delat weby je zase radost ?
            1) Kompilovana java do nativu je pomalejsi.
            2) Pametovan nenazranost javy je dost znacna a kdyz budete mit na pocitaci podobne komplexni aplikaci jako Office v Java zjistite ze si k tomu uz ani ten prohlizec skoro nepustite.

            1. Anonym

              Re: delat weby je zase radost ?
              ad 1] To byla trochu sarkastická reakce na to, že přispěvovatel výše z nějakého důvodu baží po kompilaci do nativním kódu. Tu možnost má :) Výhody/nevýhody musí zvážit sám.
              ad 2] Bohužel paměťová nenažranost nejen javy je dost značná :-/ Příkladem budiž firefox v c/c++. Spíš jde o to, jak je daný SW udělanej. Program v java může být klidně paměťově velmi úsporný. Ne že by to bylo pravidlo :)

    2. Pedro

      Re: delat weby je zase radost ?
      Pripajam sa k tomuto nazoru. U nas je realita taka, ze 90% browserov je IE6 (+WinXP). Internetova apliakcia, okolo 4000 prihlasenych userov, okolo 12000 zaregistrovanych. AJAX / Javascript len sity namieru, dolezity je aj security audit. CSS ma tiez svoje hranice.
      Ja by som skor povedal, ze to nie je ani horsie ani lepsie, ako to bolo. Resp. od cias "gopher na vax terminale" je to stale komplikovanejsie – miesto obsahu sa viac dba na formu. Chapem, z eniekedy je to nevyhnutne, ale preco uplne vzdy? Nasi uzivatelia potrebuju informacie hlavne rychlo, a len patricne mnozstvo. Vsetko naviac povazuju za obtazovanie. A animovane posuvanie okien je sice pekny marketingovy tah, ale neuveritelne otravujuci – nas manager to vola iphone efekt, a cpe to vsade. a mna ide z toho drbnut, lebo na jeho quad core super-duper compe to vyzera OK, ale pracovnici v terene s netbookmi sa z toho mozu aj to….

      1. Martin Hassman

        Re: delat weby je zase radost ?
        V tom případě to spíše vypadá, že vás "lokálně" panují podmínky, které na celém Webu byly možná tak před 5 lety. Patrně nebudete jediný, takových ostrůvků, zej. na intranetech, se v ČR najde určitě víc, ale rozhodně to není obvyklá situace na celém Webu (ani na celém Webu v ČR).

        1. Pedro

          Re: delat weby je zase radost ?
          No na prvy pohlad to tak mozno vyzera. Ale prax je taka, ze strasne vela klientov si velmi oblubilo netbooky. A atom N270 sa jednoducho vykonnostne neda porovnavat s dual core CPU. Vista tiez nie je oblubena na netbookoch (preto aj IE6). Casto sa browsuje mobilne, UMTS nie je vsade, tak sa ide cez GPRS. Teda musime optimalizovat na rychlost a prehladnost. Samozrejme vyuzivame AJAX, XML, JavaScript, CSS (WEB2.0 ako by povedal moj manager :) ) ale nemoze sa to robit na ukor funkcionality a rychlosti. Samozrejme ma AJAX zmysel, napr. na zobrazenie zakladnych udajov, a na pozadi sa stahuju zvysne udaje. Ale nejake animacne efekty (ako som vyssie spominal napr. "iPhone efekt") sme nastastie museli killnut ;)

          1. javlada

            Re: delat weby je zase radost ?
            A na netbook s XP se nedá nainstalovat Firefox, Opera, Chrome, Konqueror, Safari a nebo třeba i IE7 a IE8 (až bude)? Proč by tam měl být nutně IE6, který má 10x pomalejší zpracování Javascriptu než ostatní prohlížeče?

              1. javlada

                Re: delat weby je zase radost ?
                No tak kde je potom ten problém s netbooky? Pokud tam je dobrý prohlížeč, tak s JavaScriptem, CSS a AJAXem není žádný problém. Atom procesor na to celkem v pohodě stačí, samozřejmě si uživatel počká chvilku dýl než na dvoujádrovém stolním PC. Ale s tím snad uživatel počítá, když si pořídí levný minipočítač.

    3. Anonym

      Re: delat weby je zase radost ?
      Specialne se "nebezpecne nadseni z javascriptu" projevuje jeho pouzivanim i tam, kde vubec neni potreba (neni problem narazit na stranku, ktera bez js nefunguje, protoze js otevira treba popupy s obrazky a obycejny href k obrazku chybi).

      Ma to i bezpecnostni dusledky – velka cast security advisories k prohlizecum vyzaduje zapnuty js k exploitaci (typicky "heap spraying" aby se spustil kod).

    4. Pavel Šimek

      Re: delat weby je zase radost ?
      Proč se tlačí kancelářské aplikace a další na web? No já osobně jsem na to čekal celý život – nechci trávit čas instalací, nastavováním a údržbou SW pokaždé, když si koupím nový počítač, telefon, atd. Chci spustit prohlížeč a být ve stavu, kde jsem byl předtím na jiném (starém, cizím…) stroji. Zaplaťpánbůh za Google apps, acrobat.com, atd. atd.

    5. uživatel si přál zůstat v anonymitě

      Re: delat weby je zase radost ?

      Copak, my ještě žijeme v době HTML 3 a 256 MB RAM?

      A .NET není intepretovaný, chytrolíne. Tam je JIT kompilace, bytekód se poprvé zkompiluje rovnou do nativního kódu a tak už ZŮSTANE. A frameworky na straně serveru jsou přehnaně mohutné? Možná v tom poťapaným amatérským PHP, ale ASP.NET, to používat je radost. Pokud už si dodávám nějakou 3rd party komponentu nebo třeba třídy pro práci s nějakým API, všude jsou to jenom zkompilované knihovny DLL.

  4. Antonin Hildebrand

    Moc pekny clanek
    Pri jeho cteni me nostalgie, kdyz jsem si vzpomnel jak jsem placal svuj prvni web v GoLive :-) Tuto zkusenost jsem uz davno vytesnil z hlavy.

  5. Dlouhán

    Strictní doctype

    Jistě, chce to mimo jiné i používat striktní DOCTYPE a dalekým obloukem se vyhýbat zlu jménem quirks mode…

    To má nějakou souvislost? Můžu využívat výhod standardního vykreslovacího režimu MSIE a současně namísto ořezané verze HTML mohu používat plnou verzi, skromně nazvanou Transitional.

    Díky za výborný článek, budu jej odkazovat fňukajícím začátečníkům.

    1. Petr StaníčekAutor příspěvku

      Re: Strictní doctype
      V MSIE ano (pokud ovšem použijete DOCTYPE včetně URL). Ale Transitional HTML 4 se nevykresluje zcela striktně v Gecku. Ano, tam to sice není "quirks mode", ale takový ten hybrid "almost/pseudo standard mode", což taky není ideální. Viz ten link v článku příp. http://wellstyled.com/html-doctype-and-browser-mode.html

      Osobně ale dnes nevidím k použití Transitional DOCTYPE smysluplný důvod. Vy ano? K čemu to může být dobré, zajímalo by mě to. Dík.

      1. blizz.boz

        Re: Strictní doctype
        napr. mozes pouzivat element menu, striktny dtd ti umozni len semanticky nespravny element ul.

      2. Chamurappi

        Re: Strictní doctype

        ale takový ten hybrid „almost/pseudo standard mode“, což taky není ideální.
        V čem přesně to není ideální? To kvůli těm cca dvěma rozdílům oproti standardnímu režimu, které kodér stejně musí ošetřovat i v Exploreru? Tobě záleží na tom, jestli máš exkluzivně v Mozille pod obrázkem místo na nožičky? Člověk, který si nepřečte, že skoro-standardní režim existuje, se o jeho existenci pravděpodobně nikdy nedozví.

        Osobně ale dnes nevidím k použití Transitional DOCTYPE smysluplný důvod.
        Někdo třeba chce mít validní stránku a zároveň používat <menu>, číslovat si jinak <ol> nebo směrovat výsledek formuláře do <iframu>. Viz můj článek.

        Pokud HTML 5 na něco navazuje, tak na HTML 4.01 Transitional. Nikoliv na Strict. Jaký máš smysluplný důvod k použití Strictu?

        1. Petr StaníčekAutor příspěvku

          Re: Strictní doctype
          Já používám Strict a žádné dva rozdíly nikde neošetřuju. Což je odpověď i na ten dotaz: Strict používám především proto, že mi zaručuje maximálně shodné chování všech prohlížečů.

          A víš co? Ty můžeš svobodně používat Transitional a já zase Strict, nikomu to nevadí a všichni jsme spokojeni.

  6. David Grudl

    Drakonické parsování

    Situace, kdy stávající kreativní, „blbuvzdorné“ parsery HTML byly
    schopné přeložit málem i první kapitolu Babičky a něco podle toho
    vykreslit, mi prostě přišla z principu špatná. Naopak jednoznačné,
    drakonické parsování XML, nepřipouštějící jakoukoli syntaktickou chybu,
    se jevilo jako čisté, logické řešení.

    Jak se to vezme. Na drakoničnost nebyl nový jazyk vůbec potřeba,
    drakonicky se dalo parsovat i HTML (myslím „HTML“, tj. standardizované
    HTML, nikoliv tag soup). Nicméně i ve světě XML se brzy ukázalo, že
    drakonický přístup nelze ustát – např. uživatelé chtěli RSS čtečky,
    které fungují a nehlásí parse-error, byť chyba byla na straně nevalidního
    RSS feedu. Takže se i obdoby HTML prohlížeču, tedy RSS čtečky, naučily
    parsovat kapitoly z Babičky. A historie se opakuje, jen tu máme zbytečně
    dva jazyky.

    XHTML bylo významné spíš z hlediska osvětového, než technického.

    1. Martin Hassman

      Jak to nedrakonické parsování vlastně celé začalo
      Přikládám takovou historickou poznámku pro všechny, kdo se zamýšlí na tím, kdy, proč a jak se ona volnost do HTML dostala:

      Bylo to hned na začátku – v prvním webovém prohlížeči na světě WorldWideWeb od TBL. Co si na ty jeho zdrojáky ještě pamatuji, tak jeho HTML parser měl nějakých slabých 2-3 tisíce řádek a hlídal si hlavně počáteční značky, tj. ani se nezajímal o to, na jakou koncovou značku právě narazil – když na nějakou takovou značku narazil, jednoduše ukončil poslední otevřenou HTML značku, co měl (tj. neměl v tomhle místě žádnou kontrolu na překřížené značky, byl to jednoduchý zásobník – o úroveň dovnitř, o úroveň ven). V tehdejším jednoduchém HTML (nějakých 20 značek) tenhle primitivní nějak fungoval.

      Hlavní ovšem je, že TENKRÁT TO VŮBEC NEVADILO, protože webový prohlížeč WorldWideWeb byl zároveň WYSIWYG editorem HTML. A tak to mělo podle návrhu TBL také zůstat na věky. Tvůrci webových stránek měli používat tento editor a neměli s HTML značkami vůbec přijít do styku (jazyk HTML tedy nebyl primárně navržen, aby jej používali lidé, nýbrž stroje!). A jelikož WYSIWYG editor tvořil stránky bezchybně, bylo vlastně šumafuk, zda budou parsované drakonicky nebo ne.

      Jak sami víte, tohle TBL příliš nevyšlo. Snad žádný další webový prohlížeče té doby (a že jich vznikly během pár let asi dvě desítky) neobsahovat WYSIWYG editor. A ukázalo se, že autoři webů docela ochotně ručně píší "ty divné značky v lomených závorkách". Tady nastal problém, protože tady se začaly do HTML dokumentů vkrádat chyby jedna za druhou. Jenže ty další prohlížeče zřejmě na volné parsování HTML prostě navázaly (tuhle oblast nemám pořádně prozkoumanou, ještě jsem ty všechny jejich parsery neprošel) a bylo to hotovo, již se nedalo vycouvat.

      Tenhle mezník, kdy se z HTML coby jazyka psaného stroji stal jazyk psaný lidmi, je tím klíčovým momentem, který se nedokázal podchytit. TBL se o to snažil, ale možná jinak, než si myslíte – snažil se přesvědčit ostatní prohlížeče, aby to udělaly podle něj a také implementovali WYSIWYG editory. Marně. Kdyby se je tenkrát místo toho snažil přesvědčit, aby začaly parsovat HTML striktně, možná by uspěl a celá historie HTML by byla jinak.

      Otázka zní, zda právě tohle, zda právě tenhle "omyl" nepřispěl k rychlému a masivnímu rozšíření HTML. Já si myslím, že ano, ovšem přesvědčit se o tom nemůžeme, takže nám tu zbudou jen věčné dohady, zda by to s tím přísným přístupem hned od začátku třeba náhodou nedopadlo stejně nebo třeba taky mnohem líp.

      Kdysi jsem se o tom trochu zmiňoval na Lupě http://www.lupa.cz/clanky/mate-tam-chybu-time/

      1. Anonym

        Re: Jak to nedrakonické parsování vlastně celé začalo
        podla mojho skromneho nazoru je skor problem ten ze z HTML,volne prelozene jazyk na popisovanie/ukladanie hypertextu, sa stalo nieco co ma byt nejaky aplikacno datovy popis/api/platforma.Web mal zostat tym cim bol – ukadanie dokumentov a textu.To co sa teraz deje to je zverstvo.
        A co sa tyka kvality kodu, stacilo by drasticke opatrenie keby browseri nekorektnu stranku proste nezobrazili.Autori stranok by museli danu webu opravit aby bola validna a funkcna.

        1. Martin Hassman

          Re: Jak to nedrakonické parsování vlastně celé začalo
          stacilo by drasticke opatrenie keby browseri nekorektnu stranku proste nezobrazili

          Něco takového je dnes u HTML nemožné. Chyba, kterou jsem popisoval, nastala počátkem 90. let a tehdy se skutečně dala vyřešit. Dnes už je pozdě a stávajíc stav potrvá tak dlouho, dokud potrvá Web.

    2. kravinky

      Re: Drakonické parsování
      Pořád se xhtml parsuje řádově líp než jakýkoliv html, i 5 samozřejmě. Takže xhtml 1.0 strict budu používat nadále pro projekty, kde je parsování výsledku alfa omega, a kravinky typových inputů ve formuláři nepotřebuju.

        1. kravinky

          Re: Drakonické parsování
          To jsme si nerozumněli. Já mám naprostou kontrolu na tim, jak bude vypadat výstup, neparsuju cizí výstupy, a tím pádem mám parser postavenej tak, že stačí, že umí to, co mu předložim, a nemusí umět takovýhle čuňárny.

          1. Chamurappi

            Re: Drakonické parsování

            Takový argument je nezávislý na formátu. Říkáš, že umíš pohodlně rozebrat to, co si sám sestavíš. Já si také hravě přečtu své nevalidní HTML a mému parseru se také řádově lépe žvýká HTML než jiné formáty.

            Prakticky vzato ale málokterý webmaster potřebuje rozebírat výsledný produkt, který servíruje návštěvníkům. Kódy baští hlavně prohlížeč, a proto by formát měl být v symbióze především s ním.

        2. Aleš Friedl

          Re: Drakonické parsování
          FF3 to jako xhtml bere, jako html ne, takže mi to připadá že to zní spíš ve prospěch xhtml?

      1. Radek

        Re: Drakonické parsování
        Ale to je přece opačný případ. To co v prohlížeči zpracovává XHTML stránky není plnohodnotný XML parser. O tom není pochyb. Pointa je v tom, že XHTML stránku napsanou pro prohlížeč (tzn. v té chudé podmnožině XML, kterou prohlížeče správně zpracují) je schopen zpracovat každý XML parser. V základu PHP je jich několik s různým rozhraním, v Javě nepočítaně, v C++, v Pythnou, Perlu, … prostě tu stránku načtu a zpracuji, ať už používám cokoliv. Naopak HTML parser mimo prohlížeč, který z 'tag soap' vyrobí korektní DOM nebo jeho obdobu, aby hledal s lupou. A to už nemluvím o možnosti použít na takovou stránku třeba xsltproc nebo ji přímo nahrát do XML databáze. Možná je automatické zpracování HTML už za horizontem pro běžného webdesignéra, pro kterého svět končí prohlížečem. Ale mě jako programátorovi, který tohle musí řešit, pohaslo vznikem HTML5 veliké světlo naděje.

    3. onyx

      Re: Drakonické parsování
      Velmi striktní parsování XHTML je hloupost. Může fungovat pouze v ideálním světě, kde prohlížeč XHTML kódu je bezchybný. Ale jak známo, vše, co je dílem člověka může obsahovat chyby, na které vývojáři nepřijdou, ale několika uživatelům se objeví. Zvlášť velká slabina XHTML prohlížečů je to, že mají předepsány situace, ve kterých mají selhat (čili ukončit zpracování stránky a zobrazit chybu) a ve kterých ne. To je z hlediska uživatelů nesmysl, neboť je nezajímají chyby, je zajímá obsah. Takže XML funguje pouze v případě kombinace bezchybný prohlížeč + bezchybně napsaný kód. Bezchybně napsaný kód lze možná zaručit, bezchybně napsaný prohlížeč nikoliv.

      Existuje ještě jeden silný důkaz o neúspěšnosti XHTML. Podstatná většina stránek, které i přesto, že jsou napsány v XHTML jsou odesílány s Content-type: text/html , místo toho aby byly odesílány s Content-type: text/xml , Content-type: application/html+xml či nějakým jiným, který označuje, že jde o XML, aby se obešla kontrola správnosti sestavení XML.

      Dovolím si tvrdit, že ani jeden z prohlížečů nezpracovavá XHTML podle XML specifikace, možná kromě prohlížeče Amaya. Ostatní buď neselhávají v situacích, kdy by selhávat měly, nebo selhávají v situacích, kdy by selhávat neměli.

      1. Aleš Friedl

        Re: Drakonické parsování
        Jako text/html se neposílají kvůli obejití správnosti, autoři kteří mají opravdu stránky v xhtml, by je velmi rádi i poslali jako xhtml, ale nedělají to kvůli jedné jediné chybě v MS IE a jeho quirks mode :) Kvůli MS IE tudíž nemohou posílat xhtml, ale zbývá jen staré "dobré" html. Nebýt IE, bylo by to nejspíš jinak. Pokud nebylo, pak teprve by šlo hovořit o nějakém důkazu.

        1. Timy

          Re: Drakonické parsování
          To si nemyslím. Plno webů posílalo XHTML jako "opravdové" XHTML alespoň Firefoxu (A obecně prohlížečům, které to zvládaly), ale už tak nedělají. Za všechny třeba http://www.w3.org :-).

          1. petr_p

            Re: Drakonické parsování

            Jestli to nebude tak, že pečlivý správce nastavil XHTML a pro IE výjimku, a pak přišla lama a celý mu to „zaktualizovala“.

      2. Sten

        Re: Drakonické parsování
        Tohle jsem taky řešil a vyřešil jsem to tak, že mám engine, který podle Accept hlavičky vrátí buď XHTML s Content-Type application/xhtml+xml nebo text/xml nebo HTML s Content-Type text/html. Ono totiž posílat XHTML jako text/html je dost rozšířená prasárna.

      3. iooo

        Re: Drakonické parsování
        Velmi striktní parsování C++ je hloupost. Může fungovat pouze v ideálním světě, kde komilátor C++ kódu je bezchybný. Ale jak známo, vše, co je dílem člověka může obsahovat chyby, na které vývojáři nepřijdou, ale několika uživatelům se objeví. Zvlášť velká slabina C++ kompilátorů je to, že mají předepsány situace, ve kterých mají selhat (čili ukončit komilaci kódu a zobrazit chybu) a ve kterých ne. To je z hlediska uživatelů nesmysl, neboť je nezajímají chyby, je zajímá aby to "nějak jelo". Takže C++ funguje pouze v případě kombinace bezchybný komilátor + bezchybně napsaný kód.

        Není to odověď na otázku, proč i Franta vod vedle, kterej na základce 3x propadl je dnes Top Web Designer?

        1. David Grudl

          Re: Drakonické parsování
          Proč tento argument nefunguje vlastně dokonale vystihuje rozdíl mezi programovacím a značkovacím prezentačním jazykem. Všimněte si, že společně s HTML se vyvíjel i JavaScript, obojí vždy v jednom prohlížeči, a zatímco u JavaScriptu je jakákoliv chyba v kódu fatální, u HTML se toleruje.

          HTML totiž spíš než k programovacímu jazyku můžeme přirovnat k bitmapovému obrázku. Pokud se v JPEG objeví chyba, je obvykle lepší, pokud jej dokáže prohlížeč alespoň nějak zrekonstruovat (ať už web browser nebo bitmap editor), třeba s upozorněním, než zcela odmítnout.

          U programovacích jazyků je tomu právě naopak.

          Přičemž i XML může vystupovat v opačné úloze, než která platí pro XHTML nebo RSS. Například u API webové služby, které komunikuje v nějaké aplikaci XML, je záhodno netolerovat žádnou odchylku.

          1. Martin Hassman

            Re: Drakonické parsování
            Máš pravdu. Já bych HTML jen spíš přirovnal k formátům pro uchovávání informace jako je PDF nebo takový ty palmbooky. Vůbec mě nezajímá, zda a kolik chyb se v takovém souboru nachází. Chci, aby z něj čtečka dostala maximum, co dokáže.

  7. Martin Soukup

    Dělat weby je radost? Ani náhodou!
    Pixy se musel na stará kolena dočista pomátnout! Jestli opravdu na stránky vkládá složité prvky jedním klikem a pak mu všechno na první pokud funguje v celé škále IE, FF a dalších, tak to mu gratuluji!

    Moje praxe je jiná. IE7 má bugy, o kterých se nám dříve ani nezdálo, na trhu je dále IE8 a s nezanedbatelným podílem i IE6 (dvacet procent!!) a složité prvky se musí složitě naprogramovat. Řady obskurních prohlížečů se nazenedbatelně rozrostly (iPhone, Android, Safari) a testování zabírá nejvíce času.

    Radost to není ani omylem. To by musel být člověk masochista.

      1. Martin Hassman

        Re: Dělat weby je radost? Ani náhodou!
        Soudě podle ankety s autorem (do nějaké míry) souhlasí nějakých 80% čtenářů, což mě osobně velmi těší a doufám, že to také na českém webdesignu bude znát.

        1. Dorian.Podulka

          Re: Dělat weby je radost? Ani náhodou!
          Anketa je poněkud neštastná; už z principu vývoje by mělo být stále lépe.

          Pokud by však v anketě byla odpověd "je to dobré", málokdo by na ni asi klikl.

          1. Martin Hassman

            Re: Dělat weby je radost? Ani náhodou!
            Jenže už z "principu vývoje" to dostatečně dobré není nikdy.

    1. Yaroukh

      Re: Dělat weby je radost? Ani náhodou!
      Přesně tak. Dělat weby je radost jenom tehdy, když od toho zase tak moc nechcete nebo si můžete dovolit ignorovat IE7.
      Období veselého ignorování IE mi bohužel před pár týdny skončilo, a není snad dne, abych si nerval vlasy na hlavě z toho, jak postupně (znovu-)zjištuju, co všechno v tom zaflusanym bastlu nechodí, jak by mělo (i jak by mělo dle MS)…

      Dnes:
      1) css-hack pro transparent PNG v IE6 – odkaz na pseudo-obrázku nefunguje v místech, kde je obrázek neprůhledný
      2) IE7 bez css-hacku – kolem neprůhledné oblasti je "glow"

      Takže hlavně v IE to je "Pořád něco ku*va!!!" :(

  8. Peter

    Dnešní zákazníci jsou jen krůček od toho, aby to sami pochopili. ...
    Bohuzial, zakaznici to chapu davno a prave kvoli nim sa vsetky tie nezmyselne komplikovane stranky navrhuju (a technologie vznikaju). Niet nad jednoduchy layout bez zbytocnosti, ktore len stazuju v tej spleti slov a obrazkov najst informaciu, ktoru clovek hlada. Ja ako zakaznik chcem cistotu a informacnu hodnotu a prehladnost. Ostatne je balast, ktoreho je cim dalej viac.

    Co sa tyka prinosnosti novych technologii na webe, presvedcilo by ma nieco taketo: Napisem nativnu aplikaciu pre operacny system XY (pomocou nastrojov a s vyuzitim API, ktore su na to urcene). Chcem nastroj, ktory mi aplikaciu umozni spustat v prehliadaci (t.j. ako webaplikaciu) bez toho aby som aplikaciu nanovo rucne vytvaral v kombinacii htmo, javascript, ajax, …. A take nic zatial neexistuje, miesto toho sa nanovo prepisuju aplikacie (vid sluzby ako mobile.me a im podobne).

  9. Anonym

    Staníček asi nikdy nic na Webu nepotřeboval najít
    Já lidi jako je Staníček nechápu. Potřeboval někdy něco najít na Internetu?
    Vždyt to kvůli "jeho" stylům, javascriptům a AJAXům je prakticky nemožené.
    Ledaže byste byli něco jako grafiti na Internetu a zaujímalo Vás, jak co barevně vypadá nebo bliká a jak kde mají novou reklamu (a kdy pojede Vámi pomalované metro). Na rychlé prohlédnutí desítek odkazů si prostě musíte vzít nějaký textový WWW-browser.
    Pro koho tedy lidé jako je autor stránky vytvářejí? Asi především pro čumily na Smíchovském nádraží čekající na "svůj" zamlovaný vlak nebo metro – a potom pro zbohatlíky na krizi, kteří občas odhodí (Staníčkovi) nějaké pamlsky či peníze, aby pro jejich potěchu vypracoval design jejich firemní stránky, a to honem než zbankrotují také.

    1. Martin Hassman

      Re: Staníček asi nikdy nic na Webu nepotřeboval najít
      Jenže to není vůbec pravda. Pokud se vrátíme do začátků CSS a Google, tak tam se docela jasně ukázalo, že dobře udělaným webům používajícím CSS bez tuny zbytečných vizuálních značek vyhledávač rozumí daleko líp a uživatel je tak i snáz najde.

      1. Anonym

        Re: Staníček asi nikdy nic na Webu nepotřeboval najít
        Google si na to může obstarat dostatek výpočení kapacity.
        Ale já než se prokoušu desítkami stránek, které na mě všechny blikají a přetáčejí se anebo jsou alespon mimo obrazovku, protože zrovna nemám nejnovější browser. (A to už nemluvím o době, potřebné na stažení všech nesmyslných obrázků jenom proto, že i s těmi si tvůrce hrál ve stylech, aby byl pomalý ale "in".)
        Opravdu jste někdo potřeboval informaci, která byla třeba až v 15-tém odkazu?

        1. Martin Hassman

          Re: Staníček asi nikdy nic na Webu nepotřeboval najít
          A o upgradu prohlížeče jste nepřemýšlel? Já také někdy cvičně zkouším procházet weby v prvním Mosaicu. Vždy to prostě nejde, ale to není problém ani prohlížeče ani těch webů.

    2. karf

      Re: Staníček asi nikdy nic na Webu nepotřeboval najít
      Já lidi jako je Staníček chápu :) A to i přesto, že na některé jednotlivosti mám trošku jiný názor (např. na IE7). Naopak nechápu lidi jako "uživatel si přál zůstat v anonymitě", kteří zjevně nechápou, ale nijak jim to nebrání k jednoznačným soudům.

    3. šachy

      Re: Staníček asi nikdy nic na Webu nepotřeboval najít
      —Vždyt to kvůli "jeho" stylům, javascriptům a AJAXům je prakticky nemožené.—

      Ano, není nad mnohonásobně vnořovaný tabulkový layout, který podá všechna data krásně přehledně. </ ironie>

    4. Sten

      Re: Staníček asi nikdy nic na Webu nepotřeboval najít
      Samozřejmě, a všechna auta by mohla být černý Ford T, že.

  10. Ludivitto

    Pěkné
    Pěkný článek. Díky. A já jim tenkrát říkal: vykašlete se na univerzálnost a věnujte se pořádně jen jedné "disciplíně".

  11. srigi

    Otazka ohladne modov
    Chcem sa vas uzivatelov – webkoderov (ale aj autora clanku) spytat na toto:
    Ked zacinate kodit novy disajn stranky, rozhodujete a vedome ovplyvnjete vykreslovacie mody jednotlivych prehliadacov? Urobite konkretne rozhodnutie, ze napr. FF, O a ine std. prehliadace prepnete do std. modu a "IE-cka" do quirku, alebo to ani neriesite.

    Ak ano, ako mody nastavujete?

    Ja to robim momentalne tak, ze vsetky standardne prehliadace (vratane IE7) nastavim do std. modu pomocou DTD XHTM 1.0 Strict s plne kvalifikovanou URL a IE6 a nizsie zhodim do quirku pomocou XML prologu na prvom riadku. Kdesi som davnejsie cital nazor, ze IE6 je v quirku predvidatelnejsi browser, preto to robim.

    Stranku odladim vo FF pomocou Firebugu, v standardnych browseroch stranka takmer nevyzaduje ziadne dodatocne ladenie a potom IE6 vyladim pomocou podmienenych komentarov. Myslite si, ze je to efektivne (IMO ano)?

    1. bauglir

      Re: Otazka ohladne modov
      To je subjektivní a hodně záleží na tom, co děláte, já osobně postupuji většinou jednim ze dvou způsobů:
      1/ klasické prezentační stránky tvořím v XHTML 1.0 strict pro všechny prohlížeče a málokdy přesáhnu 5 speciálních CSS deklarací pro MSIE 6 (většinou se týkjí základních sloupců)

      2/ webové aplikace dělám v quirku (schodím ho tam buď pomocí XML deklarace, nebo pomocí CSS), protoze quirk box model je intuitivnější (box zabírá 200px bez ohledu na to, kolik zabírá jeho samotný obsah).

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=2949