Přejít k navigační liště

Zdroják » Zprávičky » Deset chyb, kterých se můžete u webdesignu dopustit

Deset chyb, kterých se můžete u webdesignu dopustit

Zprávičky Webdesign

Nálepky:

Glen Stansberry v článku Are You Making These 10 CSS Mistakes? vyjmenovává chyby, kterých se jako webdesigner můžete dopustit. Vedle základních jako je ignorování nekompatibilit mezi prohlížeči nebo ignorování malých rozlišení uvádí i ignorování CSS frameworků nebo nepoužívání validátorů. A s jakými chybami se nejčastěji setkáváte vy?

Komentáře

Subscribe
Upozornit na
guest
23 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
luboskmetko

Tak na toto nemam slov… Ja naopak za chybu povazujem pouzivanie CSS frameworkov. Celkom vazne pochybujem o vobec nejakej uspore casu, a zahltit kvoli tomu HTML a CSS mnozstvom balastu… Nehovorim, ze nie je vhodne pouzivat nejake resetujuce CSS alebo nemat niekde poruke nadefinovane casti kodu pre stale sa opakujuce ulohy, ale vyhlasovat ignorovanie CSS frameworkov za chybu je silna kava.

Anonymní

Velmi často se setkávám se starým známým neduhem, který sice s CSS moc nesouvisí, ale chtělo by ho to vymýtit.
…samozřejmě můžete stahovat aktualice programu, nové skiny, doplňky a jazykové mutace. Stahujte ZDE, ZDE, ZDE a ZDE.
Když to vidím, mám chuť poslat autora SEM

Ještě je jedna docela nepříjemná věc (ale to bych spíš upravoval na straně prohlížeče), se kterou se setkávám. Používám zvětšování celé stráky (ne jenom textu) a u stránek, které jsou tvořeny pevně danými sloupci po stranách a velikostně neurčeným středem(Příklad) se po zvětšení střed (to hlavní, kvůli čemu jsem zvětšoval) zmenší do dlouhé tenké nudle.

karf

Ten článek je poměrně dost mimo. Některé "chyby" jako je "nepoužívání CSS frameworku" nejsou už ani k smíchu, jako spíš k pláči. Kdybych měl sestavit podobný seznam já, tak bych se s tím článkem možná nepotkal ani v jediném bodě.

Jiri Knesl

A kde berete jistotu, ze jste kompetentnejsi, nez autor daneho clanku?

Napr.: Dnes mi prisel od grafika layout na narezani, zase nepouzil grid a ignoruje existenci CSS frameworku. Nakodovani bude kvuli tomu trvat o nekolik hodin vic. Zamestnavatele tim trati muj cas (penize), ktere mohl pouzit jinak a jinde a vydelat vic.

Navic weby respektujici grid nejsou o nic skaredejsi, nez ty, ktere dela grafik "od oka".

Anonymní

Kazdy autor pise veci na zaklade svojich skusenosti a poznatkov. Nikto istotu neberie.

V nepouziti gridu nevidim nic zle. Existenciu CSS frameworku by som ignoroval aj ja ak by som tvoril nejaky navrh. Grafik sa nema co riadit podla nejakeho koderskeho "nezmyslu". Jeho ma zaujimat vizualna stranka.

CSS framework je velmi na uvazenu. Neprinasa taku uroven zjednodusenia ako napriklad javascriptove framework. Ak vobec nejake zjednodusenie prinasa. Ja osobne v nom nevidim velky prinos. Jedine v pripade ak sa v kratkom case musi vychrlit mnoho navrhov.

Manq

Grafika zajímá vizuální stránka, to ano. Musí být ale ke kodérovi trochu tolerantní.

Jiri Knesl

Obecně řečeno, CSS frameworky (aspoň ty, které jsem poznal), řeší několik základních úkonů:

1) Sjednocení chování prohlížečů (obvykle je použit Eric Meyer CSS reset)
2) Nějaká typografie, s kterou by se kodér obvykle příliš nepáral, baseline a další
3) Upravují vzhled formulářů tak, aby vypadaly lépe.
4) Přidává některá implicitní pravidla užitečná pro tiskový styl.
5) Pomáhají nakódovat layout.

Všimněte si, že body 1-4 nemají s layoutem téměř nic společného. Prostě jen tím, že přilinkuji framework, projekt vypadá o něco lépe a při kódování se chová předvidatelněji. Jeho použitím tedy člověk neudělá chybu a pouze získá.

Co se nakódování layoutu týká, tam je urychlení sporné, zvlášť pokud už človek ty 2, 3 sloupcové layouty párkrát dělal. Přesto mi to čas šetří i v případě, že musím rychle prototypovat intranety, administrace a chci, aby vypadaly k světu.

Obecně řečeno, CSS frameworky mi šetří práci. Ne sice tolik, jako javascriptové, nebo serverové, ale přesto tu práci šetří. A to je pro mě důležité, protože každá hodina k dobru znamená, že se v ušetřeném čase můžu dělat něco dalšího, nebo vylepšovat projekt nad rámec zadání a přinést zákazníkovi "hodnotu navíc".

Nechci to tady nikomu vnucovat, ty frameworky spoustě lidí práci neušetří. Ale je úzkoprsý přístup "mě to nepomáhá ergo nikomu to nepomáhá".

Anonymní

1) Je to diskutabilne, kedy si tych 4-5 riadkov dokazes napisat aj ty a podla inych pravidiel. Nazory sa rozchadzaju aj v tomto.

2) Toto ma riesit graficky navrh. Nie framework. Obvykle sa riesi vyska pisna a vyska riadku. Kazdopadne tu tiez existuje viacero ciest. Zoberme si PX vs EM vs % vs PT atd. Ani jeden sposob velkosti nie je spratny. Ci si snad myslite ze ano ?

3) Upravuju v com ? Okrem dizajnu nemaju moznost co upravit, pretoze taktiez tu existuje velke mnozstvo postupov a moznosti. DIV vs LI (zoznam) a ich dalsie vnorene znacky ako SPAN pre maly doplnujuci text. Ktora je teda podla vas najlepsia cesta ? Ja preferujem DIV/SPAN. No znova upozornujem, ze ziadna nie je spatna (pokial sa nepouziju znacky, ktore tam jednoducho nepatria). A ked sa vratim k tomu dizajnu, ten je predsa dany grafickym navrhom.

4) Toto je ich velka vyhoda, pretoze sam som lenivy pisat pravidla pre tlac a nechavam spracovanie na prehliadaci, pokial nebol graficky navrh zamerany aj na tlacovy vystup. Cize ano, toto velmi ocenujem.

5) V com ? Grid je niekedy vyhodou a niekedy nie. No programator by mal uz mat davno prejdenych niekolko postupov a vybrat si pre neho tie najlepsie. Len sa spytam, a dufam, ze to nebude osobne. Vy ste byval pred pouzitim frameworkov taky hardcorista, ze ste si vsetko kodoval od piky ? V mojom pripade som mal pouzity defaultny styl, ktory som potom mierne poupravil. Takze svojim sposobom som pouzival svoj vlastny framework, ktory obsahoval postupy mne najvhodnejsie ku najrychlejsiemu a kvalitnemu koderskemu vystupu pre dany projekt. A ze sa v nom nehanbim pouzit CSS hacky sa hrdo priznavam.

Anonymní

Ten nadnes nie je treba. Lebo ako ste spominal, CSS frameworky sa formuju a nie je ziadna definicia, ktora hovori o tom, ze toto a toto vo frameworku musi byt a hento tam nesmie byt. Je pravda, ze nie kazdy koder si robi framework v takej miere ako je tam obsiahnuta, ale zase si pripravi ine veci, ktore v tom frameworku neexistuju.

Inak je pravda ze kopec vyvojarov odmieta vo vseobecnosti HTML a CSS, pretoze ucenie je pre nich strata casu. Co aj chapem. No u mna nie je problem navrhnut databazu, vytvorit na to aplikacnu logiku, nakodovat dizajn a pridat tam javascriptove vylepsenia. No najradsej kodim dizajn, pretoze je najlepsie plateny a odpada tam velka zodopovednost :)

Ano CSS frameworky hladaju svoje miesto. V niektorych pripadoch su naozaj vyuzitelne aj vdaka gridu, kedy tvorite web, kde sa dynamicky meni pocet slpcov. Niektore predvolene styly mozu byt napomocne.

Ale presne ako ste spominal. Najst paralelu k inym typom frameworkom zatial nie je. Ich cas a kvalita nedosla na taku uroven (aj vdaka "podpore" CSS zo strany prehliadacov), aby sa dostali do velkeho produkcneho nasadenia. Taky rok-dva zretia a bude sa to dat pit :)

karf

CSS se od PHP, JS atd. liší v jednom drobném detailu – nejedná se o programovací jazyk. Proto jakákoliv paralela mezi frameworky pro programovací jazyky bude nutntě velmi pokulhávat. A to je také důvodem, proč se odpůrci CSS frameworků jaksi zdráhají je vůbec nazývat frameworky. Slovo framework má již určitý zavedený význam v programovacích jazycích, jenže v CSS je ten význam poněkud posunutý.

Já jsem ve svém prvním komentáři výše nechtěl rozvádět svoji averzi k CSS frameworkům. Ale když už se tu ta diskuse takto rozvinula, přidám svůj názor:

1) Sjednocování chování prohlížečů mi připadá nadbytečný krok, neboť stejně všechny prvky, které potřebuji použít, nastyluji na požadované-cílové hodnoty. Proč bych je měl nastavovat nejprve na nějaké výchozí hodnoty, abych je potom níže zase přepsal? Typografii nastavuji všem prvkům podle potřeby – to je přece ta základní funkce stylů, že jimi definuji vzhled, jaký chci.

2) CSS je natolik syntakticky primitivní jazyk, že vše, co v něm napíšu je elementární forma, kterou již nelze nijak zjednodušit. Jakákoliv vrstva navíc tedy nutně vede pouze k zesložiťování kódu, nikdy ne ke zjednodušení.

3) CSS framework mě nutí přemýšlet způsobem, jakým přemýšlí autor frameworku. Ve většině případů mi přijde způsob uvažování autorů frameworků značně limitující.

4) Framework s sebou vnáší množství balastu, který nejen že je zbytečný, ale také zatěžuje renderovací engine, který se tím musí probírat. V případě, že používám bohatších javascriptových interakcí, je způsob, jakým jsou prvky stylovány, často důležitý pro odezvu aplikace. Pro daný konkrétní případ je pak potřeba uvažovat, zda je lepší použít float, nebo pozicování, overfloat apod.

5) Způsob, jakým se frameworky vypořádávají s chybami IE6 mi často přijde poněkud nešťastný (co jsem zatím měl možnost vidět).

6) Abych využil gridu, který podporuje framework, musel bych to brát v potaz už při tvorbě grafického návrhu – jinými slovy popírám grid jako grafický princip a určuji jej podle technologických požadavků. A ty jsou limitující. Už jen tím, že vychází z násobků 10. Co když chci vyjít třeba z násobku 8 nebo 12? Navíc to grafik musí zohledňovat, což je u většiny grafiků naprosto iluzorní představa.

karf

Nerozumíme si. Nepíšu o zjednodušení práce, nýbrž o zjednodušení kódu. Proto "syntakticky primitivní". Prostě syntaxe je tak elementární, že pokud napíšu pravidlo tak, jak je potřeba, není prakticky cesty, jak jej dále zjednodušit. Přidáním mezivrstvy se dostanu v nejlepším případě na stejné množství kódu – pokud nebudu přepisovat pravidla frameworku. Čili celý framework = výchozí šablona. Stejně jako třeba šablona ve Wordu – pokud vám vyhovuje nějaká standardní šablona, pak si jistě ušetříte práci s tvorbou vlastní, to jo.

Jiri Knesl

1) Ano, je to diskutabilní, já se dlouho bránil všem CSS resetům, jenže vždy jsem zapomněl některé elementy sjednotit a zákazníci byli zmatení, že jim to vypadá jinak v MSIE a jinak ve Firefoxu.

2) Jediný správný přístup samozřejmě neexistuje. Design a zadání webů se často tolik liší, že se musí i v připadě typo volit hodně odlišné přístupy. Přesto v 90 % případů považuji za vyhovující 18px výšku řádky (případně 1,2 nebo 1,3). Zadání v pixelech má výhodu, že když i výšku obrázků na stránce přizpůsobíte násobku 18px, vypadá to líp. Nevýhody si jistě domyslet zvládnete. :)

3) Používám Blueprint, kde je jen jemný lifting designu. Existují ale frameworky přímo pro kódování formulářů, které toho umí víc. Nepoužívám j, mám za to, že by mě už omezovaly.

5) Nejsou pouze gridové frameworky, ale mají mezi CSS frameworky drtivou převahu (to jen na okraj). Řekněme, že bych neměl problém během 10 minut nakódovat třináctisloupcový design a hned pod něj třeba devítisloupcový a pod to zase sedmisloupcový. Neříkám, že s něčím takovým se někdy potkám, ale proste rozhazování na sloupce je v takových frameworcích primitivně jednoduché.

Další výhoda je jakýsi implicitní způsob kódování. Já třeba obvykle zapisuji classy a id shora dolů, jak jsou v dokumentu. Kolega podle abecedy. Další způsob, s kterým jsem se setkal, je rozhazování typo, grafiky a textových stylů do samostatných souborů. V ničem z toho ten framework nebrání, ale přesto má framework obvykle určité konvence pojmenování (které nemusíte dodržovat) a pokud je použijete, můžete snadno upravovat CSS od kolegy, protože používáte shodnou "štábní kultůru".

Dřív jsem kódoval všechno odzačátku, což dělám stále u některých layoutů (prostě proto, že máme "nevychovaného" grafika, na čemž jsem se shodl i s kolegy, kteří žádný framework nepoužívají).

Frameworky obecně nejsou pouze skupina knihoven, ale komplexní přístup k popisu webu. Tento deklarativní přístup je viditelný nejvíc u Symfony a Ruby on Rails. Mám za to, že obdobný přístup platí i o CSS.

Anonymní

1) Zalezi v tomto z akej normy vychadzate. Ja robim „minimalne“ v XHTML 1 Strict a tym upravujem elemety. Co je starsie ma v tomto pripade nezaujima. Moze to zniet ignorantsky, ale ak si sam kodujem templatu, viem co pouzijem a co nie. Iny pripad je pri zaostalych WYSIWIG editoroch. Suhlasim vsak, ze niekedy sa veci mozu malou chybkou pokazit a treba to potom opravit.

2) Ak myslite to, ze pri pixeloch nejde zvacsovat text, tak toto platilo kedysi velmi davno. Po svete behali webovi dinosaury.

3) Presne o tom hovorim, ze mozu obmedzovat. Nevyzreli na to, aby priniesli o tolko zvyseny vykon, ak vobec.

5) Ja to chapem. Gridove frameworky su vyzdvihovane najma kvoli tomu. Ine mozu priniest zameranie najma na typografiu. Dalsie na cistotu navrhu.

Isteze CSS frameworky prinasaju nejaku stabnu kulturu, ale je toho strasne malo. Ja osobne navrhujem styl CSS suboru v stromovej skrukture. V obdobnom poradi: Reset, vseobecne atributy a elementy, pomocne triedy, konkretne identifikatory a triedy. A to stylom:

#mainNav li a
#mainNav li.active a

atd.

Dřív jsem kódoval všechno odzačátku, což dělám stále u některých layoutů (prostě proto, že máme „nevychovaného“ grafika, na čemž jsem se shodl i s kolegy, kteří žádný framework nepoužívají).

Ale to nie je chyba grafika. Opakujem, ze grafik nemusi vobec ovladat ziaden framework, maximalne nejaku predstavu o prevedeni do kodu. Ostatne si vsetko ma zariadit koder. Ak je koder schopny uz davno ma mat svoje najlepsie postupy niekde ulozene a zacne na nich stavat. Nehovorim tu len vseobecne. Hovorim o strukture formularov, tabuliek, knihe navstev, hlavnej a sekundarnej navigacii. Poklial predtym vytvoril semanticke a dobre nakodene HTML, tak upravit to do potrebneho vzhladu je zmena niektorych parametrov.

Jiri Knesl

1) o použité DTD mi zde nejde. Prohlížeče různě vykresluji h1, h2, h3, table a další.

2) no ano, ale pořád budete mít to line-height na 18px a obdobně i obrázky na tomto násobku, takže když zvětšíte písmo, už ty obrázky tak pěkně lícovat nebudou. Ledaže by i jejich rozměr byl určen v em, což považuji spíš za exotiku, než za běžnou věc.

Prohlížečů, které mají zvětšování všeho, nejen textu (Opera asi odjakživa, FF od verze 3), tímto neduhem netrpí.

3) v tom se s Vámi shodnu, některé frameworky omezují. Naštěstí ne všechny. :)

5) tady teď nejde o frameworky. Náš grafik jednoduše dělá návrhy, které se nekódují úplně snadno ani v čistém CSS. To vede k tomu, že my mu ten návrh v několika kolech připomínkujeme a vše se zbytečně protahuje a zaměstnavatel tratí peníze.

—–

Obecně k frameworkům: Asi každý jazyk, ve kterém programuju, mě něčím štve. A ať už jde o PHP, Javascript, nebo CSS, jsou chvíle, kdy bych počítač vyhodil oknem. Ale právě frameworky mě často filtrují od těch úkolů, které mě zoufale nebaví a výsledek vypadá stále profesionálně, ačkoliv jsem úkolu věnoval zlomek času, než bych byl nutný věnovat bez frameworků. Jedná se o produktivitu, lepší pohodu při práci a standartizaci toho, jak programuji. A ještě mi to vydělá víc peněz. :)

Anonymní

1) Aha tak tu sa trosku odlisujeme. U mna sa to skor stava vtedy ked zabudnem na nejaky "exoticky" prvok.

2) Tu si dovolim nesuhlasit. Kludne si mozem zvolit velkost pisma 12px a velkost riadku na 130%. Ale to su problemy prehliadacov. Prave Opera sa k tomu chovala so zvacsovanim prirodzene, kedy zvacsenie chapala ako priblizenie (lupa) a nie ako zmenu velkosti pisma.

3) Suhlas.

5) Stretol som sa s niekolkymi tazsimi orieskami, ale problemy som pozoroval najma s IE, no tam javascriptovou emulaciou CSS selektorov sa problemy riesili velmi rychlo.

—–

Ja to poznam :) Toto mi nemusite vraviet. Frameworky v programovacich jazykoch su neskutocne vylepsenie a uz by som nepracoval na projekte, ktory nestavia na nejakom frameworku. No u CSS v nom nevidim potencial. Aspon zatial. Ak bude rad sa do toho pustim a usetrim si cas.

Jiri Knesl

1) Ano, jde zejména o exotické elementy, ale i o různé kombinace základních elementů. Teď už používám tinymce nastaveny tak, že pustí jen hrstku elementů, takže ten problém je částečně vyřešen už při vkládání do databáze.

2) Ano, Opera má asi nejlepší přístup. Nechtěl jsem to sem psát, protože by se toho mohl chytnout někdo, kdo by chtěl "flejmovat". :)

5) Snažím se kódovat vzhled bez Javascriptu (a bez expressions), ale kdo ví, třeba si někdy vypomůžu. Testuju weby pro podivnosti, jako je Safari, nebo prohlížeč pro nevidomé, tu paranoidní menšinu s vypnutým javascriptem bych si mohl dovolit ignorovat :)

V pořádku, jak jsem psal výše, nikomu to nevnucuju. Některým lidem to čas ušetří, některým ne, tak to prostě je.

Anonymní

1) Suhlasim, najhorsie je riesit vstupne podmienky. Niektori ludia robia copy&paste a vznikne z toho pekny balast.

2) No snad sa flejmu nikto nechyti. Treba to povedat predsa objektivne :)

5) Taktiez mam rovnaky pristup ku kodovaniu. Zaklad je postaveny cisto na HTML a CSS. Javascript je pekne udelatko a pomocnik a mam rovnaky postoj k tym paranoidnym :) Ono to je strasne komicke, ale za to, ze ste spravil stranku ktora pouziva javascript ich strasne "serie" a pritom v Youtube si bez zapnuteho javascriptu nepustite ziadne video.

karf

O tom bychom mohli diskutovat. Ale já hlavně nic o kompetentnosti netvrdím. Naopak – kde bere autor onoho článku tu jistotu, že je natolik kompetentní, aby mohl lidem vnucoval své názory a osobní preference jako nezvratitelné dogmata a drze nazývat jejich neakceptaci chybami? Ať si klidně používá gridy, když mu to vyhovuje, ale pokud hodlá jiné postupy nazývat chybnými, pak musí být připraven na tvrdou kritiku.

Co se týče gridů – grid jako grafický princip nemá prakticky nic společného s CSS "frameworky". To jsou dvě nesouvisející věci.

luboskmetko

Mne sa paci, ked grafik pouzije grid, aspon mam istotu, ze vsetko "licuje", bloky su presne pod sebou atd. Ale na jeho nakodovanie nepotrebujem framework.

Podla mna problem CSS frameworkov je ten, ze sa snazia zovsebecnit oblast, v ktorej existuje nekonecne mnozstvo variacii (dizajn). Pritom na kodovani predsa nezabera najviac casu vytvorenie nejakeho 3-stlpcoveho layoutu, ak ste to uz predtym robili. Najviac casu zabera vysporiadavanie sa s grafickymi variaciami (rezanie obrazkov na pozadi, definovanie pisma, pozicovanie prvkov). Preto CSS frameworky uz z principu nemozu znamenat nejaku vyraznejsiu usporu casu, ktora by stala za to, ze CSS a HTML zostane zaplavene frameworkovym balastom.

Na rozdiel od toho JS frameworky sa snazia ulahcit programatorovi zivot len v urcitom konecnom pocte casto sa opakujucich uloh (prechadzanie DOM, animacie), ktore keby programator robil od zakladu, zabrali by mu ovela viac casu – preto maju JS frameworky ovela vacsi zmysel.

Martin Michálek

Dovolím si tu – sice trochu OT ale zajímavou – diskuzi o CSS frameworcích rozšířit o myšlenku navazující na větu "Why reinvent the wheel?" z článku.

Ruby on Rails, Django, jQuery, Blueprint CSS … – všechny webové frameworky z poslední doby vznikly z potřeby zlepšit produktivitu lidí pracujících ve webdesignu a zbavit je nezajímavé opakující se práce.

Myslím, že všechny je vymyslel jeden člověk. Jeho myšlenky ovšem byly natolik univerzální, že oslovily komunitu, která je vzala za své a odstranila nevýhodu jediného autora – více hlav vždy ví více a další vývoj tedy pokračuje v komunitě. Viz network Blueprint CSS: http://github.com/joshuaclayton/blueprint-css/network/members

Z pohledu "dělníka webdesignu" jsou Ruby on Rails a Blueprint CSS stejně užitečné. Problémy, které by musel řešit sám, jsou už buď vyřešené někým jiným nebo je řeší jako součást komunity.

Jediný rozdíl mezi frameworky pro programátory a frameworky pro kodéry není v tom, že ty kodérské jsou mladé. Myslím, že už leta má každý zkušenější kodér něco jako vlastní framework. Kodéři je ale začali publikovat později. Docela se tomu ale divím, protože i oni mají už leta svých problémů dost :)

Je ale zajímavé, že CSS frameworky přicházejí těsně po stabilizaci postavení dalších client-side frameworků – Javacriptových. Možná je to tím, že vymizením IE5 se už s prohlížeči dá kamarádit :)

Jak správně "opravuje" Martin – není chybou CSS framework nepoužít. Chybou je ale ignorovat framework jako databázi vědomostí lidí, kteří řeší stejné problémy jako já.

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.