81 komentářů k článku Udržovatelný stylopis: CSS kód, ze kterého nerozbolí hlava:

    1. ph0enix

      RE: Udržovatelný stylopis: CSS kód, ze kterého nerozbolí hlava
      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… :-(

      1. Martin MichálekAutor příspěvku

        RE: Udržovatelný stylopis: CSS kód, ze kterého nerozbolí hlava
        Odkazy už fungují. V souboji s doménovou problematikou bývám často poraženým :-)
        Díky za upozornění.

  1. Hoween

    Špatný příklad
    #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.

    1. VfB

      Re: Špatný příklad
      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)

      1. Mingan

        Re: Špatný příklad
        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.

        1. Hoween

          Re: Špatný příklad
          > 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? ;-)

          1. WuDo

            Re: Špatný příklad
            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…).

            1. Hoween

              Re: Špatný příklad
              > 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á.

        2. Miloslav Lešetický

          Re: Špatný příklad
          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?

          1. Hoween

            Re: Špatný příklad
            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.

            1. Miloslav Lešetický

              Re: Špatný příklad
              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.

              1. karf

                Re: Špatný příklad
                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.

        3. VfB

          Re: Špatný příklad
          na webu je dost nástrojů (i online) pro převod z "inline stylu" do "sloupcového zápisu"

    2. Martin MichálekAutor příspěvku

      Re: Špatný příklad

      Závidím vám! Vstřebáváte kód lépe než leckterý prohlížeč :-)

      Zdrojem inspirace proč psát stylopis velkoryse a ne „počítačově“ může být typografie nebo třeba Karel Kryl :-)

      Srovnejte komprimovaný zápis:

      
      Z rozmláceného kostela v krabici s kusem mýdla přinesl jsem si anděla Polámali mu křídla
      Díval se na mě oddaně já měl jsem trochu trému tak vtiskl jsem mu do dlaně lahvičku od parfému
      

      S velkorysým

      
      Z rozmláceného kostela
      v krabici s kusem mýdla
      přinesl jsem si anděla
      Polámali mu křídla
      Díval se na mě oddaně
      já měl jsem trochu trému
      tak vtiskl jsem mu do dlaně
      lahvičku od parfému
      
      1. Hoween

        Re: Špatný příklad
        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…

        1. Radovan

          Re: Špatný příklad
          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.

          1. Hoween

            Re: Špatný příklad
            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?

            1. Radovan

              Re: Špatný příklad
              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.

            2. Lokutus

              Re: Špatný příklad
              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.

              1. mofo

                Re: Špatný příklad
                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.

            3. Ash

              Re: Špatný příklad
              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í.

              1. Hoween

                Re: Špatný příklad
                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

                1. Radovan

                  Re: Špatný příklad
                  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.

        2. garcon

          Re: Špatný příklad

          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.

  2. david-binda

    Webdeveloper, Firebug
    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.

    1. Martin MichálekAutor příspěvku

      Re: Webdeveloper, Firebug
      Díky za příklad.

      Co třeba ale jen trochu upravený kód?

      
      /*footer*/
      p{color: #000; font-size: .9em; width: 500px; text-align: center; clear: both; margin: 10px 0px; padding: 5px 5px 0px 5px;}
      

      Osobně, kdybych takový kód po vás převzal, musel bych jít za nějakým CSSTidy a požádat jej o převod do velkorysé podoby.

      Ano, Firebug je skvělý a i neuvěřitelně zkomprimovaný kód převede do čitelnější podoby.

      Proč by ale za nás měl počítač (Firebug) naši práci převádět do čitelné podoby? To bychom měli dělat sami, my jsme lidé a pro nás je čitelnost důležitá.

      Od počítače chci přesně opačný proces – komprimaci a tedy převod do nečitelné podoby.

      1. Hoween

        Re: Webdeveloper, Firebug
        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…

        1. Martin MichálekAutor příspěvku

          Re: Webdeveloper, Firebug
          O syntax-highlighting jsem slyšel poprvé včera vnoci, ale do úvah, na kterých je založen článek, se je naštěstí podařilo těsně před uzávěrkou vměstnat. :-)

          Ale vážně – vy tvrdíte, že komprimovat by měl člověk a dekomprimovat počítač. Já tvrdím opak.

          Člověk potřebuje komunikovat srozumitelným způsobem. Kodér je člověk a proto často předává kód jiným lidem. Vždyť kód je také jazyk. Je to prostředník mezi člověkem a počítaček. A také člověkem a člověkem. Proto by člověk měl dbát na to, aby jeho jazyk byl srozumitelný lidem.

          1. Hoween

            Re: Webdeveloper, Firebug

            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?

            1. Martin MichálekAutor příspěvku

              Re: Webdeveloper, Firebug

              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.

              Ó, pardon, větu jsem zřejmě nedostatečně označil jako ironii.

              Ale inline zápis evidentně srozumitelný je, když ho řada lidí používá. Co na tom nechápete?

              Řada lidí také lže a krade. Pardon, to považujete za argument hodný svého jména? :-)

      2. Radovan

        Re: Webdeveloper, Firebug
        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.

      3. Anonym

        Re: Webdeveloper, Firebug
        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).

      4. VfB

        Re: Webdeveloper, Firebug
        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…

        1. Hoween

          Re: Webdeveloper, Firebug
          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.

  3. luboskmetko

    Jednoriadkovy zapis pravidiel

    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;

    1. karmi

      Re: Jednoriadkovy zapis pravidiel
      > 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.

      1. Hoween

        Re: Jednoriadkovy zapis pravidiel
        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ů.

        1. karmi

          Re: Jednoriadkovy zapis pravidiel
          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

          1. Hoween

            Re: Jednoriadkovy zapis pravidiel
            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.

            1. karmi

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

              1. Hoween

                Re: Jednoriadkovy zapis pravidiel
                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.

                1. Radovan

                  Re: Jednoriadkovy zapis pravidiel
                  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.

                  1. Hoween

                    Re: Jednoriadkovy zapis pravidiel
                    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.

                    1. Radovan

                      Re: Jednoriadkovy zapis pravidiel
                      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.

                      1. Hoween

                        Re: Jednoriadkovy zapis pravidiel
                        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.

                        1. Radovan

                          Re: Jednoriadkovy zapis pravidiel
                          Neexistuju len dobri a zli vyvojari. Je tam aj kategoria pragmaticki vyvojari, poculi ste o nich ?

                      2. Karel

                        Re: Jednoriadkovy zapis pravidiel
                        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.

            2. Martin MichálekAutor příspěvku

              Re: Jednoriadkovy zapis pravidiel

              Ach jo. Proč používat hlavu, když to všechno můžu dát stroji. … viz výše, optimalizaci CSS kódu dělám už tím, jak jej píšu

              Komprimujete kód hlavou a šetříte tím svůj software a hardware? :-) To je příkladně ekologické!

              Zároveň tím ale zvyšujete pravděpodobnost, že člověk, který kód bude chtít převzít po vás, sáhne po zcela neekologickém řešení – použije software, aby stylopis rozšifroval.


              A pokud mi chcete tvrdit, že počet požadavků na server není důležitý..

              Počet požadavků je samozřejmě důležitý, více se mu bude věnovat druhý díl článku.

              1. Hoween

                Re: Jednoriadkovy zapis pravidiel
                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.

    2. Martin MichálekAutor příspěvku

      Re: Jednoriadkovy zapis pravidiel

      cim odpada nutnost neustaleho rolovania hore dole.

      Zastánci „lidmi komprimovaného kódu“ často vychází z premisy, že rolování je zlo. Tvrdím, že rolování žádné zlo není. Je to činnost, o které lidé (nerozumím proč) často mluví s despektem, ale v reálném užívání jim dělá stejné „problémy“ jako zapnutí počítače. :-)

      …dobre vidite vztahy a dedenie medzi selektormi pokial ich zapisujete pod seba.

      Podobné selektory máte správně za sebou a souvislosti byste viděl i v případě velkorysého zápisu. Dokonce i na malém displeji:

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

        Re: Jednoriadkovy zapis pravidiel
        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.

  4. ITGuru

    Moje pravidla
    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.

    1. Martin MichálekAutor příspěvku

      Re: Moje pravidla

      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.

      Myslím, že ve vaší druhé verzi souboru o 1122 řádcích v inline verzi to nebude o mnoho lepší :-).

      Možná by pro někoho bylo zajímavé jak se v takto velkých souborech orientuji:

      Soubor mám rozdělený do sekcí a subsekcí, kde každá nemá více než 10-15 selektorů a vlastní unikátní pojmenování („Stránka Kontakt“, „Stránkování“, „Patička“). Mezi jednotlivými sekcemi se pohybuji pomocí vyhledávání (ctrl+f). V rámci sekcí pak očima.

      Na to ctrl+f nejsem příliš pyšný :-) Chtěl bych, aby můj PSPad uměl totéž, co CSSEdit – automaticky zobrazovat strukturu stylopisu: http://macrabbit.com/cssedit/screenshots/Reindent.jpg

      1. ITGuru

        Re: Moje pravidla
        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.

  5. r1.tarmaq

    inline?
    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..

    1. Hoween

      Re: inline?
      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.

      1. r1.tarmaq

        Re: inline?
        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.

    2. Anonym

      Re: inline?
      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)

  6. Ja.

    abeceda
    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;
    }

  7. Gappa

    Můj styl
    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 :)

    1. Gappa

      Re: Můj styl
      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.

      1. Gappa

        Re: Můj styl
        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 :)

  8. Jan Sládek

    výhody inline zápisu + pár odkazů do světa

    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?

    1. luboskmetko

      Re: výhody inline zápisu + pár odkazů do světa
      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?

      1. Jan Sládek

        Re: výhody inline zápisu + pár odkazů do světa
        Nijak. Napíšu #nav první a pod něj napíšu #nav li. Ale záleží to na osobních preferencích, že.

    2. Martin MichálekAutor příspěvku

      Re: výhody inline zápisu + pár odkazů do světa

      Super, Honzo. Díky za komentář.

      K odsazování…

      Nedávno jsem s ním experimentoval, ale odradila mě od toho právě Natalie Downe, která IMHO správně říká, že tím vytváříš zpětnou závislost formátování stylů na struktuře HTML. Ta když se ti změní, musíš jít ještě do stylů a upravit odsazování.

      K E. Meyerovi a tomu, že „píše některé definice na jeden řádek a jiné odsazuje na nový“

      Super, že ho zmiňuješ. Vlastně to občas dělám taky – u jednodušších stylopisů ten způsob používám pro definice skupin selektorů, které se od sebe liší jen jednou vlastností – třeba obrázkem na pozadí:

      
      .calendar-date.day-1 { background-image: url("/images/days/1.png") }
      .calendar-date.day-2 { background-image: url("/images/days/2.png") }
      

      Prostě možností je mnoho, škoda že se článek jimi aspoň trošku nezabýval..

      Jsem přesvědčený, že varianta, kterou popisuji v článku, je správná. Proč bych tedy v rubrice Subjektivně popisoval jiné? K tomu jsou komentáře a v té souvislosti jsem moc rád za odvážlivce, kteří zde svůj kód odhalili a obhajují. :-)

      1. Jan Sládek

        Re: výhody inline zápisu + pár odkazů do světa

        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..

        1. Martin MichálekAutor příspěvku

          Re: výhody inline zápisu + pár odkazů do světa

          Honzo, na příklad s článkem a jeho dceřinnými prvky velmi pravděpodobně nebudeš tou závislostí odsazování ve stylopisu na struktuře kódu omezován.

          „Velmi pravděpodobně“ pro mě ale není dost a hlavně v jiných případech nebude platit. Vezmi si třeba definici layoutu – tam se vnořování může měnit nejen z pohledu času a vývoje projektu, ale také z pohledu různých šablon projektu.

          Dávám přednost pravidlům, která lze používat obecně, a u tohoto to neplatí.

  9. ivusko

    pod seba a tabulatorovat
    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

  10. aprilchild

    OMG
    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..

  11. JanJanuska

    diskusia
    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ť.

  12. petr.steinbauer

    Můj styl
    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

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=2962