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

Zdroják » Různé » Udržovatelný stylopis: CSS kód, ze kterého nerozbolí hlava

Udržovatelný stylopis: CSS kód, ze kterého nerozbolí hlava

Články Různé, Webdesign

Technická dokonalost kaskádových stylů je samozřejmostí a nestojí už takové úsilí. Vyplatí se však začít klást důraz na udržovatelnost. Rozumíte svému stylopisu? Je jednotný, nebo spíše připomíná Babylón? Subjektivní pohled z praxe s ukázkami kódu.

Dnešní článek patří do rubriky Subjektivně. Jejím cílem je zejména poskytovat prostor pro názory a pohledy na aktuální dění v oblasti webových technologií i na jejich vývoj do budoucna. Jedná se o osobní názory, které se nemusí vždy shodovat s názory redakce. Pokud máte co říci, pojďte k nám psát Subjektivně.

Kodeřina je hrozná dřina

„Kodeřina je hrozná dřina” — takový podtitul měl můj první blog v roce 2002. A nebylo divu. Procházeli jsme dramatickým vývojem ve využívání kaskádových stylů, válčili se zastaralými prohlížeči a zkoumali řešení, bez kterých si dnes nedovedeme představit práci client-side kodérů.

Svět kaskádových se dnes už dramaticky nevyvíjí a zdá se, že v nejbližší době ani nebude. Vizuální stránka webů neprochází jednou za rok či dva redesignem. Klíčovým slovem vývoje je evoluce nikoliv revoluce. Váš dnes napsaný stylopis vás bude doprovázet ještě za pár let.

Rozumíte svému stylopisu?

Zen Garden

Technická dokonalost je samozřejmostí a nestojí už takové úsilí. Vyplatí se však začít klást důraz na udržovatelnost. Zeptejte se svého kódu: „Budu ti rozumět, až se k tobě za rok vrátím?”

Velká část mých starších stylopisů na otázku neodpoví. Nerozumí mi, stejně jako já nerozumím jim. A tak už rok hledám best practice — způsob, jak psát udržovatelný stylopis. Podělím se s vámi, k čemu jsem zatím dospěl. Zcela subjektivně.

Technicky precizní, validní stylopis totiž bude za rok k ničemu, je-li psán způsobem, kterému rozumíte jen vy a jen v tuto chvíli. Naopak, udržovatelný stylopis mluví sám. Budete mu rozumět i za rok vy, bude mu rozumět člověk, který po vás projekt převezme nebo kolega back-end vývojář, který do něj bude chtít doplnit pár pravidel. Udržovatelnému stylopisu bude rozumět i váš velký kamarád, Firebug. Ladění v něm bude ještě méně bolestné. Udržovatelný stylopis ušetří váš drahocenný čas a peníze vašich klientů.

Dva cíle a pět zásad udržovatelného stylopisu

Našim cílem je efektivita a také „radost z práce”. Hesla, která u leckterého webdesignéra budí pobavený úsměv. Ten pak po nocích kleje u vlastního špatného kódu.

Jaké jsou naše zásady?

  1. čitelnost — kdykoliv bude kdokoliv chtít udělat zásah, měl by se vždy rychle zorientovat.
  2. přenositelnost — izolovaný kus kódu můžu snadno vzít a přenést na jiný projekt, příkladem budiž plugin FancyBox nebo resetovací stylopis.
  3. centralizace — nespravuji vlastnosti jednoho prvku na více místech.
  4. dopředná kompatibilita — pro detekci prohlížečů nevyužívám konstrukcí, které využívají jejich aktuálních a často dočasných chyb. Maximálně dodržuji standardy, ty přetrvávají.
  5. jednotnost — struktura CSS souborů, jejich obsahu a způsob pojmenovávání selektorů by měla být konzistentní i napříč projekty.

Začnu špatným příkladem:

#content #hlavicka2 p#menu li a { text-transform:uppercase;width:130px;
background:#4DBEE9;color:#292929;padding:10px 4px 10px 6px;display:block; } 

Komprese kódu je pro počítače, ne pro lidi

Vyzkoušel jsem snad všechny způsoby zápisu kaskádových stylů. A došel k tomu, že člověku nejčitelnější kód je vždy ten velikostně nejméně úsporný. Můj kód je velkorysý. Každé pravidlo má svůj vlastní řádek a je odsazeno. Kompresi kódu rád přenechám softwaru k tomu určenému, například Minify.

Náš příklad tedy „dekomprimuji” do čitelnější podoby. Seřadím vlastnosti — první dám vždy ty, které určují rozměry a pozici. Pozor na zkrácené zápisy — třeba vlastnost background se tváří nevinně, ale je nebezpečná. Kromě barvy vám předefinuje například i obrázek na pozadí.

#content #hlavicka2 p#menu li a
{
 width: 130px;
 padding: 10px 4px 10px 6px;
 display: block;
 float: left;
 text-transform: uppercase;
 background-color: #4DBEE9;
 color: #292929;
} 

Indexy a „ukecané” komentáře

Už vím, že nemusím šetřit komentáři. Počítač mi je na produkční verzi odstraní.

Komentáře mého stylopisu jsou hotový román. Najdete v nich:

  • Matematiku prvního stupně ZŠ — tedy složitěji odvoditelné výpočty rozměrů prvků.
  • Vysvětlení těžce pochopitelných jevů — stylopis pro IE6 je jich plný, často do komentářů přikládám odkazy na popis workaroundu nebo vysvětlení chyby.
  • Index z-indexů — u webů s vyšším výskytem z-index vlastností dávám do specifikační části seznam všech z-indexů.
  • Index barev — seznam všech použitých barev, jejich pojmenování a příklady použití.
  • Specifikace layoutu — rozměry gridu, pravidla typografie. Layout a barvy by měly vzniknout ve spolupráci s designérem a u větších projektů narůst do manuálu stylu.

Správa indexů jde sice proti jedné ze zásad udržovatelného stylopisu (nedělat úkony na dvou místech), ale samotná jejich existence mu velmi prospívá (zvyšuje čitelnost). Bylo by skvělé, kdyby nám je uměl vygenerovat editor CSS, podobně jako to dělá Word.

Náš kód „okecám” a uvedu do souvislostí:

#content #hlavicka2 p#menu li a
{
 width: 130px; /* Celkem 150px - polovina sirky sloupce */
 padding: 10px 4px 10px 6px;
 ...
} 

Sémantické, jednoznačné a nekomplikované identifikátory

Názvy identifikátorů mají popisovat obsah, nikoliv formu ( .float-left-box není nejlepší řešení). Druhé pravidlo je, že by měly „umět mluvit”. Sebepopisnost je velmi důležitá  —  zásadně vynechávám zkratková pojmenování nebo babylónštinu – tedy nejednotnost jazyka ( .head-modry).

Babylónštna nesmí vzniknout ani při komunikaci s jinými členy týmu. Na posledním projektu například pojmenovávání přebírám z Rails controllerů od kolegy Karla Minaříka. Oba se pak shodneme na pojmenování určitých částí webu a nepotřebujeme překladatele.

Nesnažím se kaskádou popsat umístění prvku ve struktuře dokumentu. To se může snadno změnit. Proto před zápisem .page-home .articles .item dám přednost .home-page-article. Stejně tak se mohou změnit HTML prvky, proto na ně CSS selektory co nejméně navazuji ( #menu namísto  p#menu).

V našemu kódu odlehčíme selektor a ve výsledku bude vypadat takhle:

#navigation a
{
 width: 130px; /* Celkem 150px - polovina sirky sloupce */
 padding: 10px 4px 10px 6px;
 display: block;
 float: left;
 text-transform: uppercase;
 background-color: #4DBEE9;
 color: #292929;
} 

Zdá se, že k naší ukázkové definici se můžu za rok vrátit a rychle pochopit, co jsem jí myslel, nebo předat kolegovi, až se za dobře odvedenou práci odměním roční dovolenou v Karibiku.

Pokračování příště

V další části se podíváme od pravidel výše — na centrální stylopis a jednotnou strukturu souboru. Načneme také ožehavé téma: používat nebo nepoužívat hacky?


Martin Michálek se zabývá praktickým webdesignem od roku 1997. Posledních 7 let ve studiu Shortcat. Aktuálně se kromě jiného koncentruje na efektivitu webdesignérské práce. Píše blog Vzhůru dolů.

Rozumíte svému stylopisu?

Komentáře

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

ty linky na http://kratce.vzhurudolu.cz/ nefunguji..

ph0enix

Nahradte ve jmenu serveru slovo "kratce" za "blog" a linky budou fungovat. Chtel jsem sem puvodne vlozit opravene linky, ale muj prispevek byl zdejsim systemem vyhodnocen jako SPAM a nesel mi odeslat ani po prihlaseni… :-(

Hoween

#footer{margin-left:10.5em;background:rgb(213,234,183);font-family:Verdana,'Geneva CE',lucida,sans-serif !important;}
#footer h6{margin:0;font-size:0.55em;}

Pro někoho špatný příklad, pro někoho ideální zápis. S dobře nastaveným zvýrazňovačem a vypnutým automatickým zalamováním je takový zápis perfektně čitelný, člověk se v něm rychle orientuje a nemusí pak ani šaškovat s nějakou minimalizací kódu, stylopis se může rovnou deployovat na server.

VfB

souhlas, většina lidí nemá 40' monitor, tam bych si možná přepych mohl dovolit psát všechno extra na řádek, ale na svém 21' monitoru bych viděl pravidla pro jeden, dva prvky a to by se mi ladilo dost špatně
navíc stále více lcd panelů se vyrábí v wide provedení, což je optimální pro "inline" zápis, při "roztahaném" budu mít 85% pracovní plochy nevyužité
jen bych za názvem prvku a za každým pravidlem (středníkem) dal jednu mezeru), ale ne za dvojtečku, tím se znesnadňuje čtení
(píšu ve GVIm, téma dark blue na windows)

Mingan

40" monitor není vůbec potřeba. Osobně používám 19" případně 21" a vidím běžně čtyři až sedm prvků na jedné obrazovce. To mi přijde docela dost.

V poslední době, když musím pracovat s cizími stylopisy, tak jenom šílím, protože používají inline zápis bez mezer za dvojtečkami. Pokud si chci přečíst nějakou definici celou, musím scrollovat do stran. Na vertikální scrollování mám kolečko na myši, můžu si přidat zarážky a skákat jedním kliknutím na definice, se kterými práve pracuju.

Hoween

> vidím běžně čtyři až sedm prvků na jedné obrazovce
Čtyři prvky, když kóduju portlet, na který se jich vztahuje třeba 15, je hodně málo. Naopak při inline zápisu vidím všechny.

> protože používají inline zápis bez mezer za dvojtečkami.
Mezery za středníky ještě pochopím, ale za dvojtečkami? Probůh proč? Zkoušel jste si nastavit zvýrazňovač?

> Pokud si chci přečíst nějakou definici celou, musím scrollovat do stran.
17" wide a do stran posouvám kvůli cca 2% definicí. Zkusil jste dědičnost? ;-)

WuDo

Osobně dávám přednost zápisu, který je v článku popsán.

Programuji na 15" notebooku a nemám s tím sebemenší problém.

Nevím, co by mělo komukoliv vadit na scrollování stránky, to co bych musel složitě hledat v inline zápisu očima, hledám (dle mého názoru rychleji) jen scrolováním stránky dolů, kde si hledaného hned všimnu…

Zvírazňovače jsou fajn, ale tak jako pomáhají v inline zápisu, tak pomáhají i v odetnrovaným zápisu…

Mimoto že inline zápis se špatně komentuje… tak aby bylo vše jasné a nemuselo se scrollovat do stran (když je scrollování tolik někomu proti mysli…).

Hoween

> Nevím, co by mělo komukoliv vadit na scrollování stránky
Právě to, že když kóduju něco, na co se bude vztahovat víc definic, chci je vidět najednou. Nechci neustále scrollovat nahoru a dolů, s inline zápisem mi stačí jen přejet očima na jiný řádek a hned můžu pokračovat v psaní.

> Mimoto že inline zápis se špatně komentuje…
I když se hodně snažím, nepamatuju si, kdy jsem naposledy v CSS potřeboval něco komentovat
;-) Význam jakýchkoli komentářů v tak primitivním a sebepopisném značkovacím jazyku mi opravdu uniká.

Miloslav Lešetický

Jsem tu jediný, kdo při práci s cizím stylopisem, v němž kodér použil jemu vyhovující pravidla formátování, používám PSPad a prostě si ho pomocí položky menu "Přeformátovat CSS" překlopím do strukturovaného zobrazení případně naopak? Nebo nerozumím vašemu komentáři?

Hoween

Nemluvíme o cizím stylopisu, mluvíme primárně o vlastním stylopisu.

A pokud jde o podobné funkce v různých editorech – pokud byste svou práci udržoval třeba v SVN, tak byste toho moc neudělal.

Miloslav Lešetický

Kolega Štěpán Pilař mluvil o cizím stylopisu a na to jsem reagoval.

Ale to je ostatně fuk, celé tohle téma je ryze subjektivní a každý kodér má své vymakané a oblíbené postupy, jak si práci zefektivnit. V tomto případě navíc než kdy jindy platí okřídlené rčeni – "každému, co jeho jest".

SVN tak dalece neznám a počítám, že v ničem podobném nikdy pracovat nebudu.

Osobně mi vyhovuje styl v článku pojmenovaný jako "velkorysý" s pravidlem na každém řádku. Honza Bien zase preferuje řádkový stylopis (všechny definice na jednom řádku) a když jsme spolu pracovali na příkladech ke knize o CSS, neměli jsme problém se ve vlastních stylopisech zorientovat.

Tolik subjektivně k subjektivnímu článku na závěr mého subjektivního komentáře.

karf

V tomhle ohledu plně souhlasím s Howeenem (i když už ne tak s jeho agresivní rétorikou). Nedělá mi problém převzít od někoho cizí kód, pokud je "velkoryse" zformátován. Ale určitě bych jej nepřeformátovával, pokud vím, že na něm budeme dále pracovat střídavě. Pro práci s verzovacím systémem je to opravdu velmi nevhodné. Představa práce na webu bez SVN je pro mě noční můra.

Mimochodem, pokud jsem měl kdy problém s cizími styly, nebylo to nikdy ve způsobu formátování, ale vždy jen v samotné logice zápisu. Např. v článku zmiňovaný selektor "#content #hlavicka2 p#menu li a" má příliš vysokou specificitu, které se v praxi snažím spíš vyhýbat.

VfB

na webu je dost nástrojů (i online) pro převod z "inline stylu" do "sloupcového zápisu"

Hoween

Když ten kód můžu psát ručně, proč se zdržovat s nějakým dalším nástrojem?

Hoween

Pojem interpunkce vám něco říká? Bez ní jsou totiž oba vaše zápisy chybné, stejně jako by vám neprošlo CSS bez středníků.
A syntax-highlighting také? Parser dělá v podstatě něco jako větný rozbor, zkuste si automaticky vyznačit třeba podmět a přísudek jinou barvou…

Radovan

Vy sa vzdy musite do kazdeho navazat ze ano ? Mate socialny problem ?

Martin chcel len ukazat, ze cela basen je lepsie citatelna a pochopitelna vtedy, pokial sa upravi do kratkych vystiznych viet. Nie do dlhej stracajucej sa podoby.

A ano, nepouzil tam ciarky. Ale ked uz na nic ine neviete poukazat, tak je to s vami zle.

Hoween

Nemusím, jen vysvětluji, že i inline zápis může být bez problémů čitelný a zpracovatelný strojem. Mně stačí dobře udělaný syntax-highlighting, nepotřebuji k čitelnosti kódu "velkorysý" zápis. A stroj rovněž rychleji zpracuje inline zápis, šetří to traffic a vhodné strukturování kódu šetří požadavky. Co na tom nechápete vy?

Radovan

Ja nechapem vasi dogmaticku zanietenost a vymyslanie takych veci, ktore ma robit pocitac. Od toho tu je. Clovek cloveku ma odovzdat co najpochopitelnejsie udaje. Stoju to uz je jedno, on si to aj tak spracuje podla seba.

Lokutus

Jste dobrej, Howeeene. Skoro jako robot. Tak se ještě jednou poplácejte po rameni.

Jinak já CSS nekóduji, zato píšu zdrojáky. A mám také raději velkorysý styl, než všechno na jedné řádce. Velkorysý styl mi mnohem lépe zajistí, že nepřehlédnu nějakou chybku (ano já vím, moderní nástroje obarví, opraví chyby a automaticky verzují), a že se ve svém i cizím kódu lépe vyznám.
Pak jsou tu starobylá typografická pravidla z dob našich moudrých předků, a ty jsou pro mě zajímavější, než vaše robotí vnímání světa.
Jak bylo řečeno, každému co jeho jest.

mofo

jenže, panáčku, zdroják programu a zápis css jsou dvě úplně různý písničky. nemluvě o tom, že leckde je přímo vyžadováno mít jen jeden příkaz na řádku, tak nedělejte z nouze ctnost ;-)

a když se tu oháníte těma básničkama – co definice, to sloka – tak já taky raději prózu – co definice, to věta.

a hlavně – jako u spousty jiných věcí, jde hlavně o zvyk.

Ash

Argumentovat "stroj rychleji zpracuje inline zápis" a "šetří to travic" může jen velmi neznalý člověk nebo srandista, zato výhody velkorysého zápisu jsou dobře vidět při používání svn a podobných nástrojů, při diffování a patchování.

Hoween

Diffování, patchování… Verzovacímu systému je úplně jedno, kde v kódu nastane změna. Dobrý klient dokáže zvýrazňovat změny i v inline zápisu (např. subclipse, nebo želva).

A co se týká rychlosti zpracování inline zápisu, tak věřte nebo nevěřte, je to pravda. Doporučuji nastudovat, proč existují různé packery a minifiery. Nebo mi budete tvrdit, že všichni jejich autoři jsou neznalí srandisti? Včetně např. Deana Edwardse? :-D

Radovan

Vy ste to zase nepochopil alebo sa snazite znova o demagogiu v prospech seba. Ja osobne si myslim, ze v prospech seba.

On argumentoval tym, ze vas argument o tom, ze inline zapis pocitace spracuju rychlejsie a preto tak pisete je mylny. Ked clovek pise inline zapisom tak ma k tomu ine argumenty. Rychlost je vzdy minimalne na druhom mieste.

garcon

Copak interpunkce, i ten Kryl

Z rozmlacenyho kostela

    v krabici s kusem mydla

prinesl sem si andela

    Polamali mu kridla

Dival se na mne oddane

    ja mel jsem trochu tremu

tak vtiskl jsem mu do dlane

    lahvicku od parfemu

se da zapsat jako one-liner:

Z rozmlacenyho kostela /
v krabici s kusem mydla /
prinesl sem si andela /
Polamali mu kridla /
Dival se na mne oddane /
ja mel jsem trochu tremu /
tak vtiskl jsem mu do dlane /
lahvicku od parfemu

U Kryla už jsme k tomu slepi, ale treba u Isaca Wattse se zrusenim pretty-printingu ztrati to nejpodstatnejsi — srovnej:

Our God, our help in ages past, /
Our hope for years to come, /
Our shelter from the stormy blast, /
And our eternal home.

versus

Our God, our help in ages past,
Our hope for years to come,
Our shelter from the stormy blast,
And our eternal home.

Viz optický rým.

david-binda

Sám preferuji taktéž inline zápis, ovšem s mezerama za středníkem i za tečkou. Samozřejmě souhlasím, že stylopis by měl být přehledný a nějaký ten komentář neuškodí (já si třeba označuji nadpisy jednotlivých částí webu a pod ně píšu předpisy pro prvky, co se tam nachází) Takže třeba takhle:

/*footer*/
p{color: #000; font-size: .9em; width: 100%; text-align: center}

Přehledný, jasný. A když už něco jasný není, nebo po roce nebude, máme tu firebug či webdeveloper, který nám už předpisy pro konkrétní prvek dohledá nejen na více místech jednoho CSS ale i ve více CSSkách, když už jsme si to takhle roztahali.

Hoween

Ale proč? Každá mezera ten zápis zbytečně nafukuje, takže se ztrácí výhody inline zápisu. Znovu opakuji, zkuste do svých úvah přibrat syntax-highlighting…

Hoween

O syntax-highlighting jsem slyšel poprvé včera vnoci
Pak ovšem váš článek a obhajobu „velkorysého“ zápisu naprosto chápu. Leč jsou lidé, kteří tuto funkci používají a proto nemají potřebu používat „velkorysý“ zápis.

Ale vážně – vy tvrdíte, že komprimovat by měl člověk a dekomprimovat počítač. Já tvrdím opak.
Probůh, kde? Stroj nic nedekomprimuje. Stroj zpracuje to, co mu přijde na vstup. Komprimovaný vstup zpracovává rychleji. Stačí vám to takhle?

Proto by člověk měl dbát na to, aby jeho jazyk byl srozumitelný lidem.
Ale inline zápis evidentně srozumitelný je, když ho řada lidí používá. Co na tom nechápete?

Radovan

Ono riadkovy styl aj odriadkovany styl maju nieco do seba. Len musia byt dobre organizovane, co samozrejme spomina aj tento clanok.
Z mojich skusenosti viem, ze zapis do riadku je dobry pokial nepresiahne dlzku 4-5 definicii. Potom sa stava necitatelnym a velmi jednotvarnym.
Naopak pokial treba zapisat viac direktiv, tak je dobre vyuzit odriadkovanie, pretoze pre oko je jednoduchsie citat kratke dlzky riadkov nez dlhe.

Inak suhlasim s tebou v tom, ze preco by mal pocitac previest nasi hnusnu pracu do pouzitelnej podoby. Prave to ma robit opacne, my mame urobit peknu pracu, a o optimalizacie sa ma postarat pocitac. Na to tu predsa je.

Anonymní

Ono je to hodne o nastrojich co clovek pouziva. Zminovany priklad v editoru co nema fixni velikost pismen vypada o dost lepe a kdyz se pouzije jeste syntax-highliting a vymazou mezery na dvojteckami, dokazu si predstavit ze bych to pouzivat bez preformatovavani.

Osobne posledni dobou ale pouzivam prevazne 'vim' a pouzivam trosku kompromis – mezery za dvojteckami ne, neco nechavam na jednom radku (napr. celou definici pisma) a neco davam na radek dalsi (zvlast barvy, zvlast pismo, zvlast okraje):

.ukazka {
color:#000; backgroud-color:#fff;
font-size:.9em; font-weight:bold;
width:500px; height:200px;
text-align:center; clear:both;
margin:10px 0px; padding:5px 5px 0px 5px;
}

Co se tyce zvetseni kodu, tak ten se prilis nezvetsi (misto jedne mezery za strednikem je konec radku a tabulator = jeden znak navic) a je to o neco prehlednejsi nez vse na jednom radku a navic to neni ani prilis dlouhe (takze se neuroluji k smrti).

VfB

pro mně je tento způsob zápisu s mezerami na dvoutečkou špatně čitelný, pokud bych neměl obarvený kód, tak pořádně nevidím, kde končí jedna definice…

Hoween

Překvapivě od toho tu syntax-highlighting máme. A kromě pár extrémních editorů (Notepad, nano…) se dá nastavit ve všem.

luboskmetko

Tiez pouzivam jednoriadkovy zapis pravidiel, ale s medzerami:

/* Secondary navigation */
#sec-nav a { text-decoration: none; color: #a47463; }
#sec-nav a:hover { color: #c86130; }
#sec-nav a.current { font-weight: bold; }

Dlhe roky som bol zastancom viacriadkoveho zapisu, ale potom som prisiel na to, ze jednoriadkovy ma viacero vyhod. Okrem zjavnych ako je mensia velkost vysledneho suboru, je to hlavne mensi pocet riadkov (3 – 4 krat menej), cim odpada nutnost neustaleho rolovania hore dole. Skuste pracovat s 200-riadkovym kodom a potom s 800-riadkovym.

No a napokon dalsia velka vyhoda (ak nie najvacsia) je, ze dobre vidite vztahy a dedenie medzi selektormi pokial ich zapisujete pod seba. Jasne vidite (na jednej obrazovke), co vsetko ovplyvnuje vysledny dizajn urciteho prvku. Ako je to konkretne ovplyvnovane, teda pravidla, je dolezite az sekundarne, preto pravidla mozu byt na jednom riadku, kde si uz lahko dohladate ci tam je float: left; alebo float: right;

karmi

> Skuste pracovat s 200-riadkovym kodom a potom s 800-riadkovym.

To pak ale svědčí o tom, že stylesheet není rozdělen do separátních souborů. Pracovat s CSS v jednom souboru s 800 řádky může být hezký masakr.

Hoween

Svědčí. No a? U vysoce zatížených systémů se kromě minimalizace provozu snažíme omezovat i počet požadavků na server. Proto se použije inline zápis a X řádků, místo řádkování za každou direktivou, čímž vznikne soubor s 5X řádky, který pak musím zbytečně dělit do více souborů.

karmi

Ne.

a) Čitelnost a udržovatelnost kódu je důležitější vlastnost než (mnohdy fiktivní) výkonnost. "Far better to trade a few cycles and a few kilobytes of memory for the overhead of a scripting language's memory manager and economize on far more valuable human time." Eric Raymond, Why Python?, http://www.linuxjournal.com/article/3882

b) Od optimalizace, minimalizace a manipulace kódu jsou tu dobré nástroje a stroje, ne lidé. Například v Ruby on Rails: http://api.rubyonrails.org/classes/ActionView/Helpers/AssetTagHelper.html#M001687

Hoween

Ach jo. Proč používat hlavu, když to všechno můžu dát stroji.

Ad a) inline kód je pro mě čitelný a udržovatelný, nevidím důvod ho psát jinak. A co se týká výkonnosti, kterou označujete za fiktivní – zkuste méně číst a více dělat. Opět tady poučuje někdo, kolem koho praxe ani neproběhla. Zkuste si to někdy změřit a spočítat, jaký traffic které řešení produkuje a kolik požadavků jde na server. A od své osobní stránečky to přepočítejte na portál se stovkami tisíc pageviews denně. A pokud mi chcete tvrdit, že počet požadavků na server není důležitý, tak se s vámi opravdu nemám o čem bavit.

Ad b) viz výše, optimalizaci CSS kódu dělám už tím, jak jej píšu. Nepotřebuju na to nástroje. Na JS samozřejmě Edwardsůw packer používám.

karmi

Pane, zkuste více číst a méně psát, nebo alespoň více číst před tím, než píšete.

Hoween

Já čtu dobře. Vy na základě cizích článků tvrdíte, že traffic a počet requestů nemá vliv na výkon. Ovšem každý, kdo má aspoň trochu vlastních zkušeností z praxe vám řekne přesný opak :-) Pokud byste někdy řešil nějaký opravdu zatížený 24×7 systém, pochopil byste, jak hrozné bláboly tady citujete.

Ano, jsou dva přístupy k práci. Buď zaměstnavatel najme lemply programátory a radši koupí silnější železo, nebo bude zaměstnávat profíky, kteří nebudou mít se čtením kódu takové problémy, a pak se mu ta investice vrátí v mnohem více věcech, než jen na ušetřeném železe.

Radovan

Pisete fakt tendencne a mlzivo, ze vam to snad aj niektori uveria.

No nejako zabudate na fakt, ze existuje taka pekna vec co sa vola CACHE. A pri casto navstevovanych strankach, pocitam ze tam ti ludia chodia kazdy den, zapracuje velmi dobre prehliadac.

Hoween

Ale já na nic nezapomínám, to jen vy nepřemýšlíte.

Cache funguje na regulaci samotného trafficu, ale požadavek jako takový se posílá vždy.

Radovan

Vy viete vsetko, ostatni nevedia nic. S takymi som sa stretol vela krat, vyskakuju len na internete. V skutocnom zivote je to s nimi naopak velmi zle.

Ano poziadavok sa posiela stale. Toho som si vedomi. Kedysi som bol podobne na tom ako vy. Setrit, setrit, setrit. Lenze praca vyvojara je drahsia ako to zelezo na ktorom to bezi.

Hoween

A to je přesně ten špatný přístup. Zaměstnavatel radši nakoupí mizerné vývojáře, a udělá jednorázovou investici do nového železa, než mít pořádné programátory a železo používat na jiné věci.

Radovan

Neexistuju len dobri a zli vyvojari. Je tam aj kategoria pragmaticki vyvojari, poculi ste o nich ?

Karel

Tak to jste měl štěstí. Já už pár takových potkal i v běžném životě. Extrovertní osobnosti využívající faktu, že jen z cca 20% záleží na tom co umíte, ale ze 70% záleží na tom, jak to umíte prodat. Měl jsem kolegu, který se půl dne mořil s nějakým problémem. Pak přišel jiný kolega, podrbal se za uchem a za minutu bylo hotovo. Z reakce našeho "extroverta" jsem se pak hodně naučil. Na manažerském mítingu neřekl "podívejte jak jsem hloupý, že jsem na to ani po půl dni nepřišel", ale velmi sebejistě prohlásil "podívejte jak těžký problém to byl, ani já jsem na to za půl dne nepřišel". Hoween zjevně patří do stejné kategorie – ze svých nedostatků dělá své přednosti a manipulativní rétorikou se snaží ostatní přesvědčit, že jeho obvykle mimořádné názory nejsou "out" ale "in". Zkrátka snaží se budit dojem těžkého profesionála, který všechno zná, všechno ví a všechno už naprogramoval dvakrát. Možná jím je, možná ne. Nevím, ale podle pravidla "když ti bůh někde přidal, jinde ti musel ubrat" mám nedůvěru k lidem, kteří mají rozvinuté "marketingové" dovednosti.

Ale teď k celému článku – subjektivní článek o ničem (o tom ale asi rubrika je). Jediné co podle mého názoru je dobré dodržovat je pasáž o používání zkrácených zápisů. Zkratek je moc a jeden pak neví, zda původní autor "nedohlédl" všech dopadů zkratky, nebo v tom byl naopak záměr. Jestli jsou vlastnosti na jedné řádce nebo na více je v době syntax highlighting opravdu jedno.

Hoween

Vzhledem k tomu, kolik lidí tady v komentářích uvádí, že používají inline zápis, nemyslím si, že by můj eventuální nástupce s tím musel mít nějaký problém. Nehledě na to, že při práci třeba s SVN se stejně musí styl práce zachovat. Takže je to zase jen a pouze o lidech. Inline zápis se používá a ti, kdo jej používají, se v něm bez problémů vyznají. Že se v něm nevyzná někdo jiný je jen a pouze jeho problém.

luboskmetko

No lenze to bol len jednoduchy priklad s par pravidlami, keby ich bolo viac a keby aj tych selektorov bolo viac, tak uz by to take jasne pri viacriadkovom zapise nebolo.

ITGuru

Tak já se musím přidat k inline stylařům. Já píšu styly pořád inline. Odřádkovávat jsem musel tam, kde to už kolega odřádkované měl abych dodržel jednotný formát. Pří zápisu mi to docela vyhovuje, je to rychlé a IDE s tím dost pomáhá, ale při čtení mi to přijde hrozně nepřehledné protože je to moc dlouhé a pořád musím scrolovat. Největší CSS soubor se kterým jsem dělal měl 4960 řádků (styl byl jak je uveden v článku). V takovém souboru se opravdu mizerně orientuje. Teď jsem pro zkušební účely zkusil CSS přeformátovat na řádkový a vešlo se to na 1122 řádků. Díky inline zápisu scroluji vertikálně jen málo a horizontálně jen velmi výjimečně. Když by byl řádek hodně dlouhý, tak už jsem použil i zalomení – př.: (nejde zadat – prý spam)

Jinak moje další pravidla jsou: Mezery za středníky (aby byla rychlejší orientace mezi vlastnostmi na řádku), ale za dvojtečkou ne (tam to imho není potřeba – hledám margin, pomocí mezer ho rychle najdu a sotva najdu margin, tak už znám jeho hodnotu). Mezery za dvojtečkou by byly dobré, kdybych hledal podle hodnot :-).
Jak psal nějaký kolega nade mnou řádkový zápis, ale s mezerami za otevírací složenou závorkou a před uzavírací, tak tento způsob se mi nelíbí – ty mezery mi přijdou takové matoucí a zbytečně roztahují řádek. Komentáře píšu pouze u celých sekcí kde označuji místo že tady styluju hlavní menu, tady levé menu, tady stránkování, tady univerzální styly atp.

ITGuru

Ano – je pravda, že u takto velkých souborů je orientace mizerná asi vždycky. Jen jsem chtěl uvést příklad jak se kód zmenší. Navíc jsem přesvědčen, že by se ten styl dal přepsat na minimálně o třetinu menší. Styl jsem ale nedělal sám, tak jsem se v tom nemohl moc vrtat.

r1.tarmaq

Pridavam se k autorovi clanku, preferuji zapis na vice radku. Chapu jsou zde dve strany, jedna preferuje to druha ono. Je zde ale dalsi argument proti inline zapisu – verzovani (SVN, GIT, Mercurial atp.)
Je mnohem jednodussi cist diff, kdyz presne vidim ktery radek byl odebran a ktery smazan.
Posudte sami:

– #content #hlavicka2 p#menu li a { width: 130px; padding: 10px 4px 10px 6px; display: block; float: left; text-transform: uppercase; background-color: #4DBEE9; color: #292929; }
+ #content #hlavicka2 p#menu li a { width: 180px; padding: 10px 4px 10px 6px; display: block; float: left; text-transform: uppercase; background-color: #4DBEE9; color: #292929; }

vs.

#content #hlavicka2 p#menu li a {

– width: 130px;
+ width: 180px;

}

V kterem z dvou vyse uvedenych zapisu zjistite jaka byla opravdu zmena rychleji?
Jinak toto samozrejme plati i pro jine jazyky.
Pokud vam vadi prilis zobrazeneho kodu naraz, tak na to pouzivam folding..

PS: omlouvam se ze u druheho prikladu jsem umazal ostatni vlastnosti, ale mistni system chtel prispevek oznacit jako SPAM, berte to prosim tedy orientacne..

Hoween

Minimálně sublipse, a možná že i želva, umí zvýrazňovat přímo konkrétní změnu. Takže ve vašem příkladu by zvýraznila pouze ta čísla 130/180, nikoli přidaný/odebraný celý řádek kódu.

r1.tarmaq

jasne, tyhle nastroje zvyraznujici zmenu znam, neda se ale prece predpokladat, ze je pouziva kazdy.
Navic kdyz ovladam SVN z terminalu, tak si nebudu zapinat zelvu nebo neco podobnyho.

Anonymní

Tak nevím, ale myslím si že je docela jedno jak kdo daný kód píše. Samozřejmě je přehlednější použít "velkorysý" kód, ale když pak listuji těmi tisíciřádkovými css tak to je hrozné. Osobně píši (když už teda po prasokodérech musím stylovat) velkoryse a púřed uploadem provedu kompresi. Preferuji psát stromově a ne na dané id a dostylovávat daný element, i když to zde nedoporučujete. Výsledné html je pak plné naprosto zbytečných ID, které šly nahranit za klasický DOM (ať žije). Je to sice nepřehlednější a húře se to přenáší jinam, ale je pak mnohem přehlednější. Ale jak zde již bylo řečeno, každý máme svůj způsob který preferujeme popř. odsuzujeme.
Víc si říkám zda by nebylo záhodny mistry kódery taky naučit kódovat. Když po nich následně provádím implementaci a zjistím že tenhle box není roztahovací, tohle je úplně blbě a ve výsledku si 40% musím nastylovat sám tak by mě z toho "jeblo". Uvedu příklad který mě vážně rozesmál: koder mi nastyloval počasí jako obrázek na pozadí, který v sobě obsahoval ikonu počasí a danou teplotu. (a ted co ja s tim, mam pro kazždý stupeň generovat obráízek, nebo si to nastylovat sám? :-D)

alian

Mne sa pacili tieto nedavno publikovane tipy http://www.hongkiat.com/blog/20-useful-css-tips-for-beginners/

Ja.

Ja používam abecedné poradie (pokial nie je potrebné inak), je v tom problém? Som totiž php programátor a css beriem ako nutné zlo, keďže to nemá kto iný robiť…
Príklad:
.objekt {
border:1px solid black;
border-bottom: 2px solid black;
display:block;
float:left;
font-size:1.2em;
height:100px;
width:100px;
}

mofo

php prográmator? to je nějaká omezující nemoc? v tvém podání to tak vyznělo :-P

Ja.

nj, mám takú diagnózu :-)

Gappa

Vyzkoušel jsem už také několik způsobů a momentálně mi příjde nejlepší tento :)

div#menu4    {}
div#menu4 ul {margin: 0; padding: 0;}
div#menu4 li {float: left;}
div#menu4 a  {}

Oblíbil jsem si ho z těchto důvodů:

  • vejde se více na obrazovku
  • jelikož pracuji na širokoúhlém displayi, lépe ho využiji
  • deklarace začínají od stejného místa
  • a celkově mi to osobně příjde přehlednější

Není to všespásné – pokud ze potřeba zapsat něco opravdu dlouhého, co by se na řádek nevešlo, použiji klasický rozšířený a je to. Také má člověk trochu víc práce s formátováním, ale nic zásadního.

Komentáře jsem si zvykl psát, vyplatí se to. Ve výsledku je jedno, jaké formátování použiji, nakonec to stejně přechroustá script, ze kterého vypadne kompaktní verze.

Samozřejmě, je to o zvyku a osobních preferencích, tak to tak nehroťte :)

Gappa

Málem bych zapomněl na obvyklou posloupnost:

  1. pozicování
  2. float & display
  3. rozměry
  4. margin & padding
  5. color/font/line-height/text-align…
  6. border
  7. background
  8. zbytek

Snad je tam tak nějak vše podstatné a na nic jsem nezapomněl.

Ve většině případů postupuji právě zhruba takto – zatím mi to vyhovuje.

Hoween

Ty prázdné definice tam mají jaký význam?

Gappa

Někdy se hodí, aby se pouhým kouknutím do css dala odhadnout struktura html, ale v tomto případě mi tam zůstali tak nějak do počtu :)

Gappa

"zůstaly" :(

Honza Sládek

Předně děkuji autorovi za otevření tohoto tématu zde na Zdrojáku. O tom, jakým způsobem psát stylopis tak, aby se v něm vyznal i někdo jiný (popřípadě i sám autor po delší době) a aby byl snadno udržitelný, bychom měli mluvit stále dokola.

Osobně jsem zastánce inline zápisu. Proč?

  1. Jako uživatel širokoúhlé obrazovky mám přeci jen více místa do strany, než do výšky
  2. Jsem šťastný uživatel Macbooku. Pokud jste někdy pracovali s jeho touchpadem zjistíte, že mezi scrolováním dolů a jakýkoli jiným směrem není rozdíl. Pokud ovšem pracuji s myší uznávám, že scrollování do strany jde maličko hůře.
  3. Inline zápis mi umožňuje odsadit jednotlivé definice dle toho, jak jsou zanořeny ve struktuře stránky. Např:

.article {margin: 1em; overflow: hidden}
	.article h2  {border-bottom: 0}

Takto se mi lépe orientuje v kódu, nejvíc na levé straně je nadřazený element, věci, které jsou uvnitř něj nastylovány specificky jsou poté odsazeny.

Několikrát jsem řešil to, zda bych měl jednotlivé definice nějak řadit. Někteří lidé to dělají abecedně, jiní na to kašlou a další mají nějaký svůj způsob. Osobně to nikterak neřadím z důvodu toho, že jsem příliš pohodlný takovou strukturu dodržovat a přemýšlet, kam danou definici napsat. Máte někdo zkušenosti s abecedním řazením? Pokud po vás někdo převezme kód, je to pro něj pohodlnější, když ví přesně kde má definici hledat?

Ještě mě zaujal systém Erica Meyera. Ten píše některé definice na jeden řádek a jiné odsazuje na nový. Má v tom určitý systém, kdysi o tom psal, ale nedaří se mi ten článek dohledat.. (pro ilustraci mrkněte na jeho CSS).

Nebo třeba Chris Coyier, ten píše css taky inline zápisem, ovšem rozděluje opticky stylopis na dvě poloviny. V jedné jsou selektory a v druhé definice (viz např. stylopis CSS-tricks.com). Taky zajímavé a opticky to nevypadá špatně…

Prostě možností je mnoho, škoda že se článek jimi aspoň trošku nezabýval a rovnou šel stylem co řádek, to definice. Určitě to může spoustě lidem sedět, další spousta lidí ale raději vidí více selektorů najednou a má větší přehled nad dědičností (imho je to z inline zápisu lépe vidět – tedy alespoň já to tam lépe vidím. To je důvod, proč ho používám. S čímž je částečně spojené to zanořování o kterém jsem mluvil.

Co vy na to? Používáte některou z uvedených věcí, nebo máte svůj vlastní styl? Řadíte jednotlivé definice, nebo je necháváte ležet?

luboskmetko

Sorry, ale akekolvek odsadzovanie v CSS mi odjakziva pripadalo ako zbytocne zdrzovanie, navyse sa straca to, ze vidis lahko dedicnost. Tiez stale musis rozmyslat kolko ktory selector odsadit, napr. #nav li a pod tym #nav a odsadis ako?

Honza Sládek

Nijak. Napíšu #nav první a pod něj napíšu #nav li. Ale záleží to na osobních preferencích, že.

Honza Sládek

Máš pravdu, v subjektivním článku se asi má obhajovat jeden postup. :)

K Natalii a vytváření zpětné vazby

Ona má nepochybně pravdu, vytvářím tím určitou vazbu. Ale vem si modelový příklad. Mám z html5 element article a v něm nějaký nadpis, jméno autora etc. Mě osobně dává smysl to, že tyto dva prvky budou v tomto elementu nastylovány vždy stejně. Pokud tedy změním html strukturu třeba tak, že přesunu jméno autora na konec článku, tak se mi v CSS žádné odsazení nezmění (v CSS si naznačuji závislost, že prvek address se vyskytuje v prvku article). Pokud bych prvek address vyndal z elementu article, tak se najednou vztahuje zcela k jiné části obsahu a nemá se na něj co vztahovat jakákoli definice pro prvek address v article. Bude pravděpodobně vypadat zcela rozdílně a bude třeba napsat jinou/původní přepsat. A pokud už to přepisuji, zmáčknout ctrl+x a ctrl+v na správném místě stylu, mi přijde jako minimální cena za to, že člověk po mě přijde a koukne: jo, tady je článek, v něm je prvek address a ani se nemusí koukat do html…

Je to možná trošku zmatené, ale snad je z toho vidět ta myšlenka..

quqwbaq

88GqOH ewutvbkkoynp,
[url=http://qu­qeksacoeiw.com/]qu­qeksacoeiw[/ur­l],
[link=http://gcg­ovlrutrcc.com/]gcgo­vlrutrcc[/lin­k], http://snlpsysspgcy.com/

Anonymní

hhh, what a lusers.

ivusko

Mne sa okrem spominanych postupov osvedcilo tabulatorovat jednotlive idcka a classy podla hierarchie.

#header
#header h1
#header h1 a

potom netreba ani komentare a vsetko sa da lahko najst

aprilchild

co tady proboha resite? piste to v ramci teamu a projektu (tym muze byt i jeden clovek:) stejne, drzte v git/svn/cokoliv, do produkce to hazejte minifikovany a nemarte cas zbytecnou diskuzi.. je to jen css..

JanJanuska

Nikdy by ma nenapadlo, koľko sa dá diskutovať či používať inline zápis alebo nie. Keď niekomu vyhovuje inline viac, tak je to jeho vec. Len otázne je, či tomu bude rozumieť aj osoba, ktorá ho bude po ňom čítať.

petr.steinbauer

zasílám odkaz na náhled mého stylu, zdá se že nikdo ho nepoužívá:
http://img516.imageshack.us/img516/7707/styl.png (screen z rozpracovaného realitního projektu)

Výhody zarážek jsou obrovské:
– ihned vím co je nad čím a co pod čím, orientuji se v řádkách velmi rychle – bloky mi rovnou říkají co patří pod co.

prosím o oponeturu

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.