phpFashion

Na navigaci | Klávesové zkratky

Rubrika Web

Jak správně načítat webové fonty

Stránka by měla být čitelná ihned. Je velmi protivné, když si například v metru nemůžete přečíst článek jen kvůli tomu, že se nestihl načíst webový font.

Prohlížeče se totiž chovají tak, že text zobrazí až poté, co se font stáhne, aby zabránili tzv. Flash of Unstyled Text (FOUT), tedy nepříjemnému probliknutí jiného fontu. Problém je, že nemají žádný timeout, po jehož uplynutí by se použil alternativní font.

O tomhle tématu jsem psal už dříve a doporučoval pro mobilní zařízení webové fonty vůbec nepoužívat. Stejně krom autora grafiky to nikdy nepozná :-)

Mobilům (nebo lépe řečeno zařízením do šířky 500px) můžeme ulevit tímto způsobem:

/* font stáhneme jen na větších zařízeních */
@import "http://fonts.googleapis.com/css?family=PT+Serif" screen and (min-width: 500px);

body {
    font: 18px/1.7 Georgia, serif;
}

@media (min-width: 500px) {
    body { /* a font použijeme jen na větších zařízeních */
        font-family: 'PT Serif', Georgia, serif;
    }
}

Emulace timeoutu

Další možností je timeout implementovat pomocí JavaScriptu. Jenže zjistit, že se font načetl, není nic triviálního, dělá se to pomocí triků, jako je třeba detekce změny šířky předpřipraveného text atd. Font Loading API zatím podporuje jen Chrome. Takže lepší bude použít hotové řešení, jako je například Web Font Loader.

Web Font Loader

Knihovnu Web Font Loader vyvíjí Google společně s Typekit. Nedávno o ní psal Aleš Roubíček, takže na něj navážu a pokusím se upravit řešení tak, aby se skript načítal asynchronně a neblokoval stránku.

Do hlavičky vložte tento kód, kterým asynchronně načtete Web Font Loader a také příslušný font:

<script>
    WebFontConfig = { google: { families: ['PT+Serif:400:latin,latin-ext'] } };
</script>
<script src="https://ajax.googleapis.com/ajax/libs/webfont/1.5.18/webfont.js" async defer></script>

Web Font Loader umí detekovat stavy, kdy se font načítá a kdy už je načtený, a to pomocí událostí nebo nastavováním tříd elementu <html>. Jakmile je font načtený, nastaví třídu wf-active. Zároveň řeší timeout.

Upravíme styl tak, aby se font použil teprve ve správný okamžik:

body {
    font: 18px/1.7 Georgia, serif;
}

html.wf-active body {
    font-family: 'PT Serif', Georgia, serif;
}

Tohle řešení má ale potíž. Bude docházet k FOUT, tedy k probliknutí alternativního fontu. A to vypadá velmi ošklivě.

Proto během načítání písmo skryjeme, tak jak to dělají prohlížeče standardně, bez loaderu.

html.wf-loading * {
    color: transparent !important;
}

Třídu wf-loading musíme nastavit ihned, nelze čekat, až se Web Font Loader načte. Ale zároveň ji musíme odstranit, když načtení loaderu selže. Výsledný kód vypadá takto:

<script>
    WebFontConfig = { google: { families: ['PT+Serif:400:latin,latin-ext'] } };

    var el = document.documentElement;
    el.className += ' wf-loading';
    setTimeout(function() {
        el.className = el.className.replace(/(^|\s)wf-loading(\s|$)/g, ' ');
    }, 1000);
</script>
<script src="https://ajax.googleapis.com/ajax/libs/webfont/1.5.18/webfont.js" async defer></script>

Doplnění: tohle vypadá jako způsob, jak obejít jakékoliv probliknutí


Rychlejší stránky s Google Universal Analytics

Ukáži vám, jak zrychlit načítání Google Analytics nebo Web Loaderu a ještě zjednodušit měřící kód.

Tímto kódem vložíme do stránky měřící bod Google Analytics:

<script>
    (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
    (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
    m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
    })(window,document,'script','//www.google-analytics.com/analytics.js','ga');

    ga('create', 'UA-XXXXX-XX', 'auto');
    ga('send', 'pageview');
</script>

Když si ho odtemníme, vypadá takto:

<script>
    (function() {
        window['GoogleAnalyticsObject'] = 'ga';
        window['ga'] = window['ga'] || function() {
            (window['ga'].q = window['ga'].q || []).push(arguments)
        }, window['ga'].l = 1 * new Date();
        var script = document.createElement('script'),
            firstScript = document.getElementsByTagName('script')[0];
        script.async = 1;
        script.src = '//www.google-analytics.com/analytics.js';
        firstScript.parentNode.insertBefore(script, firstScript)
    })();

    ga('create', 'UA-XXXXX-XX', 'auto');
    ga('send', 'pageview');
</script>

Řádek window['GoogleAnalyticsObject'] = 'ga' říká, že objekt Google Analytics bude uložen v globální proměnné ga, nicméně je zbytečný, protože ga je výchozí hodnota.

Dále následuje vytvoření objektu v proměnné ga, který představuje jen dočasný zásobník, kam se ukládá sekvence volání jednotlivých příkazů, a po načtení skriptu bude nahrazen skutečným objektem Google Analytics. Uvedený kód se dá výrazně zjednodušit vypuštěním window a pokud na stránce není víc měřících kódu, můžeme zrušit i podmínky ga = ga || ... a dostáváme se k jednoduchému:

ga = function() { ga.q.push(arguments) };
ga.q = [];
ga.l = +new Date;

Dále následuje vytvoření elementu <script> a jeho vložení do stránky. Nastavení script.async = 1 je zbytečné, protože podle HTML specifikace je každý skriptem vkládaný <script> asynchronní.

Nicméně – neexistuje žádný důvod, proč element <script> vytvářet JavaScriptem. Je mnohem výhodnější použít normální HTML. Stránka se díky tomu načte rychleji, nedochází k blokování a může se využít preload scanner v moderních prohlížečích. Tím se dostáváme k této podobě:

<script>
    ga = function() { ga.q.push(arguments) };
    ga.q = [];
    ga.l = +new Date;
    ga('create', 'UA-XXXXX-XX','auto');
    ga('send','pageview');
</script>
<script src="//www.google-analytics.com/analytics.js" async></script>

Aby se kód načítal asynchronně i v prohlížečích IE 5.5 – 9, je nutné kromě atributu async přidat ještě defer.

V dnešní době se relativní URL //www.google-analytics.com dá považovat za antipattern, vhodnější je vždy používat https.

Finální podoba

Konečná podoba včetně minifikace vypadá takto:

<script>
    ga=function(){ga.q.push(arguments)};ga.q=[];ga.l=+new Date;
    ga('create','UA-XXXXX-XX','auto');ga('send','pageview');
</script>
<script src="https://www.google-analytics.com/analytics.js" async defer></script>

Rychlejší, kratší a ještě navíc hezčí. Nechť slouží :-)

Web Font Loader

Podobným způsobem je vhodné načítat i Web Font Loader, tj. místo v dokumentaci uvedeného

<script>
   WebFontConfig = {
      typekit: { id: 'xxxxxx' }
   };

   (function(d) {
      var wf = d.createElement('script'), s = d.scripts[0];
      wf.src = 'https://ajax.googleapis.com/ajax/libs/webfont/1.5.18/webfont.js';
      s.parentNode.insertBefore(wf, s);
   })(document);
</script>

používejte

<script>
   WebFontConfig = {
      typekit: { id: 'xxxxxx' }
   };
</script>
<script src="https://ajax.googleapis.com/ajax/libs/webfont/1.5.18/webfont.js" async defer></script>

Google Tag Manager

Protože adresa skriptu se v kódu Tag Manageru skládá, uvedenou optimalizaci nelze bohužel použít.


Nefunguje ti flexbox na iPadu, co?

Jak zprovoznit CSS Flexbox na iOS zařízeních aneb pár poznámek pro sebe, až zase příště budu zoufat, proč to neflexí, a tápat v paměti, jak jsem to minule vyřešil.

Prefixy

Safari stále ještě, i ve verzi 8.1, vyžaduje pro Flexible Box prefixy. Jsi opět překvapený, že? Takže tam hezky doplň display: -webkit-flex nebo -webkit-flex-wrap: wrap atd.

Pořadí

Záleží na pořadí deklarací! Tohle funguje:

-webkit-flex-wrap: wrap;
-webkit-justify-content: space-between;
flex-wrap: wrap;
justify-content: space-between;
display: -webkit-flex;
display: flex;

Zatímco tohle pořadí, které se ti líbí více, na iPhone a iPadu vůbec neflexí:

display: -webkit-flex;
-webkit-flex-wrap: wrap;
-webkit-justify-content: space-between;

display: flex;
flex-wrap: wrap;
justify-content: space-between;

Jak udělat mezeru mezi prvky?

Řešíš, jak zajistit minimální mezeru mezi prvky v natahovacím kontejneru s justify-content: space-between? Vždycky nad tím dlouze dumáš, googlíš to a nikdy jsi nic nevygooglil.

Mezera má být natahovací, ale nesmí jít pod určité minimum. A krajní prvky musí přiléhat ke kraji.

Můžeš prvkům nastavit margin-right: x a kontejneru margin-right: -x, ale to trošku rozhodí layout a na mobilu půjde stránku horizontálně posouvat. Třeba ti někdo poradí něco lepšího… Řešením je obalit kontejner do prvku s overflow: hidden.


Za GitHub krásnější se Stylishem

Stylish je doplněk do Chrome, který umožňuje přidat webovým stránkám vlastní CSS styly.

(Lze ho nainstalovat i do nové Opery, nejprve si přidejte Download Chrome extension a pak už ho přímo nainstalujete z Chrome webstore.)

Stylish jsem si přidal kvůli GitHubu, který mě štve příliš širokými tabulátory a hlavně nezalamováním řádků s textem, bez čehož se podobné commity vůbec nedají číst.

Zalamování jsem vyřešil stylem:

div.blob-wrapper td.blob-code {
    white-space: pre-wrap !important;
}

A tabulátory:

html * {
    tab-size: 4 !important;
}

Pak jsem si ještě vzpomněl, jak mi vadí nevhodně umístěné tlačítko „Close pull request“ hned vedle „Comment“ a posunul jsem ho trošku bokem:

button.js-comment-and-button {
    float: left !important;
    color: #C22;
}

A hned je svět krásnější :-)


Jak efektivně píšu na klávesnici

psaní na klávesnici

Naučit se psát všemi deseti, zvládnou správné prstoklady – to je nepochybně prima přednost. Ale mezi námi, sám datluji celý život dvěma prsty a při psaní přikládám daleko větší důraz něčemu jinému. A tím je rozložení klávesnice.

Webmasteři a programátoři mají při psaní ten problém, že spousta často používaných znaků na české klávesnici buď úplně chybí, nebo je hůř přístupná. Obvykle se to řeší přepínáním mezi dvě klávesnicemi, českou a anglickou, nebo osvojením si milionu zkratek AltGr-X a Alt-číslo, které chybějící znaky suplují. Ať už tak či onak, jedná se o značné brzdy tvořivosti.

Není lepší používat jen jednu klávesnici bez zkratek pro nejčastěji používané znaky?

A co třeba psaní typografických uvozovek, výpustek „ “ … × © atd. Umíte je napsat jednou rukou? Pokud ne, tak pak Vám radím jediné:

Vytvořte si vlastní rozložení klávesnice

Je to snadné, je to zábavné a je to neuvěřitelně užitečné. Teprve až to vyzkoušíte, tak zjistíte, kolik času a překlepů Vám vlastní rozložení klávesnice ušetří.

Jak začít. Přímo od Microsoftu si stáhněte kouzelný a dobře utajený program Microsoft Keyboard Layout Creator (ke svému chodu vyžaduje .NET Framework).

Hned při spuštění se Vám zobrazí „prázdná“ klávesnice, tedy taková, kde ještě není definováno žádné rozložení kláves. Začínat na zelené louce není to pravé ořechové, proto si najděte v menu příkaz Load existing keyboard a načtěte některé standardní rozložení (například klasickou českou klávesnici).

Microsoft Keyboard Layout Creator

U každé klávesy můžete definovat znak, který se napíše při samostatném stisku a dále při použití přepínačů (tedy Shift, Ctrl+Alt (pravý Alt), pravý Alt +Shift, Caps Lock a Shift+Caps Lock). Dále lze klávesu označit jako mrtvou (dead key), což znamená, že znak se napíše až po stisknutí další klávesy. Takto funguje například háček a čárka v české klávesnici.

Skutečná bomba je export hotové klávesnice. Výsledkem je plnohodnotný ovladač klávesnice včetně instalačního programu. Takže svou klávesnici si můžete pověsit na internet a nainstalovat na jiné počítače.

Mé rozložení klávesnice

Své rozložení jsem si vypiplal už před deseti lety. Je vhodné pro programátory, webdesignery a obsahuje všechny důležité typografické vychytávky, jako je pomlčka, dvojité a jednoduché uvozovky atd., intuitivně umístěné. Rozložení si můžete samozřejmě upravit.

Ke stažení: klávesnice dg v5


Na co tvůrci mobilních webů často zapomínají?

Několik tipů, jak vylepšit vzhled vašeho webu v mobilním telefonu.

Okraje

Zkontrolujte si, jak na mobilu vypadají okraje kolem textu. Velmi pravděpodobně je bude potřeba přizpůsobit. Buď budou moc široké a zbytečně tak ubírají drahocenný prostor, nebo nebudou žádné, což je při čtení značně iritující.

Vlastní písma

Obsah je daleko důležitější, než úžasný webový font, kterým je napsaný. To si uvědomíte zejména ve chvíli, když si nemůžete v metru přečíst článek jen proto, že se na zastávce nestihl načíst font (obrázek vlevo):

Obrázek uprostřed a vpravo se liší v použitém fontu: jeden z nich je nativní, druhý se natahuje z Google, což představuje řadu HTTP požadavků a přenesených dat navíc. Kromě autora grafiky stejně nikdo nepozná, který je který :-), tak mobilům klidně ulevte:

/* font stáhneme jen na větších zařízeních */
@import "http://fonts.googleapis.com/css?family=PT+Serif" screen and (min-width: 500px);

body {
    font: 18px/1.7 Georgia, serif;
}

@media (min-width: 500px) {
    body { /* a font použijeme jen na větších zařízeních */
        font-family: 'PT Serif', Georgia, serif;
    }
}

Velikost písma

Obvykle používám na webech o něco větší písmo, než je běžné, protože se mi parádně čte (třeba tento text má velikost 16px s řádkováním 1.65, podle mě minimum). A to nemám žádné dioptrie, jen je to příjemnější. Pro lidi s horším zrakem je větší font nutnost. A na mobilu, který držíme v ruce, často v třesoucím se dopravním prostředku nebo za chůze, je malé písmo důvod web vůbec nečíst.

Vyšší kontrast

Ironií je, že nejlepší displeje najdete v mobilech a tabletech, zatímco do notebooků se dávají šunty. Na druhou stranu, z mobilu daleko častěji čtete na přímém slunci, nebo si snižujete jas kvůli výdrži baterky, tudíž jemnou hru odstínů tolik neoceníte. Přidejte na kontrastu:

body {
    color: #555;
}

@media (max-width: 500px) {
    body {
        color: #111;
    }
}

Vysoké rozlišení

Displeje s vysokým rozlišením (retina) zkomplikovaly životy kodérům, do života vcházejí nové specifikace pro obrázkové elementy, grafiku je třeba exportovat v řadě různých rozlišení … houby!

Vůbec si nekomplikujte život. Stačí si jen zvyknout exportovat veškeré bitmapy ve dvojnásobném rozlišení (či vyšším) a změnu velikosti nechat na prohlížeči. Kvalitnější obrázky chceme stejně především kvůli mobilům. V případě fotografií v JPEG stačí snížit kvalitu, nárůst velikosti souboru bude minimální a okem nepoznáte rozdíl. Tedy na nízkém rozlišení, na vysokém bude mnohem prokreslenější.

Obrázek definovaný v CSS následně jen zmenšíte pomocí background-size (umí všechny prohlížeče krom IE8, takže pro něj budete zatím potřebovat i malý obrázek), obrázek v elementu <img> pomocí atributu width nebo CSS. Třeba tady na blogu všechny obrázky v článcích resizuju automaticky pomocí:

article img {
    max-width: 100%;
    height: auto;
}

Kde je to možné, použijte grafiku vektorovou. Jednobarevné ikony je nejlepší vyexportovat jako font, protože jen tak jim můžete v CSS měnit barvu. Můžete použít hotové sady nebo si vytvořit font na míru, šikovný je na to třeba Fontastic.

Bacha na jednu věc: pokud bude font umístěn na jiné (sub)doméně, musí jej server odesílat s HTTP hlavičkou Access-Control-Allow-Origin: *.

Formuláře

Na co rozhodně nikdy nezapomeňte: políčkům pro zadávání emailů nastavit <input type=email>.

V mobilním telefonu je mnohem lepší mít popisky nad prvky, aby při vyplňování bylo vidět, co vlastně zadáváte, a ne jen řadu inputů. Tohle umí šikovně řešit třeba Bootstrap v3, ale i mnoho jiných CSS frameworků.

A nakonec

Na mobilech nejvíc bolí navazování HTTP požadavků, takže spojujte styly a JavaScripty do jednoho souboru.


Psát isomorfní webové aplikace?

Isomorfní webové aplikace jsou takové, které sdílejí kód mezi serverovou a klientskou stranou. Jinými slovy, jsou obě strany psané v JavaScriptu. I když tak to vůbec nemuselo být, historie je zajímavější.

Úplně poprvé jsem se s touto koncepcí setkal před (fíha, to je neuvěřitelné) takřka 20 lety. Vlastně JavaScript přímo vznikl jako client-side i server-side jazyk, serverové prostředí se jmenovalo Netscape LiveWire a kód vypadal nějak takto. Šlo tedy o mix HTML a JavaScriptu, jen s tím rozdílem, že skript se vykonával na serveru. JavaScript byl zamýšlený jako jazyk pro amatérské programátory, jako konkurent tehdejšího PHP a Microsoftího ASP, zatímco pro profesionály tu byla client-side a server-side Java.

Nic nedopadlo podle očekávání. Kvůli soudním sporům Java z prohlížečů zmizela, ke konci se držela už jen v porno chatech a bankovnictví, a dnes je z ní jeden velký bezpečnostní kráter distribuovaný jako adware, který je nutno v prohlížečích vypínat. Neuspěl ani JavaScript na serveru, protože byl příliš nezralý a nevhodný na takové nasazení a serverové řešení upadajícího Netscape nezískalo popularitu.

Vývoj webů na mnoho let zbrzdilo šílenství okolo specifikací začínajících na X a monopol Internet Exploreru, ale pak došlo k jejich svržení a máme tu hromadu nových technologií. A s tím se pochopitelně vrací i otázka jednoho jazyka na obou stranách. Odstartoval to zejména výkonnostně nadupaný interpret JavaScriptu z Google Chrome a platforma Node.js.

Situace je dosti jiná, než před 20 lety:

  • server-side technologie ušly obrovský kus cesty a vyzrály
  • client-side prožívá pubertu
  • v průniku jazyků je pouze JavaScript

Tvorba webů pomocí serverových frameworků se stává komoditou, na řadu složitých otázek odpovídají zažité návrhové vzory. Na straně klienta to naopak bují, dnešní novinky nejspíš brzy nahradí novinky jiné, a to se ještě několikrát zopakuje. Tenhle stav je fajn, dohání se dlouhé zpoždění a máte šanci se zapojit a odvětvím pohnout.

Dohání také JavaScript, leč jeho skutečnou pozici nejlépe charakterizuje potřeba a popularita nejrůznějších nadstaveb, ať už jde o CoffeeScript, Google Closure Compiler nebo TypeScript. Pomocí nich už dnes lze z JavaScriptu udělat něco celkem robustního, což ale ve skutečnosti stále není. Přičemž jazyky s ambicí jej nahradit existují.

Osobně mi cesta k izomorfním aplikacím připadá přirozená a správná. U klientského skriptování jsem začínal a stále hledal různé spojnice, například Nette má dosud poměrně ojedinělou vlastnost, že pravidla pro validaci formulářů zapsaná na straně serveru vám automaticky překlopí na stranu prohlížeče. Isomorfní validace formulářů od roku 2008.

Ale v žádném případě bych si isomorfně nenechal naprogramovat třeba e-shop. Zatím.

Příliš mladé prostředí znamená absenci zažitých návrhových vzorů a různá rizika. Když si Dan Steigerwald, který pro mě částečně pochopitelně odmítá jakékoliv problémy této technologie připouštět, si tuhle posteskl, že čeští vývojáři jsou pozadu za frikulíny ze San Francisca a stále se drží serverových technologií, rozjela se diskuse o výhodách a nevýhodách jednotlivých přístupů a Dan jako odpověď na jednu námitku poslal příklad webu (tuším jeho kolegů) iodine.com psaný v React.js. Čímž poskytl pěkný příklad neduhů SPA/isomorfních aplikací:

  • na webu nefunguje správně tlačítko zpět
  • na mnoha různých URL se nachází identický obsah
  • jeho výroba byla násobně dražší

Zdůrazňuji, že z jeho stany nešlo o ukázkový příklad, nicméně tím lépe demonstruje hlavní problém SPA/isomorfních aplikací: udělat je dobře je stále velmi těžké a potažmo drahé. Přičemž tentýž web za použití server-side frameworku, jako je například Nette, zvládne napsat i průměrný a levný programátor. A podobných hrubek se přitom nedopustí.

Izomorfním aplikacím se nevyhýbejte, zkoušejte si novinky, zavčasu odhalujte slepé cesty, rozšiřujte si obzory. Ale s ostrým nasazením se držte jen u typů aplikací, kde je to skutečně nutné a výhodné. Není jich zase tolik.

Navíc nemáte v žádné žhavé technologii jistotu. Tvrdit opak, třeba proto, že za nějakou z nich stojí obří firma, znamená být slepý k historii posledních 20 let.


Kdy používat preprocesory a kdy ne?

Složitá otázka, těžké kodérovo dilema, které se pokusím rozseknout: používejte preprocesory vždy!

Jak se Internet přesunul do mobilů, staly se největší zabijáci rychlosti načítání stránek tyhlety úhledné sloupečky:

<link rel="stylesheet" href="/css/reset.css">
<link rel="stylesheet" href="/css/content.css">
<link rel="stylesheet" href="/css/layout.css">
<link rel="stylesheet" href="/css/screen.css" media=screen>
<link rel="stylesheet" href="/css/fancybox/jquery.fancybox.css" media=screen>
<link rel="stylesheet" href="/css/print.css" media=print>
<script src="/js/jquery.js"></script>
<script src="/js/jquery.autocomplete.js"></script>
<script src="/js/fancybox/jquery.fancybox.js"></script>
<script src="/js/tooltips/jquery.tooltips.js"></script>
<script src="/js/jquery.scrollspy.js"></script>
<script src="/js/main.js"></script>

To nechceš! Chceš tohle:

<head><link rel="stylesheet" href="/assets/combined.css"></head>

<body>
...
<script src="/assets/combined.js"></script>
</body>

Taky chceš, aby se ti všechny soubory posílaly zazipované a vypadaly hutně: combined.css a hustě: combined.js.

Byly doby, kdy se komprimované skripty psaly ručně. Vynechávaly se komentáře, v JavaScriptu používaly jednopísmenné proměnné atd.

Nedělejte to. Vaším úkolem je psát čitelný kód a komprimování JavaScriptu nechte na bedrech Google Closure Compiler, který to dokáže řádově lépe než vy a navíc upozorní na chyby, o minifikaci stylů se postará například Less.

Ten dokonce zvládá vychytávku, kdy u všech miniobrázků můžete nahradit:

textarea {
    background: #fff url("img/input.gif") repeat-x;
}

za

textarea {
    background: #fff data-uri("img/input.gif") repeat-x;
}

a preprocesor je přímo vloží do combined.css, čímž odpadne hromada HTTP requestů na 100bajtové drobky.

Preprocesory prostě a jednoduše chcete!


SASS, LESS, Stylus or pure CSS? (3)

Journey into the heart of the three most known CSS preprocessors continues, though not in the way I originally planned.

CSS preprocessor is a tool that take code written in their own syntax and generates the CSS for the browser. The most popular preprocessors are SASS, LESS and Stylus. We have talked about installation and syntax + mixins. All three preprocessors have a fundamentally different way of mixins conception.

Each of them have gallery of finished mixins: For SASS there is a comprehensive Compass, the LESS has framework Twitter Bootstrap or small Elements a Stylus NIB.

… this was opening sentences of article I started write year and quarter ago and never finished. I came to the conclusion that all three preprocessors are useless. They required to do so many compromises that potential benefits seemed insignificant. Today I will explain it.

…pokračování


SASS, LESS, Stylus nebo čisté CSS? (3)

Cesta do nitra tří nejznámějších CSS preprocesorů pokračuje, i když ne tak, jak jsem původně plánoval.

CSS preprocesor je nástroj, který vám ze zdrojového kódu zapsaného ve vlastní syntaxi vygeneruje CSS pro prohlížeč. Mezi nejznámější patří SASS, LESS a Stylus. Ukázali jsme si, jak je nainstalovat a naťukli téma syntaxe a mixinů. Všechny tři preprocesory nabízejí fundamentálně rozdílný způsob, jak programovat s mixiny. Každý je v tom jinak konzistentní a každý umí být jinak matoucí.

Pro každý preprocesor existuje galerie hotových mixinů, do kterých nahlédněte přinejmenším k posouzení jejich srozumitelnosti. Pro SASS existuje komplexní Compass, LESS má framework Twitter Bootstrap nebo drobné Elements a Stylus NIB.

…tak takhle začínal článek, který jsem rozepsal před rokem a čtvrt a nikdy nedokončil. Přišel jsem totiž k závěru, že všechny tři preprocesory jsou, alespoň zatím, nepoužitelné. Jejich nasazení by představovalo tolik ústupků, že by se vedle nich potenciální výhody dočista ztrácely. Dnes to vysvětlím.

…pokračování