Komentáře k článku
Webdesign po deseti letech. Dělat weby je zase radost
Kudy se ubíral webdesign v uplynulých deseti letech a jak moc odlišně se tvoří weby dnes? Co podstatného se v průběhu posledních roků změnilo a jaké byly nejdůležitější technické mezníky na cestě, kterou se tvorba webových stránek do současnosti ubírala?
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í.
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?
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.
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.
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.
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.
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.
Re: Co bue s SVG a MathML
vzorce vkladaji do stranek jenom smradlavy matfyzaci, to nikoho nezajima ….
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. ;-)
Re: Co bue s SVG a MathML
Smradlaví matfyzáci používají TEX, XHTML + MathML by využila Wikipedia.
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é.
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.
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í).
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.
Re: delat weby je zase radost ?
Tak si ty javovský zdrojáky kompiluj. Kompilátory do strojového kódu existují.
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.
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 :)
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….
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).
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 ;)
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?
Re: delat weby je zase radost ?
Jasne ze sa da, preco by sa nemalo dat?
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č.
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).
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.
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.
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.
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.
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.
Re: Strictní doctype
napr. mozes pouzivat element menu, striktny dtd ti umozni len semanticky nespravny element ul.
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?
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.
Drakonické parsování
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.
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/
Re: Jak to nedrakonické parsování vlastně celé začalo
koho zajimaji prakticke duvody: http://www.ericsink.com/Browser_Wars.html , vice v stackoverflow podcastu.
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.
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.
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.
Re: Drakonické parsování
Ano, to je velmi oblíbený argument pramenící z neznalosti, na který obvykle odpovídám dotazem: dokáže tohle váš parser?
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.
Re: Drakonické parsování
*nerozuměli
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.
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?
Re: Drakonické parsování
ano, dokáže
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.
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.
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.
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 :-).
Re: Drakonické parsování
presne tak
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“.
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.
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?
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.
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.
Redakčně smazáno
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.
Re: Dělat weby je radost? Ani náhodou!
Ty beres jeho nazory vazne? To teda koukam.
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.
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.
Re: Dělat weby je radost? Ani náhodou!
Jenže už z "principu vývoje" to dostatečně dobré není nikdy.
Re: Dělat weby je radost? Ani náhodou!
presne tak
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!!!" :(
nejlepsi renderovaci engine
ja myslim, ze IE7 je jeste hodne spatny, ale IE8 uz dela presne to co ocekavam!
toto je uzasny renderovaci engine implementovany v PHP!!! http://freshmeat.net/projects/html2ps_php/
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).
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é.
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.
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?
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ů.
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.
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>
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.
RE: Webdesign po deseti letech. Dělat weby je zase radost
Pekny clanek, diky.
RE: Webdesign po deseti letech. Dělat weby je zase radost
nasprosty souhlas – diky za clanek
Redakčně smazáno
pre mna je to stale rovnake
pretoze IE ma, ako jediny prehliadac, najslabsiu podporu css selektorov a css3..
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ě".
Hezky clanek
Hezke shrnuti. Jednou za cas kvalitni clanek.
Re: Hezky clanek
Pripojuji se, nic lepsi na sobotni rano jsem k snidani nemohl doprat :-)
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)?
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).