35 komentářů k článku Scukařina, žádná dřina – díl čtvrtý: jiná práce s CSS:

  1. Lukas

    Mnoho povyku pro nic

    Opravdu je nutné věnovat tolik prostoru pár kulatým rohům a jednomu buttonu? To jsou věci, které řeší každý kodér dnes a denně… Mimochodem než bych si zaplácal kód tímhle příkladem, raději použiju klasické sliding doors se stejným efektem, kratším kódem a podporou ve všech prohlížečích ;-)

    1. mikiqex

      Re: Mnoho povyku pro nic

      Bohužel musím souhlasit. Článek je moc pěkně zpracovaný, ale jeho informační hodnotu by bylo možné shrnout do jednoho, dvou odstavců.
      Ale ačkoliv jsem odpůrce jakýchkoliv segregací v CSS, zaujala mě myšlenka „využívat CSS3 kde lze, ostatním podstrčit obrázky“. Díky za tip.

    2. Karel Minařík

      Re: Mnoho povyku pro nic

      Ale? Naopak, „kulaté rohy“ zde slouží jako vynikající, protože všem srozumitelný a jednoduchý příklad vlastnosti, kterou je potřeba upravovat specificky pro jednotlivé prohlížeče. _Postup úvahy_ shrnutý v článku je hezký a inspirativní. Technické řešení taky, ale důležitější je právě to první – myšlenka sama.

      1. Ladislav Toral

        Re: Mnoho povyku pro nic

        Ale tyhle problémy design vs úsilí přece řeší webdesigneři každý den, Mlho…
        Promiň Martine, dobrý článek, jenom mám pocit že je na Zdrojáku už trochu přescukováno.

        1. Petr Staníček

          Re: Mnoho povyku pro nic

          Beru to jako výbornou case study. Každý problém se dá řešit X způsoby a je prima sledovat, jak se s tím vypořádávají jiní. Osobně vůbec nevnímám, že to je nějaký konkrétní Scuk, ale některé popsané postupy považuju za velice zajímavé. Zrovna tenhle článek je hodně pěkný a užitečný: kdo si nevidí na špičku nosu, vidí v tom jen další stokrát omleté řešení kulatých rohů, kdo ale trochu přemýšlí, najde tu nádherné a praktické řešení gracefull degradation v praxi. Mně se moc líbí a určitě mi to hodně dalo. Dík.

  2. Ondřej Válka

    Kupuju! Vyborna case-study

    Dlouho (mozna nikdy) jsem nepotkal tak skvele podany progressive enhancement s tak nepodlomitelnymi argumenty. Uvaha i samotna realizace je velmi chytra. Diky Martine!

    1. Petr Staníček

      Re: Kupuju! Vyborna case-study

      To je zajímavé, za poslední týden tohle řeším už potřetí… :) Tohle není progressive enhancement (PE), ale právě naopak, příklad gracefull degradation GD): výchozí funcionalita je vytvořena pro ideální browsery, které umí kulaté rohy samy, a do kódu se přidává jako nástavba řešení pro horší browsery.
      Být to PE, jde se na to přesně opačně: udělá se výchozí funcionalita, kterou zvládnou všechny browsery, a pak se tam přidává jako nástavba vylepšení pro ty lépe vybavené.
      Dneska se často setkávám právě s mnoha příklady PE (prakticky všechna řešení postavená na pluginech pro jQuery a všemožné jiné JS knihovny), ale dobře udělaná GD se moc často nevidí. Proto se mi tenhle článek tolik líbí, protože tady je použita přímo ukázkově.

  3. Jan Sládek

    Článek skvěle demonstruje, že se nad kódem musí přemýšlet

    Martin skvěle demonstruje, že ve web designu neexistují univerzální řešení. Skutečně paráda.
    Ovšem tip na vyjmutí vendor prefixů ven z hlavní definice je k nezaplacení. Dlouho jsem nemohl vymyslet rozumný způsob a tohle vypadá moc rozumně. :)

    1. tiso

      Re: Článek skvěle demonstruje, že se nad kódem musí přemýšlet

      Je to pekné, ale predsa len: kopírovať aj selektor? Nestačilo by:

      nav#categories li a {
        display: inline-block;
        padding: 10px 6px;
        border-radius: 7px 7px 0 0;
      /* [OBSOLETE?] Vendor prefixy */ -moz-border-radius: 7px 7px 0 0; }
      1. Martin MichálekAutor příspěvku

        Re: Článek skvěle demonstruje, že se nad kódem musí přemýšlet

        Jasně! Proč ne. Pro případy, kde se mění jen pravidla v rámci selektoru může být dostačující.

        1. Jan Sládek

          Re: Článek skvěle demonstruje, že se nad kódem musí přemýšlet

          Kluci, tak Martinovo řešení má přeci jen chybku.. Je potřeba dávat vendor prefixy PŘED ty nevedorprefixované věci. Viz článek Chrise Coyiera. http://css-tricks.com/ordering-css3-properties/
          Podle mě řešení je vyjmout i ty reálné věci a jako [FUTURE] pod to. Ale není to ideální. Máte někdo lepší nápad?

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

            Re: Článek skvěle demonstruje, že se nad kódem musí přemýšlet

            Dobrý postřeh, Honzo.

            Důležité je zmínit, že řešení s odsazování „zastarávajících“ se netýká jen vendor prefixů. Koukám do CSS Scuku a převažují situace bez nich.

            Příklad typické situace:

            #search input {
             ...
            }
              /* [OBSOLETE?] Pokud prohlizec neumi placeholder, musime ho stylovat jinak */
              .no-placeholder #search input {
                margin-top: 5px;
              } 

            Na ten článek na CSS Tricks odkazoval už Tomáš Hellebrand a já si říkal, že musím otestovat kolik kombinací prohlížeč/CSS3 vlasnost/pořadí je takto postiženo. Chris zmiňuje kombinaci jen jednu.

            Nicméně – odsazování a uvádění „zastarávajícího“ kódu za kód „stabilní“ je jen jednou částí výhody toho řešení.

            Asi důležitější součástí je štítek [OBSOLETE?], pomocí kterého můžeš „zastarávající“ kód snadno dohledávat během budoucích aktualizacích webu.

            Dovedu si pak příklad z článku představit takhle:

            /* Polozka navigace */
            nav#categories li a {
              display: inline-block;
              padding: 10px 6px;
              /* [OBSOLETE?] Vendor prefixy */
              -moz-border-radius: 7px 7px 0 0;
              border-radius: 7px 7px 0 0;
            } 

            Není to tak elegantní, ale zase nepoužívám dvakrát stejný selektor jak správně psal Tiso.

            Nakonec, Textmate myslím umí vytáhnout z kódu všechny části označení pomocí TODO. Určitě by ho nějaký zkušený uživatel Maca (tedy nikoliv já .-)), naučil vytáhnout i všechny [OBSOLETE?]. :-)

  4. pk

    další vrstva JavaScriptu?

    Píšete, že jste se rozhodli nepoužít CurvyCorners, abyste prohlížeče nezatížili další vrstvou JavaScriptu. A najednou bum ho, Modernizr. Rozhodli jste se pro tuto vrstvu JavaScriptu na základě benchmarků, a pokud ano, můžete se prosím podělit o čísla?

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

      Re: další vrstva JavaScriptu?

      Nebylo to na základě benchmarků. Modernizr bychom použili vždycky pro jeho přínos, který má pro vývojáře a v důsledku i pro uživatele.
      „Další vrstvou“ je CurvyCorners vzhledem k ostatním scriptům, které na Scuku používáme. Určitě jste se díval do zdrojáku, je jich dost. Proto přidání každého dalšího dost zvažujeme.

    2. keff

      Re: další vrstva JavaScriptu?

      Modernizr jen jednorázově při startu během pár milisekund detekuje browser capabilities a přidá třídy pro tag body, za běhu stránky tedy už žádnou zátěž nepředstavuje.
      CurvyCorners přidají do layoutu desítky DIVů a event listenerů na změny a přidání elementů, čímž zvýší zátěž CPU po celou dobu zobrazení stránky.
      Ale vy jste si asi přišel jen zakřičet, že (soudím tak podle toho, že mi přijde zbytečné benchmarkovat jeden ‚rozvětvený if‘, kterým modernizr je, a stejně tak mi přijde, že nikdo, kdo ví, co dělá, by ho nenazval ‚vrstvou‘)?

      1. pk

        Re: další vrstva JavaScriptu?

        Dobrý den,
        přišel jsem se zeptat na věc, které jsem se kvůli své chabé znalosti problematiky nerozumněl.
        Mějte se.

        1. ujc

          Re: další vrstva JavaScriptu?

          Jeste se podivejte na: ‚http://priruc­ka.ujc.cas.cz/?slo­vo=rozumět&Hle­dej=Hledej‘ Treba Vam to take diky Vasi „chabé znalosti problematiky“ pomuze.

  5. Hellish

    Vendor prefixy

    Perfektní článek, díky Martine.

    Jedna poznámka k vendor prefixům. Obecně se doporučuje dávat vendor prefixovaný vlastnosti před ty obecný (tzn. -moz-border-radius před border-radius) – viz. například http://css-tricks.com/ordering-css3-properties V uvedeném příkladě by stačilo jen přesunout „obsolete“ sekci úplně nahoru.

    Jinak já kvůli CSS3 a vendor prefixům používám SCSS (http://sass-lang.com/) to mi umožní mít vendor prefixy jen na jednom jediném místě jako:

    @mixin border-radius($pRadius){
        -webkit-border-radius: $pRadius;
        -moz-border-radius: $pRadius;
        border-radius: $pRadius;
    }

    Pak můžu kdekoliv jednoduše použít kulaté rohy jako:

    nav#categories li a {
        @include border-radius(5px);
    }

    Má to tu výhodu, že je to krásně přehledný (jen jeden řádek místo tří a více) a krásně se to udržuje. Až v budoucnu nebude potřeba používat např. -webkit prefix, tak ho na jednom jediném místě odstraním. Stejně snadno můžu přidat nový prefix, pokud to bude potřeba.

      1. Hellish

        Re: Vendor prefixy

        No právě kvůli jednoduchosti, kterou mi přináší, používám SASS! Tak to asi necháme na tu jinou diskusi :)

  6. David Grudl

    Stejná myšlenka ale jiné řešení

    Výborný článek! Moc se mi líbí, že autor uvažuje, než do stránky hodí nějakou univerzální všeřešící knihovnu. S dovolením bych přidal svůj ryze laický pohled, ať ho můžeme zkonfrontovat :-)

    Chybějící CSS3 vlastnosti vnímám z hlediska zastoupení prohlížečů jako problém čistě IE. Na druhou stranu tento prohlížeč jako jediný podporuje VML, což si troufám považovat za ověřenou a rychlou technologii, protože na ni staví Cufon. Tedy bych hledal něco, co simuluje border-radius pomocí VML a nedělá nic jiného. Pohled do zdrojového kódu CurvyCorners je pro mě odrazující, není tam zmínka o VML, zato má 55kB. (Odrazující je tedy i samotný web a přehled feature, které nechci). Vygooglil jsem totok http://code.google.com/p/curved-corner/ a zdá se, že uvedené řešení splňuje všechny požadavky. Malinké, registruje si pouze událost onresize a získám vektory namísto tahání bitmap ze serveru.

    Trošku jinak bych postupoval i při úpravě stylesheetu. Opět zcela souhlasím s myšlenkou, tedy že fixy je třeba oddělit od čistého kódu. Nicméně jako srozumitelný oddělovač vnímám samotný vendor prefix (resp. behavior:url). Jejich další vyčleňování mi připadá jako hlásit, že klakson troubí :-) Samozřejmě něco úplně jiného je běžná vlastnost (např. padding) řešící konkrétní problém nějakého prohlížeče. Ale i tam jsem si svého času dělal poznámku v podobě prefixu, kterému rozuměl buď jen IE 6 resp. 7. Tedy vyčleňoval bych teprve v okamžiku, když by byl fix tvořen více vlastnostmi dohromady.

    Berte prosím komentář s rezervou, CSS není můj šálek PHP.

    10. 9. 2010 10:47 redakčně upravil Martin Malý, důvod: Dělení do odstavců
    1. David Grudl

      Re: Stejná myšlenka ale jiné řešení

      Ale ku***práce! Tohle je můj poslední komentář na Zdroják. To je fakt úžasný, když na serveru, kde vychází články o tom, jak vycházet vstříc uživatelům, dokážou uživatele tak naat tím, že mu dorví komentář a srazí ho do jednoho řádku. Jděte s tím Texy už do**dele ******** ******.

          1. Jakub Vrána

            Re: Stejná myšlenka ale jiné řešení

            Přidání názoru trpí závažnou a velmi častou chybou použitelnosti: nikde není uvedeno, jaký formát vstupu se očekává. Pod boxem je jen cosi o povolených XHTML značkách, o Texy ani zmínka. Taky nikde není uvedeno, jak by se měly psát speciální znaky jako třeba &.

          2. Borek Bernard

            Re: Stejná myšlenka ale jiné řešení

            Proč je ze strany Zdrojáku vždycky takové hrobové ticho, když přijde na formátování komentářů? Martine, pokud tuhle věc nemůžeš ovlivnit, tak aspoň prosím napiš, co se kua děje, nebo (ještě lépe) dej kontakt na někoho zodpovědného. Nasíráte si čtenáře úplně zbytečně.

            1. Martin Malý

              Re: Stejná myšlenka ale jiné řešení

              Borku – vždy to předávám vývojářům. To je celé co s tím mohu dělat; zbytek jsou interní firemní procesy, které neovlivním. „Kontakt na někoho zodpovědného“ je představa sice dráždivá, ale neproveditelná (čti: to se nedělá). Takže: Ne, nemohu to ovlivnit víc než to ovlivňuju, tj. bugreportem a požadavkem na změnu. Ne, kontakt na vývojáře dát nemohu. Že jsou čtenáři nasíráni (a nejen tímto) a že mi podobné záležitosti ztěžují vydávání článků o použitelnosti etc. vnímám nelibě – a věř, že mou nelibost patřičná místa slyší. Ale to je tak asi všechno.
              Doufám že si uvědomuješ, že nejsme na blogu, kde stačí pojebat majitele v komentářích, aby „s tím něco udělal“, a on může někam sáhnout a něco změnit…

              1. Borek Bernard

                Re: Stejná myšlenka ale jiné řešení

                Samozřejmě si uvědomuju, že tohle je typický boj s firemním procesem, který není nikdy jednoduchý. Skutečnost je ale taková, že se ani po mnoha měsících neděje nic, a ačkoliv to rozhodně nedávám za vinu tobě (a doufám, že ani nikdo z ostatních), nevěřím, že s tím nejde nic dělat. Chápu, že se odkaz na programátory nedává, ale oni mají nějakého šéfa, ty máš nějakého šéfa nebo prostě někde sedí někdo, kdo má pravomoc i zodpovědnost tuhle věc řešit, a právě od řešení takovýhle procesních problémů ve firmě tyhle lidi jsou. Pokud máte v bugzille už 10 měsíců jednoduchý bug report na špatné zalamování odstavců s top prioritou a programátoři na to kašlou, jejich šéf by o tom měl vědět. Pokud na to kašle jejich šéf, měl by o tom vědět jeho šéf atd. Vím, že procesy jsou někdy zkostnatělé, ale tohle je dlouhodobá ostuda Zdrojáku a musí se vyřešit.
                Znovu opakuji, že tohle není vůbec nic proti tobě, chápu, že jsi v trochu nešťastné pozici a možná tě problémy s komentáři štvou víc než nás ostatní dohromady, ale tohle všechno je jen snaha podpořit tvé úsilí o nápravu a možná způsobit trochu víc hluku, aby si toho někdo všimnul. Tak mě napadá, na http://www.iinfo.cz/o-nas/vedeni-spolecnosti/ jsou kontakty na lidi z vedení, zkusím se na ně večer obrátit (Miklík + Krause?).

    2. patrik.sima

      Re: Stejná myšlenka ale jiné řešení

      Logický klam: „Na druhou stranu tento prohlížeč jako jediný podporuje VML, což si troufám považovat za ověřenou a rychlou technologii, protože na ni staví Cufon.“
      Ještě se v článku zapomnělo na řešení čtvrté a páté, prostě kulaté rohy nevykreslovat nebo je klasicky vykreslit skrze obrázek (což při 10MB inetu a směšné velikosti opravdu nikoho nezpomalí – to více zpomalí načtení a vykonání toho js).
      Jinak hezký článek.

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

        Re: Stejná myšlenka ale jiné řešení

        Ještě se v článku zapomnělo na řešení čtvrté a páté, prostě kulaté rohy nevykreslovat nebo je klasicky vykreslit skrze obrázek

        Nezapomnělo. :-) Je o nich zmínka v rozhodovacím procesu.

        K obrázkům – to v článku není a stojí za zmínku. Samozřejmě technicky není žádný problém použít obrázky všude, nejen v navigaci pro IE. V případě Scuku, kdy kulaté rohy zdobí velké množství prvků s různými variacemi barev, rozměrů, rámečků atd. si myslím rychle spočtete, že kodérovi raději zaplatíte za něco užitečnějšího. :-)

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

      Re: Stejná myšlenka ale jiné řešení

      Nádhera. To je samý podnětný komentář. Musel jsem si ověřit URL stránky, zda jsme ještě na Zdrojáku. ;-)

      Davide, Na CurvedCorner jsem buď nenarazil, nebo mě odradilo to HTC a bál jsem se výkonnostních problémů. Musíme vyzkoušet. Pro použití jen v té navigaci může sloužit dobře.

      Jak píšu v odpovědi Honzovi Sládkovi – to štítkování „zastarávajících“ se netýká jen vendor prefixů. Mnohem častěji ho využívám pro oddělení situací, kdy prohlížeč nepodporuje některou z HTML5 nebo CSS3 vlastností vůbec (např. neumí placeholder) nebo třeba pro oddělení úprav nadpisů generovaných Cufónem. Ten s námi taky už dlouho nepobude. :) Proto ty „zastarávající“ ještě štítkuju jako [OBSOLETE?]. Jinak bych je za půlroku nenašel. :)

  7. Nemarr

    hezky clanek

    Myslenka s pouzitim css3 kulatych rohu kde to jde a jinde s pomoci modernizru pouzit obrazky je asi nejlepsi soucasne reseni.
    Zkusil jsem asi 10 reseni js kulatych rohu. prvni to ma vzdy ten wow efekt. potom stavite slozitejsi sablonu a najednou zjistite ze jedno reseni nefunguje s position absolute. druhe ma problemy ze z-index, treti se „zahadne“ prestava fungovat po pridani jquery. nemluve o mensich problemech jak obcasne zdvojnasobeni paddingu, zruseni marginu apod – vse vzdy samozrejme nejlepe jen v jednom prohlizeci a jen za specifickych situaci. chvilku se to snazite reportovat obchazet, pridavat hacky ktere to opet „davaji dohromady“. nakonec proste zjistite za ty problemy to nestoji.
    nicmene pokud nekdo chcete zkusit tak ze soucasnych reseni mi jako nejlepsi pripada http://css3pie.com/
    pouziti „OBSOLETE“ naopak povazuji z krok vedle. nikdo nedokaze rict co bude do budoucna. jsou to tak jen odhady. navic odstraneni techto casti v pripade globalniho utrideni je stejne napovazenou protoze ne kazdy musi mit vte dobe aktualni verze prohlizecu. a ponechani nekolika „zastaralych“ css vlastnosti neni zadny problem.

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

      Re: hezky clanek

      pouziti „OBSOLETE“ naopak povazuji z krok vedle. nikdo nedokaze rict co bude do budoucna.

      Dobře, hledím do své křišťálová koule a tvrdím, že pokud za rok bude svět světem, stane se toto:

      • Namísto Cufónu budeme na Scuku používat Webfonts
      • Namísto vendor prefixů a obrázků pro kulaté rohy, budeme moci alespoň v IE9 používat CSS3 border-radius
      • Všechny moderní prohlížeče budou umět vlastnost placeholder

        Mohl bych pokračovat, ale nechávám si rezervu. Přecejen mohli mít Mayové pravdu. .-)

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