[
{
"path": "README.md",
"content": "# Principles of writing consistent, idiomatic CSS\n\nThe following document outlines a reasonable style guide for CSS development.\nThese guidelines strongly encourage the use of existing, common, sensible\npatterns. They should be adapted as needed to create your own style guide.\n\nThis is a living document and new ideas are always welcome. Please\ncontribute.\n\n\n## Table of contents\n\n1. [General principles](#general-principles)\n2. [Whitespace](#whitespace)\n3. [Comments](#comments)\n4. [Format](#format)\n5. [Practical example](#example)\n\n[Acknowledgements](#acknowledgements)\n\n[License](#license)\n\n\n\n## 1. General principles\n\n> \"Part of being a good steward to a successful project is realizing that\n> writing code for yourself is a Bad Idea™. If thousands of people are using\n> your code, then write your code for maximum clarity, not your personal\n> preference of how to get clever within the spec.\" - Idan Gazit\n\n* Don't try to prematurely optimize your code; keep it readable and\n understandable.\n* All code in any code-base should look like a single person typed it, even\n when many people are contributing to it.\n* Strictly enforce the agreed-upon style.\n* If in doubt when deciding upon a style use existing, common patterns.\n\n\n\n## 2. Whitespace\n\nOnly one style should exist across the entire source of your code-base. Always\nbe consistent in your use of whitespace. Use whitespace to improve\nreadability.\n\n* _Never_ mix spaces and tabs for indentation.\n* Choose between soft indents (spaces) or real tabs. Stick to your choice\n without fail. (Preference: spaces)\n* If using spaces, choose the number of characters used per indentation level.\n (Preference: 4 spaces)\n\nTip: configure your editor to \"show invisibles\" or to automatically remove\nend-of-line whitespace.\n\nTip: use an [EditorConfig](http://editorconfig.org/) file (or equivalent) to\nhelp maintain the basic whitespace conventions that have been agreed for your\ncode-base.\n\n\n\n## 3. Comments\n\nWell commented code is extremely important. Take time to describe components,\nhow they work, their limitations, and the way they are constructed. Don't leave\nothers in the team guessing as to the purpose of uncommon or non-obvious\ncode.\n\nComment style should be simple and consistent within a single code base.\n\n* Place comments on a new line above their subject.\n* Keep line-length to a sensible maximum, e.g., 80 columns.\n* Make liberal use of comments to break CSS code into discrete sections.\n* Use \"sentence case\" comments and consistent text indentation.\n\nTip: configure your editor to provide you with shortcuts to output agreed-upon\ncomment patterns.\n\nExample:\n\n```css\n/* ==========================================================================\n Section comment block\n ========================================================================== */\n\n/* Sub-section comment block\n ========================================================================== */\n\n/**\n * Short description using Doxygen-style comment format\n *\n * The first sentence of the long description starts here and continues on this\n * line for a while finally concluding here at the end of this paragraph.\n *\n * The long description is ideal for more detailed explanations and\n * documentation. It can include example HTML, URLs, or any other information\n * that is deemed necessary or useful.\n *\n * @tag This is a tag named 'tag'\n *\n * TODO: This is a todo statement that describes an atomic task to be completed\n * at a later date. It wraps after 80 characters and following lines are\n * indented by 2 spaces.\n */\n\n/* Basic comment */\n```\n\n\n\n## 4. Format\n\nThe chosen code format must ensure that code is: easy to read; easy to clearly\ncomment; minimizes the chance of accidentally introducing errors; and results\nin useful diffs and blames.\n\n* Use one discrete selector per line in multi-selector rulesets.\n* Include a single space before the opening brace of a ruleset.\n* Include one declaration per line in a declaration block.\n* Use one level of indentation for each declaration.\n* Include a single space after the colon of a declaration.\n* Use lowercase and shorthand hex values, e.g., `#aaa`.\n* Use single or double quotes consistently. Preference is for double quotes,\n e.g., `content: \"\"`.\n* Quote attribute values in selectors, e.g., `input[type=\"checkbox\"]`.\n* _Where allowed_, avoid specifying units for zero-values, e.g., `margin: 0`.\n* Include a space after each comma in comma-separated property or function\n values.\n* Include a semi-colon at the end of the last declaration in a declaration\n block.\n* Place the closing brace of a ruleset in the same column as the first\n character of the ruleset.\n* Separate each ruleset by a blank line.\n\n```css\n.selector-1,\n.selector-2,\n.selector-3[type=\"text\"] {\n -webkit-box-sizing: border-box;\n -moz-box-sizing: border-box;\n box-sizing: border-box;\n display: block;\n font-family: helvetica, arial, sans-serif;\n color: #333;\n background: #fff;\n background: linear-gradient(#fff, rgba(0, 0, 0, 0.8));\n}\n\n.selector-a,\n.selector-b {\n padding: 10px;\n}\n```\n\n#### Declaration order\n\nIf declarations are to be consistently ordered, it should be in accordance with\na single, simple principle.\n\nSmaller teams may prefer to cluster related properties (e.g. positioning and\nbox-model) together.\n\n```css\n.selector {\n /* Positioning */\n position: absolute;\n z-index: 10;\n top: 0;\n right: 0;\n bottom: 0;\n left: 0;\n\n /* Display & Box Model */\n display: inline-block;\n overflow: hidden;\n box-sizing: border-box;\n width: 100px;\n height: 100px;\n padding: 10px;\n border: 10px solid #333;\n margin: 10px;\n\n /* Other */\n background: #000;\n color: #fff;\n font-family: sans-serif;\n font-size: 16px;\n text-align: right;\n}\n```\n\nLarger teams may prefer the simplicity and ease-of-maintenance that comes with\nalphabetical ordering.\n\n#### Exceptions and slight deviations\n\nLarge blocks of single declarations can use a slightly different, single-line\nformat. In this case, a space should be included after the opening brace and\nbefore the closing brace.\n\n```css\n.selector-1 { width: 10%; }\n.selector-2 { width: 20%; }\n.selector-3 { width: 30%; }\n```\n\nLong, comma-separated property values - such as collections of gradients or\nshadows - can be arranged across multiple lines in an effort to improve\nreadability and produce more useful diffs. There are various formats that could\nbe used; one example is shown below.\n\n```css\n.selector {\n background-image:\n linear-gradient(#fff, #ccc),\n linear-gradient(#f3c, #4ec);\n box-shadow:\n 1px 1px 1px #000,\n 2px 2px 1px 1px #ccc inset;\n}\n```\n\n### Preprocessors: additional format considerations\n\nDifferent CSS preprocessors have different features, functionality, and syntax.\nYour conventions should be extended to accommodate the particularities of any\npreprocessor in use. The following guidelines are in reference to Sass.\n\n* Limit nesting to 1 level deep. Reassess any nesting more than 2 levels deep.\n This prevents overly-specific CSS selectors.\n* Avoid large numbers of nested rules. Break them up when readability starts to\n be affected. Preference to avoid nesting that spreads over more than 20\n lines.\n* Always place `@extend` statements on the first lines of a declaration\n block.\n* Where possible, group `@include` statements at the top of a declaration\n block, after any `@extend` statements.\n* Consider prefixing custom functions with `x-` or another namespace. This\n helps to avoid any potential to confuse your function with a native CSS\n function, or to clash with functions from libraries.\n\n```scss\n.selector-1 {\n @extend .other-rule;\n @include clearfix();\n @include box-sizing(border-box);\n width: x-grid-unit(1);\n // other declarations\n}\n```\n\n\n\n## 5. Practical example\n\nAn example of various conventions.\n\n```css\n/* ==========================================================================\n Grid layout\n ========================================================================== */\n\n/**\n * Column layout with horizontal scroll.\n *\n * This creates a single row of full-height, non-wrapping columns that can\n * be browsed horizontally within their parent.\n *\n * Example HTML:\n *\n * \n */\n\n/**\n * Grid container\n *\n * Must only contain `.cell` children.\n *\n * 1. Remove inter-cell whitespace\n * 2. Prevent inline-block cells wrapping\n */\n\n.grid {\n height: 100%;\n font-size: 0; /* 1 */\n white-space: nowrap; /* 2 */\n}\n\n/**\n * Grid cells\n *\n * No explicit width by default. Extend with `.cell-n` classes.\n *\n * 1. Set the inter-cell spacing\n * 2. Reset white-space inherited from `.grid`\n * 3. Reset font-size inherited from `.grid`\n */\n\n.cell {\n position: relative;\n display: inline-block;\n overflow: hidden;\n box-sizing: border-box;\n height: 100%;\n padding: 0 10px; /* 1 */\n border: 2px solid #333;\n vertical-align: top;\n white-space: normal; /* 2 */\n font-size: 16px; /* 3 */\n}\n\n/* Cell states */\n\n.cell.is-animating {\n background-color: #fffdec;\n}\n\n/* Cell dimensions\n ========================================================================== */\n\n.cell-1 { width: 10%; }\n.cell-2 { width: 20%; }\n.cell-3 { width: 30%; }\n.cell-4 { width: 40%; }\n.cell-5 { width: 50%; }\n\n/* Cell modifiers\n ========================================================================== */\n\n.cell--detail,\n.cell--important {\n border-width: 4px;\n}\n```\n\n\n## Translations\n\n* [Bahasa Indonesia](https://github.com/necolas/idiomatic-css/tree/master/translations/id-ID)\n* [Bulgarian](https://github.com/vestimir/idiomatic-css)\n* [Česky](https://github.com/necolas/idiomatic-css/tree/master/translations/cs-CZ)\n* [Dansk](https://github.com/necolas/idiomatic-css/tree/master/translations/da-DK)\n* [Deutsch](https://github.com/necolas/idiomatic-css/tree/master/translations/de-DE)\n* [Español](https://github.com/necolas/idiomatic-css/tree/master/translations/es-ES)\n* [Français](https://github.com/necolas/idiomatic-css/tree/master/translations/fr-FR)\n* [Italiano](https://github.com/necolas/idiomatic-css/tree/master/translations/it-IT)\n* [日本語](https://github.com/necolas/idiomatic-css/tree/master/translations/ja-JP)\n* [한국어](https://github.com/necolas/idiomatic-css/tree/master/translations/ko-KR)\n* [Nederlands](https://github.com/necolas/idiomatic-css/tree/master/translations/nl-NL)\n* [Polski](https://github.com/necolas/idiomatic-css/tree/master/translations/pl-PL)\n* [Português (Brasil)](https://github.com/necolas/idiomatic-css/tree/master/translations/pt-BR)\n* [Русский](https://github.com/necolas/idiomatic-css/tree/master/translations/ru-RU)\n* [Srpski](https://github.com/necolas/idiomatic-css/tree/master/translations/sr-SR)\n* [Türkçe](https://github.com/necolas/idiomatic-css/tree/master/translations/tr-TR)\n* [正體中文](https://github.com/necolas/idiomatic-css/tree/master/translations/zh-TW)\n* [简体中文](https://github.com/necolas/idiomatic-css/tree/master/translations/zh-CN)\n\n\n\n## Acknowledgements\n\nThanks to everyone who has provided translations and to all those who\ncontributed to [idiomatic.js](https://github.com/rwldrn/idiomatic.js). It was a\nsource of inspiration, quotations, and guidelines.\n\n\n\n## License\n\n_Principles of writing consistent, idiomatic CSS_ by Nicolas Gallagher is\nlicensed under the [Creative Commons Attribution 3.0 Unported\nLicense](http://creativecommons.org/licenses/by/3.0/). This applies to all\ndocuments and translations in this repository.\n\nBased on a work at\n[github.com/necolas/idiomatic-css](https://github.com/necolas/idiomatic-css).\n"
},
{
"path": "translations/cs-CZ/README.md",
"content": "# Zásady psaní konzistentního, idiomatického CSS\n\nTohle je příručka stylu (_style guide_) pro psaní CSS. Neberte ji jako\nnařizující, nechci jiným lidem vnucovat styl psaní kódu podle svých preferencí.\nNásledující zásady ale silně podporují využívání existujících vzorů jež\npovažuji za obvyklé a rozumné.\n\nNa dokumentu se pracuje a nové nápady vítám. Přispějte jimi prosím.\n\n\n[Idiomatic CSS anglicky](https://github.com/necolas/idiomatic-css/)\n\n\n## Obsah\n\n1. [Obecné principy](#general-principles)\n2. [Bílá mezera](#whitespace)\n3. [Komentáře](#comments)\n4. [Formát](#format)\n5. [Pojmenovávání](#naming)\n6. [Praktická ukázka](#example)\n7. [Uspořádání](#organization)\n8. [Build a deploy](#build-and-deployment)\n\n[Poděkování](#acknowledgements)\n\n\n\n## 1. Obecné principy\n\n> „Pokud chcete být dobrý správce úspěšného projektu, musíte si kromě jiného\n> uvědomit, že psaní kódu pro sebe je dost blbý nápad. Pokud váš kód užívají\n> tisíce lidí, musíte jej psát pro maximální srozumitelnost a ne pro svou\n> radost z dodržení specifikace.” - Idan Gazit\n\n* Nejste lidský kompiler ani kompresor kódu. Nesnažte se jím stát.\n* Veškerý kód jednoho projektu by měl vypadat jako by ho napsal jediný člověk.\n Bez ohledu na to kolik lidí přispělo.\n* Striktně vymáhejte dohodnutý styl.\n* V případě pochybností o dohodnutém stylu, použijte existující obecné vzory.\n\n\n\n## 2. Bílá mezera\n\nV kódu vašeho projektu by měl existovat jen jediný styl užívání bílé mezery\n(_whitespace_). Zlepšujte s její pomocí čitelnost.\n\n* Nikdy pro odsazování nepoužívejte mezery a zároveň tabulátory.\n* Vyberte si buď měkké odsazení (pomocí mezer) nebo skutečné tabulátory. Držte\n se svého výběru bez výjimky. (Upřednostňujte mezery)\n* Pokud používáte mezery, zvolte si počet znaků používaných pro úroveň\n odsazení. (Upřednostňujte 4 mezery)\n\nTip: nastavte si editor tak, aby zobrazoval neviditelné znaky. To vám umožní\npotlačit bílé mezery na konci řádků nebo nechtěné prázdné řádky s bílou\nmezerou. Zabráníte tak zaneřádění commitů.\n\nTip: používejte soubor [EditorConfig](http://editorconfig.org/) (nebo něco\npodobného) aby vám pomohl dodržovat úmluvy o bílých mezerách, které jste\ndohodli pro celý projekt.\n\n\n\n## 3. Komentáře\n\nDobře komentovat kód je hrozně důležité. Udělejte si čas pro popis komponent,\ntoho jak pracují, jejich omezení, a způsobu jakým jsou sestrojeny. Nenechávejte\nostatní v týmu odhadovat účel neobvyklého nebo málo zřejmého kódu.\n\nStyl komentářů by měl být jednoduchý a konzistentní pro celý projekt.\n\n* Umísťujte komentáře na nový řádek nad jejich subjekt.\n* Vyhněte se komentářům na konci řádky.\n* Ponechte šířku řádky na citlivém maximu, například 80 znacích.\n* Velkorysým používáním komentářů dělte CSS kód do jednotlivých sekcí.\n* Pište komentáře ve větách (_sentence case_) a text konzistentně odsazujte.\n\nTip: Nastavte si editor tak, abyste dohodnuté komentářové vzory měli vždy po\nruce.\n\n#### Example:\n\n```css\n/* ==========================================================================\n Nadpis pro sekci\n ========================================================================== */\n\n/* Nadpis pro podsekci\n ========================================================================== */\n\n/**\n * Kratky popis co se drzi komentaroveho formatu Doxygen\n *\n * Tady zacina prvni veta dlouheho popisu a chvili pokracuje dokud neskonci\n * na dalsim radku.\n *\n * Nejdelsi popisek je idealni pro detailnejsi vysvetleni a dokumentace. Muze\n * obsahovat ukazkove HTML, URL adresy nebo jakekoliv jine informace co se\n * povazuji za nezbytne nebo uzitecne.\n *\n * @tag Tohle je znacka s nazvem „tag”\n *\n * @todo Tohle je popis ukolu (todo) co ma byt vyresen pozdeji.\n * Zalomi se po 80ti znacich. Druhy a dalsi radky odsazujeme 2 mezerami.\n */\n\n/* Jednoduchy komentar */\n```\n\n_(Pozn. překl. – Komentáře v kódu je lepší jednotně psát bez diakritiky. Hlavně\nproto, že velká část českých vývojářů píše kód pomocí anglické klávesnice.)_\n\n\n\n## 4. Formát\n\nZvolený formát musí zajistit aby číst kód a vytvářet v něm srozumitelné\nkomentáře bylo snadné. Omezte riziko náhodně vzniklých chyb. Výsledkem dobrého\na jednotného formátu je snadné porovnávání dvou verzí (_diff_) a čitelný\n_blame_, jež ukazuje autora a commit poslední změny konkrétního řádku.\n\n* V pravidlech obsahujících více selektorů mějte každý selektor na\n samostatné řádce.\n* Před otevírací složenou závorku pravidla vkládejte jednu mezeru.\n* V bloku deklarací mějte každou deklaraci na zvláštním řádku.\n* Každou deklaraci odsazujte o jednu úroveň.\n* V deklaraci pište za dvojtečku jednu mezeru.\n* Ve zkrácených variantách hexa hodnot barev používejte malá písmena\n (např. `#aaa`).\n* Konzistentně používejte jednoduché anebo dvojité „uvozovky”.\n Doporučujeme dvojité (např. `content: \"\"`).\n* Hodnoty atribut selektorů uvádějte v „uvozovkách” (např.\n `input[type=\"checkbox\"]`).\n* Tam kde je to u nulových hodnot možné, vyhněte se uvádění jednotek\n (např. `margin: 0`).\n* Za každou čárku použitou jako oddělovač hodnot nebo parametrů funkcí\n vložte mezeru.\n* Na konec každé deklarace v bloku deklarací vložte středník.\n* Uzavírací složenou závorku pro konec pravidla odsaďte stejně jako první\n znak pravidla.\n* Jednotlivá pravidla oddělujte prázdným řádkem.\n\n```css\n.selector-1,\n.selector-2,\n.selector-3[type=\"text\"] {\n -webkit-box-sizing: border-box;\n -moz-box-sizing: border-box;\n box-sizing: border-box;\n display: block;\n font-family: helvetica, arial, sans-serif;\n color: #333;\n background: #fff;\n background: linear-gradient(#fff, rgba(0, 0, 0, 0.8));\n}\n```\n\n#### Pořadí deklarací\n\nDeklarace v kódu jednoho projektu řaďte v souladu s jediným principem.\nUpřednostňuji deklarovat nejprve konstrukčně důležité vlastnosti (např.\npozicování nebo box model).\n\n```css\n.selector {\n /* Pozicovani */\n position: absolute;\n z-index: 10;\n top: 0;\n right: 0;\n bottom: 0;\n left: 0;\n\n /* Zobrazeni & box model */\n display: inline-block;\n overflow: hidden;\n box-sizing: border-box;\n width: 100px;\n height: 100px;\n padding: 10px;\n border: 10px solid #333;\n margin: 10px;\n\n /* Ostatni */\n background: #000;\n color: #fff\n font-family: sans-serif;\n font-size: 16px;\n text-align: right;\n}\n```\n\nPoměrně populární je také abecední pořadí. To má ale nevýhodu, že odděluje\npříbuzné vlastnosti. Například – ofsety pozice (vlastnosti `top`, `left` apod.)\ntak nemohou být seskupeny dohromady a vlastnosti box-modelu mohou skončit\nrozptýlené po celém pravidle.\n\n_(Pozn. překl. — Některé vlastnosti jsou navíc pro rychlý sken stylopisu\ndůležitější než jiné – position, z-index. I proto jim patří místo na začátku\npravidla.)_\n\n#### Výjimky a mírné odchylky\n\nVelké bloky pravidel s jednou deklarací můžete zapisovat trochu jinak — na\njeden řádek. V tomto případě by za otevírací a před uzavírací složenou závorkou\nneměla chybět mezera.\n\n```css\n.selector-1 { width: 10%; }\n.selector-2 { width: 20%; }\n.selector-3 { width: 30%; }\n```\n\nDlouhé bloky hodnot oddělované čárkou – jako třeba vícenásobná pozadí nebo\nstíny – je lepší pro zlepšení čitelnosti nebo zajištění užitečnějších diffů\nrozdělit do více řádků. Formátů jež je možné použít je mnoho. Tady je jeden\npříklad:\n\n```css\n.selector {\n background-image:\n linear-gradient(#fff, #ccc),\n linear-gradient(#f3c, #4ec);\n box-shadow:\n 1px 1px 1px #000,\n 2px 2px 1px 1px #ccc inset;\n}\n```\n\n### Preprocesory\n\nRůzné CSS preprocesory mají různé vlastnosti, funkce a syntaxi. Vaše konvence\nbyste měli rozšířit tak, aby vyhověly zvláštnostem preprocesoru, který\nvyužíváte. Následující zásady se vztahují k Sass.\n\n* Omezte zanořování pravidel na 1 úroveň. Přehodnoťte každé zanořování\n hlubší než 2 úrovně. To omezí existenci příliš specifických selektorů.\n* Vyhněte se velkému množství vnořených pravidel. Jakmile se čitelnost\n začíná zhoršovat, rozdělte je. Doporučuji rozdělovat vnořená pravidla\n jež zaberou více než 20 řádků.\n* Direktivy `@extend` vždy zapisujte do prvních řádků pravidla.\n* Tam kde je to možné seskupte direktivy `@include` hned za řádky s `@extend`.\n* Zvažte prefixování vašich funkcí pomocí x- nebo jiného jmenného prostoru.\n To vám pomůže vyhnout se kolizím s názvy nativních CSS funkcí nebo funkcí\n z knihoven.\n\n```scss\n.selector-1 {\n @extend .other-rule;\n @include clearfix();\n @include box-sizing(border-box);\n width: x-grid-unit(1);\n // ostatni deklarace\n}\n```\n\n\n\n## 5. Pojmenovávání\n\nPojmenovávání je těžké, ale velice důležité. Je to stěžejní část procesu vývoje\nspravovatelného kódu. Dobrý způsob pojmenovávání vám zajistí škálovatelné\nrozhraní mezi vaším HTML a CSS.\n\n* Vyhněte se systematickému používání zkrácených názvů tříd. Nedělejte\n věci těžké k pochopení.\n* Pro třídy v HTML používejte čisté, smysluplné a odpovídající názvy.\n* Vyberte srozumitelný a konzistentní vzorec pojmenovávání co dává smysl jak\n v HTML tak CSS souborech.\n* Selektory pro komponenty by měly využívat názvy tříd. Vyhněte se\n používání generických značek (tagů) nebo unikátních id.\n\n```css\n/* Ukazky kodu se spatnymi pojmenovavanim selektoru */\n\n.s-scr {\n overflow: auto;\n}\n\n.cb {\n background: #000;\n}\n\n/* Ukazky kodu s lepsim pojmenovanim selektoru */\n\n.is-scrollable {\n overflow: auto;\n}\n\n.column-body {\n background: #000;\n}\n```\n\n\n\n## 6. Praktická ukázka\n\n```css\n/* ==========================================================================\n Mrizkovy layout\n ========================================================================== */\n\n/**\n * Ukazka HTML:\n *\n * \n */\n\n.grid {\n overflow: visible;\n height: 100%;\n /* Zamezi zalomeni inline-block bunek mrizky */\n white-space: nowrap;\n /* Odstrani mezeru mezi bunkami */\n font-size: 0;\n}\n\n.cell {\n position: relative;\n display: inline-block;\n overflow: hidden;\n box-sizing: border-box;\n width: 20%;\n height: 100%;\n /* Nastavime vnitrni okraj bunek */\n padding: 0 10px;\n border: 2px solid #333;\n vertical-align: top;\n /* Resetujeme bilou mezeru */\n white-space: normal;\n /* Resetujeme velikost pisma */\n font-size: 16px;\n}\n\n/* Stavy bunky */\n\n.cell.is-animating {\n background-color: #fffdec;\n}\n\n/* Varianty sirky bunky\n ========================================================================== */\n\n.cell-1 { width: 10%; }\n.cell-2 { width: 20%; }\n.cell-3 { width: 30%; }\n.cell-4 { width: 40%; }\n.cell-5 { width: 50%; }\n\n/* Modifikatory bunky\n ========================================================================== */\n\n.cell--detail,\n.cell--important {\n border-width: 4px;\n}\n```\n\n\n\n## 7. Uspořádání\n\nUspořádání (organizace větších celků) je důležitá vlastnost každé CSS části\nkódu projektu, ale pro ty větší je dost zásadní.\n\n* Logicky oddělujte odlišné části kódu.\n* Pro odlišné komponenty kódu používejte oddělené soubory, které pak spojte\n v sestavovacím (_build_) kroku.\n* Pokud používáte preprocesor, zobecněte často používaný kód do proměnných\n pro barvy, typografii atd.\n\n\n\n## 8. Build a deploy\n\nUrčitě byste se měli pokusit na projektu nasadit nějaké nástroje pomocí kterých\nmůžete kód projektu prověřit lint analýzou, zkomprimovat a verzovat během\npřípravy pro produkční použití. Pro tenhle účel existuje vynikající nástroj\n[grunt](https://github.com/cowboy/grunt) od Bena Almana.\n\n\n\n## Poděkování\n\nDíky všem co přispěli k [idiomatic.js](https://github.com/rwldrn/idiomatic.js).\nByl to můj zdroj inspirace, citací a zásad.\n"
},
{
"path": "translations/da-DK/README.md",
"content": "# Principper for at skrive konsistent, idiomatisk CSS\n\nDette dokument skitserer en række fornuftige og logiske retningslinjer til CSS udvikling.\nDet er ikke ment som et asolut regelsæt og jeg ønsker ikke at presse min måde at\nskrive CSS på ned over andres kode. Ikke desto mindre så indbyder disse principper\ntil at benytte allerede eksisterende og logiske kodemønstre.\n\nDette dokument er levende og nye tilføjelser og idéer er altid velkomne.\n\n\n## Oversættelser\n\n* [Dansk](https://github.com/necolas/idiomatic-css/tree/master/translations/da-DK)\n* [Italiano](https://github.com/necolas/idiomatic-css/tree/master/translations/it-IT)\n* [日本語](https://github.com/necolas/idiomatic-css/tree/master/translations/ja-JP)\n* [Nederlands](https://github.com/necolas/idiomatic-css/tree/master/translations/nl-NL)\n* [Português (Brasil)](https://github.com/necolas/idiomatic-css/tree/master/translations/pt-BR)\n* [Srpski](https://github.com/necolas/idiomatic-css/tree/master/translations/sr)\n* [Türkçe](https://github.com/necolas/idiomatic-css/tree/master/translations/tr-TR)\n* [简体中文](https://github.com/necolas/idiomatic-css/tree/master/translations/zh-CN)\n\n\n## Indholdsfortegnelse\n\n1. [Generelle principper](#general-principles)\n2. [Mellemrum](#whitespace)\n3. [Kommentarer](#comments)\n4. [Formatering](#format)\n5. [Navngivning](#naming)\n6. [Praktisk eksempel](#example)\n7. [Organisering](#organization)\n8. [Build og udrulning](#build-and-deployment)\n\n[Anerkendelser](#acknowledgements)\n\n\n\n## 1. Generelle principper\n\n> \"En del af det at være en god forvalter af et succésfuldt projekt er at\n> indse, at det at skrive kode til én selv er En Dårlig Idé™. Hvis tusindvis af\n> mennesker bruger din kode, bør du optimere din kode til maksimal\n> læsevenlighed, ikke til dine personlige preferencer og sjove eller underlige\n> forkortelser.\" - Idan Gazit\n\n* Al kode i kode-basen bør se ud som om, kun én person har skrevet det hele,\n uanset hvor mange der rent faktisk har leveret indhold.\n* Håndhæv den aftalte stil strengt.\n* Hvis der er tvivl bør eksisterende, bredt accepterede kodemønstre benyttes.\n\n\n\n## 2. Mellemrum\n\nKun én stil bør eksistere på tværs af hele dit projekts kilde. Vær altid\nkonsistent i din brug af mellemrum. Brug mellemrum og ekstra linjeskift til at\nforbedre læsbarheden.\n\n* Du må _aldrig_ blande mellemrum og tablatorer ved indrykning.\n* Vælg mellem bløde indrykninger (mellemrum) eller tabulatorer. Stå ved dit\n valg uden forbehold. (Anbefales: mellemrum)\n* Hvis du bruger mellemrum, vælges et antal der bruges pr. indrykningsniveau.\n (Anbefales: 4 mellemrum)\n\nTip: Indstil din CSS-editor til at vise skjulte tegn. Dette giver dig mulighed\nfor, at slette mellemrum i slutningen af kodelinjer, slette uønskede\ndobbelt-mellemrum og dermed undgå at \"forurene\" kode-commits.\n\n\n\n## 3. Kommentarer\n\nVelkommenteret (og dermed veldokumenteret) kode er virkelig vigtigt. Brug tid\npå at beskrive komponenter, hvordan de virker, deres begrænsninger og måden\nhvorpå de er konstrueret. Overlad det ikke til andre i teamet at gætte sig frem\ntil, hvad usædvanlig eller ikke-indlysende kode skal bruges til.\n\nKommentar-stilen bør være simpel og konsistent på tværs er hele kode-basen.\n\n* Placér kommentarer på en ny linje over den kode, de beskriver.\n* Undgå kommentarer for enden af kodelinjer.\n* Hold kommentarlinjer fornuftigt korte, fx 80 karakterer.\n* Vær gavmild med kommentarer til at bryde CSS'en op i mindre sektioner.\n* Brug korrekt grammetik i kommentarer og vær konsistent med tekst-indrykning.\n\nTip: Indstil din CSS-editor til at give dig genveje til at indsætte\ntekststumper med de aftalte kommentar-mønstre.\n\n#### CSS-eksempel:\n\n```css\n/* ==========================================================================\n Afsnit kommentar-blok\n ========================================================================== */\n\n/* Underafsnit kommentar-blok\n ========================================================================== */\n\n/*\n * Gruppe kommentar-blok.\n * Idéel til fler-linjede forklaringer og dokumentation.\n */\n\n/* Simpel kommentar */\n```\n\n#### SCSS-eksempel:\n\n```scss\n// ==========================================================================\n// Afsnit kommentar-blok\n// ==========================================================================\n\n// Underafsnit kommentar-blok\n// ==========================================================================\n\n//\n// Gruppe kommentar-blok.\n// Idéel til fler-linjede forklaringer og dokumentation.\n//\n\n// Simpel kommentar\n```\n\n\n\n## 4. Formatering\n\nDet valgte kodeformat skal tilsikre at koden er: nem at læse; nem at kommentere\nklart; minimere risikoen for at introducere fejl ved et tilfælde; og resulterer\ni brugbare diffs og blames\n(https://git.wiki.kernel.org/index.php/Textconv#Blame_and_diff)\n\n1. Én diskret selector pr. linje i multi-selector regelsæt.\n2. Ét enkelt mellemrum før krøllet start-parentes i regelsæt.\n3. Én erklæring pr. linje i regelsæt.\n4. Ét indrykningsniveau på regelsæt.\n5. Ét enkelt mellemrum efter kolon i hver erklæring.\n6. Afslut _alle_ erklæringer med et semikolon - også den sidste.\n7. Placér den krøllede slut-parentes på samme indrykningsniveau som det første\n tegn i regelsættet.\n8. Opdel de enkelte regelsæt med en tom linje.\n\n```css\n.selector-1,\n.selector-2,\n.selector-3 {\n -webkit-box-sizing: border-box;\n -moz-box-sizing: border-box;\n box-sizing: border-box;\n display: block;\n color: #333;\n background: #fff;\n}\n```\n\n#### Erklæringers rækkefølge\n\nErklæringer bør sorteres i overensstemmelse med et simpelt princip. Mit\nforetrukne princip er at gruppere relaterede egenskaber sammen, og\nstrukturmæssigt vigtigt egenskaber (fx positionering og box-modellen) erklæring\ninden typografi, baggrund og farveegenskaber.\n\n```css\n.selector {\n position: relative;\n display: block;\n width: 50%;\n height: 100px;\n padding: 10px;\n border: 0;\n margin: 10px;\n color: #fff\n background: #000;\n}\n```\n\nAlfabetisk rækkefølge er også populær, men ulempen er, at denne sortering\nadskiller relaterede egenskaber. For eksempel vil positioneringsegenskaber ikke\nlængere være samlet i en gruppe, og box-modellens egenskaber kan ende med at\nblive spredt ud over hele regelsættet.\n\n#### Undtagelser og små afvigelser\n\nStore blokke af enkelt-linje erklæringer kan benytte et enkeltlinje-format. I\ndette tilfælde bør der inkluderes et enkelt mellemrum før krøllet\nstart-parentes og inden krøllet slut-parentes.\n\n```css\n.selector-1 { width: 10%; }\n.selector-2 { width: 20%; }\n.selector-3 { width: 30%; }\n```\n\nLange, kommaseparerede egenskaber - fx samlinger af farveforløb eller skygger -\nkan arrangeres over flere linjer, i en betræbelse på, at forbedre læsbarheden\nog producere mere brugbare diffs. Det er flere forskellige formater der kan\nbenyttes; en måde at gøre det på kan ses herunder.\n\n```css\n.selector {\n box-shadow:\n 1px 1px 1px #000,\n 2px 2px 1px 1px #ccc inset;\n background-image:\n linear-gradient(#fff, #ccc),\n linear-gradient(#f3c, #4ec);\n}\n```\n\n#### Diverse\n\n* Brug små bogstaver i hex værdier, fx `#aaa`.\n* Brug enkelt- eller dobbelt-anførselstegn konsistent. Dobbelt-anførselstegn\n foretrækkes, fx `content: \"\"`.\n* Brug altid anførselstegn i selctorers egenskaber, fx\n `input[type=\"checkout\"]`.\n* _Hvor det er muligt_ bør du undgå at specificere enheder for nul-værdier, fx\n `margin: 0`.\n\n### Preprocessors: Ekstra overvejelser i forbindelse med formatering\n\nForskellige CSS preprocessors har forskellige egenskaber, funktionalitet og\nsyntaks. Dine konventioner bør udvides og tilpasses, således at de imødekommer\nde forhold, der er i de proprocessors der benyttes af gruppen. De efterfølgende\nguidelines relaterer sig til SASS.\n\n* Begræns indlejring til 1 niveau. Genovervej alle indlejringer der er mere end\n 2 niveauer dyb. Dette forhindrer alt for specifikke CSS selektorer.\n* Undgå et højt antal indlejrede regler. Bryd dem op når læsbarheden begynder\n at blive påvirket. Det anbefales at undgå indlejringer der breder sig over\n mere end 20 linjer.\n* Placér altid `@extend`-erklæringer på første linje i regelsæt.\n* Hvis det er muligt, placeres `@include` i toppen af regelsættet, lige efter\n `@extend`-erklæringer.\n* Overvej at starte brugerdeficerede funktioner med `x-` eller lignende. Dette\n hjælper med at undgå, at dine funktioner konflikter med (eller overskriver)\n standard CSS-funktioner fra biblioteker og frameworks.\n\n```scss\n.selector-1 {\n @extend .other-rule;\n @include clearfix();\n @include box-sizing(border-box);\n width: x-grid-unit(1);\n // andre erklæringer\n}\n```\n\n\n\n## 5. Navngivning\n\nDu er ikke en menneskelig compiler/compressor, så lad være med at prøve at være\nen sådan.\n\nBrug klare og logiske navne til dine HTML-class'er. Vælg et forståelig og\nkonstistent navngivningsmønster der giver mening i både HTML- og CSS-filer.\n\n```css\n/* Eksempel på kode med dårlig navngivning */\n\n.s-scr {\n overflow: auto;\n}\n\n.cb {\n background: #000;\n}\n\n/* Eksempel på kode med god navngivning */\n\n.is-scrollable {\n overflow: auto;\n}\n\n.column-body {\n background: #000;\n}\n```\n\n\n\n## 6. Praktisk eksempel\n\nEt eksempel på en række forskellige konventioner.\n\n```css\n/* ==========================================================================\n Gitter layout\n ========================================================================== */\n\n/*\n * HTML-eksempel:\n *\n * \n */\n\n.grid {\n overflow: visible;\n height: 100%;\n /* Undgå at \"inline-block\"-celler ombrydes */\n white-space: nowrap;\n /* Fjerner mellemrum mellem celler */\n font-size: 0;\n}\n\n.cell {\n box-sizing: border-box;\n position: relative;\n overflow: hidden;\n width: 20%;\n height: 100%;\n /* Angiver mellemrum mellem celler */\n padding: 0 10px;\n border: 2px solid #333;\n vertical-align: top;\n /* Nulstil white-space */\n white-space: normal;\n /* Nulstil font-size */\n font-size: 16px;\n}\n\n/* Cellers tilstande */\n\n.cell.is-animating {\n background-color: #fffdec;\n}\n\n/* Cellers dimensioner\n ========================================================================== */\n\n.cell-1 { width: 10%; }\n.cell-2 { width: 20%; }\n.cell-3 { width: 30%; }\n.cell-4 { width: 40%; }\n.cell-5 { width: 50%; }\n\n/* Celle-ændringer\n ========================================================================== */\n\n.cell--detail,\n.cell--important {\n border-width: 4px;\n}\n```\n\n\n\n## 7. Organisering\n\nOrganisering af kode er en vigtig del af enhver CSS kodebase, og livsnødvendig\nfor store kodebaser.\n\n* Lav en logisk separering mellem særskilte stumper af kode.\n* Brug separate filer (sammenkædes i et build) for at bryde koden op i\n særskilte komponenter.\n* Hvis du bruger en preprocessor, opsættes fælles kode i variabler for farver,\n typografi osv.\n\n\n## 8. Builds og udrulning\n\nForud for brug i live-miljøer, bør projekter altid forsøge at inkludere en\ngenerisk metode til at linte, teste, komprimere og versionere koden. Til dette\nformål er [grunt](https://github.com/cowboy/grunt) af Ben Alman et fremragende\nværktøj.\n\n\n\n## Anerkendelser\n\nTak til alle der har bidraget til\n[idiomatic.js](https://github.com/rwldrn/idiomatic.js). I har været en\nfantastisk kilde til inspiration, noteringer og retningslinjer.\n"
},
{
"path": "translations/de-DE/README.md",
"content": "# Grundlagen zum Schreiben von einheitlichem, idiomatischem CSS\n\nDas folgende Dokument legt eine vernünftige Gestaltungsrichtlinie für die\nCSS-Entwicklung dar. Diese Richtlinien ermutigen zur Verwendung existierender,\nüblicher und sinnvoller Muster. Sie sollten nach Bedarf angepasst werden, um\neine eigene Gestaltungsrichtlinie zu erstellen.\n\nDies ist ein lebendiges Dokument, und neue Ideen sind immer willkommen. Bitte\ntrage bei.\n\n[Idiomatic CSS auf englisch](https://github.com/necolas/idiomatic-css/).\n\n\n## Inhaltsverzeichnis\n\n1. [Allgemeine Grundlagen](#general-principles)\n2. [Leerraum](#whitespace)\n3. [Kommentare](#comments)\n4. [Formatierung](#format)\n5. [Praktisches Beispiel](#example)\n\n[Danksagung](#acknowledgements)\n\n[Lizenz](#license)\n\n\n\n## 1. Allgemeine Grundlagen\n\n> „Ein Teil der Aufgabe eines guten Verwalters eines erfolgreichen Projekts ist\n> es, zu realisieren, dass Code für sich selbst zu schreiben eine schlechte\n> Idee™ ist. Wenn tausende Leute deinen Code verwenden, dann schreibe deinen\n> Code für maximale Klarheit, nicht nach deinen persönlichen Vorlieben, wie\n> man innerhalb der Spezifikation gerissen sein kann.“ - Idan Gazit\n\n* Du bist kein menschlicher Code-Compiler/Kompressor, versuche also nicht,\n einer zu sein.\n* Der gesamte Code in jeder Code-Basis soll aussehen wie von einer einzigen\n Person eingegeben, unabhängig davon wieviele Leute beigetragen haben.\n* Erzwinge den vereinbarten Stil streng.\n* Im Zweifel bei einer Stilentscheidung verwende bestehende, übliche Muster.\n\n\n\n## 2. Leerraum\n\nNur ein Stil soll in den gesamten Quellen deines Projekts existieren. Sei\nstets konsistent beim Einsatz von Leerraum. Verwende Leerraum, um die\nLesbarkeit zu erhöhen.\n\n* Mische _niemals_ Leerzeichen und Tabs zur Einrückung.\n* Wähle zwischen weicher Einrückung (Leerzeichen) oder wirklichen Tabs. Bleibe\n bei deiner Wahl ohne Abweichung. (Vorzug: Leerzeichen)\n* Beim Einsatz von Leerzeichen wähle die Anzahl Zeichen pro Einrückebene.\n (Vorzug: 4 Leerzeichen)\n\nTipp: Richte deinen Editor so ein, dass er unsichtbare Zeichen zeigt. Das\nerlaubt dir, Leerzeichen am Zeilenende zu entfernen, unbeabsichtigte\nLeerzeichen in leeren Zeilen und Commits zu verschmutzen.\n\nTipp: Verwende eine [EditorConfig](http://editorconfig.org/)-Datei (oder\nentsprechend), um die grundlegenden Leerraum-Konventionen, die vereinbart\nwurden, verwalten zu helfen.\n\n\n\n## 3. Kommentare\n\nGut kommentierter Code ist extrem wichtig. Nimm dir Zeit, Komponenten zu\nbeschreiben, wie sie arbeiten, welche Beschränkungen sie haben und wie sie\ngebaut sind. Lass andere im Team nicht raten, was den Zweck von ungewöhnlichem\noder nicht offensichtlichem Code betrifft.\n\nDer Kommentarstil soll einfach und konsistent innerhalb einer einzelnen\nCode-Basis sein.\n\n* Platziere Kommentare auf neuen Zeilen über ihrem Gegenstand.\n* Behalte die Zeilenlänge bei einem sinnvollen Maximum, z.B. 80 Spalten.\n* Mache großzügigen Gebrauch von Kommentaren, um CSS in einzelne Abschnitte zu\n unterteilen.\n* Beginne mit einem Großbuchstaben und verwende konsistente Einrückung.\n\nTip: Konfiguriere deinen Editor so, dass er Kürzel für die Ausgabe von\nausgemachten Kommentar-Mustern anbietet.\n\nBeispiel:\n\n```css\n/* ==========================================================================\n Abschnitt Kommentar-Block\n ========================================================================== */\n\n/* Unterabschnitt Kommentar-Block\n ========================================================================== */\n\n/**\n * Kurze Beschreibung im Doxygen-Stilformat\n *\n * Der erste Satz der langen Beschreibung beginnt hier und wird auf dieser\n * Zeile für eine Weile fortgeführt, bis er schließlich hier endet.\n *\n * Die lange Beschreibung ist ideal für detailliertere Erläuterungen und\n * Dokumentation. Sie kann Beispiel-HTML, URLs und andere Information\n * beinhalten, die nützlich oder notwendig erscheint.\n *\n * @tag Dies ist ein Schlagwort namens 'tag'\n *\n * @todo Dies ist eine Todo-Angabe, die eine unteilbare Aufgabe beschreibt,\n * die später vollendet wird. Sie bricht nach 80 Zeichen um und folgende\n * Zeilen sind mit zwei Leerzeichen eingerückt.\n */\n\n/* Einfacher Kommentar */\n```\n\n\n\n## 4. Formatierung\n\nDie gewählte Codeformatierung muss gewährleisten, dass der Code: leicht zu\nlesen ist; leicht klar zu kommentieren ist; nicht dazu verleitet, unabsichtlich\nFehler einzuführen; und zu nützlichen Diffs und Blames der Versionsverwaltung\nführt.\n\n* Verwende einen einzelnen Selektor pro Zeile in Multi-Selektor-Regelsets.\n* Füge ein einzelnes Leerzeichen vor der öffnenden Klammer eines Regelsets ein.\n* Füge eine Deklaration pro Zeile in einem Deklarationsblock ein.\n* Verwende eine Einrückungsebene für jede Deklaration.\n* Füge ein einzelnes Leerzeichen nach dem Doppelpunkt jeder Deklaration ein.\n* Verwende Kleinbuchstaben und Kurzschreibweise bei Hexwerten, z. B. `#aaa`.\n* Verwende einfache oder doppelte Anführungszeichen konsistent. Doppelte\n Anführungszeichen werden bevorzugt, z. B. `content: \"\"`.\n* Setze Attributwerte in Selektoren in Anführungszeichen, z. B.\n `input[type=\"checkbox\"]`.\n* _Wo es erlaubt ist,_ vermeide die Angabe von Einheiten für Nullwerte, z. B.\n `margin: 0`.\n* Füge ein Leerzeichen nach jedem Komma ein bei komma-getrennten Eigenschaften\n oder Funktionswerten.\n* Füge einen Strichpunkt nach der letzten Deklaration in einem\n Deklarationsblock ein.\n* Platziere die schließende Klammer eines Regelsets in derselben Spalte wie\n das erste Zeichen des Regelsets.\n* Trenne jedes Regelset mit einer Leerzeile.\n\n```css\n.selektor-1,\n.selektor-2,\n.selektor-3[type=\"text\"] {\n -webkit-box-sizing: border-box;\n -moz-box-sizing: border-box;\n box-sizing: border-box;\n display: block;\n font-family: helvetica, arial, sans-serif;\n color: #333;\n background: #fff;\n background: linear-gradient(#fff, #bbb);\n background: linear-gradient(#fff, rgba(0, 0, 0, 0.8));\n}\n\n.selektor-a,\n.selektor-b {\n padding: 10px;\n}\n```\n\n#### Deklarations-Reihenfolge\n\nDeklarationen sollen nach einem einzelnen, einfachen Prinzip sortiert werden,\nwenn sie geordnet werden. Ich bevorzuge es, strukturell wichtige Eigenschaften\n(z.B. Positionierung und Box-Modell) vor allen anderen zu notieren.\n\n```css\n.selektor {\n /* Positionierung */\n position: absolute;\n z-index: 10;\n top: 0;\n right: 0;\n bottom: 0;\n left: 0;\n\n /* Anzeige & Box-Modell */\n display: inline-block;\n overflow: hidden;\n box-sizing: border-box;\n width: 100px;\n height: 100px;\n padding: 10px;\n border: 10px solid #333;\n margin: 10px;\n\n /* Andere */\n background: #000;\n color: #fff;\n font-family: sans-serif;\n font-size: 16px;\n text-align: right;\n}\n```\n\nStreng alphabetische Sortierung ist ebenfalls populär, hat aber den Nachteil,\ndass sie verwandte Eigenschaften trennt. Zum Beispiel sind Positions-Versätze\nnicht mehr zusammen gruppiert und Box-Modell-Eigenschaften können sich über\neinen ganzen Deklarationsblock verteilt wiederfinden.\n\n#### Ausnahmen und leichte Abweichungen\n\nGroße Blöcke mit einzelnen Deklarationen können ein leicht unterschiedliches,\neinzeiliges Format verwenden. In diesem Fall wird ein Leerzeichen nach der\nöffnenden und vor der schließenden Klammer eingefügt.\n\n```css\n.selektor-1 { width: 10%; }\n.selektor-2 { width: 20%; }\n.selektor-3 { width: 30%; }\n```\n\nLange, komma-getrennte Eigenschaftswerte - wie Sammlungen von Gradienten oder\nSchatten - können über mehrere Zeilen angeordnet werden, um die Lesbarkeit zu\nerhöhen und nützlichere Diffs zu produzieren. Es gibt verschiedene\nFormatierungen, die verwendet werden können; ein Beispiel ist im Folgenden\ngezeigt.\n\n```css\n.selektor {\n background-image:\n linear-gradient(#fff, #ccc),\n linear-gradient(#f3c, #4ec);\n box-shadow:\n 1px 1px 1px #000,\n 2px 2px 1px 1px #ccc inset;\n}\n```\n\n### Präprozessoren: Zusätzliche Formatier-Überlegungen\n\nVerschiedene CSS-Präprozessoren haben verschiedene Besonderheiten,\nFunktionalität und Syntax. Deine Konventionen sollen so erweitert werden, dass\nsie den Eigenheiten jedes verwendeten Präprozessors Rechnung tragen. Die\nfolgenden Richtlinien beziehen sich auf Sass.\n\n* Beschränke Verschachtelungen auf eine Ebene Tiefe. Überprüfe jede\n Verschachtelung tiefer als 2 Ebenen. Das verhindert übermäßg spezifische\n CSS-Selektoren.\n* Vermeide große Mengen verschachtelter Regeln. Brich sie in Teile auf, wenn\n Lesbarkeit beeinträchtigt wird. Der Vorzug gilt dem Vermeiden von\n verschachtelten Anweisungen mit mehr als 20 Zeilen Länge.\n* Setze `@extend`-Angaben immer in die erste Zeile eines Deklarationsblocks.\n* Wo möglich gruppiere `@include`-Angaben am Anfang eines Deklarationsblocks,\n nach jedem `@extend`.\n* Ziehe in Betracht, eigenen Funktionen `x-` oder einen anderen Namensraum\n voranzustellen. Das hilft zu verhindern, dass deine Funktionen mit nativen\n CSS-Funktionen verwechselt werden oder mit Funktionen anderer Bibliotheken\n kollidieren.\n\n```scss\n.selektor-1 {\n @extend .andere-regel;\n @include clearfix();\n @include box-sizing(border-box);\n width: x-grid-unit(1);\n // andere Deklarationen\n}\n```\n\n\n\n## 5. Praktisches Beispiel\n\nEin Beispiel verschiedener Konventionen.\n\n```css\n/* ==========================================================================\n Rasterlayout\n ========================================================================== */\n\n/**\n * Beispiel-Layout mit horizontalem Scrollen.\n *\n * Dies erzeugt eine Reihe von maximal-hohen, nicht umbrechenden Spalten, die\n * horizontal innerhalb ihres Elternelements durchsucht werden können.\n *\n * Beispiel-HTML:\n *\n * \n */\n\n/**\n * Grid-Container\n * Darf nur `.cell`-Kinder enthalten.\n */\n\n.grid {\n height: 100%;\n /* Verhindere Leerraum in Zellen */\n font-size: 0;\n /* Hindere inline-block-Zellen am Umbruch */\n white-space: nowrap;\n}\n\n/**\n * Grid-Zellen\n * Keine vorgegebene Breite. Erweitere mit `.cell-n`-Klassen.\n */\n\n.cell {\n position: relative;\n display: inline-block;\n overflow: hidden;\n box-sizing: border-box;\n height: 100%;\n /* Setzt den Abstand zwischen Zellen */\n padding: 0 10px;\n border: 2px solid #333;\n vertical-align: top;\n /* Stellt Leerraum wieder her */\n white-space: normal;\n /* Stellt Schriftgröße wieder her */\n font-size: 16px;\n}\n\n/* Zell-Zustände */\n\n.cell.is-animating {\n background-color: #fffdec;\n}\n\n/* Zell-Abmessungen\n ========================================================================== */\n\n.cell-1 { width: 10%; }\n.cell-2 { width: 20%; }\n.cell-3 { width: 30%; }\n.cell-4 { width: 40%; }\n.cell-5 { width: 50%; }\n\n/* Zell-Modifikatoren\n ========================================================================== */\n\n.cell--detail,\n.cell--important {\n border-width: 4px;\n}\n```\n\n\n\n## Danksagung\n\nDanke an alle, die Übersetzungen erstellt haben und all jene, die zu\n[idiomatic.js](https://github.com/rwldrn/idiomatic.js) beigetragen haben. Es\nwar eine Quelle der Inspiration, von Zitaten und Richtlinien.\n\n\n\n## Lizenz\n\n_Grundlagen zum Schreiben von einheitlichem, idiomatischem CSS_ von Nicolas\nGallagherist lizenziert unter der [Creative Commons Attribution 3.0\nUnported-License](http://creativecommons.org/licenses/by/3.0/). Dies trifft\nauf alle Dokumente und Übersetzungen in diesem Repository zu.\n\nBasierend auf einer Arbeit auf\n[github.com/necolas/idiomatic-css](https://github.com/necolas/idiomatic-css).\n"
},
{
"path": "translations/es-ES/README.md",
"content": "# Principios para escribir CSS idiomático y consistente\n\nEl siguiente documento ofrece una guía razonable de estilo para el desarrollo\nde CSS. No es mi intención ser preceptivo y no deseo imponer mis preferencias\nde estilo en el código de otras personas. Sin embargo esta guía anima\nenérgicamente a que se utilicen los patrones existentes, que son de sentido\ncomún.\n\nEste es un documento vivo y nuevas ideas son siempre bienvenidas. Por favor\ncontribuya.\n\n[CSS idiomático en inglés (Original)](https://github.com/necolas/idiomatic-css/)\n\n\n## Tabla de contenido\n\n1. [Principios generales](#general-principles)\n2. [Espacios en blanco](#whitespace)\n3. [Comentarios](#comments)\n4. [Formato](#format)\n5. [Nomenclatura](#naming)\n6. [Ejemplos prácticos](#example)\n7. [Organización](#organization)\n8. [Construcción y distribución](#build-and-deployment)\n\n[Agradecimientos](#acknowledgements)\n\n\n\n## 1. Principios generales\n\n> \"Parte de ser un buen administrador al crear un proyecto exitoso es darse\n> cuenta que escribir código para uno mismo es una Mala Idea™. Si miles de\n> personas están utilizando tu código, entonces escríbelo con la máxima\n> claridad, no con tus preferencias personales de cómo ser inteligente con la\n> especificación.\" - Idan Gazit\n\n* Todo el código en una aplicación debe parecer como si sólo una persona lo\n hubiese escrito, no importa cuántas personas hayan contribuido.\n* Fuerce a que se respete el estilo acordado.\n* Si tiene dudas utilice los patrones de uso común.\n\n\n\n## 2. Espacios en blanco\n\nSólo debe existir un estilo en el código de su proyecto. Siempre sea\nconsistente en el uso de los espacios en blanco. Utilice espacios en blanco\npara mejorar la legibilidad.\n\n* _Nunca_ mezcle espacios y tabulaciones para indentar.\n* Elija entre indentaciones blandas (espacios) o tabulaciones reales. Apéguese\n a su elección sin fallo. (Preferencia: espacios)\n* Si utiliza espacios, elija el número de caracteres a usar para cada nivel de\n indentación. (Preferencia: 4 espacios)\n\nConsejo: configure su editor para que \"muestre los caracteres invisibles\". Esto\nle permitirá eliminar los espacios en blanco al final de las líneas, eliminar\nespacios en blanco de líneas en blanco y evitar commits con basura.\n\nConsejo: Utilice el editor [EditorConfig](http://editorconfig.org/) (o algún\nequivalente) para ayudarse a mantener las convenciones básicas que han sido\nacordadas en su proyecto.\n\n\n\n## 3. Comentarios\n\nUn código bien comentado es muy importante. Tómese el tiempo necesario para\ndescribir los componente, cómo trabajan, sus limitaciones y la forma en que\nfueron construidos. No deje que otros miembros de su equipo tengan que adivinar\nel propósito de un código poco común o poco obvio.\n\nEl estilo de los comentarios debe ser siempre simple y consistente con un mismo\ncódigo base.\n\n* Coloque los comentarios en una línea nueva sobre cada objeto.\n* Evite los comentarios al final de las líneas.\n* Mantenga el largo de cada línea con un máximo razonable, por ejemplo, 80\n columnas.\n* Haga un uso libre de los comentarios para separar código CSS en secciones\n discretas.\n* Realice comentarios que comiencen con una letra mayúscula y con indentación\n consistente.\n\nConsejo: configure su editor para que le ofrezca atajos para la creación de\ncomentarios comunes.\n\n#### Ejemplo de CSS:\n\n```css\n/* ==========================================================================\n Bloque de comentario de sección\n ========================================================================== */\n\n/* Bloque de comentario de sub-sección\n ========================================================================== */\n\n/*\n * Pequeña descripción utilizando el formato de comentario Doxygen.\n *\n * La primer oración de una descripción larga comienza aquí y continúa en\n * esta linea durante un tiempo para finalmente terminar aquí al final de\n * este párrafo.\n *\n * Las descripciones largas son ideales para explicaciones de mayor detalle\n * y documentación. Pueden incluir ejemplos de HTML, URLs o cualquier otro\n * tipo de información que es considerada necesaria o útil.\n *\n * @tag Esto es una etiqueta llamada 'tag'\n *\n * @todo Esto es una declaración 'todo' (\"a realizar\") que describe una tarea\n * atómica (específica) a realizar posteriormente. Continua luego de 80\n * caracteres por lo que las lineas consecutivas son indentadas con dos\n * espacios adicionales.\n */\n\n/* Comentario básico */\n```\n\n\n\n## 4. Formato\n\nEl formato del código elegido debe asegurarse de que el código: es fácil de\nleer, es fácil de comentar claramente, minimiza las posibilidades de introducir\nerrores accidentalmente, y facilita el hallazgo de diferencias y\nresponsabilidades.\n\n* Utilice un selector discreto por línea en un conjunto de reglas con multi\n selectores.\n* Incluya un solo espacio antes de la llave de apertura en un conjunto de\n reglas.\n* Incluya una declaración por línea en un bloque de declaraciones.\n* Utilice un nivel de indentación para cada declaración.\n* Incluya un solo espacio luego de los dos puntos en una declaración.\n* Utilice minúsculas y valores hexadecimales abreviados, ejemplo `#aaa`.\n* Utilice comillas simples o dobles pero de forma consistente. Se prefiere la\n utilización de comillas dobles, ejemplo `content: \"\"`.\n* Utilice comillas en los valores de los atributos de los selectores, ejemplo\n `input[type=\"checkbox\"]`.\n* _Siempre que pueda_, evite especificar valores de 0, por ejemplo `margin:\n 0`.\n* Incluya un espacio luego de cada coma en las propiedades separadas por comas\n o en los valores de las funciones.\n* Siempre incluya un punto y coma al final de la línea de la última declaración\n en un bloque de declaraciones.\n* Coloque la llave de cierre de un conjunto de reglas en la misma columna que\n el primer carácter del conjunto.\n* Separe cada conjunto de reglas con una línea en blanco.\n\n```css\n.selector-1,\n.selector-2,\n.selector-3[type=\"text\"] {\n -webkit-box-sizing: border-box;\n -moz-box-sizing: border-box;\n box-sizing: border-box;\n display: block;\n font-family: helvetica, arial, sans-serif;\n color: #333;\n background: #fff;\n background: linear-gradient(#fff, rgba(0, 0, 0, 0.8));\n}\n```\n\n#### Orden de las declaraciones\n\nLas declaraciones deben ser ordenadas con un único principio. Mi preferencia es\nque las propiedades relacionadas con la estructura (por ejemplo, de posición y\nbox-model) sean declaradas antes que las demás.\n\n```css\n.selector {\n /* Posicionamiento */\n position: absolute;\n z-index: 10;\n top: 0;\n right: 0;\n bottom: 0;\n left: 0;\n\n /* Display & Box Model */\n display: inline-block;\n overflow: hidden;\n box-sizing: border-box;\n width: 100px;\n height: 100px;\n padding: 10px;\n border: 10px solid #333;\n margin: 10px;\n\n /* Otras */\n background: #000;\n color: #fff\n font-family: sans-serif;\n font-size: 16px;\n text-align: right;\n}\n```\n\nEl ordenamiento alfabético es también muy popular, pero la desventaja es que\nlas propiedades relacionadas no se mantienen juntas. Por ejemplo, los\ndesplazamientos de posición no permanecen juntos y las propiedades de box-model\npueden ser esparcidas a través del bloque de declaraciones.\n\n#### Excepciones y pequeñas desviaciones\n\nBloques grandes de una sola declaración pueden ser ligeramente diferentes,\nutilizando el formato de una sola línea. En este caso, un espacio debe ser\nincluido luego de la llave de apertura y antes de la llave de cierre.\n\n```css\n.selector-1 { width: 10%; }\n.selector-2 { width: 20%; }\n.selector-3 { width: 30%; }\n```\n\nGrandes propiedades de valores separados por coma -tal como una colección de\ngradientes o sombras- pueden ser organizadas en múltiples líneas en un intento\nde mejorar la legibilidad y producir visualizaciones de diferencias más\nútiles. Hay varios formatos que pueden ser utilizados: uno, por ejemplo, es\nmostrado más abajo.\n\n```css\n.selector {\n background-image:\n linear-gradient(#fff, #ccc),\n linear-gradient(#f3c, #4ec);\n box-shadow:\n 1px 1px 1px #000,\n 2px 2px 1px 1px #ccc inset;\n}\n```\n\n### Preprocesadores: consideraciones a formatos adicionales\n\nCada preprocesador de CSS tiene sus características, funcionalidades y\nsintaxis. Sus convenciones deben extenderse para adaptarse a las\nparticularidades de cada preprocesador en uso. La siguiente guía está referida\na Sass.\n\n* Limítese a anidar con 1 nivel de profundidad. Corrija cualquier anidado de\n más de 2 niveles. Esto previene que existan selectores de CSS muy\n específicos.\n* Evite realizar un gran número de reglas anidadas. Sepárelas cuando la\n legibilidad comience a ser afectada. Se prefiere evitar el anidado que se\n extiende a más de 20 líneas.\n* Siempre coloque las declaraciones `@extend` en la primer línea de los bloques\n declarativos.\n* Dónde sea posible, agrupe las declaraciones `@include` en la parte superior\n del bloque declarativo, luego de las declaraciones `@extend`.\n* Considere prefijar funciones personalizadas con `x-` u otro separador. Esto\n ayuda a evitar cualquier confusión potencial con una función nativa de CSS, o\n entrar en conflicto con una función de alguna librería.\n\n```scss\n.selector-1 {\n @extend .other-rule;\n @include clearfix();\n @include box-sizing(border-box);\n width: x-grid-unit(1);\n // other declarations\n}\n```\n\n\n\n## 5. Nomenclatura\n\nLa nomenclatura es difícil, pero muy importante. Es una parte crucial del\nproceso de desarrollo y mantenimiento del proyecto, y le asegura a usted tener\nuna relativamente escalable interfaz entre su código HTML y CSS.\n\n* Evite la _sistemática_ utilización de abreviaciones en los nombres de las\n clases. No haga las cosas difíciles de entender.\n* Utilice nombres claros y meditados para las _clases HTML_.\n* Elija un comprensible y consistente patrón de nombres que tengan sentido\n tanto para los archivos HTML como para los archivos CSS.\n* Los selectores para los componentes deben utilizar nombres de clases; evite\n la utilización de etiquetas genéricas e ids únicos.\n\n\n```css\n/* Ejemplo de código con nombres incorrectos */\n\n.s-scr {\n overflow: auto;\n}\n\n.cb {\n background: #000;\n}\n\n/* Ejemplo de código con nombres correctos */\n\n.is-scrollable {\n overflow: auto;\n}\n\n.column-body {\n background: #000;\n}\n```\n\n\n\n## 6. Ejemplos prácticos\n\nUn ejemplo de varias convenciones.\n\n```css\n/* ==========================================================================\n Grid layout\n ========================================================================== */\n\n/*\n * Ejemplo HTML:\n *\n * \n */\n\n.grid {\n overflow: visible;\n height: 100%;\n /* Prevent inline-block cells wrapping */\n white-space: nowrap;\n /* Remove inter-cell whitespace */\n font-size: 0;\n}\n\n.cell {\n box-sizing: border-box;\n position: relative;\n overflow: hidden;\n width: 20%;\n height: 100%;\n /* Set the inter-cell spacing */\n padding: 0 10px;\n border: 2px solid #333;\n vertical-align: top;\n /* Reset white-space */\n white-space: normal;\n /* Reset font-size */\n font-size: 16px;\n}\n\n/* Estados de las celdas */\n\n.cell.is-animating {\n background-color: #fffdec;\n}\n\n/* Dimensiones de las celdas\n ========================================================================== */\n\n.cell-1 { width: 10%; }\n.cell-2 { width: 20%; }\n.cell-3 { width: 30%; }\n.cell-4 { width: 40%; }\n.cell-5 { width: 50%; }\n\n/* Modificadores de celdas\n ========================================================================== */\n\n.cell--detail,\n.cell--important {\n border-width: 4px;\n}\n```\n\n\n\n## 7. Organización\n\nLa organización del código es una parte importante en cualquier base de código\nCSS, y crucial para grandes bases de código.\n\n* Separe las distintas partes de código de forma lógica.\n* Utilice archivos independientes (unidos por un proceso de construcción) para\n ayudar a separar código para distintos componentes.\n* Si utiliza un preprocesador, abstraiga código común en variables para el\n color, la tipografía, etc.\n\n\n\n## 8. Construcción y distribución\n\nLos proyectos deben siempre intentar incluir algunos medios genéricos para que\nel código pueda ser verificado, probado, comprimido y versionado para luego ser\nutilizado en producción. Para esta tarea,\n[grunt](https://github.com/cowboy/grunt), de Ben Alman es una excelente\nherramienta.\n\n\n\n## Agradecimientos\n\nGracias a todos los que han contribuido en\n[idiomatic.js](https://github.com/rwldrn/idiomatic.js).\nHa sido fuente de inspiración, referencia y guía.\n"
},
{
"path": "translations/fr-FR/README.md",
"content": "# Principes d'écriture pour des CSS cohérents et idiomatiques\n\nLe présent document liste des recommandations raisonnables pour le\ndéveloppement CSS.\n\nIl n'est pas destiné à être normatif et je ne souhaite pas imposer mes\npréférences en matière de code à tout le monde. Toutefois, ces lignes\ndirectrices encouragent fortement l'utilisation de conventions existantes,\ncommunes et judicieuses.\n\nCeci est un document évolutif et les nouvelles idées sont toujours les\nbienvenues.\n\nMerci de bien vouloir contribuer.\n\n[Idiomatic CSS en anglais](https://github.com/necolas/idiomatic-css/)\n\n\n## Table des matières\n\n1. [Principes généraux](#general-principles)\n2. [Indentation](#whitespace)\n3. [Commentaires](#comments)\n4. [Format](#format)\n5. [Nommage](#naming)\n6. [Exemple pratique](#example)\n7. [Organisation](#organization)\n8. [Compilation et déploiement](#build-and-deployment)\n\n[Remerciements](#acknowledgements)\n\n\n\n## 1. Principes généraux\n\n> Une des clefs d'une bonne gestion de projet est de réaliser qu'écrire du code\n> pour soi-même est une MAUVAISE IDÉE™. Si des milliers de personnes sont\n> amenées à utiliser votre code, alors écrivez votre code en visant un maximum\n> de clarté, et non en fonction de croyances personnelles comme la lecture de\n> spécifications qui rendrait plus intelligent.\" - Idan Gazit\n\n* Tout code présent dans n'importe quelle base de code doit avoir l'air d'avoir\n été écrit par une seule personne, peu importe le nombre de gens qui y ont\n contribué ;\n* Appliquez les conventions de style de manière stricte ;\n* En cas de doute, utilisez des conventions existantes et communes.\n\n\n\n## 2. Indentation\n\nUne seule manière d‘indenter devrait être utilisée sur l'ensemble du code\nsource de votre projet. Soyez toujours constant dans votre façon d‘indenter.\nUtilisez des espaces pour améliorer la lisibilité.\n\n* Ne mélangez _jamais_ les espaces et les tabulations pour l'indentation.\n* Choisissez entre des espaces ou de vraies tabulations. Tenez-vous en à votre\n choix sans y déroger. (Préference : espaces)\n* Si vous utilisez les espaces, choisissez le nombre de caractères utilisé pour\n chaque niveau d'indentation. (Préference : 4 espaces)\n\nAstuce : Configurez votre éditeur afin qu'il affiche les \"caractères\ninvisibles\". Cela vous permettra de supprimer les espaces en fin de ligne, les\nespaces dans les lignes vides et évitera de polluer vos commits.\n\n\n\n## 3. Commentaires\n\nBien commenter son code est extrêmement important. Prenez le temps de décrire\nles composants, comment ils fonctionnent, leurs limites, et la manière dont ils\nsont conçus. Ne laissez pas les autres membres de l'équipe deviner le but d'un\ncode inhabituel ou non trivial.\n\nLa façon de commenter doit être simple et similaire dans toute base de code.\n\n* Placez les commentaires sur une nouvelle ligne au-dessus de leur sujet ;\n* Evitez les commentaires en fin de ligne ;\n* Gardez une longueur de ligne de taille raisonnable, par exemple 80\n caractères ;\n* Utilisez les commentaires comme bon vous semble pour diviser le code CSS en\n parties distinctes ;\n* Rédigez vos commentaires avec des majuscules et des minuscules et gardez une\n indentation constante pour le texte.\n\nAstuce: Paramètrez votre éditeur pour qu'il vous fournisse des raccourcis\nclaviers qui produisent des commentaires conventionnels.\n\n#### Exemple en CSS :\n\n```css\n/* ==========================================================================\n Bloc de commentaire de section\n ========================================================================== */\n\n/* Bloc de commentaire de sous-section\n ========================================================================== */\n\n/*\n * Groupe de bloc de commentaires.\n * Parfait pour les explications sur plusieurs lignes et la documentation.\n */\n\n/* Commentaire simple */\n```\n\n#### SCSS exemple :\n\n```scss\n// ==========================================================================\n// Bloc de commentaire de section\n// ==========================================================================\n\n// Bloc de commentaire de sous-section\n// ==========================================================================\n\n//\n// Groupe de bloc de commentaires.\n// Parfait pour les explications sur plusieurs lignes\n// et la documentation\n\n// Commentaire simple\n```\n\n\n\n## 4. Format\n\nLe format de code choisi doit assurer: une bonne lisibilité, des commentaires\nclairs, une réduction des probabilités d'insertion accidentelle d'erreurs, et\nla production de fichiers diff et de résolution des problèmes pratiques.\n\n1. Un seul sélecteur par ligne dans les régles à plusieurs sélecteurs ;\n2. Un espace avant l'accolade ouvrante d'une règle ;\n3. Une déclaration par ligne dans un bloc de déclarations ;\n5. Un espace après les deux points d'une déclaration ;\n6. Ajoutez toujours un point-virgule à la fin de la dernière déclaration d’un\n bloc ;\n7. Fermez l'accolade d'une règle au même niveau que le premier caractère de la\n règle ;\n8. Sautez une ligne entre chaque règle.\n\n```css\n.selecteur-1,\n.selecteur-2,\n.selecteur-3 {\n -webkit-box-sizing: border-box;\n -moz-box-sizing: border-box;\n box-sizing: border-box;\n display: block;\n color: #333;\n background: #fff;\n}\n```\n\n#### Ordre des déclarations\n\nL'ordre des déclarations doit toujours obéir à la même règle. Je préfère\nregrouper les règles connexes ensemble et déclarer les propriétés importantes\nrelatives à la structure (c-à-d le positionnement et le modèle de boîte) avant\nles règles typographiques, l'arrière-plan et les couleurs.\n\n```css\n.selecteur {\n position: relative;\n display: block;\n width: 50%;\n height: 100px;\n padding: 10px;\n border: 0;\n margin: 10px;\n color: #fff\n background: #000;\n}\n```\n\nL'ordre alphabétique est également très utilisé, mais le problème est qu'il\nsépare les propriétés liées. Par exemple, les décalages de positionnement ne\nsont plus regroupés ensemble et les propriétés du modèle de boîte se retrouvent\néparpillées dans le bloc de déclaration.\n\n#### Exceptions et légers écarts\n\nDe gros blocs de déclarations uniques peuvent utiliser un format légèrement\ndifférent, regroupées sur une seule ligne. Dans ce cas, il faut insérer un\nespace après l'accolade ouvrante et avant l'accolade fermante.\n\n```css\n.selecteur-1 { width: 10%; }\n.selecteur-2 { width: 20%; }\n.selecteur-3 { width: 30%; }\n```\n\nLes longues valeurs de propriétés, séparées par des virgules - comme des\nensembles de dégradés et d'ombres - peuvent être agencées sur plusieurs lignes\nde manière à améliorer la lisibilité et produire des fichiers diff plus utiles.\nDivers formats peuvent alors être utilisés comme le montre l'exemple donné\nci-dessous :\n\n```css\n.selecteur {\n box-shadow:\n 1px 1px 1px #000,\n 2px 2px 1px 1px #ccc inset;\n background-image:\n linear-gradient(#fff, #ccc),\n linear-gradient(#f3c, #4ec);\n}\n```\n\n#### Divers\n\n* Utilisez des minuscules pour les valeurs hexadécimales, exemple : `#aaa` ;\n* Utilisez toujours le même type de guillemets. Ma préférence va aux doubles\n guillemets, exemple : `content: \"\"` ;\n* Utilisez toujours des guillemets pour les valeurs dans les sélecteurs,\n exemple : `input[type=\"checkbox\"]` ;\n* _Lorsque c'est autorisé_, évitez de spécifier les unités pour les valeurs\n nulles, exemple : `margin: 0`.\n\n### Préprocesseurs: considérations additionnelles pour le formatage\n\nLes différents préprocesseurs CSS offrent des possibilités, des fonctionnalités\net une syntaxe différentes. Vos conventions doivent être étendues pour\ns'adapter aux particularités des préprocesseurs que vous utilisez. Les\nconventions suivantes font référence à Sass.\n\n* Limiter l'imbrication à un niveau de profondeur. Réexaminez toute imbrication\n supérieure à deux niveaux de profondeur. Cela évite des sélecteurs CSS trop\n spécifiques.\n* Evitez d'imbriquer un trop grand nombre de règles, séparez les lorsque cela\n nuit à la lisibilité. Je préfère éviter les imbrications qui dépassent les 20\n lignes.\n* Placez toujours les déclarations \"@extend\" en début de bloc.\n* Si possible, regroupez toutes les déclarations \"@include\" en début de bloc\n juste après les déclarations \"@extend\".\n* Pensez à préfixer vos propres fonctions avec `x-` ou un autre espace de nom.\n Cela permet d'éviter potentiellement de confondre votre fonction avec une\n fonction native CSS, ou les conflits avec des fonctions provenant de\n bibliothèques.\n\n```scss\n.selecteur-1 {\n @extend .other-rule;\n @include clearfix();\n @include box-sizing(border-box);\n width: x-grid-unit(1);\n // other declarations\n}\n```\n\n\n\n## 5. Nommage\n\nVous n'êtes pas un compilateur/compresseur de code humain, alors ne prétendez\npas en être un.\n\nUtilisez des noms clairs et réfléchis pour les classes HTML. Choisissez un\nmodèle de nommage cohérent et compréhensif qui a du sens à la fois dans les\nfichiers HTML et dans les fichiers CSS.\n\n```css\n/* Exemple de code mal nommé */\n\n.s-scr {\n overflow: auto;\n}\n\n.cb {\n background: #000;\n}\n\n/* Exemple de code bien nommé */\n\n.is-scrollable {\n overflow: auto;\n}\n\n.column-body {\n background: #000;\n}\n```\n\n\n\n## 6. Exemple pratique\n\nUn exemple de divers conventions.\n\n```css\n/* ==========================================================================\n Construction de la grille\n ========================================================================== */\n\n/*\n * Exemple de code HTML:\n *\n * \n */\n\n.grid {\n overflow: visible;\n height: 100%;\n /* Évite d'entourer les cellules avec un inline-block */\n white-space: nowrap;\n /* Suppression des espaces entre les cellules */\n font-size: 0;\n}\n\n.cell {\n box-sizing: border-box;\n position: relative;\n overflow: hidden;\n width: 20%;\n height: 100%;\n /* Définition de l'espacement entre les cellules */\n padding: 0 10px;\n border: 2px solid #333;\n vertical-align: top;\n /* Réinitialisation de la gestion des espaces */\n white-space: normal;\n /* Réinitialisation de la taille de police */\n font-size: 16px;\n}\n\n/* Etats des cellules */\n\n.cell.is-animating {\n background-color: #fffdec;\n}\n\n/* Dimensions des cellules\n ========================================================================== */\n\n.cell-1 { width: 10%; }\n.cell-2 { width: 20%; }\n.cell-3 { width: 30%; }\n.cell-4 { width: 40%; }\n.cell-5 { width: 50%; }\n\n/* Styles de cellule\n ========================================================================== */\n\n.cell--detail,\n.cell--important {\n border-width: 4px;\n}\n```\n\n\n\n## 7. Organisation\n\nL'organisation du code est une partie importante de n'importe quelle base de\ncode CSS et devient cruciale pour les grosses bases de code.\n\n* Séparez de manière logique les différentes parties de code ;\n* Utilisez des fichiers distincts (concaténés au cours de l'étape de\n compilation) pour aider à découper le code en différents composants ;\n* Si vous utilisez un préprocesseur, stockez le code récurrent dans des\n variables pour la couleur, la typographie, etc.\n\n\n\n## 8. Compilation et déploiement\n\nLes projets devraient toujours essayer de mentionner des façons génériques\ngrâce auxquelles le code source peut être validé, testé, compressé et versionné\nen préparation à l'utilisation en production. Pour cela,\n[grunt](https://github.com/cowboy/grunt) de Ben Alman est un excellent outil.\n\n\n\n## Remerciements\n\nMerci à tous ceux qui ont contribué à\n[idiomatic.js](https://github.com/rwldrn/idiomatic.js). Cela a été une source\nd'inspiration, de citations et de conventions.\n"
},
{
"path": "translations/id-ID/README.md",
"content": "# Prinsip Penulisan CSS yang Konsisten, Idiomatic\n\nDokumen dibawah ini menjelaskan petunjuk umum dalam pengembangan CSS. Petunjuk\nini sangat mengutamakan penggunaan pola umum yang ada. Dan sebaiknya digunakan\ndalam Penulisan CSS sesuai kebutuhan anda.\n\nDokumen ini sedang digunakan oleh banyak orang, dan sangat terbuka dengan saran\nyang masuk. Silahkan berpartisipasi.\n\n\n## Daftar Isi\n\n1. [Prinsip Umum](#general-principles)\n2. [Whitespace](#whitespace)\n3. [Komentas](#comments)\n4. [Format](#format)\n5. [Contoh Penggunaan](#example)\n\n[Lisensi](#license)\n\n[Kontribusi & Saran](#contribute)\n\n\n\n## 1. Prinsip Umum\n\n> \"Salah satu bagian untuk menjadi staf yang baik dalam Proyek adalah memahami\n> bahwa menulis kode untuk diri sendiri adalah hal yang buruk. Jika ribuan\n> sedang menggunakan kode anda, maka tulislah kode anda dengan jelas dan\n> objektif, jangan menggunakan cara pribadi dalam memahami kode.\" - Idan\n> Gazit\n\n* Jangan mencoba menjadi manusia Compiler.\n* Semua kode harus tampak seperti ditulis oleh satu orang, walaupun ada banyak\n orang yang berpartisipasi.\n* Melaksanakan pola yang disepakati dengan ketat.\n* Jika ragu dengan pola tersebut, gunakan pola yang ada dan umum.\n\n\n\n## 2. Whitespace\n\nAnda disarankan menggunakan satu pola dalam seluruh kode. Harap konsisten\ndengan penggunaan whitespace pada kode. Gunakan Whitespace untuk memudahkan\npembacaan kode.\n\n* _Hindari_ membaurkan Spasi dan Tab untuk indentasi.\n* Pilih salah satu antara _Soft Indents_ (Spasi) atau Tab original. Yakinlah\n akan pilihan anda. (Disarankan: Spasi)\n* Jika menggunakan Spasi, pilih jumlah karakter yang digunakan ditiap\n indentasi. (Disarankan: 4 Spasi)\n\nTip: Setting Editor anda untuk mengaktifkan \"show invisibles\". Hal ini\nmeperbolehkan anda menghapus whitespace yang tidak diinginkan.\n\nTip: Gunakan File [EditorConfig](http://editorconfig.org) (atau yang sejenis)\nuntuk membantu pengaturan Whitespace yang anda gunakan pada kode anda.\n\n\n\n## 3. Komentar\n\nKode yang dikomentari dengan baik sangatlah penting. Sisihkan waktu untuk\nmenjelaskan komponen, bagaimana mereka bekerja, dan cara penggunaannya. Jangan\nmembiarkan staf di Tim anda untuk menduga-duga atau menebak-nebak karena kode\nyang kurang jelas.\n\nPola Komentar harus sederhana dan konsisten di setiap kode anda.\n\n* Tempatkan Komentar di atas subjeknya.\n* Tetapkan standar panjang karakter ditiap Komentar. Contoh: 80 Karakter\n* Anda bebas untuk menentukan Komentar sebagai pemecah kode CSS menjadi\n beberapa bagian.\n* Gunakan \"Sentence Case\" pada Komentar dan penggunaan indentasi yang konsisten\n\nTip: Buat snippet pada Editor anda sebagai shortcut untuk Komentar yang akan\nanda gunakan.\n\nContoh:\n```css\n/* ==========================================================================\n Blok Bagian\n ========================================================================== */\n\n/* Blok Sub-Bagian\n ========================================================================== */\n\n/**\n * Deskripsi Singkat menggunakan format Komentar Doxygen-style\n *\n * Kalimat pertama dari Deskripsi Detail dimulai di sini dan berlanjut di baris\n * selanjutnya hingga sampai kepada kesimpulan pada akhir paragraf.\n *\n * Deskripsi Detail sangat ideal untuk Penjelasan yang lebih lengkap dan\n * sebagai Dokumentasi. Disini anda dapat memasukkan contoh HTML, URL, atau\n * informas-informasi lain yang berguna untuk penjelasan.\n *\n * @tag Tag ini dinamakan 'tag'\n *\n * @todo Ini adalah Statemen Todo yang mendeskripsikan tugas-tugas yang harus\n * anda selesaikan di waktu yang akan datang. Bagian ini memilik panjang\n * maksimal 80 karakter dan baris dibawahnya di indentasi menggunakan 2 spasi\n */\n\n/* Komentar standar */\n```\n\n\n\n## 4. Format\n\nFormat kode yang anda gunakan harus memastikan bahwa kode tersebut: mudah\ndibaca; mudah di-Komentari; meminimalkan kemungkinan kesalahan penggunaan;\ndan menghasil _diff_ dan _blame_ yang berguna.\n\n* Gunakan satu baris per selector, dalam deklarasi rule multi-selector.\n* Masukkan satu Spasi sebelum Buka Kurung dalam deklarasi rule.\n* Gunakan deklarasi per baris dalam blok deklarasi.\n* Gunakan satu level indentasi di tiap blok deklarasi.\n* Masukkan satu Spasi setelah tanda Titik Koma dalam deklarasi.\n* Gunakan _lowercase_ untuk Short Nilai Hex. Contoh: `#aaa`.\n* Gunakan salah satu dari tanda Kutip Satu atau Kutip Dua secara konsisten.\n Disarankan Tanda Kutip Dua. Contoh: `content: \"\"`.\n* Gunakan tanda kutip pada Nilai dari Attribute Selector. Contoh:\n `input[type=\"checkbox\"]`.\n* _Jika Memungkinkan_ hindari memberi satuan unit pada Nilai Nol. Contoh:\n `margin: 0`.\n* Masukkan satu Spasi setelah Koma dalam Comma-Separated properti atau nilai\n function.\n* Tetap ikutkan Titik Koma setelah deklarasi properti akhir di dalam blok\n deklarasi.\n* Tempatkan tanda Tutup Kurung `}` pada blok deklarasi sesuai dengan posisi\n kolom tanda Buka Kurung `{`.\n* Pisahkan tiap blok deklarasi dengan Baris Kosong.\n\n```css\n.selector-1,\n.selector-2,\n.selector-3[type=\"text\"] {\n -webkit-box-sizing: border-box;\n -moz-box-sizing: border-box;\n box-sizing: border-box;\n display: block;\n font-family: helvetica, arial, sans-serif;\n color: #333;\n background: #fff;\n background: linear-gradient(#fff, rgba(0, 0, 0, 0.8));\n}\n\n.selector-a,\n.selector-b {\n padding: 10px;\n}\n```\n\n#### Urutan Deklarasi\n\nJika anda mengurutkan deklarasi properti, maka anda harus menggunakan aturan\nsederhana. Saran saya anda harus mendahulukan properti yang lebih penting\nseperti Positioning, Box Model.\n\n```css\n.selector {\n /* Positioning */\n position: absolute;\n z-index: 10;\n top: 0;\n right: 0;\n bottom: 0;\n left: 0;\n\n /* Display & Box Model */\n display: inline-block;\n overflow: hidden;\n box-sizing: border-box;\n width: 100px;\n height: 100px;\n padding: 10px;\n border: 10px solid #333;\n margin: 10px;\n\n /* Other */\n background: #000;\n color: #fff;\n font-family: sans-serif;\n font-size: 16px;\n text-align: right;\n}\n```\n\nPengurutan propery berdasarkan Huruf juga cukup populer, tetapi kekurangannya\nadalah dia memisahkan properti yang berhubungan. Contoh properti pendukung\ndari position tidak lagi dikelompokkan bersama-sama dan akan menyebar di\nseluruh blok deklarasi.\n\n#### Pengecualian\n\nBlok panjang dari deklarasi tunggal dapat ditulis secara berbeda, format satu\nbaris. Dalam kasus ini, satu Spasi dimasukkan setelah tanda Buka Kurung `{` dan\nsebelum tanda Tutup Kurung `}`.\n\n```css\n.selector-1 { width: 10%; }\n.selector-2 { width: 20%; }\n.selector-3 { width: 30%; }\n```\n\nNilai yang cukup panjang, Comma-separated seperti Nilai font-family, gradient,\ndan box shadow dapat ditulis dengan memisahkan per baris dengan tujuan\nmemudahkan cara pembacaan dan menghasilkan diff yang berkualitas. Banyak format\nyang dapat digunakan, berikut adalah salah satu contoh.\n\n```css\n.selector {\n background-image:\n linear-gradient(#fff, #ccc),\n linear-gradient(#f3c, #4ec);\n box-shadow:\n 1px 1px 1px #000,\n 2px 2px 1px 1px #ccc inset;\n}\n```\n\n### Preprocessor: Tambahan Pertimbangan Format\n\nCSS Preprocessor Berbeda juga mempunyai fitur, fungsi, dan syntax yang berbeda.\nAturan pola kode anda harus memadai dan cocok di tiap CSS Preprocessor.\nPetunjuk di bawah ini di adaptasi dari petunjuk SASS.\n\n* Batasi sarang _(nesting)_ satu level lebih dalam. Deklarasi kan deklarasi\n blok yang melebihi dua level sarang. Hal ini mencegah selector menjadi\n terlalu spesifik.\n* Hindari menggunakan deklarasi rule bersarang yang berlebihan. Pisahkan\n secepatnya ketika sudah mulai mengurangi tingkat kemudahan pembacaan kode.\n Saran, hindari menggunakan deklarasi rule bersarang jika rulenya melebihi dari\n 20 baris.\n* Selalu tempatkan statemen `@extend` pada baris pertama dari blok deklarasi.\n* Jika memungkinkan, tempatkan `@include` statemen pada baris awal setelah\n `@extend` statemen.\n* Pertimbangkan menggunakan prefix `x-` atau prefix lainnya jika menggunakan\n fungsi buatan. Hal ini membantu menghindari kebingungan menggunakan fungsi\n asli dari CSS atau konflik dengan fungsi dari librari yang anda gunakan.\n\n```scss\n.selector-1 {\n @extend .other-rule;\n @include clearfix();\n @include box-sizing(border-box);\n width: x-grid-unit(1);\n // other declarations\n}\n```\n\n\n\n## 5. Contoh Penggunaan\n\nSebuah contoh dari aturan kode yang beragam.\n\n```css\n/* ==========================================================================\n Grid layout\n ========================================================================== */\n\n/**\n * Column layout dengan horizontal scroll.\n *\n * Ini membuat satu baris full-height, non-wrap kolom yang bisa digunakan\n * horizontal dengan parent mereka.\n *\n * Contoh HTML:\n *\n * \n */\n\n/**\n * Grid container\n * Harus diisi oleh `.cell`\n */\n\n.grid {\n height: 100%;\n /* Hilangkan inter-cell whitespace */\n font-size: 0;\n /* Cegah wrapping inline-block */\n white-space: nowrap;\n}\n\n/**\n * Grid cells\n * Tidak ada spesifik width secara default. Extend dengan `.cell-n` class\n */\n\n.cell {\n position: relative;\n display: inline-block;\n overflow: hidden;\n box-sizing: border-box;\n height: 100%;\n /* Set inter-cell spasi */\n padding: 0 10px;\n border: 2px solid #333;\n vertical-align: top;\n /* Reset white-space */\n white-space: normal;\n /* Reset font-size */\n font-size: 16px;\n}\n\n/* Cell states */\n\n.cell.is-animating {\n background-color: #fffdec;\n}\n\n/* Dimensi Cell\n ========================================================================== */\n\n.cell-1 { width: 10%; }\n.cell-2 { width: 20%; }\n.cell-3 { width: 30%; }\n.cell-4 { width: 40%; }\n.cell-5 { width: 50%; }\n\n/* Cell Pengubah\n ========================================================================== */\n\n.cell--detail,\n.cell--important {\n border-width: 4px;\n}\n```\n\n\n\n## Lisensi\n\n_Principles of writing consistent, idiomatic CSS_ oleh Nicolas Gallagher\ndirilis dengan lisensi [Creative Commons Attribution 3.0 Unported\nLicense](http://creativecommons.org/licenses/by/3.0/). Lisensi ini berlaku\nuntuk semua dokumen dan terjemahan di repository.\n\nDibuat berdasarkan proyek di\n[github.com/necolas/idiomatic-css](https://github.com/necolas/idiomatic-css).\n\n\n\n## Kontribusi & Saran\n\nJika anda ingin berpartisipasi dalam Proyek Penerjemahan ini, silahkan fork\n[Idiomatic](http://github.com/novrian/idiomatic_id-ID).\n"
},
{
"path": "translations/it-IT/README.md",
"content": "# Princìpi per la scrittura di CSS consistente ed idiomatico\n\nL'intento di questo documento è quello di esporre una ragionevole guida allo\nstile per lo sviluppo del CSS. Queste linee guida incoraggiano al riutilizzo di\npattern già esistenti ed ampiamente testati dalla comunità. Si dovrebbe\ncercare, infine, di adattare questi pattern alle proprie necessità in modo da\ncreare proprie regole ed un proprio stile.\n\nQuesto è un documento in continua evoluzione e nuove idee sono sempre bene\naccette. Per favore contribuite.\n\n[Leggi la versione originale in inglese](https://github.com/necolas/idiomatic-css)\n\n\n## Tavola dei contenuti\n\n1. [Princìpi generali](#general-principles)\n2. [Spazio vuoto](#whitespace)\n3. [Commenti](#comments)\n4. [Formato](#format)\n5. [Esempio pratico](#example)\n\n[Ringraziamenti](#acknowledgments)\n\n[Licenza](#license)\n\n\n\n## 1. Princìpi generali\n\n> \"Parte dell'essere un buon amministratore in un progetto votato al successo è\n> capire che la scrittura di codice per sé stessi è una Cattiva Idea™. Se\n> migliaia di persone usano il tuo codice, allora scrivi il tuo codice in modo\n> che abbia la massima chiarezza, e non seguendo i tuoi gusti personali su come\n> renderlo chiaro all'interno delle specifiche\" - Idan Gazit\n\n* Non cercare di ottimizzare in anticipo il tuo codice; cerca di mantenerlo\n leggibile e comprensibile.\n* Tutto il codice, in qualsiasi linguaggio sia, dovrebbe sembrare come scritto\n da un'unica persona, anche quando molte persone vi stanno contribuendo.\n* Rispettate al massimo lo stile prescelto.\n* Nel dubbio, usate pattern comuni già esistenti e collaudati.\n\n\n\n# 2. Spazio vuoto\n\nDovrebbe esistere solo uno stile in tutto il sorgente del vostro progetto.\nSiate sempre consistenti nell'uso dello spazio vuoto. Usate questo spazio per\nmigliorare la leggibilità.\n\n* _Mai_ mischiare spazi e tabulazioni per i rientri.\n* Scegliete tra rientri soft (spazi) o tabulazioni reali. Mantenete quella\n scelta (preferenza: spazi).\n* Se usate gli spazi, scegliete il numero di caratteri usati per il livello di\n rientro (preferenza: 4 spazi).\n\nSuggerimento: configurate il vostro editor in modo da \"visualizzare i caratteri\ninvisibili\" o rimuovere automaticamente gli spazio vuoti a fine linea.\n\nSuggerimento: usate un file [EditorConfig](http://editorconfig.org/) (o\nequivalente) per aiutarvi a mantenere le convenzioni di base relative allo\nspazio vuoto che si è scelto di usare per il vostro codice.\n\n\n\n## 3. Commenti\n\nUn codice ben commentato è estremamente importante. Prendetevi il tempo\nnecessario per descrivere i vari componenti, come funzionano, i loro limiti, ed\nil modo in cui sono stati costruiti. Non create una situazione nella quale\naltri membri del vostro team debbano cercare di immaginare il motivo ed il\nfunzionamento di codice non comune o poco chiaro.\n\nLo stile di un commento dovrebbe essere semplice e consistente all'interno di\nuna singola base di codice.\n\n* Mettete i commenti su di una nuova linea che preceda il relativo soggetto.\n* Mantenete una lunghezza massima per le linee, es. 80 colonne.\n* Fate libero uso di commenti per spezzare il codice CSS in sezioni logiche più\n piccole.\n* Fate un uso corretto e consistente della grammatica, delle maiuscole e dei\n rientri.\n\nSuggerimento: configurate il vostro editor in modo che vi fornisca delle\nscorciatoie per la gestione di pattern predefiniti per i commenti.\n\nEsempio:\n\n```css\n/* ==========================================================================\n Sezione blocco commento\n ========================================================================== */\n\n/* Sotto sezione blocco commento\n ========================================================================== */\n\n/**\n * Breve descrizione utilizzando un formato nei commenti in stile Doxygen\n *\n * La prima frase di una lunga descrizione inizia qui e continua su questa\n * linea per un po' fino alla sua conclusione qui alla fine di questo paragrafo.\n *\n * Una lunga descrizione è ideale per una più dettagliata spiegazione e\n * documentazione. Essa può includere esempi in HTML, URL o qualsiasi altra\n * informazione che riteniate importante o utile.\n *\n * @tag Questo è un 'tag'\n *\n * TODO: Questa è una dichiarazione 'todo' che descrive un'attività necessaria\n * che dovrà essere completata in un momento successivo. Essa va a capo dopo\n * 80 caratteri e le linee successive vengono rientrare di 2 spazi.\n */\n\n/* Commento base */\n```\n\n\n\n## 4. Formato\n\nIl formato scelto deve far sì che il codice: sia facile da leggere; sia facile\nda commentare in modo chiaro; minimizzi la possibilità di introdurre\naccidentalmente errori; dia risultati utili nei diff e blame.\n\n* Un solo selettore per linea in set di regole con più selettori.\n* Un singolo spazio prima della parentesi graffa di apertura di un set di\n regole.\n* Una dichiarazione per linea in un blocco dichiarativo.\n* Un livello di rientro per ogni dichiarazione.\n* Un singolo spazio dopo i due-punti di una dichiarazione.\n* Usate valori esadecimali in minuscolo ed in forma abbreviata, es. `#aaa`.\n* Usate apici e doppi apici in modo uniforme. La preferenza è per i doppi\n apici, es. `content: \"\"`.\n* Racchiudete in doppi apici i valori nei selettori, es.\n `input[type=\"checkbox\"]`.\n* _Dove possibile_, evitate di specificare l'unità di misura per valori uguali\n a zero, es. `margin: 0`.\n* Includete uno spazio dopo ogni virgola, per le liste di proprietà separate da\n virgola o per i valori nelle funzioni.\n* Includete un punto-e-virgola alla fine dell'ultima dichiarazione in un blocco\n dichiarativo.\n* Mettete la parentesi graffa di chiusura di un set di regole, nella stessa\n colonna del primo carattere del set di regole.\n* Separate ogni set di regole con una linea vuota.\n\n```css\n.selector-1,\n.selector-2,\n.selector-3[type=\"text\"] {\n -webkit-box-sizing: border-box;\n -moz-box-sizing: border-box;\n box-sizing: border-box;\n display: block;\n font-family: helvetica, arial, sans-serif;\n color: #333;\n background: #fff;\n background: linear-gradient(#fff, rgba(0, 0, 0, 0.8));\n}\n\n.selector-a,\n.selector-b {\n padding: 10px;\n}\n```\n\n#### Ordine di dichiarazione\n\nSe le dichiarazioni devono essere ordinate in modo logico, esse dovrebbero\nseguire un semplice ed unico criterio.\n\nI piccoli team potrebbero preferire il raggruppamento delle proprietà (es.\nposizionamento e box-model) per categoria.\n\n```css\n.selector {\n /* Posizionamento */\n position: relative;\n z-index: 10;\n top: 0;\n right: 0;\n bottom: 0;\n left: 0;\n\n /* Visualizzazione e box-model */\n display: inline-block;\n overflow: hidden;\n box-sizing: border-box;\n width: 100px;\n height: 100px;\n padding: 10px;\n border: 10px solid #333;\n margin: 10px;\n\n /* Altro */\n background: #000;\n color: #fff;\n font-family: sans-serif;\n font-size: 16px;\n text-align: right;\n}\n```\n\nI grossi team potrebbero preferire la semplicità e facilità di manutenzione che\nderiva dall'ordinamento alfabetico.\n\n\n#### Eccezioni e piccole deviazioni\n\nGrossi blocchi di dichiarazioni di una sola linea, possono usare un formato\nleggermente differente, a linea singola. In questo caso, uno spazio dovrebbe\nessere messo dopo la parentesi graffa di apertura e prima di quella di\nchiusura.\n\n```css\n.selector-1 { width: 10%; }\n.selector-2 { width: 20%; }\n.selector-3 { width: 30%; }\n```\n\nLunghe liste di valori di proprietà separate da virgole - come una collezione\ndi sfumature od ombre - possono essere suddivisi su più linee nel tentativo di\nmigliorarne la leggibilità e produrre diff più utili. Ci sono vari formati che\npotrebbero essere usati; di seguito ne viene mostrato un esempio.\n\n```css\n.selector {\n background-image:\n linear-gradient(#fff, #ccc),\n linear-gradient(#f3c, #4ec);\n box-shadow:\n 1px 1px 1px #000,\n 2px 2px 1px 1px #ccc inset;\n}\n```\n\n### Preprocessori: ulteriori considerazioni sul formato\n\nOgni preprocessore per CSS ha le sue caratteristiche, funzionalità e sintassi.\nLe vostre convenzioni dovrebbero adattarsi per venire in contro alle\nparticolarità del preprocessore in uso. Quelle che seguono sono le linee guida\nprendendo come riferimento Sass.\n\n* Limitate la nidificazione ad 1 livello di profondità. Riarrangiate ogni\n nidificazione con 2 o più livelli di profondità. Questo previene la creazione\n di selettori CSS inutilmente troppo specifici.\n* Evitate un numero elevato di regole nidificate. Spezzatele in blocchi logici\n più piccoli quando cominciate a rendervi conto che la leggibilità inizia a\n risentirne. Preferite di evitare nidificazioni che siano più lunghe di 20\n linee.\n* Come prima cosa in un blocco dichiarativo, mettete sempre le dichiarazioni\n `@extend`.\n* Dove possibile, raggruppate le dichiarazioni `@include` all'inizio di un\n blocco dichiarativo, subito dopo le dichiarazioni `@extend`.\n* Considerate l'idea di anteporre una `x-` o un altro namespace alle funzioni\n personalizzate. Questo vi aiuterà ad evitare ogni potenziale errore dato\n dalla confusione della vostra funzione con una funzione nativa del CSS o di\n altre librerie.\n\n```scss\n.selector-1 {\n @extend .other-rule;\n @include clearfix();\n @include box-sizing(border-box);\n width: x-grid-unit(1);\n // altre dichiarazioni\n}\n```\n\n\n\n## 5. Esempio pratico\n\nUn esempio di varie convenzioni.\n\n```css\n/* ==========================================================================\n Layout a griglia\n ========================================================================== */\n\n/**\n * Layout a griglia con scroll orizzontale.\n *\n * Questo crea una singola riga di colonne, a piena altezza e che non vanno\n * a capo, che può essere navigata orizzontalmente all'interno del suo\n * contenitore.\n *\n * Esempio HTML:\n *\n * \n */\n\n/**\n * Contenitore griglia\n *\n * Deve contenere solo figli `.cell`.\n *\n * 1. Rimuove lo spazio tra le celle\n * 2. Previene che le celle inline-block vadano a capo\n */\n\n.grid {\n height: 100%;\n font-size: 0; /* 1 */\n white-space: nowrap; /* 2 */\n}\n\n/**\n * Celle della griglia\n *\n * Di default, nessuna larghezza esplicita. Estendible con le classi `.cell-n`.\n *\n * 1. Imposta la spaziatura tra le celle\n * 2. Ripristina il white-space ereditato da `.grid`\n * 3. Ripristina la dimensione del font ereditata da `.grid`\n */\n\n.cell {\n position: relative;\n display: inline-block;\n overflow: hidden;\n box-sizing: border-box;\n height: 100%;\n padding: 0 10px; /* 1 */\n border: 2px solid #333;\n vertical-align: top;\n white-space: normal; /* 2 */\n font-size: 16px; /* 3 */\n}\n\n/* Stati delle celle */\n\n.cell.is-animating {\n background-color: #fffdec;\n}\n\n/* Larghezza delle celle\n ========================================================================== */\n\n.cell-1 { width: 10%; }\n.cell-2 { width: 20%; }\n.cell-3 { width: 30%; }\n.cell-4 { width: 40%; }\n.cell-5 { width: 50%; }\n\n/* Modificatori di cella\n ========================================================================== */\n\n.cell--detail,\n.cell--important {\n border-width: 4px;\n}\n```\n\n\n\n## Ringraziamenti\n\nGrazie a tutti coloro che hanno fornito le traduzioni e contribuito a\n[idiomatic.js](https://github.com/rwldrn/idiomatic.js). È stato una fonte di\nispirazione, citazioni e linee guida.\n\n\n\n## Licenza\n\n_Princìpi per la scrittura di CSS consistente ed idiomatico_ di Nicolas\nGallagher è rilasciata sotto la [Creative Commons Attribution 3.0 Unported\nLicense](http://creativecommons.org/licenses/by/3.0/), che viene applicata\nanche a tutti i documenti e traduzioni contenuti in questo repository.\n\nLavoro basato su\n[github.com/necolas/idiomatic-css](https://github.com/necolas/idiomatic-css).\n"
},
{
"path": "translations/ja-JP/README.md",
"content": "# 一貫性のあるCSSらしいCSSを書くための原則\n\n以下の文書はCSS開発のための合理的なスタイルガイドの骨子です。\n規範になるべきものではないし、私自身のスタイルの好みを他者のコードに押し付けるつもりは一切ありません。しかし、これらのガイドラインは現存する一般的で分別のあるパターンを利用することを推奨します。\n\nこのドキュメントは常に変わっていくものなので、新しいアイデアを常に求めています。ぜひアイデア等を投稿してください。\n\n[一貫性のあるCSSらしいCSSを書くための原則の英語版はこちらから](https://github.com/necolas/idiomatic-css/)\n\n## 目次\n\n1. [一般原則](#general-principles)\n2. [ホワイトスペース(余白)](#whitespace)\n3. [コメント](#comments)\n4. [フォーマット](#format)\n5. [命名規則](#naming)\n6. [実例](#example)\n7. [編成](#organization)\n8. [ビルドとデプロイ](#build-and-deployment)\n\n[謝辞](#acknowledgements)\n\n\n\n## 1. 一般原則\n\n> \"成功を収めるプロジェクトをうまく管理することの一つが自分でコードを書いて実現する\n> ということではない。もし多くの人があなたのコードを利用しているなら、仕様の\n> 中にはあなたの好みではなく、最大限に明確なコードを書くべきである。\" - Idan Gazit\n\n* どんなに多くの人が貢献したとしても、どのコードも一人で書いたようにする。\n* 同意の上のでのスタイルを厳格に守る。\n* もし悩むようであれば常に現存する共通のパターンを利用する。\n\n\n\n## 2. ホワイトスペース(余白)\n\nプロジェクト内全てのソースコードで1つのスタイルのみを利用すること。ホワイトスペース(余白)は常に一貫性を保つこと。そしてホワイトスペース(余白)を可読性を向上するために利用すること。\n\n* インデントにはタブ、スペースを**絶対に**混在させないこと\n* ソフトインデント(スペース)かタブのどちらかを選び、その選択を途中で変更しないこと(スペースを優先)\n* もしスペースを利用する場合にインデントに利用する文字数を決めること (4スペースを優先)\n\nヒント: 利用しているエディタにて“隠しキャラクターの表示”が出来る様に設定すること。これで行の最後のホワイトスペースを削除し、意図的ではない空行を削除し、無駄なコミットを避ける。\n\n\n\n## 3. コメント\n\nソースコード上の詳細なコメントは非常に重要です。コンポーネントがどのように動作するのか、どんな制約があるのか、そしてどんな構成になっているかを説明すること。チーム内の他のメンバーが一般的でなく、明確でもないコードの目的を推測させることがないようにしてください。\n\nコメントのスタイルはシンプルでかつソースコードベースの中で一貫性を保っている必要があります。\n\n* コメントは対象になるコンポーネントの上の行に配置すること。\n* コメントを宣言文の後に追加しないこと。\n* 折り返し行は分別のある最大行以内におさめること。例: 80文字\n* コメントを使ってCSSのコードを別々のセクションに分解すること。\n* コメントの文頭を大文字にし、テキストインデントに一貫性を持たせること。\n\nヒント: エディタの設定でショートカットなどを用いて承諾済みのコメントパターンを出力できるようにしておく。\n\n#### CSSの例:\n\n```css\n/* ==========================================================================\n セクションコメントブロック\n ========================================================================== */\n\n/* サブ・セクションコメントブロック\n ========================================================================== */\n\n/*\n * グループコメントブロック\n * 複数行になるドキュメントや説明の際に最適\n */\n\n/* 基本コメント */\n```\n\n#### SCSSの例:\n\n```scss\n// ==========================================================================\n// セクションコメントブロック\n// ==========================================================================\n\n// サブ・セクションコメントブロック\n// ==========================================================================\n\n//\n// グループコメントブロック\n// 複数行になるドキュメントや説明の際に最適\n//\n\n// 基本コメント\n```\n\n\n\n## 4. フォーマット\n\n選択したコードフォーマットはコードが: 読みやすく、コメントが明確で、意図しないエラーを最低限に防ぎ、かつdiffやblameなどのコマンドの利点が活かせる形であること。\n\n1. 複数セレクタを持つルールセットの場合、セレクタを1行ずつ記述すること。\n2. ルールセットの開き中カッコの前に1スペースを入れること。\n3. 宣言ブロックないでは宣言を1行ずつ記述すること。\n4. 各宣言で1レベルのインデントを行うこと。\n5. 宣言文のコロンの後にに1スペースを入れること。\n6. 宣言ブロック内の最後の宣言文には常にセミコロンを追加すること。\n7. ルールセットの閉じ中括弧はルールセット内の1番始めの文字の位置に合わせること。\n8. ルールセットは空行で分けること。\n\n```css\n.selector-1,\n.selector-2,\n.selector-3 {\n -webkit-box-sizing: border-box;\n -moz-box-sizing: border-box;\n box-sizing: border-box;\n display: block;\n color: #333;\n background: #fff;\n}\n```\n\n#### 宣言順\n\n宣言の順番は1つの原則に従って並べること。私の場合は関連するプロパティ同士でグループ化し、構造的に重要なプロパティ(例: ポジションやボックスモデル)はタイポグラフィー、バックグランド、カラーのプロパティよりも前に宣言するようにしている。\n\n```css\n.selector {\n position: relative;\n display: block;\n width: 50%;\n height: 100px;\n padding: 10px;\n border: 0;\n margin: 10px;\n color: #fff\n background: #000;\n}\n```\n\nアルファベット順もよく使われるが欠点は関連するプロパティ同士を分断してしまう点。例えば、ポジションのオフセットをグループ化できないし、ボックスモデルのプロパティは宣言ブロック内でバラバラに宣言されることになってしまいます。\n\n#### 例外と少しの偏差\n\n1行の宣言が数多くある場合、これまでと異なる1行フォーマットを利用することも可能です。この場合、中カッコの内側両端に1つのスペースを入れること。\n\n```css\n.selector-1 { width: 10%; }\n.selector-2 { width: 20%; }\n.selector-3 { width: 30%; }\n```\n\nグラデーションやシャドウなどの長く、コンマで分割できるプロパティ値を持つ場合、diffをより有効活用するために複数ラインを利用しても構いません。様々なフォーマットが考えられますが、以下はその内の1つです。\n\n```css\n.selector {\n box-shadow:\n 1px 1px 1px #000,\n 2px 2px 1px 1px #ccc inset;\n background-image:\n linear-gradient(#fff, #ccc),\n linear-gradient(#f3c, #4ec);\n}\n```\n\n#### その他\n\n* hex値は小文字を利用すること。例: `#aaa`\n* シングル、ダブルクォートには一貫性を持つこと。推奨はダブルクォートです。例: `content: \"\"`\n* セレクタ内の属性値は常にクォートで囲むこと。例: `input[type=\"checkbox\"]`\n* **可能な場合**にはゼロになる値に対して単位指定を行わないこと。例: `margin: 0`\n\n### プリプロセッサ: 追加フォーマット\n\nCSSプリプロセッサの特性、機能、シンタックスはツールによって全く異なります。規則は利用しているプリプロセッサの特性に併せて拡張してください。\n以下のガイドラインはSassを対象としたものになります。\n\n* 入れ子は1レベルに止めること。2レベル以上の入れ子構造になる場合は再度コードを見直すこと。これによりCSSのセレクタが必要以上に詳細になるのを防ぎます。\n* 入れ子ルールを数多く利用しないこと。読みやすさに影響を与え始めるようであれば分割すること。入れ子ルール内に20以上のルールセットを置かないことを推奨します。\n* `@extend`文は宣言ブロック内の1番上に記述すること。\n* 可能な限り`@include`を宣言ブロック内、`@extend`の下にグループ化すること\n* ネイティブCSSの機能とカスタムした機能との違いの混乱を避け、ライブラリからの関数との衝突を避けるためにカスタム関数に`x-`のようなプリフィックスを利用するか他のネームスペースをつけるようにすること。\n\n```scss\n.selector-1 {\n @extend .other-rule;\n @include clearfix();\n @include box-sizing(border-box);\n width: x-grid-unit(1);\n // other declarations\n}\n```\n\n\n\n## 5. 命名規則\n\n我々は人間コードコンパイラ、コンプレッサではないので、そのように振る舞う必要はありません。\n\nHTMLのクラスは明確で熟慮された名前を使用すること。HTMLファイル、CSSファイル内の両方で理解しやすく、一貫性のある命名パターンを選ぶこと。\n\n```css\n/* 悪い命名規則の例 */\n\n.s-scr {\n overflow: auto;\n}\n\n.cb {\n background: #000;\n}\n\n/* よりよい命名規則の例 */\n\n.is-scrollable {\n overflow: auto;\n}\n\n.column-body {\n background: #000;\n}\n```\n\n\n\n## 6. 実例\n\n様々な規則の例\n\n```css\n/* ==========================================================================\n グリッドレイアウト\n ========================================================================== */\n\n/*\n * HTML例:\n *\n * \n */\n\n.grid {\n overflow: visible;\n height: 100%;\n /* Prevent inline-block cells wrapping */\n white-space: nowrap;\n /* Remove inter-cell whitespace */\n font-size: 0;\n}\n\n.cell {\n box-sizing: border-box;\n position: relative;\n overflow: hidden;\n width: 20%;\n height: 100%;\n /* Set the inter-cell spacing */\n padding: 0 10px;\n border: 2px solid #333;\n vertical-align: top;\n /* Reset white-space */\n white-space: normal;\n /* Reset font-size */\n font-size: 16px;\n}\n\n/* Cellの状態 */\n\n.cell.is-animating {\n background-color: #fffdec;\n}\n\n/* Cellのサイズ\n ========================================================================== */\n\n.cell-1 { width: 10%; }\n.cell-2 { width: 20%; }\n.cell-3 { width: 30%; }\n.cell-4 { width: 40%; }\n.cell-5 { width: 50%; }\n\n/* Cellの修飾因子\n ========================================================================== */\n\n.cell--detail,\n.cell--important {\n border-width: 4px;\n}\n```\n\n\n\n## 7. 編成\n\nソースコードの編成はどんなCSSコード内でも重要なパートになり、また巨大なコードベースの場合はさらに重要になります。\n\n* ソースコードは論理的にはっきり異なることがわかるように分割すること\n* コンポーネントの明白さを強めるために別ファイルにすること(ビルドステップで連結すること)\n* プリプロセッサを利用している場合、共通なコード、タイポグラフィー、色などを変数にしておくこと\n\n\n\n## 8. ビルドとデプロイ\n\nプロジェクトは常にソースコードの文法チェック、テスト、圧縮、プロダクションへの準備のためのバージョンコントロールの手法を持つべきです。\nこれらのタスクにはBen Alman氏による[grunt](https://github.com/cowboy/grunt)が優れたツールです。\n\n\n\n## 謝辞\n\n[idiomatic.js](https://github.com/rwldrn/idiomatic.js)に貢献した皆さんに感謝します。idoomatic.jsはインスピレーションであり、引用もし、ガイドラインとしても活用しました。\n"
},
{
"path": "translations/ko-KR/README.md",
"content": "# 일관성있는 CSS다운 CSS를 작성하기 위한 원칙\n\n이하 문서는 CSS개발을 위한 합리적인 스타일가이드의 중요한 내용입니다.\n규범이 될만한 것이라 하긴 좀 그렇고 스스로 스타일 작업시 즐겨쓰는 방식을 다른분들께 꼭 이렇게 해야 한다고 말하려는 의도는 전혀 없습니다. 단, 이런 가이드라인은 현존하는 일반적이며 분별력있는 페턴을 이용하는 것을 추천합니다.\n\n이 문서는 계속 변경해 나갈 예정이므로 새로운 아이디어를 계속해서 추가해 나갈 생각입니다. 많은 아이디어들을 주시면 고맙겠습니다.\n\n[일관성있는 CSS다운 CSS를 작성하기 위한 원칙](https://github.com/necolas/idiomatic-css/)\n\n\n## 목차\n\n1. [일반원칙](#general-principles)\n2. [화이트스페이스(여백)](#whitespace)\n3. [커맨트(주석)](#comments)\n4. [포멧](#format)\n5. [명명규칙](#naming)\n6. [실례](#example)\n7. [편성](#organization)\n8. [빌드와 디플로이](#build-and-deployment)\n\n[감사의 말](#acknowledgements)\n\n\n\n## 1. 일반규칙\n\n> \"성공을 거둔 프로젝트를 잘 관리하는 한 방법은 스스로 코드를 작성하여 실행해 보는것이다.\n> 라고 말하는건 아니다. 혹시 많은 사람들이 당신의 코드를 이용하고 있다면, 사양은\n> 당신의 취향이 아닌, 최대한 명확한 코드를 사용해야 한다.\" - Idan Gazit\n\n* 아무리 많은 사람들이 참여했다고 하더라도, 코드는 한사람이 작성한 것처럼 보여야 한다.\n* 동의하에 스타일을 엄격하게 지킨다.\n* 혹시 고민하게 될 경우에는 현존하는 공통의 페턴을 이용한다.\n\n\n\n## 2. 화이트스페이스(여백)\n\n프로젝트의 모든 소스코드에 한개의 스타일만을 사용할것. 화이트스페이스(여백)은 늘 일관성을 갖어야 한다. 그리고 화이트스페이스(여백)을 가독성을 향상시키기 위해서 이용해야 한다.\n\n* 들여쓰기는 텝, 스페이스를 **절대로** 섞어서 사용해서는 안된다.\n* 들여쓰기는 스페이스로 할지 아니면 텝으로 할지를 결정하고, 도중에 변경해서는 안된다.(스페이스 선호)\n* 만약 스페이스를 이용하는 경우에 들여쓰기에 이용하는 문자수를 결정할 것.(4 스페이스 선호)\n\n힌트: 이용하고 있는 에디터에 숨김문자표시기능을 활성화 해두자. 이걸로 행의 마지막에 스페이스를 삭제한다던가 불필요한 공백을 삭제하여 불필요한 커밋을 피할 수 있다.\n\n\n\n## 3. 커맨트(주석)\n\n소스코드에 상세한 주석은 비상시에 중요하다. 컴포넌트가 어떤식으로 동작하는 건지, 어떤 제약이 있는지, 어떤 구성을 갖고 있는지를 설명할 수 있기 때문이다. 팀 내에서 다른 맴버가 일반적이지 않고 명확하지도 않은 코드를 추측하게끔 하는 일은 만들어서는 안된다.\n\n주석의 스타일은 간단하고 소스코드안에서 일관성을 갖고 있을 필요가 있다.\n\n* 주석은 대상이 되는 컴포넌트의 상단에 배치한다.\n* 주석은 선언문의 뒤에 추가하지 않도록 한다.\n* 행바꿈 折り返し行は分別のある最大行以内におさめること。例: 80文字\n* 주석을 사용해서 CSS 코드를 따로따로 구분하기.\n* 주석의 맨 앞자는 대문자로 하고 텍스트의 들여넣기는 일관성을 갖도록 한다.\n\n힌트: 에디터의 설정에 스닙펫기능을 활용해서 정해진 주석페턴을 등록해놓고 사용하도록 한자.\n\n#### CSS의 예:\n\n```css\n/* ==========================================================================\n 섹션 블럭\n ========================================================================== */\n\n/* 서브 섹션 블럭\n ========================================================================== */\n\n/*\n * 그룹 블럭\n * 여러행을 포함하고 있는 문서나 설명을 적을때 사용한다.\n */\n\n/* 기본 주석 */\n```\n\n#### SCSS의 예:\n\n```scss\n// ==========================================================================\n// 색션 블럭\n// ==========================================================================\n\n// 서브 섹션 블럭\n// ==========================================================================\n\n//\n// 그룹 블럭\n// 여러행을 포함하고 있는 문서나 설명을 적을때 사용한다.\n//\n\n// 기본 주석\n```\n\n\n\n## 4. 포멧\n\n선택한 코드 포멧은 코드가 해독이 쉬운지, 주석이 명확한지, 예상치 못한 에러를 최대한 방지하고 있는지, 그리고 diff,blame과 같은 커멘드의 이점을 잘 활용하는 형태여야 한다.\n\n1. 복수셀렉터를 갖고있는 룰셋의 경우, 셀러터를 한줄씩 기술할것.\n2. 룰셋에서 맨 처음 괄호의 앞에 스페이스 한개를 둘것.\n3. 선언 블럭 안에서는 선언을 한줄씩 기술할것.\n4. 각 선언에 1레벨의 들여쓰기를 할것.\n5. 선언문의 콜론뒤에 스페이스 한개를 둘것.\n6. 선언 블럭안의 맨 마지막의 선언문에는 늘 세미콜론을 추가할 것.\n7. 룰셋의 닫기괄호는 룰셋안의 첫번째 문자의 위치와 맞춘다.\n8. 룰셋은 빈줄로 구분을 짓는다.\n\n```css\n.selector-1,\n.selector-2,\n.selector-3 {\n -webkit-box-sizing: border-box;\n -moz-box-sizing: border-box;\n box-sizing: border-box;\n display: block;\n color: #333;\n background: #fff;\n}\n```\n\n#### 선언\n\n선언 순서는 단 하나의 원칙에 따라서만 작성할 것. 저와 같은 경우엔 관련하는 프로퍼티끼리 그룹화하였고, 구조적으로 중요한 프로퍼티(예:포지션이나 박스모델)는 타이포그래피, 백그라운드, 컬러의 프로퍼티보다 먼저 선언하도록 하고 있습니다.\n\n\n```css\n.selector {\n position: relative;\n display: block;\n width: 50%;\n height: 100px;\n padding: 10px;\n border: 0;\n margin: 10px;\n color: #fff\n background: #000;\n}\n```\n\n알파벳순도 자주 사용되고 있지만 결점은 관련하는 프로퍼티끼리 떨어져있다는 점입니다. 예를 들어서 포지션의 옵셋을 그룹화할수가 없고, 박스모델의 프로퍼티는 선언블럭안에서 서로서로 떨어져서 선언 됩니다.\n\n#### 예외와 작은 편차\n\n한줄 선언의 수가 많아지게 되는 경우, 지금까지와는 다른 한줄포멧을 사용할 수 있습니다. 이 경우에는 중괄호 안쪽의 양쪽 끝에 스페이스를 한자 넣는 것입니다.\n\n```css\n.selector-1 { width: 10%; }\n.selector-2 { width: 20%; }\n.selector-3 { width: 30%; }\n```\n\n그라데이션이나 쉐도우같이 길고, 컴마로 구분하여 사용하는 프로퍼티값을 갖고있는 경우에는 diff를 좀 더 유용하게 활용하기 위해 여러줄을 사용해도 괜찮습니다. 여러가지의 포맷이 있을 것으로 생각되지만 밑에 적은것과 비슷한 형태일 것입니다.\n\n```css\n.selector {\n box-shadow:\n 1px 1px 1px #000,\n 2px 2px 1px 1px #ccc inset;\n background-image:\n linear-gradient(#fff, #ccc),\n linear-gradient(#f3c, #4ec);\n}\n```\n\n#### 그 외...\n\n* hex값은 소문자를 이용할 것. 예: `#aaa`\n* 싱글따옴표, 더블따옴표에는 일관성을 둘 것. 추천하는 것은 더블따옴표입니다. 예: `content: \"\"`\n* 셀렉터안의 속성치는 늘 따옴표로 감쌀 것. 예: `input[type=\"checkbox\"]`\n* **가능한 경우**에는 0이 되는 값에는 단위지정을 하지 않는다. 例: `margin: 0`\n\n### 프리프로세서:추가 포멧\n\nCSS프리프로세서의 특성, 기능, 신텍스는 툴에 의해서 전혀 틀립니다. 규칙은 이용하고 있는 프리프로세서의 특성에 맞춰서 확장하세요.\n이후의 가이드라인은 SASS를 대상으로 하고 있습니다.\n\n* 코드블럭(nesting)은 한단계만 들여쓰도록 한다. 2단계이상 들어간 중첩요소들이 있는 구조라면 다시한번 코드를 고쳐야 한다. 이렇게 함으로써 CSS셀렉터가 필요이상 상세해 지는걸 막을 수 있다.\n* 코드블럭 작성룰은 여러가지를 사용하지 않도록 한다. 읽기 어려워 질것 같다면 나눠서 작성한다. 코드블럭에는 20개 이상의 룰셋을 두지 않도록 한는걸 추천한다.\n* `@extend`문은 선언 블럭의 최상단에 기술한다.\n* 가능한한 `@include`는 선언블럭안의 `@extend`의 밑에 그룹화 한다.\n* 네이티브 CSS함수와 커스텀화한 함수의 차이를 알기 쉽게 하고, 라이브러리에서 함수의 충돌을 피하기 위해 커스텀화한 함수의 접두어로 'x-'를 사용한다던가 아니면 다른 네임스페이스를 지정하여 사용하도록 한다.\n\n```scss\n.selector-1 {\n @extend .other-rule;\n @include clearfix();\n @include box-sizing(border-box);\n width: x-grid-unit(1);\n // other declarations\n}\n```\n\n\n\n## 5. 명명규칙\n\n우리 인간은 코드컴파일러, 콤프레셔가 아니기 때문에 그렇게 행동할 필요는 없다.\n\nHTML 클래스는 명확하고 심사숙고하여 만든 이름을 사용하여야 한다. HTML화일, CSS화일 안에서 서로가 알기 쉽도록, 일관성있는 명명 페턴을 선택해야 한다.\n\n```css\n/* 안좋은 명명규칙의 예 */\n\n.s-scr {\n overflow: auto;\n}\n\n.cb {\n background: #000;\n}\n\n/* 좀 더 낳은 명명규칙의 예 */\n\n.is-scrollable {\n overflow: auto;\n}\n\n.column-body {\n background: #000;\n}\n```\n\n\n\n## 6. 실례\n\n여러가지 규칙의 예\n\n```css\n/* ==========================================================================\n 그리드 레이아웃\n ========================================================================== */\n\n/*\n * HTML예:\n *\n * \n */\n\n.grid {\n overflow: visible;\n height: 100%;\n /* Prevent inline-block cells wrapping */\n white-space: nowrap;\n /* Remove inter-cell whitespace */\n font-size: 0;\n}\n\n.cell {\n box-sizing: border-box;\n position: relative;\n overflow: hidden;\n width: 20%;\n height: 100%;\n /* Set the inter-cell spacing */\n padding: 0 10px;\n border: 2px solid #333;\n vertical-align: top;\n /* Reset white-space */\n white-space: normal;\n /* Reset font-size */\n font-size: 16px;\n}\n\n/* Cell 상태 */\n\n.cell.is-animating {\n background-color: #fffdec;\n}\n\n/* Cell 사이즈\n ========================================================================== */\n\n.cell-1 { width: 10%; }\n.cell-2 { width: 20%; }\n.cell-3 { width: 30%; }\n.cell-4 { width: 40%; }\n.cell-5 { width: 50%; }\n\n/* Cell 수식 인자\n ========================================================================== */\n\n.cell--detail,\n.cell--important {\n border-width: 4px;\n}\n```\n\n\n\n## 7. 편성\n\n소스코드의 편성은 어떤 CSS코드안에서도 중요한 부분이며 또한 거대한 코드베이스의 경우에는 더더욱 중요해진다.\n\n* 소스코드는 논리적으로 확실하게 틀린부분을 이해할 수 있도록 잘 나눠놔야 한다.\n* 컴포넌트의 명백함을 강화시키기 위해서 별도의 화일로 만든다.(빌드스텝에서 연결한다.)\n* 프리프로세서를 이용하는 경우에는 공통의 코드, 타이포그래피, 색등을 변수로 정의 해둔다.\n\n\n\n## 8. 빌드와 디플로이\n\n프로젝트는 늘 소스코드의 문법체크, 테스트, 압축과 실제 사용에 앞서 버젼관리의 수단들을 갖추어야 합니다.\n이런 테스크들은 Ben Alman씨에 의해서 만들어진 [grunt](https://github.com/cowboy/grunt)가 괜찮은 툴입니다.\n\n\n\n## 감사의 말\n\n[idiomatic.js](https://github.com/rwldrn/idiomatic.js)에 참여해주신 여러분들께 감사드립니다. idiomatic.js는 기발한 생각이며、인용과 가이드라인의 원본입니다.\n"
},
{
"path": "translations/nl-NL/README.md",
"content": "# Principes voor het schrijven van consistente, idiomatische CSS\n\nHet volgende document schetst een logische stijlgids voor het schrijven van\nCSS. Het is niet normatief bedoeld en ik wens niet mijn stijlvoorkeuren op te\ndringen aan andermans code. Deze richtlijnen zijn echter een sterke\naanmoediging voor het gebruik van bestaande, algemene, verstandige patronen.\n\nDit is een document in ontwikkeling en nieuwe ideeën zijn altijd welkom. Draag\nalstublieft bij!\n\nAndere vertalingen zijn te vinden in het [originele Engelse Idiomatic CSS\ndocument](https://github.com/necolas/idiomatic-css).\n\n\n## Inhoudsopgave\n\n1. [Algemene principes](#general-principles)\n2. [Witruimte](#whitespace)\n3. [Commentaar](#comments)\n4. [Opmaak](#format)\n5. [Naamgeving](#naming)\n6. [Praktisch voorbeeld](#example)\n7. [Ordening](#organization)\n8. [Build en deployment](#build-and-deployment)\n\n[Dank](#acknowledgements)\n\n\n\n## 1. Algemene principes\n\n> \"Het zijn van een goed rentmeester van een succesvol project is deels het\n> realiseren dat het schrijven van code voor jezelf een Slecht Idee™ is. Als\n> duizenden mensen je code gebruiken schrijf je code dan voor maximale\n> duidelijkheid, niet je persoonlijke voorkeur slim om te gaan binnen de\n> specificatie.\" - Idan Gazit\n\n* Alle code in elke codebase zou getypt moeten lijken door een enkel persoon,\n ongeacht hoeveel personen een bijdrage leverden.\n* Dwing de afgesproken stijl streng af.\n* Gebruik bij twijfel bestaande, algemene patronen.\n\n\n\n## 2. Witruimte\n\nIn de hele broncode van uw project zou slechts één stijl moeten bestaan. Wees\naltijd consistent in het gebruik van witruimte. Gebruik witruimte om de\nleesbaarheid te bevorderen.\n\n* Wissel _nooit_ het gebruik van tabs en spaties voor het inspringen van tekst\n af.\n* Kies tussen zacht inspringen (spaties) of echte tabs. En blijf daarbij\n (voorkeur: spaties).\n* Als u spaties gebruikt, kies het aantal karakters per niveau van inspringen\n (voorkeur: 4 spaties)\n\nTip: Stel uw tekstverwerker in om \"onzichtbare tekens te tonen\". Dit stelt u in\nstaat witruimte aan regeleinden en onbedoelde witregels te verwijderen en\nvoorkomt vervuilde commits.\n\n\n\n## 3. Commentaar\n\nGoed becommentarieerde code is extreem belangrijk. Neem de tijd om componenten\nte beschrijven. Hoe deze werken, de beperkingen en de manier waarom deze zijn\nsamengesteld. Laat anderen in het team niet raden naar het doel van ongewone of\nonduidelijke code.\n\nDe stijl van commentaar binnen broncode zou simpel en consistent moeten zijn.\n\n* Plaats commentaar op een nieuwe regel boven het onderwerp.\n* Vermijd commentaar aan het einde van een regel.\n* Houdt regellengte tot een verstandig maximum: b.v. 80 kolommen.\n* Maak ruim gebruik van commentaar om CSS-code op te breken in aparte\n secties.\n* Gebruik \"standaard kapitalen\"-commentaar en het consistent inspringen van\n tekst.\n\nTip: Stel uw tekstverwerker in met toetscombinaties om de afgesproken algemene\npatronen te genereren.\n\n\n#### CSS-voorbeeld:\n\n```css\n/* ==========================================================================\n Sectie commentaarblok\n ========================================================================== */\n\n/* Subsectie commentaarblok\n ========================================================================== */\n\n/*\n * Groep commentaarblok.\n * Ideaal voor uitleg over meerdere regels en documentatie.\n */\n\n/* Standaard commentaar */\n```\n\n#### SCSS-voorbeeld:\n\n```scss\n// ==========================================================================\n// Sectie commentaarblok\n// ==========================================================================\n\n// Subsectie commentaarblok\n// ==========================================================================\n\n//\n// Groep commentaarblok\n// Ideaal voor uitleg over meerdere regels en documentatie.\n//\n\n// Standaard commentaar\n```\n\n\n\n## 4. Opmaak\n\nDe gekozen code-opmaak moet verzekeren dat de code: makkelijk te lezen en te\nbecommentariëren is. Dit vermindert de kans op de onbedoelde introductie van\nfouten en resulteert in bruikbare diffs en blames.\n\n1. Eén aparte selector per regel en in multi-selector rulesets.\n2. Eén afzonderlijke spatie voor de openings-accolade van een ruleset.\n3. Eén declaratie per regel in een declaratieblok.\n4. Eén inspringniveau voor elke declaratie.\n5. Eén afzonderlijke spatie na de dubbele punt van een declaratie.\n6. Voeg altijd een puntkomma aan het eind van de laatste declaratie in een\n declaratieblok.\n7. Plaats de afsluitende accolade van een ruleset in dezelfde kolom als het\n eerste karakter van de ruleset.\n8. Scheidt elke ruleset door een witregel.\n\n```css\n.selector-1,\n.selector-2,\n.selector-3 {\n -webkit-box-sizing: border-box;\n -moz-box-sizing: border-box;\n box-sizing: border-box;\n display: blok;\n color: #333;\n background: #fff;\n}\n```\n\n#### Volgorde van declaraties\n\nDeclaraties dienen geordend te worden overeenkomstig een enkel principe. Mijn\nvoorkeur is dat gerelateerde eigenschappen gegroepeerd worden en dat\nstructureel belangrijke eigenschappen (b.v. positionering en box-model) voor\ntypografische-, achtergronds- en kleureigenschappen gedeclareerd worden.\n\n```css\n.selector {\n position: relative;\n display: blok;\n width: 50%;\n height: 100px;\n padding: 10px;\n border: 0;\n margin: 10px;\n color: #fff\n background: #000;\n}\n```\n\nAlfabetische volgorde is ook populair, maar het nadeel is dat dit gerelateerde\neigenschappen afzondert. Bijvoorbeeld: positie-afstanden zijn niet langer\ngegroepeerd en box-modeleigenschappen kunnen door het hele declaratieblok\nverspreid worden.\n\n#### Uitzonderingen en kleine afwijkingen\n\nGrote blokken alleenstaande declaraties kunnen een enigszins andere,\nenkele-regel-opmaak gebruiken. In dit geval zou een spatie toegevoegd kunnen\nworden na de openingsaccolade en voor de sluitende accolade.\n\n```css\n.selector-1 { width: 10%; }\n.selector-2 { width: 20%; }\n.selector-3 { width: 30%; }\n```\n\nLange, kommagescheiden eigenschapwaarden - zoals sets aan verlopen of schaduwen\n- kunnen gerangschikt kunnen worden over meerdere regels om de leesbaarheid en\nbeter bruikbare diffs te bevorderen. Er zijn verschillende opmaakstijlen die\ngebruikt zouden kunnen worden; een voorbeeld is hieronder getoond.\n\n```css\n.selector {\n box-shadow:\n 1px 1px 1px #000,\n 2px 2px 1px 1px #ccc inset;\n background-image:\n linear-gradient(#fff, #ccc),\n linear-gradient(#f3c, #4ec);\n}\n```\n\n#### Diversen\n\n* Gebruik onderkast hex waarden, b.v., `#aaa`.\n* Gebruik consistent enkele of dubbele aanhalingstekens. Dubbele\n aanhalingstekens hebben de voorkeur, b.v. `content: \"\"`.\n* Gebruik altijd aanhalingstekens bij attribuutwaarden in selectors, b.v.\n `input[type=\"checkbox\"]`.\n* Vermijd, _indien toegestaan_, specifieke eenheden voor nulwaarden b.v.\n `margin: 0`.\n\n### Preprocessors: extra opmaakoverwegingen\n\nVerschillende CSS preprocessors hebben verschillende kenmerken, functionaliteit\nen syntaxis. Uw conventies zullen moeten worden afgestemd op de unieke\nkenmerken van de gebruikte preprocessors. De volgende richtlijnen hebben\nbetrekking op Sass.\n\n* Beperk geneste regels tot 1 niveau diep. Bekijk sets dieper dan 2 niveaus\n opnieuw. Dit voorkomt te specifieke CSS-selectors.\n* Voorkom grote aantallen geneste regels. Splits ze wanneer de leesbaarheid\n verminderd. De voorkeur is om geneste regels van meer dan 20 regels te\n vermijden.\n* Plaats `@extend`-statements altijd op de eerste regel van een\n declaratieblok.\n* Groepeer `@include`-statements waar mogelijk bovenaan een declaratieblok, na\n mogelijke `@extend`-statements.\n* Overweeg een voorvoegsel van `x-` of een andere namespace voor eigen\n functies. Dit voorkomt mogelijke verwarring van uw functies met een CSS-eigen\n functie of een conflict met functies van andere libraries.\n\n```scss\n.selector-1 {\n @extend .other-rule;\n @include clearfix();\n @include box-sizing(border-box);\n width: x-grid-unit(1);\n // andere declaraties\n}\n```\n\n\n\n## 5. Naamgeving\n\nU bent geen menselijke codecompiler/compressor; probeer dit dan ook niet te\nzijn.\n\nGebruik duidelijke en doordachte namen voor HTML classes. Kies een begrijpelijk\nen consistent patroon voor naamgeving dat zowel in de HTML- als CSS-bestanden\nvoor zich spreekt.\n\n```css\n/* voorbeeld van code met slechte naamgeving */\n\n.s-scr {\n overflow: auto;\n}\n\n.cb {\n background: #000;\n}\n\n/* Voorbeeld van code met betere naamgeving */\n\n.is-scrollable {\n overflow: auto;\n}\n\n.column-body {\n background: #000;\n}\n```\n\n\n\n## 6. Praktisch voorbeeld\n\nEen voorbeeld van verschillende conventies.\n\n```css\n/* ==========================================================================\n Grid lay-out\n ========================================================================== */\n\n/*\n * Voorbeeld HTML:\n *\n * \n */\n\n.grid {\n overflow: visible;\n height: 100%;\n /* Voorkom het omslaan van inline-block cellen */\n white-space: nowrap;\n /* Verwijder witruimte tussen cellen */\n font-size: 0;\n}\n\n.cell {\n box-sizing: border-box;\n position: relative;\n overflow: hidden;\n width: 20%;\n height: 100%;\n /* Bepaal de ruimte tussen cellen */\n padding: 0 10px;\n border: 2px solid #333;\n vertical-align: top;\n /* Herstel witruimte */\n white-space: normal;\n /* Herstel font-size */\n font-size: 16px;\n}\n\n/* Cel states */\n\n.cell.is-animating {\n background-color: #fffdec;\n}\n\n/* Celafmetingen\n ========================================================================== */\n\n.cell-1 { width: 10%; }\n.cell-2 { width: 20%; }\n.cell-3 { width: 30%; }\n.cell-4 { width: 40%; }\n.cell-5 { width: 50%; }\n\n/* Celaanpassingen\n ========================================================================== */\n\n.cell--detail,\n.cell--important {\n border-width: 4px;\n}\n```\n\n\n\n## 7. Ordening\n\nCode-organisatie is een belangrijk onderdeel van elke CSS codebase en cruciaal\nvoor grotere codebases.\n\n* Verdeel logisch afzonderlijke codeonderdelen.\n* Gebruik afzonderlijke bestanden (samengevoegd door een buildproces) om code\n voor aparte componenten op te breken.\n* Abstraheer algemene code in variabelen voor kleur, typografie enz. als\n gebruik gemaakt wordt van een preprocessor.\n\n\n\n## 8. Build en deployment\n\nProjecten dienen altijd een generieke manier te bevatten om broncode te linten,\ntesten, comprimeren en van versienummer te voorzien in voorbereiding op gebruik\nin productie. [grunt](https://github.com/cowboy/grunt) door Ben Alman is\nhiervoor een uitstekende oplossing.\n\n\n ## Dank\n\nDank voor iedereen die bijgedragen heeft aan\n[idiomatic.js](https://github.com/rwldrn/idiomatic.js). Het was een bron van\ninspiratie, citaties en richtlijnen.\n"
},
{
"path": "translations/pl-PL/README.md",
"content": "# Zasady tworzenia spójnych, zgodnych z regułami języka deklaracji CSS\n\nPoniżej opisane zostały podstawowe zasady tworzenia arkuszy stylów. Nie jest\nto uniwersalne czy wyczerpujące temat zestawienie. Intencją autora nie było\nbowiem narzucanie jedynie słusznych rozwiązań, a raczej zachęta do stosowania\nistniejących, wypróbowanych i uznanych wzorców.\n\nZ tego samego powodu mile widziana będzie wszelka pomoc w dalszym rozwijaniu i\nwzbogacaniu niniejszego dokumentu.\n\n\n[Artykuł Idiomatic CSS w oryginale](https://github.com/necolas/idiomatic-css/)\n\n\n## Spis treści\n\n1. [Główne zasady](#general-principles)\n2. [Wcięcia](#whitespace)\n3. [Komentarze](#comments)\n4. [Format](#format)\n5. [Nazewnictwo](#naming)\n6. [Przykłady praktyczne](#example)\n7. [Organizacja](#organization)\n8. [Przygotowanie i wdrożenie](#build-and-deployment)\n\n[Podziękowania](#acknowledgements)\n\n\n\n## 1. Główne zasady\n\n> „Pierwszym krokiem do stworzenia projektu, który odniesie sukces, jest\n> zrozumienie, że pisanie kodu dla samego siebie to Bardzo Zły Pomysł®. Jeśli\n> z twoich rozwiązań mają korzystać tysiące innych osób, nie pisz tak, jak\n> lubisz, ale tak, by osiągnąć maksymalną przejrzystość.” - Idan Gazit\n\n* Nie jesteś maszyną do kompilowania czy kompresowania kodu i nie staraj się\n nią zostać.\n* Kod powinien zawsze wyglądać tak, jakby napisał go jeden człowiek -\n niezależnie od liczby osób współpracujących przy tym zadaniu.\n* Trzymaj się ściśle ustalonych na wstępie reguł.\n* Jeśli masz wątpliwości, korzystaj z istniejących, sprawdzonych rozwiązań.\n\n\n\n## 2. Wcięcia\n\nW całym projekcie stosuj konsekwentnie tylko jeden styl wcięć. Nie zapominaj,\nże wcięcia służą przede wszystkim czytelności kodu.\n\n* _Nigdy_ nie stosuj równolegle spacji i tabulatorów.\n* Wybierz jedną z powyższych metod do tworzenia wcięć (najlepiej spacje) i\n trzymaj się jej.\n* Jeśli używasz spacji, wybierz stałą liczbę znaków dla jednego poziomu wcięcia\n (najlepiej cztery).\n\nWskazówka: włącz w swoim edytorze kodu opcję pokazywania znaków\nniedrukowalnych. To pozwoli ci wyeliminować spacje na końcu linii i w pustych\nwierszach.\n\nWskazówka: używaj pliku [EditorConfig](http://editorconfig.org/) albo innego\nrozwiązania, które pomoże ci trzymać się ustalonych zasad tworzenia wcięć.\n\n\n\n## 3. Komentarze\n\nDokładne dokumentowanie kodu jest niezwykle istotne. Poświęć czas na opisanie\nkomponentów, ich działania i ograniczeń oraz sposobu ich tworzenia. Nie pozwól,\nżeby inni członkowie zespołu musieli domyślać się znaczenia kodu.\n\nStyl tworzenia komentarzy powinien być prosty i spójny w obrębie całego\nprojektu.\n\n* Umieszczaj komentarze w nowej linii, nad elementem, który opisują.\n* Unikaj tworzenia komentarzy na końcu linii.\n* Utrzymuj sensowne maksimum długości linii, np. 80 znaków.\n* Używaj komentarzy do dzielenia kodu CSS na osobne sekcje.\n* Komentuj, używając standardowych zdań i wcięć akapitów.\n\nWskazówka: skonfiguruj swój edytor tak, byś mógł stosować skróty klawiszowe do\nwstawiania komentarzy w ustalonej wcześniej postaci.\n\n#### Przykład:\n\n```css\n/* ==========================================================================\n Blok komentarzy sekcji\n ========================================================================== */\n\n/* Blok komentarzy podsekcji\n ========================================================================== */\n\n/**\n * Krótki opis z zastosowaniem formatowania w stylu Doxygen\n *\n * Długi opis - pierwsze zdanie rozpoczyna się tutaj i biegnie jeszcze przez\n * chwilę, zajmując cały wiersz, aby wreszcie zakończyć się konkluzją w tym\n * miejscu, u dołu akapitu.\n *\n * Dłuższy opis jest najlepszym miejscem do umieszczenia szczegółowych\n * objaśnień i dokumentacji. Może zawierać przykładowy kod HTML, adresy\n * internetowe oraz inne przydatne informacje.\n *\n * @tag To jest znacznik o nazwie 'tag'\n *\n * @todo To jest opis todo, wskazujący istotne zadanie, które należy wykonać\n * później. Zawija się po około 80 znakach a kolejne linie są wcięte za\n * pomocą 2 spacji.\n */\n\n/* Podstawowy komentarz */\n```\n\n\n\n## 4. Format\n\nWybrany format kodu musi gwarantować, że kod ten będzie łatwy do przeczytania i\nskomentowania, co w efekcie zminimalizuje szanse przypadkowego popełnienia\nbłędu. W ten sposób także tworzenie przejrzystych zestawień zmian w plikach i\nwskazywanie osób odpowiedzialnych za określone poprawki stanie się znacznie\nłatwiejszym zadaniem.\n\n* W deklaracjach z wieloma selektorami używaj jednego selektora w linii.\n* Wstawiaj jedną spację przed nawiasem otwierającym zestaw reguł.\n* W bloku reguł umieszczaj jedną deklarację w wierszu.\n* Stosuj jeden poziom wcięcia dla każdej deklaracji.\n* Wstawiaj jedną spację po dwukropku w deklaracji.\n* Używaj wartości pisanych małymi literami i skrótów, np. `#aaa`.\n* Stosuj pojedyncze i podwójne cudzysłowy w sposób spójny. Preferuj jednak\n podwójne, jak na przykład `content: \"\"`.\n* Wyodrędbniaj cudzysłowami wartości atrybutów w selektorach, na przykład\n `input[type=\"checkbox\"]`.\n* _Tam gdzie to możliwe_ unikaj podawania jednostek dla wartości zerowych, na\n przykład `margin: 0`.\n* W oddzielonych przecinkami właściwościach wstawiaj spację po każdym\n przecinku.\n* Pamiętaj o średniku na końcu ostatniej deklaracji w bloku.\n* Nawias zamykający zestaw reguł umieszczaj w tej samej kolumnie (z tym samym\n wcięciem), co otwierający.\n* Bloki deklaracji oddzielaj pustą linią.\n\n```css\n.selektor-1,\n.selektor-2,\n.selektor-3[type=\"text\"] {\n -webkit-box-sizing: border-box;\n -moz-box-sizing: border-box;\n box-sizing: border-box;\n display: block;\n font-family: helvetica, arial, sans-serif;\n color: #333;\n background: #fff;\n background: linear-gradient(#fff, rgba(0, 0, 0, 0.8));\n}\n```\n\n#### Kolejność deklaracji\n\nDeklaracje powinny być uporządkowane zgodnie z jedną, przyjętą na wstępie\nregułą. Preferowanym przeze mnie sposobem jest umieszczanie na początku\nwłaściwości określających strukturę elementu - czyli np. jego pozycję i\nwymiary.\n\n```css\n.selektor {\n /* Pozycja */\n position: absolute;\n z-index: 10;\n top: 0;\n right: 0;\n bottom: 0;\n left: 0;\n\n /* Wyświetlanie i wymiary */\n display: inline-block;\n overflow: hidden;\n box-sizing: border-box;\n width: 100px;\n height: 100px;\n padding: 10px;\n border: 10px solid #333;\n margin: 10px;\n\n /* Inne */\n background: #000;\n color: #fff\n font-family: sans-serif;\n font-size: 16px;\n text-align: right;\n}\n```\n\nStosunkowo popularne jest także porządkowanie deklaracji alfabetycznie. Metoda\nta ma jednak taką wadę, że oddziela od siebie powiązane właściwości. W takim\nwypadku np. definicje marginesów, odstępów, wysokości i szerokości elementu\nbędą rozrzucone po całym bloku.\n\n#### Wyjątki i drobne odstępstwa\n\nDuże fragmenty arkusza zawierające pojedyncze deklaracje można formatować nieco\ninaczej, ujmując całość w jednym wierszu. W takim wypadku po nawiasie\notwierającym oraz przed zamykającym należy wstawić spację.\n\n```css\n.selektor-1 { width: 10%; }\n.selektor-2 { width: 20%; }\n.selektor-3 { width: 30%; }\n```\n\nDłuższe, oddzielone przecinkami właściwości, np. zestawy gradientów albo cieni,\nmożna rozbijać na kilka linii, by poprawić czytelność i ułatwić generowanie\nprzejrzystych zestawień zmian. Poniższy przykład obrazuje jedno z możliwych\nrozwiązań:\n\n```css\n.selektor {\n background-image:\n linear-gradient(#fff, #ccc),\n linear-gradient(#f3c, #4ec);\n box-shadow:\n 1px 1px 1px #000,\n 2px 2px 1px 1px #ccc inset;\n}\n```\n\n### Preprocesory: dodatkowe uwagi dotyczące formatu\n\nRóżne narzędzia do wstępnego przetwarzania kodu CSS mają zróżnicowane\nmożliwości i składnię. W związku z tym zasady postępowania należy ustalać\nzawsze w odniesieniu do unikalnych właściwości danego preprocesora. Te wskazane\nniżej odnoszą się do jednego z nich - Sass.\n\n* Ogranicz zagnieżdżanie do jednego poziomu. To pozwoli ci uniknąć tworzenia\n nazbyt szczegółowych selektorów.\n* Unikaj stosowania dużej liczby zagnieżdżonych reguł. 20 wierszy wydaje się\n być rozsądną granicą. Podziel kod na mniejsze fragmenty, gdy tylko zauważysz,\n że traci na czytelności.\n* Pamiętaj o umieszczaniu `@extend` w pierwszych liniach bloku deklaracji.\n* Gdy to możliwe, grupuj `@include` na początku bloku deklaracji, zaraz za\n `@extend`.\n* Nazwy tworzonych przez siebie funkcji poprzedzaj `x-` lub innym prefiksem.\n Pomoże ci to odróżnić je w trakcie pracy od domyślnych funkcji CSS i uniknąć\n konfliktów z funkcjami zawartymi w innych bibliotekach.\n\n```scss\n.selektor-1 {\n @extend .inna-regula;\n @include clearfix();\n @include box-sizing(border-box);\n width: x-jednostka-siatki(1);\n // pozostałe deklaracje\n}\n```\n\n\n\n## 5. Nazewnictwo\n\nWybór odpowiedniego nazewnictwa jest trudny, ale bardzo istotny. To kluczowy\nelement w procesie tworzenia łatwej w aktualizacji i elastycznej bazy kodu\nCSS.\n\n* Unikaj _zbyt częstego_ wykorzystywania skróconych nazw klas. Nie komplikuj\n kodu ponad potrzebę.\n* Używaj jasnych, kojarzących się, dobrze przemyślanych nazw klas.\n* Wybierz zrozumiały i spójny wzorzec tworzenia nazw, który będzie zrozumiały\n zarówno w trakcie lektury kodu HTML, jak i CSS.\n* Selektory dla komponentów strony powinny wykorzystywać nazwy klas - unikaj\n używania nazw tagów i identyfikatorów (id).\n\n```css\n/* Przykład kodu z kiepskimi nazwami klas */\n\n.m-prz {\n overflow: auto;\n}\n\n.tk {\n background: #000;\n}\n\n/* Przykład kodu z lepszymi nazwami */\n\n.mozna-przewijac {\n overflow: auto;\n}\n\n.tekst-kolumny {\n background: #000;\n}\n```\n\n\n\n## 6. Przykłady praktyczne\n\nPropozycje zastosowania opisanych wcześniej konwencji.\n\n```css\n/* ==========================================================================\n Siatka\n ========================================================================== */\n\n/**\n * Przykładowy kod HTML:\n *\n * \n */\n\n.siatka {\n overflow: visible;\n height: 100%;\n /* Zapobiegaj zawijaniu tekstu w komórkach z inline-block */\n white-space: nowrap;\n /* Usuń spacje między komórkami */\n font-size: 0;\n}\n\n.komorka {\n position: relative;\n display: inline-block;\n overflow: hidden;\n box-sizing: border-box;\n width: 20%;\n height: 100%;\n /* Ustaw odstępy między komórkami */\n padding: 0 10px;\n border: 2px solid #333;\n vertical-align: top;\n /* Resetuj spacje */\n white-space: normal;\n /* Resetuj rozmiar czcionki */\n font-size: 16px;\n}\n\n/* Stany komórek */\n\n.komorka.jest-animowana {\n background-color: #fffdec;\n}\n\n/* Wymiary komorek\n ========================================================================== */\n\n.komorka-1 { width: 10%; }\n.komorka-2 { width: 20%; }\n.komorka-3 { width: 30%; }\n.komorka-4 { width: 40%; }\n.komorka-5 { width: 50%; }\n\n/* Modyfikacje komorek\n ========================================================================== */\n\n.komorka--szczegoly,\n.komorka--istotne {\n border-width: 4px;\n}\n```\n\n\n\n## 7. Organizacja\n\nOdpowiednia organizacja jest istotnym elementem tworzenia każdej bazy kodu CSS.\nW przypadku dużych baz to wręcz kwestia kluczowa.\n\n* Pamiętaj o logicznym wyodrębnianiu samodzielnych fragmentów kodu.\n* Używaj osobnych plików (łączonych podczas budowania kodu) aby w prosty sposób\n dzielić kod na mniejsze komponenty.\n* Jeśli używasz preprocesora, powtarzające się definicje kolorów, typografii\n itp. przypisuj do zmiennych.\n\n\n\n## 8. Przygotowanie i wdrożenie\n\nW projektach powinno się zawsze wdrażać pewne ogólne zasady, według których kod\nźródłowy może być analizowany, testowany, kompresowany i wersjonowany przed\nwdrożeniem. Doskonałym narzędziem służącym do tego celu jest\n[grunt](https://github.com/cowboy/grunt) autorstwa Bena Almana.\n\n\n\n## Podziękowania\n\nDziękuję wszystkim, którzy współtworzyli\n[idiomatic.js](https://github.com/rwldrn/idiomatic.js). Projekt ten był dla\nmnie źródłem inspiracji, cytatów i wskazówek.\n"
},
{
"path": "translations/pt-BR/README.md",
"content": "# Princípios para escrever CSS de forma consistente e idiomática\n\nO documento a seguir descreve um sensato guia de estilo para desenvolvimento\nCSS. Não pretendo ser prescritivo e não quero impor as minhas preferências de\nestilo no código de outras pessoas. Entretanto, estas orientações incentivam\nfortemente o uso de existentes, comuns e sensatos padrões.\n\nEsse é um documento vivo e novas ideias são sempre bem-vindas. Por favor\ncontribua.\n\n[Idiomatic CSS em Inglês (Original)](https://github.com/necolas/idiomatic-css)\n\n\n## Índice\n\n1. [Princípios gerais](#general-principles)\n2. [Espaços em branco](#whitespace)\n3. [Comentários](#comments)\n4. [Formatação](#format)\n5. [Nomeando](#naming)\n6. [Exemplo prático](#example)\n7. [Organização](#organization)\n8. [Build e deploy](#build-and-deployment)\n\n[Agradecimentos](#acknowledgements)\n\n\n\n## 1. Princípios gerais\n\n> \"Parte de ser um bom gestor de um projeto bem sucedido é perceber que\n> escrever código para si mesmo é uma Má Ideia™. Se milhares de pessoas estão\n> usando o seu código, então escreva-o com máxima clareza, não sob a sua\n> preferência pessoal de como ser esperto com a especificação.\" - Idan Gazit\n\n* Todo código em qualquer aplicação deve parecer como se tivesse sido escrito\n por uma única pessoa, independentemente de quantas pessoas tenham contribuído.\n* Faça cumprir rigorosamente o estilo acordado.\n* Em caso de dúvida, utilizar padrões existentes e comuns.\n\n\n\n## 2. Espaços em branco\n\nApenas um estilo deve existir em todo o projeto. Seja sempre consistente na\nutilização de espaços em branco. Use espaços em branco para melhorar a\nlegibilidade.\n\n* _Nunca_ misture espaços e tabs para indentação.\n* Escolha entre indentação suave (espaços) ou tabulação. Atenha-se à sua\n escolha sem falhar. (Preferência: espaços)\n* Se usar espaços, escolha o número de caracteres usados por nível de\n indentação. (Preferência: 4 espaços)\n\nDica: configure seu editor para \"mostrar invisíveis\". Isso irá permitir que\nvocê elimine espaços em branco da quebra de linha, elimine espaços em branco de\nlinhas vazias sem indentação e evite commits poluídos.\n\nDica: use um [EditorConfig](http://editorconfig.org/) arquivo (ou equivalente) para ajudar a menter a convenção básica de espaços em branco que você aceitou para sua base de código.\n\n\n\n## 3. Comentários\n\nCódigo bem comentado é extremamente importante. Tire tempo para descrever\ncomponentes, como eles funcionam, suas limitações, e o modo como são\nconstruídos. Não deixe outros no time adivinharem o propósito de códigos\nincomuns ou não óbvios.\n\nEstilo de comentário deve ser simples e consistente dentro de uma única base de\ncódigo.\n\n* Coloque comentários em uma nova linha acima do seu assunto.\n* Evite comentários no fim da linha.\n* Mantenha o comprimento da linha a um máximo sensível, por exemplo, 80\n colunas.\n* Faça o uso liberal de comentários para quebrar o código CSS em seções\n distintas.\n* Use comentários com iniciais maiúsculas e indentação de texto consistente.\n\nDica: configure seu editor para lhe prover com atalhos a geração do padrão de\ncomentários acordado.\n\n#### exemplo com CSS:\n\n```css\n/* ==========================================================================\n Bloco de comentário de seção\n ========================================================================== */\n\n/* Bloco de comentário de sub-seção\n ========================================================================== */\n\n/*\n * Bloco de comentário de grupo\n * Ideal para explicações em múltiplas linhas e documentação.\n */\n \n/**\n * Breve descrição usando o estilo de formato de comentário Doxygen\n *\n * A primeira frase da descrição longa começa aqui e continua\n * nesta linha por um tempo finalmente concluindo aqui no final deste parágrafo.\n *\n * A descrição longa é ideal para explicações mais detalhadas e documentação.\n * Ele pode incluir HTML exemplo, URLs, ou qualquer outra informação\n * que seja considerada necessária ou útil.\n *\n * @tag Esta é uma tag chamada 'tag'\n *\n * @todo Esta é uma declaração de tarefas que descreve uma tarefa atômica para ser \n * concluída numa data posterior. Ela envolve depois de 80 caracteres e as linhas a\n * seguir são Recuado por dois espaços.\n */\n\n/* Comentário básico */\n```\n\n#### exemplo com SCSS:\n\n```scss\n// ==========================================================================\n// Bloco de comentário de seção\n// ==========================================================================\n\n// Bloco de comentário de sub-seção\n// ==========================================================================\n\n//\n// Bloco de comentário de grupo\n// Ideal para explicações em múltiplas linhas e documentação.\n//\n\n// Comentário básico\n```\n\n\n\n## 4. Formatação\n\nO formato de código escolhido deve garantir que o código seja: fácil de ler;\nfácil de comentar claramente; minimize a chance de introduzir erros\nacidentalmente; e resulte em úteis visualizações de diferença.\n\n* Um seletor discreto por linha em um conjunto de regras com multi-seletores.\n* Um único espaço antes da abertura das chaves em um conjunto de regras.\n* Uma única declaração por linha em um bloco de declarativo.\n* Um nível de indentação para cada declaração.\n* Um único espaço depois dos dois pontos de uma declaração.\n* Use valores minúsculos e abreviações hexadecimais, por exemplo, `#aaa`.\n* Use aspas simples ou duplas de forma consistente. Preferência é por aspas duplas,\n por exemplo, `conteúdo:\" \"`.\n* Citação valores de atributos em seletores, por exemplo, `input [type=\"checkbox\"]`.\n* _Onde for permitido_, evitar especificar unidades para zero valores, por exemplo, `margin: 0`.\n* Inclua um espaço após cada vírgula em propriedades separadas por vírgula ou valores de funções.\n* Sempre inclua um ponto-e-vírgula no fim da última declaração em um bloco\n declarativo.\n* Coloque o fechamento das chaves na mesma coluna que o primeiro caracter do\n conjunto de regras.\n* Separe cada conjunto de regras por uma linha em branco.\n\n```css\n.selector-1,\n.selector-2,\n.selector-3 {\n -webkit-box-sizing: border-box;\n -moz-box-sizing: border-box;\n box-sizing: border-box;\n display: block;\n color: #333;\n background: #fff;\n}\n```\n\n#### Ordem de declaração\n\nDeclarações devem ser ordenadas segundo um único princípio. Minha preferência é\npor propriedades relacionadas para serem agrupadas e por propriedades\nestruturalmente importantes (por exemplo, posicionamento e box-model) para\nserem declaradas antes de propriedades tipográficas, fundo ou cor.\n\n```css\n.selector {\n /* Posicionamento */\n position: absolute;\n z-index: 10;\n top: 0;\n right: 0;\n bottom: 0;\n left: 0;\n\n /* Display & Modelo de Caixa */\n display: inline-block;\n overflow: hidden;\n box-sizing: border-box;\n width: 100px;\n height: 100px;\n padding: 10px;\n border: 10px solid #333;\n margin: 10px;\n\n /* Outros */\n background: #000;\n color: #fff;\n font-family: sans-serif;\n font-size: 16px;\n text-align: right;\n}\n```\n\nOrdenação alfabética também é popular, mas a desvantagem é que ela separa as\npropriedades relacionadas. Por exemplo, deslocamentos de posição não são mais\nagrupados e propriedades do box-model podem acabar propagando ao longo de um\nbloco de declaração.\n\n#### Exceções e ligeiros desvios\n\nGrandes blocos de declarações individuais podem atuar de forma diferente,\natravés da formatação de linha única. Nesse caso, um espaço deve ser\nconsiderado depois da abertura das chaves e antes do fechamento das chaves.\n\n```css\n.selector-1 { width: 10%; }\n.selector-2 { width: 20%; }\n.selector-3 { width: 30%; }\n```\n\nLongos valores de propriedades separados por vírgula - como coleções de\ndegradês ou sombras - podem ser organizados em várias linhas em um esforço para\nmelhorar a legibilidade e produz visualizações de diferença mais úteis. Existem\nvários formatos que poderiam ser usados; um exemplo é mostrado abaixo.\n\n```css\n.selector {\n background-image:\n linear-gradient(#fff, #ccc),\n linear-gradient(#f3c, #4ec);\n box-shadow:\n 1px 1px 1px #000,\n 2px 2px 1px 1px #ccc inset;\n}\n```\n\n#### Miscelânea\n\n* Use valores hexadecimais em letras minúsculas, por exemplo: `#aaa`.\n* Use aspas simples ou duplas de forma consistente. Preferência por aspas\n duplas, por exemplo: `content: \"\"`.\n* Sempre coloque aspas em valores de atributos nos seletores, por exemplo:\n `input[type=\"checkbox\"]`.\n* _Onde permitido_, evite especificar unidades para valores-zero, por exemplo:\n `margin: 0`.\n\n### Pré-processadores: considerações de formatação adicionais\n\nDiferentes pré-processadores de CSS possuem diferentes características,\nfuncionalidades e sintaxe. Suas convenções devem ser extendidas para acomodar\nas particularidades de qualquer pré-processador em uso. As seguintes diretrizes\nsão em referência ao Sass.\n\n* Limite o aninhamento a 1 nível de profundidade. Reavalie qualquer aninhamento\n que tenha mais de 2 níveis de profundidade. Isso impede que existam seletores\n CSS muito específicos.\n* Evite um grande número de regras aninhadas. Quebre-os para quando a\n legibilidade começar a ser afetada. Preferência por evitar aninhamentos que\n se espalhem por mais de 20 linhas.\n* Sempre coloque as declarações `@extend` nas primeiras linhas de um bloco\n declarativo.\n* Quando possível, agrupe declarações `@include` no topo de blocos\n declarativos, depois de qualquer declaração `@extend`.\n* Considere funções customizadas para prefixos com `x-` ou qualquer namespace.\n Isso ajuda a evitar qualquer potencial confusão na sua função com a função de\n CSS nativo ou de colidir com funções de bibliotecas.\n\n```scss\n.selector-1 {\n @extend .other-rule;\n @include clearfix();\n @include box-sizing(border-box);\n width: x-grid-unit(1);\n // other declarations\n}\n```\n\n\n## 5. Nomeando\n\nVocê não é um compilador/compressor de código humano, então não tente ser.\n\nUse nomes claros e previdentes para classes HTML. Escolha um padrão de nomes\ncompreensível e consistente que faça sentido para arquivos HTML e arquivos\nCSS.\n\n```css\n/* Exemplo de código com nomes ruins */\n\n.s-scr {\n overflow: auto;\n}\n\n.cb {\n background: #000;\n}\n\n/* Exemplo de código com bons nomes */\n\n.is-scrollable {\n overflow: auto;\n}\n\n.column-body {\n background: #000;\n}\n```\n\n\n\n## 6. Exemplo prático\n\nUm exemplo de várias convenções.\n\n```css\n/* ==========================================================================\n Grid layout\n ========================================================================== */\n\n/*\n * Layout da coluna com scroll horizontal.\n *\n * Isso cria uma única linha de altura completa, não-envolvendo colunas que podem\n * ser navegadas na horizontal dentro de seu pai.\n *\n * Exemplo de HTML:\n *\n * \n */\n \n/**\n * Grid container\n * Deve conter apenas filhos de `.cell`\n */\n\n.grid {\n overflow: visible;\n height: 100%;\n /* Prevent inline-block cells wrapping */\n white-space: nowrap;\n /* Remove inter-cell whitespace */\n font-size: 0;\n}\n\n/**\n * Grid cells\n * Largura não-explícita por padrão. Extenda com classes `.cell-n`.\n */\n\n.cell {\n box-sizing: border-box;\n position: relative;\n overflow: hidden;\n width: 20%;\n height: 100%;\n /* Set the inter-cell spacing */\n padding: 0 10px;\n border: 2px solid #333;\n vertical-align: top;\n /* Reset white-space */\n white-space: normal;\n /* Reset font-size */\n font-size: 16px;\n}\n\n/* Cell states */\n\n.cell.is-animating {\n background-color: #fffdec;\n}\n\n/* Cell dimensions\n ========================================================================== */\n\n.cell-1 { width: 10%; }\n.cell-2 { width: 20%; }\n.cell-3 { width: 30%; }\n.cell-4 { width: 40%; }\n.cell-5 { width: 50%; }\n\n/* Cell modifiers\n ========================================================================== */\n\n.cell--detail,\n.cell--important {\n border-width: 4px;\n}\n```\n\n\n\n## 7. Organização\n\nOrganização de código é uma importante parte de qualquer base de código CSS, e\ncrucial para grandes bases de código.\n\n* Separar logicamente distintas partes do código.\n* Usar arquivos separados (concatenados por um processo de build) para ajudar a\n dividir código para componentes distintos.\n* Se estiver usando um pré-processador, abstrair partes comuns de código em\n variáveis para cor, tipografia, etc.\n\n\n\n## 8. Build e deploy\n\nOs projetos devem sempre tentar incluir alguns meios genéricos pelos quais sua\nfonte possa ser avaliada, testada, comprimida e versionada em preparação para\nuso em produção. Para essa tarefa, o [grunt](https://github.com/cowboy/grunt)\npor Ben Alman é uma excelente ferramenta.\n\n\n\n## Agradecimentos\n\nObrigado a todos que contribuiram para\n[idiomatic.js](https://github.com/rwldrn/idiomatic.js). Foi uma fonte de\ninspiração, citações e diretrizes.\n"
},
{
"path": "translations/ru-RU/README.md",
"content": "# Принципы написания однородного CSS-кода\n\nЭтот документ представляет собой общие рекомендации по стилю написания CSS. Он\nне был задуман как набор жёстких правил, и мне бы не хотелось навязывать\nсобственные предпочтения другим людям. Тем не менее, данное руководство\nпризывает к использованию общепринятых и устоявшихся подходов к написанию\nкода.\n\nЭтот документ не закончен, и новые идеи всегда приветствуются. Пожалуйста,\nвнесите свой вклад.\n\n[«Принципы написания однородного CSS» на английском языке\n(Original)](https://github.com/necolas/idiomatic-css)\n\n\n## Содержание\n\n1. [Общие принципы](#general-principles)\n2. [Отступы](#whitespace)\n3. [Комментарии](#comments)\n4. [Форматирование](#format)\n5. [Именование](#naming)\n6. [Практический пример](#example)\n7. [Организация кода](#organization)\n8. [Сборка и развёртывание](#build-and-deployment)\n\n[Благодарности](#acknowledgements)\n\n\n\n## 1. Общие принципы\n\n> «Вы сослужите проекту хорошую службу, если будете осознавать, что написание\n> кода только для себя — Плохая Идея™. Если тысячи людей используют ваш код, то\n> пишите его максимально ясным и не делайте что-то только потому, что\n> спецификация языка допускает это». — Idan Gazit\n\n* Весь код в любом проекте должен выглядеть так, будто его создал один человек,\n вне зависимости от того, сколько людей на самом деле принимали участие.\n* Строго соблюдайте соглашения.\n* В сомнительных случаях используйте общепринятый подход.\n\n\n\n## 2. Отступы\n\nДля всего проекта должен применяться единый стиль отступов. Всегда будьте\nпоследовательны в использовании отступов и применяйте их для повышения\nчитабельности кода.\n\n* _Никогда_ не смешивайте пробелы и табуляцию.\n* Между табуляцией и мягкими отступами (пробелы вместо табуляции) выберите\n что-то одно. Придерживайтесь своего выбора, не делая исключений.\n(Предпочтение: пробелы)\n* Если вы используете пробелы, определитесь с количеством символов,\n соответствующим одному уровню отступа. (Предпочтение: 4 пробела)\n\nСовет: настройте редактор кода так, чтобы он отображал невидимые символы. Это\nпозволит избегать случайных пробелов в конце строк или в пустых строках и легче\nотслеживать изменения в коде.\n\n\n\n## 3. Комментарии\n\nХорошо откомментированный код очень важен. Потратьте время на то, чтобы описать\nкомпоненты, особенности их работы, ограничения и то, как они были созданы. Не\nзаставляйте других членов команды гадать над назначением неочевидного кода.\n\nСтиль комментариев должен быть простым и однородным для всего проекта.\n\n* Помещайте комментарий на строке перед комментируемым фрагментом кода.\n* Избегайте добавления комментариев в конец строки.\n* Установите обоснованную максимальную длину строки, например, 80 символов.\n* Свободно используйте комментарии для оформления разделов внутри CSS-файла.\n* Начинайте предложения с заглавной буквы, в конце ставьте точку, а также\n используйте однородные отступы.\n\nСовет: настройте в редакторе кода горячие клавиши для быстрого набора шаблонов\nкомментирования.\n\n#### Пример для CSS:\n\n```css\n/* ==========================================================================\n Блок комментариев для раздела\n ========================================================================== */\n\n/* Блок комментариев для подраздела\n ========================================================================== */\n\n/*\n * Блок комментариев для группы правил.\n * Хорошо подходит для подробных пояснений и документации.\n */\n\n/* Обычный комментарий */\n```\n\n#### Пример для SCSS:\n\n```scss\n// ==========================================================================\n// Блок комментариев для раздела\n// ==========================================================================\n\n// Блок комментариев для подраздела\n// ==========================================================================\n\n//\n// Блок комментариев для группы правил.\n// Хорошо подходит для подробных пояснений и документации.\n//\n\n// Обычный комментарий\n```\n\n\n\n## 4. Форматирование\n\nВыбранный формат записи кода должен гарантировать, что код легко читается; что\nего легко комментировать; должен минимизировать шанс случайного внесения\nошибки; и в результате обеспечивать удобство чтения сообщений внутри системы\nуправления версиями.\n\n1. При создании правила для нескольких селекторов помещайте каждый селектор на\n отдельной строке.\n2. Перед открывающей скобкой ставьте один пробел.\n3. Внутри блока объявлений помещайте каждое объявление на отдельной строке.\n4. Добавляйте один уровень отступов перед каждым объявлением.\n5. Ставьте пробел после двоеточия внутри объявления.\n6. Всегда ставьте точку с запятой после последнего объявления в блоке.\n7. Ставьте закрывающую скобку на одной вертикальной линии с первым символом в\n селекторе.\n8. Разделяйте правила пустой строкой.\n\n```css\n.selector-1,\n.selector-2,\n.selector-3 {\n -webkit-box-sizing: border-box;\n -moz-box-sizing: border-box;\n box-sizing: border-box;\n display: block;\n color: #333;\n background: #fff;\n}\n```\n\n#### Порядок объявлений\n\nОбъявления должны быть упорядочены по единому принципу. Я предпочитаю\nобъединять их по смыслу и помещать структурно важные свойства (например, те,\nчто отвечают за позиционирование и блочную модель) перед свойствами, связанными\nс типографикой, фоном и цветом.\n\n```css\n.selector {\n position: relative;\n display: block;\n width: 50%;\n height: 100px;\n padding: 10px;\n border: 0;\n margin: 10px;\n color: #fff\n background: #000;\n}\n```\n\nУпорядочение по алфавиту тоже популярно, но его минус в том, что связанные по\nсмыслу свойства оказываются разделены. К примеру, свойства, связанные с\nотступами, могут встречаться как в начале, так и в конце одного и того же\nблока определений.\n\n#### Исключения и небольшие отклонения\n\nК большим группам правил, состоящих из одного свойства, может применяться\nзапись в одну строку. В таком случае следует ставить пробел после открывающей и\nперед закрывающей скобками.\n\n```css\n.selector-1 { width: 10%; }\n.selector-2 { width: 20%; }\n.selector-3 { width: 30%; }\n```\n\nДлинные значения свойств, разделяемые запятыми — как, например, набор\nградиентов или теней — могут быть помещены на отдельной строке каждое, чтобы\nповысить читабельность кода и сообщений в системе управления версиями. Формат\nзаписи может слегка различаться, один из вариантов приведён ниже.\n\n```css\n.selector {\n box-shadow:\n 1px 1px 1px #000,\n 2px 2px 1px 1px #ccc inset;\n background-image:\n linear-gradient(#fff, #ccc),\n linear-gradient(#f3c, #4ec);\n}\n```\n\n#### Прочее\n\n* Пишите шестнадцатеричные значения в нижнем регистре, например, `#aaa`.\n* Последовательно используйте либо одинарные, либо двойные кавычки. Я\n предпочитаю двойные, к примеру, `content: \"\"`.\n* Всегда берите в кавычки значения атрибутов внутри селектора, например,\n `input[type=\"checkbox\"]`.\n* _Везде, где возможно_, опускайте единицы измерения при нулевом значении,\n например, `margin: 0`.\n\n### Препроцессоры: дополнительные соглашения\n\nРазные препроцессоры CSS имеют разный набор возможностей и различный\nсинтаксис. Ваши соглашения должны быть дополнены, чтобы отражать особенности\nиспользования конкретного препроцессора. Следующий набор правил относится\nк Sass.\n\n* Ограничивайте вложенность одним уровнем. Пересмотрите все правила, в которых\n больше двух уровней вложенности. Это позволит избегать чрезмерной\n специфичности правил.\n* Избегайте большого числа вложенных правил. Оформляйте их отдельно,\n когда их становится трудно читать. Предпочтительно ограничивать длину\n вложенных правил 20 строками.\n* Всегда помещайте оператор `@extend` в первой строке блока объявлений.\n* По возможности группируйте операторы `@include` в начале блока объявлений,\n сразу после `@extend`.\n* Подумайте над добавлением префикса вида `x-` перед своими функциями. Это\n позволит избежать возможной путаницы между вашими функциями и стандартными\n функциями CSS, а также функциями из сторонних библиотек.\n\n```scss\n.selector-1 {\n @extend .other-rule;\n @include clearfix();\n @include box-sizing(border-box);\n width: x-grid-unit(1);\n // прочие объявления\n}\n```\n\n\n\n## 5. Именование\n\nВы не компилятор и не компрессор кода, поэтому ведите себя соответственно.\n\nИспользуйте понятные и осмысленные имена для классов в HTML. Выберите ясный и\nпоследовательный шаблон именования, который будет удобен как для HTML, так и\nдля CSS.\n\n```css\n/* Пример кода с плохими именами */\n\n.s-scr {\n overflow: auto;\n}\n\n.cb {\n background: #000;\n}\n\n/* Пример лучшего подхода к именованию */\n\n.is-scrollable {\n overflow: auto;\n}\n\n.column-body {\n background: #000;\n}\n```\n\n\n\n## 6. Практический пример\n\nПример использования нескольких соглашений.\n\n```css\n/* ==========================================================================\n Макет сетки\n ========================================================================== */\n\n/*\n * HTML для примера:\n *\n * \n */\n\n.grid {\n overflow: visible;\n height: 100%;\n /* Предотвращаем перенос строчных блоков на новую строку */\n white-space: nowrap;\n /* Убираем пробелы между ячейками сетки */\n font-size: 0;\n}\n\n.cell {\n box-sizing: border-box;\n position: relative;\n overflow: hidden;\n width: 20%;\n height: 100%;\n /* Задаём отступы внутри ячеек */\n padding: 0 10px;\n border: 2px solid #333;\n vertical-align: top;\n /* Восстанавливаем поведение по умолчанию */\n white-space: normal;\n /* Восстанавливаем размер шрифта */\n font-size: 16px;\n}\n\n/* Состояния ячеек */\n\n.cell.is-animating {\n background-color: #fffdec;\n}\n\n/* Размеры ячеек\n ========================================================================== */\n\n.cell-1 { width: 10%; }\n.cell-2 { width: 20%; }\n.cell-3 { width: 30%; }\n.cell-4 { width: 40%; }\n.cell-5 { width: 50%; }\n\n/* Модификаторы для ячеек\n ========================================================================== */\n\n.cell--detail,\n.cell--important {\n border-width: 4px;\n}\n```\n\n\n\n## 7. Организация кода\n\nОрганизация кода — важная часть любого проекта на CSS и ключевой элемент в\nбольшом проекте.\n\n* Логически отделяйте различные части кода.\n* Используйте отдельные файлы (объединяемые на этапе сборки), чтобы разделить\n код обособленных компонентов.\n* При использовании препроцессора оформляйте часто используемый код в\n переменные, например, для типографики, цветов и т.д.\n\n\n\n## 8. Сборка и развёртывание\n\nВ любом проекте по возможности должны использоваться средства для проверки,\nтестирования, сжатия и управления версиями кода при подготовке к развёртыванию.\nХороший инструмент для этих задач —\n[grunt](https://github.com/cowboy/grunt), написанный Ben Alman.\n\n\n\n## Благодарности\n\nСпасибо всем, кто внёс вклад в проект\n[idiomatic.js](https://github.com/rwldrn/idiomatic.js). Это мой источник\nвдохновения, цитат и общих рекомендаций.\n"
},
{
"path": "translations/sr-SR/README.md",
"content": "# Principi pisanja konzistentnog, idiomatskog CSS-a\n\nSledeći dokument ocrtava razumne stilove za CSS razvoj. Nije namenjen da bude\nperskriptivan i ja ne želim da namećem svoje preferencije stilova na kod drugih\nljudi. Međutim, ove smernice snažno ohrabruju korišćenje postojećih,\nzajedničkih, razumnih šema.\n\nOvo je \"živi\" dokument i nove ideje su uvek dobrodošle. Molimo Vas da\ndoprinesete.\n\n[Idiomatski CSS na Engleskom (Original)](https://github.com/necolas/idiomatic-css)\n\n\n## Sadržaj\n\n1. [Generalni principi](#general-principles)\n2. [Znaci za razmake](#whitespace)\n3. [Komentari](#comments)\n4. [Formatiranje](#format)\n5. [Imenovanje](#naming)\n6. [Praktični primeri](#example)\n7. [Organizovanje](#organization)\n8. [Izrada i razvoj](#build-and-deployment)\n\n[Priznanja](#acknowledgements)\n\n\n\n## 1. Generalni principi\n\n> \"Deo zaduženja dobrog stjuarda za uspešan projekat je shvatanje da pisanje\n> koda za samog sebe je loša ideja™. Ako hiljade ljudi koristi tvoj kod, onda\n> piši tvoj kod sa maksimalnom jasnoćom, a ne sa svojim personalnim\n> preferencijama o tome kako da se napraviš pametan u okviru specifikacije.\" -\n> Idan Gazit\n\n* Sav kod u bilo kom projektu bi trebao da izgleda kao da ga je pisala jedna\n osoba, bez obzira koliko je ljudi doprinelo razvoju projekta.\n* Striktno primenjujte dogovoreni stil.\n* Ako ste u sumnji, koristite postojeće, zajedničke šablone.\n\n\n\n## 2. Znaci za razmake\n\nSamo jedan stil bi trebao da postoji u celom vašem projektu. Uvek budite\nkonzistentni u upotrebi razmaka. Koristite razmake da poboljšate čitljivost.\n\n* _Nikada_ nemojte mešati space karakter i tab za indentaciju.\n* Izaberite između mekih indentacija(space karakteri) i pravih tabova. Držite se\nvašeg izbora bez obzira na sve. (Preferencija: space karakteri)\n* Ako koristite space karaktere, izaberite broj karaktera za indentacioni nivo.\n(Preferencija: 4 space karaktera)\n\nSavet: konfigurišite vaš editor da prikazuje \"nevidljive karaktere\". Ovo će vam\nomogućiti da eliminišete prazne karaktere na kraju linije, da eliminišete space\nkaraktere praznim linijama i da izbegnete \"zagađivanje\" komitova.\n\n\n\n## 3. Komentari\n\nDobro komentarisan kod je ekstremno bitan. Uzmite vremena da opišete komponente,\nkako rade, njihove limite, i način na koji su konstruisani. Nemojte ostavljati\ndrugim članovima tima da nagađaju svrhu neuobičajenih i ne očiglednih delova\nkoda.\n\nStil komentara treba da bude jednostavan i konzistentan u celom projektu.\n\n* Postavljajte komentare na novu liniju iznad dela koda koji hoćete da\niskomentarišete.\n* Izbegavajte komentare na kraju linije koda.\n* Držite dužinu linije na razumnom maksimumu, npr 80 kolona.\n* Slobodno koristite komentare da \"razbijete\" CSS kod na diskretne sekcije.\n* Koristite komentare dužine jedne rečenice i konzistentno indentovanje teksta.\n\n\nSavet: konfigurišite vaš editor da vam omogući prečice za ispisivanje unapred\ndogovorenog šablona za komentare.\n\n#### CSS primer:\n\n```css\n/* ==========================================================================\n Blok komentar za odeljak\n ========================================================================== */\n\n/* Blok komentar za pododeljak\n ========================================================================== */\n\n/*\n * Blok komentar za grupu.\n * Idealan za objašnjavanja koja se protežu u više redova i dokumentaciju.\n */\n\n/* Običan komentar */\n```\n\n#### SCSS primer:\n\n```scss\n// ==========================================================================\n// Blok komentar za odeljak\n// ==========================================================================\n\n// Blok komentar za pododeljak\n// ==========================================================================\n\n//\n// Blok komentar za grupu.\n// Idealan za objašnjavanja koja se protežu u više redova i dokumentaciju.\n//\n\n// Običan komentar\n```\n\n\n\n## 4. Formatiranje\n\nIzabrani tip formatiranja koda mora da obezbedi da je kod: lak za čitanje; lak\nda se jasno komentariše; minimizuje šanse da se slučajno uvedu greške; i\nrezultira korisnim `diff` i `blame` komandama u vašem sistemu za kontrolu\nverzija.\n\n1. Jedan selektor na jednu liniju kada koristite više selektora u jednom setu\n pravila.\n2. Jedan space karakter pre otvarajuće zagrade za set pravila.\n3. Jedna deklaracija na jednu liniju unutar seta pravila.\n4. Jedan nivo indentacije za svaku deklaraciju.\n5. Jedan space karakter nakon dve tačke u deklaraciju.\n6. Uvek stavite tačku-zarez na kraju poslednje deklaracije u deklarativnom\n bloku.\n7. Stavite zatvarajuću zagradu seta pravila u istu kolonu gde se nalazi prvi\n karakter selektora tog seta pravila.\n8. Razdvojite svaki set pravila praznom linijom.\n\n```css\n.selektor-1,\n.selektor-2,\n.selektor-3 {\n -webkit-box-sizing: border-box;\n -moz-box-sizing: border-box;\n box-sizing: border-box;\n display: block;\n color: #333;\n background: #fff;\n}\n```\n\n#### Redosled deklaracija\n\nDeklaracije bi trebale biti poređane u skladu sa jednim principom. Moje\npreferencije su da slična svojstva budu grupisana zajedno i da strukturno bitna\nsvojstva (npr pozicioniranje i box-model) budu deklarisana pre svojstava\nza tipografiju, pozadine i boje.\n\n```css\n.selektor {\n position: relative;\n display: block;\n width: 50%;\n height: 100px;\n padding: 10px;\n border: 0;\n margin: 10px;\n color: #fff\n background: #000;\n}\n```\n\nAlfabetni redosled je isto popularan, ali mana mu je da razdvaja slična\nsvojstva. Na primer, svojstva za pomeranja pozicija više nisu grupisana zajedno\ni box-model svojstva mogu da završe raširena kroz ceo deklarativni blok.\n\n#### Izuzeci i mala odstupanja\n\nVeliki blokovi gde se nalaze deklaracije u samo jednoj liniji mogu koristiti\nmalo izmenjen format na jednoj liniji. U ovom slučaju space karakter se\npostavlja posle otvarajuće i pre zatvarajuće zagrade.\n\n```css\n.selektor-1 { width: 10%; }\n.selektor-2 { width: 20%; }\n.selektor-3 { width: 30%; }\n```\n\nDugačka svojstva koja su razdvojena zarezom, kao što su na primer kolekcija\ngradijenta ili senka, mogu biti raspoređena preko više linija sve sa ciljem\npoboljšanja čitljivosti, a takođe da može da proizvede bolji `diff`. Postoje\nrazni formati koji bi mogli biti korišćeni, jedan primer je prikazan ispod.\n\n```css\n.selector {\n box-shadow:\n 1px 1px 1px #000,\n 2px 2px 1px 1px #ccc inset;\n background-image:\n linear-gradient(#fff, #ccc),\n linear-gradient(#f3c, #4ec);\n}\n```\n\n#### Razno\n\n* Koristite heksadecimalne vrednosti sa malim slovim, npr `#aaa`.\n* Koristite jedan ili dupli apostrof konzistentno. Preferencija je da se\n koriste dupli apostrofi, npr `content: \"\"`.\n* Vrednosti atributa u selektorima uvek stavljajte između apostrofa, npr\n `input[type=\"checkbox\"]`.\n* _Gde je moguće_ izbegavajte specifiranje jedinica za nula vrednosti, npr\n `margin: 0`.\n\n### Preprocesori: dodatna razmatranja za formatiranje\n\nRazličiti CSS preprocesori imaju drugačije karakteristike, funkcionalnosti i\nsintaksu. Vaše konvencije bi trebale biti proširene da prime specifičnosti\npreprocesora u upotrebi. Sledeće smernice su napomene za Sass.\n\n* Limitirajte ugnežđenja na 1 nivo dubine. Preispitajte sva gneždenja koja su\n dublja od 2 nivoa. Ovo sprečava previše specifične CSS selektore.\n* Izbegavajte preveliki boj ugneždenih pravila. Razbijte ih na manje delove\n kada to počne da utiče na čitljivost. Preferencije su da izbegavate gnežđenja\n koja se rasprostiru na više od 20 linija.\n* Uvek postavite `@extend` izjave na prvu liniju deklarativnog bloka.\n* Gde je moguće, grupišite `@include` izjave na vrhu deklarativnog bloka, nakon\n svih `@extend` izjava.\n* Razmotrite upotrebu prefiksa kod custom funkcija sa `x-` ili drugim\n namespace-om. Ovo pomaže da se izbegne bilo kakav potencijal da se pobrkaju\n vaše funkcije sa nativnim CSS funkcijama, ili da dođe do \"sukoba\" sa\n funkcijama iz drugih biblioteka.\n\n```scss\n.selektor-1 {\n @extend .other-rule;\n @include clearfix();\n @include box-sizing(border-box);\n width: x-grid-unit(1);\n // druge deklaracije\n}\n```\n\n\n\n## 5. Imenovanje\n\nTi nisi ljudski kompajler/kompresor za kod, tako da ne pokušavaj da budeš to.\n\nKoristi jasna i pažljivo izabrana imena za HTML klase. Izaberi razumljive i\nkonzistentne šeme za imenovanje koje imaju smisla za korišćenje i u HTML\nfajlovima i u CSS fajlovima.\n\n```css\n/* Primer koda sa lošim imenovanjem */\n\n.s-scr {\n overflow: auto;\n}\n\n.cb {\n background: #000;\n}\n\n/* Primer koda sa boljim imenovanjem */\n\n.is-scrollable {\n overflow: auto;\n}\n\n.column-body {\n background: #000;\n}\n```\n\n\n\n## 6. Praktični primeri\n\nPrimeri raznih konvencija.\n\n```css\n/* ==========================================================================\n Grid layout\n ========================================================================== */\n\n/*\n * HTML example:\n *\n * \n */\n\n.grid {\n overflow: visible;\n height: 100%;\n /* Prevent inline-block cells wrapping */\n white-space: nowrap;\n /* Remove inter-cell whitespace */\n font-size: 0;\n}\n\n.cell {\n box-sizing: border-box;\n position: relative;\n overflow: hidden;\n width: 20%;\n height: 100%;\n /* Set the inter-cell spacing */\n padding: 0 10px;\n border: 2px solid #333;\n vertical-align: top;\n /* Reset white-space */\n white-space: normal;\n /* Reset font-size */\n font-size: 16px;\n}\n\n/* Cell states */\n\ncell.is-animating {\n background-color: #fffdec;\n}\n\n/* Cell dimensions\n ========================================================================== */\n\n.cell-1 { width: 10%; }\n.cell-2 { width: 20%; }\n.cell-3 { width: 30%; }\n.cell-4 { width: 40%; }\n.cell-5 { width: 50%; }\n\n/* Cell modifiers\n ========================================================================== */\n\n.cell--detail,\n.cell--important {\n border-width: 4px;\n}\n```\n\n\n\n## 7. Organizacija\n\nOrganizacija koda je važan deo za svaku bazu CSS koda i krucijalan za velike\nbaze koda.\n\n* Logična separacija posebnih delova koda.\n* Koristite odvojene fajlove(spojene u delu izgradnje za produkciju) da vam\n pomogne da razbijete kod u više posebnih komponenti.\n* Ako koristite preprocesor, abstraktujte uobičajene delove koda u promenljive,\n npr boje, tipografiju, itd.\n\n\n\n## 8. Izgradnja i razvoj\n\nProjekti bi uvek trebalo da uključe neki generički način da se izvorni kod\n\"lintuje\", testira i kompresuje u pripremi za upotrebu u produkciji. Za ovaj\nzadatak, [grunt](https://github.com/cowboy/grunt) od strane Ben Alman-a je\nodlična alatka.\n\n\n## Priznanja\n\nHvala svima koji su doprineli\n[idiomatic.js](https://github.com/rwldrn/idiomatic.js) projektu. Taj projekat\nje bio izvor inspiracije, citata i smernica.\n"
},
{
"path": "translations/tr-TR/README.md",
"content": "# Tutarlı, İdiomatic CSS yazma prensipleri\n\nAşağıdaki döküman CSS geliştirme konusunda makul bir stil rehberini içerir.\nKuralcı olması ve düşünülmedi ve kendi stil seçimlerini diğer kişilerin koduna\nempose etmek istemiyorum. Ama bu yönergeler varolan yaygın ve mantıklı\nkalıpların kullanımını teşvik etmektedir.\n\nBu yaşayan bir dökümandır ve yeni fikirler daima hoş karşılanacak. Lütfen\nkatkıda bulunun.\n\n[İngilizce İdiomatik CSS (Orijinal)](https://github.com/necolas/idiomatic-css)\n\n\n## İçindekiler\n\n1. [Genel Prensipler](#general-principles)\n2. [Beyaz Alanlar](#whitespace)\n3. [Açıklamalar](#comments)\n4. [Format](#format)\n5. [İsimlendirme](#naming)\n6. [Uygulanabilir Örnek](#example)\n7. [Organizasyon](#organization)\n8. [Yapı ve Dağıtma](#build-and-deployment)\n\n[Acknowledgements](#acknowledgements)\n\n\n\n## 1. Genel Prensipler\n\n> \"Başarılı bir projenin iyi bir temsilci olmanın bir bölümü kendin için kod\n> yazmanın kötü bir fikir olduğunun farkına varmaktır. Eğer binlerce insan\n> senin kodunun kullanıyorlarsa, o zaman kodunu, şartnameler dahilinde nasıl\n> akıllılık yapacağın kişisel seçimlere göre değil maksimum açıklık için yaz.\"\n> - Idan Gazit\n\n* Herhangi bir kod tababındaki tüm kod, kaç kişi katkıda bulunumuş olursa olsun\n sanki tek bir kişi tarafından yazılmış gibi görünmelidir.\n* Strictly enforce the agreed upon style.\n* Karar verilen stili katı bir şekilde uygula.\n* Eğer şüphen varsa yaygın olarak kullanılan yönergeleri uygula.\n\n\n\n## 2. Beyaz Alanlar\n\nProjenin tüm kaynağında sadece tek bir stil hüküm sürmelidir. Beyaz alan\nkullanımında her zaman tutarlı ol. Beyaz alanları okunabilirliği artırmak için\nkullan.\n\n* _Asla_ girintiler için boşluk ve tabları karıştırma.\n* Yumuşak girintiler (boşluklar) veya gerçek tablar arasında bir seçim yap.\n Seçimine sadık kal. (Tercih: boşluklar)\n* Eğer boşluk kullanıyorsan girinti bölümü için kullanılan karakter saysını\n seç. (Tercih: 4 boşluk)\n\nİpucu: Editörünü \"görünmezleri göster\" şeklinde ayarla. Bu, satır sonu\nboşluklarının ve kasıtsız boş satırların önüne geçmeni ve \"commit\"lerin\nkirlenmemesini sağlayacaktır.\n\n\n\n## 3. Açıklamalar\n\nİyi açıklanmış kod son derece önemlidir. Bileşenleri tanımlamak, nasıl\nçalıştıklarını, sınırlamalarını ve nasıl yapıldıklarını açıklamakk için zaman\nayır. Takımdaki diğer kişileri yaygın veya açık olmayan kodu tahmin etmek\nzorunda bırakma.\n\nAçıklama stili basit ve tek bir kod tabanı içinde tutarlı olmalıdır.\n\n* Açıklamaları iligili öznelerinin üzerinde yeni satıra koy.\n* Satır sonu açıklamalarından kaçın.\n* Satır uzunluğunu makul bir uzunlukta tut. Ör: 80 sütun.\n* CSS kodu farklı aralıklarda kısımlara bölmek için açıklamaları özgürce\n kullan.\n* Cümle yapısında açıklamalar yap ve tutarlı girintileme kullan.\n\nİpucu: Editörünü karar vediğin açıklama bloklarının çıktısını verecek şekilde\nayarla.\n\n#### CSS örneği:\n\n```css\n/* ==========================================================================\n Kısım açıklama bloğu\n ========================================================================== */\n\n/* Alt-kısım açıklama bloğu\n ========================================================================== */\n\n/*\n * Grup açıklama bloğu\n * Birden fazla satır açıklamalar ve dökümantasyon için ideal.\n */\n\n/* Basit açıklama / yorum */\n```\n\n#### SCSS örneği:\n\n```scss\n// ==========================================================================\n// Kısım açıklama bloğu\n// ==========================================================================\n\n// Alt-kısım açıklama bloğu\n// ==========================================================================\n\n//\n// Grup açıklama bloğu\n// Birden fazla satır açıklamalar ve dökümantasyon için ideal.\n//\n\n// Basit açıklama / yorum\n```\n\n\n\n## 4. Format (Biçem)\n\nSeçilen kod formatı (biçemi) kodun; kolay okunabildiğinden, kolay açıklanabilir\n(yorumlamanabilir) olduğundan, kazara hataların oluşmasını minimuma\nindirdiğinden ve faydalı \"diff\" ve hatalar ürettiğinden emin olmalıdır.\n\n1. Çoklu seçicilerin olduğu kural setlerinde her satırda tek bir seçici.\n2. Kural setinin açış parantezi önünde tek bir boşluk.\n3. Her deklarasyon bloğunda her satırda tek bir deklarasyon.\n4. Her bir deklarasyon için bir girinti seviyesi.\n5. Deklarasyondaki iki noktadan sonra tek bir boşluk.\n6. Her deklarayon bloğundaki son deklarasyondan sonra mutlaka bir noktalı\n virgül kullan\n7. Bir kural setinin sonundaki parantezi o kural setindeki ilk karakter ile\n aynı sütuna koy.\n8. Her kural setini boş bir satır ile ayır.\n\n```css\n.selector-1,\n.selector-2,\n.selector-3 {\n -webkit-box-sizing: border-box;\n -moz-box-sizing: border-box;\n box-sizing: border-box;\n display: block;\n color: #333;\n background: #fff;\n}\n```\n\n#### Deklarasyon sırası\n\nDeklarasyonlar tek bir prensibe göre sıralandırılmalıdırlar. Benim seçimim\nilişkili özellikleri beraber gruplamak ve yapısal önemi olan özellikleri (ör:\nposizyonlama ve box-model) tipografik, arka plan ve renk özelliklerinden önce\nyapmak şeklinde.\n\n```css\n.selector {\n position: relative;\n display: block;\n width: 50%;\n height: 100px;\n padding: 10px;\n border: 0;\n margin: 10px;\n color: #fff\n background: #000;\n}\n```\n\nAlfabetik sıralama da oldukça popüler ama bunun kusuru ise ilişkili özellikleri\nbirbirinden ayırması. Örneğin posizyon offsetleri artık beraber gruplanmış\ndeğil ce box-model özellikleri deklarasyon bloğu içinde yayılmış olacaklar.\n\n#### İstisnalar ve ufak sapmalar\n\nTek deklarasyonlu büüyük bloklar biraz daha farklı tek-satır bir biçem\nkullanabilirler. Bu açılış parantezinden sonra ve kapanış parantezinden önce\nbir boşluk olmalıdır.\n\n```css\n.selector-1 { width: 10%; }\n.selector-2 { width: 20%; }\n.selector-3 { width: 30%; }\n```\n\nVirgülle ayrılmış uzun özellik değerleri - gradient ve gölgeler gibi -\nokunabilirliği arttırmak ve daha faydalı \"diff\"ler yaratmak için birden fazla\nsatıra yayılabilirler. Bunun için kullanılabilecek çeşitli biçemler var. Bir\nörnek aşağıda.\n\n```css\n.selector {\n box-shadow:\n 1px 1px 1px #000,\n 2px 2px 1px 1px #ccc inset;\n background-image:\n linear-gradient(#fff, #ccc),\n linear-gradient(#f3c, #4ec);\n}\n```\n\n#### Diğer\n\n* Hex değerlerinde küçük harf kullan, ör., `#aaa`.\n* Tek veya çift tırnağı tutarlı kullanın. Tercih çift tırnaktan yana, ör.,\n `content: \"\"`.\n* Seçicilerdeki özellik değerlerini her zaman tırnak içine alın, ör.,\n `input[type=\"checkbox\"]`.\n* _Mümkün olduğu durumlarda_, sıfır değerler için ünite kullanmayın, ör.,\n `margin: 0`.\n\n### Preprocessors (Önderleyiciler) : dikkate alınacak ek formatlar (biçem)\n\nFarklı CSS önderleyicileri farklı özelliklere, işlevselliğe ve sözdizimine\n(syntax) sahipler. Kurallarınız kullanılmakta olan önderleyecinin özellikleri\nile uyum sağlayacak şekilde olmalıdır. Aşağıdaki yönergeler Sass'ı referans\nalarak verilmiştir.\n\n* Gömmeyi (nesting) sadece 1 bölüm olacak şekilde sınırla. İki seviyeden fazla\n olan bütün gömmeleri gözden geçir. Bu aşırı spesifik CSS seçicilerini\n engeller.\n* Yüksek sayıdaki gömme kurallarını engellemeye çalış. Okunabilirlik\n etkilenmeye başladıkça bunları küçük parçalara böl. Tercih 20 satırı aşan\n gömmelerin önüne geçmek.\n* `@extend` ifadelerini deklarasyon bloğunun ilk satırına koy.\n* Mümkün oldukça `@include` ifadelerini deklarasyon bloğunun tepesine `@extend`\n ifadelerinden sonrasına koy.\n* özel fonksiyonları `x-` veya başka bir isim alanı ile başlat. Bu özel\n fonsiyonların CSS fonksiyonları ile karşımasına veya başka kütüphaneler ile\n çakışmasına engel olur.\n\n```scss\n.selector-1 {\n @extend .other-rule;\n @include clearfix();\n @include box-sizing(border-box);\n width: x-grid-unit(1);\n // other declarations\n}\n```\n\n\n\n## 5. İsimlendirme\n\nSen bir insan kod derleyicisi/sıkıştırıcı değilsin, dolayısı ile olmaya da\nçalışma.\n\nHTML sınıfları için açık ve iyi düşünülmüş isimler kullan. He HTML hem de CSS\ndosyalarında anlamı olan tutarlı bir isimlendirme şekli seç.\n\n```css\n/* Kötü isim örnekleri kodu */\n\n.s-scr {\n overflow: auto;\n}\n\n.cb {\n background: #000;\n}\n\n/* Daha iyi isimli örneklerin kodu */\n\n.is-scrollable {\n overflow: auto;\n}\n\n.column-body {\n background: #000;\n}\n```\n\n\n\n## 6. Uygulanabilir örnek\n\nÇeşitli teammüllerin örnekleri.\n\n```css\n/* ==========================================================================\n Grid layout\n ========================================================================== */\n\n/*\n * Örnek HTML:\n *\n * \n */\n\n.grid {\n overflow: visible;\n height: 100%;\n /* inline-block hücrelerin fazla satıra yayılmasını engelle */\n white-space: nowrap;\n /* Hücre içindeki beyaz alanları kaldır */\n font-size: 0;\n}\n\n.cell {\n box-sizing: border-box;\n position: relative;\n overflow: hidden;\n width: 20%;\n height: 100%;\n /* Hücre arası boşluğu ayarla */\n padding: 0 10px;\n border: 2px solid #333;\n vertical-align: top;\n /* Beyaz alanları sıfırla */\n white-space: normal;\n /* Font büyüklüğünü sıfırla */\n font-size: 16px;\n}\n\n/* Hücre durumları */\n\n.cell.is-animating {\n background-color: #fffdec;\n}\n\n/* Hücre boyutları\n ========================================================================== */\n\n.cell-1 { width: 10%; }\n.cell-2 { width: 20%; }\n.cell-3 { width: 30%; }\n.cell-4 { width: 40%; }\n.cell-5 { width: 50%; }\n\n/* Hücre değişiklikleri\n ========================================================================== */\n\n.cell--detail,\n.cell--important {\n border-width: 4px;\n}\n```\n\n\n\n## 7. Organizasyon\n\nKod organizsayonu bütün CSS kod tabanları için önemlidir ve büyük kod tabanları\niçinse kritik önem taşır.\n\n* Kodun farklı bölümlerini mantıksal bir şekilde ayır.\n* Farklı bileşenleri ayırmak için ayrı dosyalar (inşa sırasında birleştirilen)\n kullan.\n* Eğer bir önderleyici kullanıyorsan, renk, tipografi gibi genel kodları\n değişkenlerle soyutla.\n\n\n\n## 8. Yapı ve Dağıtma (Build and deployment)\n\nProjeler, kaynağın bir şekilde lint edilebileceği, sıkıştırılabileceği, test\nedilebileceği, ve üretim için sürümlendirilebileceği soysal (jenerik) bir\nyöntem içermelidir. Bunun için Ben Alman'ın\n[grunt](https://github.com/cowboy/grunt)'ı mükemmel bir araç.\n\n\n\n## Teşekkürler\n\nİlham, alıntı ve kılavuz bir kaynak olan\n[idiomatic.js](https://github.com/rwldrn/idiomatic.js)'ye katkıda bulunan\nherkese teşekkürler.\n"
},
{
"path": "translations/zh-CN/README.md",
"content": "# 编写如一、符合习惯的CSS的原则\n\n以下文档将概述一个合理的CSS开发风格指导。本指导文件强烈鼓励开发者使用已经存在了的、常见的、合力的文风。您应该有选择地吸纳一些内容来创造您自己的风格指南。\n\n这个文档将持续更新，欢迎提出新的想法。还请多多贡献。\n\n[Principles of writing consistent, idiomatic CSS（原版）](https://github.com/necolas/idiomatic-css)\n\n\n## 目录\n\n1. [通用原则](#general-principles)\n2. [空格](#whitespace)\n3. [注释](#comments)\n4. [格式](#format)\n5. [命名](#naming)\n6. [实例](#example)\n7. [代码组织](#organization)\n8. [构建及部署](#build-and-deployment)\n\n[致谢](#acknowledgements)\n\n\n\n## 1. 通用原则\n\n> “作为成功的项目的一员，很重要的一点是意识到只为自己写代码是很糟糕的行为。如果将有成千上万人使用你的代码，\n> 那么你需要编写最具明确性的代码，而不是以自我的喜好来彰显自己的智商。” - Idan Gazit\n\n* 别想着过早地优化代码。先得保证它们可读又可理解才行。\n* 在任何代码库中，无论有多少人参与及贡献，所有代码都应该如同一个人编写的一样。\n* 严格执行一致认可的风格。\n* 如果有疑议，则使用现有的、通用的模式。\n\n\n\n## 2. 空格\n\n在项目的所有代码中，应该只有一个风格。在空格的使用上，必须始终保持一致。使用空格来提高可读性。\n\n* *永远不要*在缩进时混用空格和制表符（又称TAB符号）。\n* 在软缩进（使用空格）和真正的制表符间选择其一，并始终坚持这一选择。（推荐使用空格）\n* 如果使用空格进行缩进，选择每个缩进所使用的空格数。（推荐：4个空格）\n\n提示：将编辑器配置为“显示不可见内容”。这使你可以清除行尾的空格和不需要缩进的空行里的空格，同时可以避免对注释的污染。\n\n提示：确定好一种空格格式后，您可以用一个[EditorConfig](http://editorconfig.org/)文件（或者其他相同的东西）来帮助在代码库之间维持这种基本的空格约定。\n\n\n## 3. 注释\n\n良好的注释是非常重要的。请留出时间来描述组件（component）的工作方式、局限性和构建它们的方法。不要让你的团队其它成员\n来猜测一段不通用或不明显的代码的目的。\n\n注释的风格应当简洁，并在代码库中保持统一。\n\n* 将注释放在主题上方并独占一行。\n* 控制每行长度在合理的范围内，比如80个字符。\n* 使用注释从字面上将CSS代码分隔为独立的部分。\n* 注释的大小写应当与普通句子相同，并且使用一致的文本缩进。\n\n提示：通过配置编辑器，可以提供快捷键来输出一致认可的注释模式。\n\n#### CSS示例：\n\n```css\n/* ==========================================================================\n 区块代码注释\n ========================================================================== */\n\n/* 次级区块代码注释\n ========================================================================== */\n\n/**\n * “Doxygen式注释格式”的简短介绍\n *\n * 较长的说明文本从这里开始，这是这段文字的第一句话，而且这句话还\n * 没结束，过了好一会儿，我了个去终于结束了，烦不烦啊。\n *\n * 当需要进行更细致的解释说明、提供文档文本时，较长的说明文本就很\n * 有用了。这种长长的说明文本，可以包括示例HTML啦、链接啦等等其\n * 他你认为重要或者有用的东西。\n *\n * @tag 这是一个叫做“tag”的标签。\n *\n * TODO: 这个“‘需做’陈述”描述了一个接下来要去做的小工作。这种文本，\n * 如果超长了的话，应该在80个半角字符（如英文）或40个全角字符（\n * 如中文）后便换行，并（在“ * ”的基础上）再在后面缩进两个空格。\n */\n\n/* 一般的注释 */\n```\n\n\n## 4. 格式\n\n最终选择的代码风格必须保证：易于阅读，易于清晰地注释，最小化无意中引入错误的可能性，可生成有用的diff和blame。\n\n1. 在多个选择器的规则集中，每个单独的选择器独占一行。\n2. 在规则集的左大括号前保留一个空格。\n3. 在声明块中，每个声明独占一行。\n4. 每个声明前保留一级缩进。\n5. 每个声明的冒号后保留一个空格。\n6. 对于声明块的最后一个声明，始终保留结束的分号。\n7. 规则集的右大括号保持与该规则集的第一个字符在同一列。\n8. 每个规则集之间保留一个空行。\n\n```css\n.selector-1,\n.selector-2,\n.selector-3[type=\"text\"] {\n -webkit-box-sizing: border-box;\n -moz-box-sizing: border-box;\n box-sizing: border-box;\n display: block;\n font-family: helvetica, arial, sans-serif;\n color: #333;\n background: #fff;\n background: linear-gradient(#fff, rgba(0, 0, 0, 0.8));\n}\n\n.selector-a,\n.selector-b {\n padding: 10px;\n}\n```\n\n#### 声明顺序\n\n样式声明的顺序应当遵守一个单一的原则。我的倾向是将相关的属性组合在一起，并且将对结构来说比较重要的属性（如定位或者盒模型）\n放在前面，先于排版、背景及颜色等属性。\n\n小型的开发团体，可能会想要把相关的属性声明（比如说定位和箱模型）摆在一起。\n\n```css\n.selector {\n /* Positioning */\n position: absolute;\n z-index: 10;\n top: 0;\n right: 0;\n bottom: 0;\n left: 0;\n\n /* Display & Box Model */\n display: inline-block;\n overflow: hidden;\n box-sizing: border-box;\n width: 100px;\n height: 100px;\n padding: 10px;\n border: 10px solid #333;\n margin: 10px;\n\n /* Other */\n background: #000;\n color: #fff;\n font-family: sans-serif;\n font-size: 16px;\n text-align: right;\n}\n```\n\n大型团队，则可能更喜欢按字母排序，因为这样做起来很方便，而且维护起来很容易。\n\n#### 例外及细微偏移原则的情况\n\n对于大量仅包含单条声明的声明块，可以使用一种略微不同的单行格式。在这种情况下，在左大括号之后及右大括号之前都应该保留一个空格。\n\n```css\n.selector-1 { width: 10%; }\n.selector-2 { width: 20%; }\n.selector-3 { width: 30%; }\n```\n\n对于以逗号分隔并且非常长的属性值 -- 例如一堆渐变或者阴影的声明 -- 可以放在多行中，这有助于提高可读性，并易于生成有效的diff。这种情况下有多\n种格式可以选择，以下展示了一种格式。\n\n```css\n.selector {\n box-shadow:\n 1px 1px 1px #000,\n 2px 2px 1px 1px #ccc inset;\n background-image:\n linear-gradient(#fff, #ccc),\n linear-gradient(#f3c, #4ec);\n}\n```\n\n#### 杂项\n\n* 在十六进制值中，使用小写，如`#aaa`。\n* 单引号或双引号的选择保持一致。推荐使用双引号，如`content: \"\"`。\n* 对于选择器中的属性值也加上引号，如`input[type=\"checkbox\"]`。\n* *如果可以的话*，不要给0加上单位, 如`margin: 0`。\n\n### 预处理：格式方面额外的考虑\n\n不同的CSS预处理有着不同的特性、功能以及语法。编码习惯应当根据使用的预处理程序进行扩展，以适应其特有的功能。推荐在使用SCSS时遵守以下指导。\n\n* 将嵌套深度限制在1级。对于超过2级的嵌套，给予重新评估。这可以避免出现过于详实的CSS选择器。\n* 避免大量的嵌套规则。当可读性受到影响时，将之打断。推荐避免出现多于20行的嵌套规则出现。\n* 始终将`@extend`语句放在声明块的第一行。\n* 如果可以的话，将`@include`语句放在声明块的顶部，紧接着`@extend`语句的位置。\n* 考虑在自定义函数的名字前加上`x-`或其它形式的前缀。这有助于避免将自己的函数和CSS的原生函数混淆，或函数命名与库函数冲突。\n\n```scss\n.selector-1 {\n @extend .other-rule;\n @include clearfix();\n @include box-sizing(border-box);\n width: x-grid-unit(1);\n // other declarations\n}\n```\n\n\n\n## 5. 命名\n\n不要试着把自己当作编译器或者预处理器，因此命名的时候尽量采用清晰的、有意义的名字。另外，对于\nhtml文件和css文件中的代码，尽量采用一致的命名规则。\n\n\n```css\n/* 没有意义的命名 */\n.s-scr {\n overflow: auto;\n}\n.cb {\n background: #000;\n}\n\n/* 比较有意义的命名方式 */\n.is-scrollable {\n overflow: auto;\n}\n.column-body {\n background: #000;\n}\n```\n\n\n\n## 6. 实例\n\n下面是含有上述约定的示例代码：\n\n```css\n/* ==========================================================================\n Grid layout\n ========================================================================== */\n\n/**\n * Column layout with horizontal scroll.\n *\n * This creates a single row of full-height, non-wrapping columns that can\n * be browsed horizontally within their parent.\n *\n * Example HTML:\n *\n * \n */\n\n/**\n * Grid container\n *\n * Must only contain `.cell` children.\n *\n * 1. Remove inter-cell whitespace\n * 2. Prevent inline-block cells wrapping\n */\n\n.grid {\n height: 100%;\n font-size: 0; /* 1 */\n white-space: nowrap; /* 2 */\n}\n\n/**\n * Grid cells\n *\n * No explicit width by default. Extend with `.cell-n` classes.\n *\n * 1. Set the inter-cell spacing\n * 2. Reset white-space inherited from `.grid`\n * 3. Reset font-size inherited from `.grid`\n */\n\n.cell {\n position: relative;\n display: inline-block;\n overflow: hidden;\n box-sizing: border-box;\n height: 100%;\n padding: 0 10px; /* 1 */\n border: 2px solid #333;\n vertical-align: top;\n white-space: normal; /* 2 */\n font-size: 16px; /* 3 */\n}\n\n/* Cell states */\n\n.cell.is-animating {\n background-color: #fffdec;\n}\n\n/* Cell dimensions\n ========================================================================== */\n\n.cell-1 { width: 10%; }\n.cell-2 { width: 20%; }\n.cell-3 { width: 30%; }\n.cell-4 { width: 40%; }\n.cell-5 { width: 50%; }\n\n/* Cell modifiers\n ========================================================================== */\n\n.cell--detail,\n.cell--important {\n border-width: 4px;\n}\n```\n\n\n\n## 7. 代码组织\n\n对于css代码库来说，如何组织代码文件是很重要的，尤其对于那些很大的代码库显得更加重要。这里介绍\n几个组织代码的建议：\n\n* 逻辑上对不同的代码进行分离。\n* 不同的组件(component)的css尽量用不同的css文件（可以在build阶段用工具合并到一起）\n* 如果用到了预处理器（比如less），把一些公共的样式代码抽象成变量，例如颜色，字体等等。\n\n\n\n## 8. 构建及部署\n\n任何一个项目，都应该有一个build的过程，在这个阶段我们可以通过工具对代码进行检测，测试，压缩等等，还\n可以为生产环境准备好带有版本号的代码。在这里我推荐一下[grunt](https://github.com/cowboy/grunt)这个工具，我感觉它很不错。\n\n\n\n## 致谢\n\n感谢所有对[idiomatic.js](https://github.com/rwldrn/idiomatic.js)作出贡献的网友。\n\n##许可\n_Principles of writing consistent, idiomatic CSS_ 是Nicolas Gallagher发布在[Creative Commons Attribution 3.0 Unported License](http://creativecommons.org/licenses/by/3.0/)许可证下的作品。该许可证适用于本代码栈中的所有文档，包括翻译文本。\n\n本作品基于[github.com/necolas/idiomatic-css](https://github.com/necolas/idiomatic-css)著就。\n"
},
{
"path": "translations/zh-TW/README.md",
"content": "# 通順一致的CSS編寫原則\n\n以下的文件描述了一個合理的CSS開發風格規範。\n這些守則特別著重於使用現有那些普遍且合理的形式。你可以採用它們來創造你自己的風格規範。\n\n這是一份持續更新的文件，而且永遠歡迎新的想法，別吝於貢獻。\n\n\n## 目錄\n\n1. [通用原則](#general-principles)\n2. [空格](#whitespace)\n3. [註解](#comments)\n4. [格式](#format)\n5. [實例](#example)\n\n[Acknowledgements](#acknowledgements)\n\n[License](#license)\n\n\n\n## 1. 通用原則\n\n> 「良好管理成功專案的其中一點是能夠了解到\n> 只為自己寫代碼是很糟糕的行為。如果有很多人正在使用你寫的代碼，\n> 那麼盡可能保持你的代碼明確可讀，而不是在規格中隨個人喜好取巧。」- Idan Gazit\n\n* 不要嘗試過早地優化你的代碼。讓它保持易讀且容易理解。\n* 不論有多少人參與，專案內任何項目的代碼都應該要看起來像是同一人的手筆。\n* 嚴格實行被一致認同的風格。\n* 當對風格有疑義時應採行現有而普遍的形式。\n\n\n\n## 2. 空格\n\n在全部的項目原始碼中只能有唯一的風格，在使用空白時應永遠保持一致性。\n使用空白來提升可讀性。\n\n\n* _絕對_ 不要在縮排時混用空格和跳格。\n* 在偽縮排（空格）或是真正的跳格中擇一。並且堅持你的選擇不要漏失。（建議使用：空格）\n* 如果使用空格，指定每個縮進等級使用的字元長度。（建議使用：4個空格）\n\n提示: 設定你的編輯器「顯示不可見字元」或是自動移除行尾空白。\n\n提示: 使用 [EditorConfig](http://editorconfig.org/) 設定檔 （或是類似的工具） 來協助維護項目中已被接受的基本空白慣例。\n\n\n\n## 3. 註解\n\n代碼有良好註解是非常重要的。留些時間去描述元件是如何作用，有哪些侷限，以及是如何組成的。\n別讓團隊裡的其他人去猜測那些不尋常的或是意圖不明顯的代碼。\n\n註解的風格在同一專案項目中應該力求簡明一致。\n\n* 將註解放在解釋的對象上方並獨立成行。\n* 保持單行長度在一個合理的最大值，例如：80個字元。\n* 使用字面上的註解把 CSS 代碼分隔成不同的部分。\n* 使用與一般文句相同的大小寫以及一致的段落縮排。\n\n提示: 設定你的編輯器以提供快捷鍵來輸出被一致接受的註解形式。\n\n範例:\n\n```css\n/* ==========================================================================\n 註解章節區塊\n ========================================================================== */\n\n/* 註解子章節區塊\n ========================================================================== */\n\n/**\n * 使用Doxygen風格註解格式的簡短描述\n *\n * 這一長段敘述的第一個句子從這裡開始，在這行持續一下子，\n * 最後收尾在這段的結尾。\n *\n * 這一長段敘述對於更仔細的解釋以及說明是很合適的。它可以包含一些範例 HTML、URL，\n * 或是任何其他有用或必要的資訊。\n *\n * @tag 這是一個命名為'tag'的標籤\n *\n * TODO: 這是描述一個要在稍後完成的簡單任務的待辦事項。\n * 它在80個字元長度後斷行（譯註：翻成中文後在這裡並非如此）且以下每行\n * 都使用兩個空白縮進。\n */\n\n/* 基本註解 */\n```\n\n\n\n## 4. 格式\n\n指定的代碼格式必須要確保的是：易於閱讀；易於清晰地註解；減少意外引入錯誤的機會；\n而且可以產生實用的 diff 以及 blame 。\n\n* 在有許多選擇器的樣式集中，讓每個單獨的選擇器單獨成行。\n* 在樣式集的開始括號前保留一個空格。\n* 在樣式區塊中保持每個樣式至少一行。\n* 在每個樣式前使用一個段落的縮進。\n* 在每個樣式的冒號後保留一個空格。\n* 使用小寫以及縮略的 HEX 數值，例如：`#aaa`。\n* 一致地使用單引號或是雙引號。推薦使用雙引號，例如：`content: \"\"`。\n* 在選擇器中以引號夾注屬性值，例如： `input[type=\"checkbox\"]`。\n* _可以的話_，避免在值為零時指定單位，例如：`margin: 0`。\n* 在每一個以逗號分隔的屬性的逗號或是函式值後面保留一個空格。\n* 在樣式區塊的最後一個樣式結尾保留分號。\n* 樣式集的結束括號應該擺放在與樣式集的第一個字元同樣位置。\n* 以一個空白行分隔每個樣式集。\n\n```css\n.selector-1,\n.selector-2,\n.selector-3[type=\"text\"] {\n -webkit-box-sizing: border-box;\n -moz-box-sizing: border-box;\n box-sizing: border-box;\n display: block;\n font-family: helvetica, arial, sans-serif;\n color: #333;\n background: #fff;\n background: linear-gradient(#fff, rgba(0, 0, 0, 0.8));\n}\n\n.selector-a,\n.selector-b {\n padding: 10px;\n}\n```\n\n#### 宣告順序\n\n如果宣告按照順序一貫地排列下來，應當要符合一個簡單的原則。\n\n比較小的團隊們也許會偏好將有關聯的屬性（例如位置和容器模型）群組在一起。\n\n```css\n.selector {\n /* 位置 */\n position: absolute;\n z-index: 10;\n top: 0;\n right: 0;\n bottom: 0;\n left: 0;\n\n /* 顯示 & 區塊模型 */\n display: inline-block;\n overflow: hidden;\n box-sizing: border-box;\n width: 100px;\n height: 100px;\n padding: 10px;\n border: 10px solid #333;\n margin: 10px;\n\n /* 其它 */\n background: #000;\n color: #fff;\n font-family: sans-serif;\n font-size: 16px;\n text-align: right;\n}\n```\n\n比較大的團隊們也許會偏好以字母排序所帶來的簡潔性以及易於維護。\n\n#### 例外與細微偏差\n\n對於大量只包含逐一樣式宣告的區塊，可以採用一種稍微不同的單行格式。\n在這種情況下，應在開始括號之後以及結束括號之前都保留一個空格。\n\n```css\n.selector-1 { width: 10%; }\n.selector-2 { width: 20%; }\n.selector-3 { width: 30%; }\n```\n\n對於很長且以逗號分隔的屬性值——例如漸層或是陰影的集合——可以整理成多行達到改善可讀性以及產生更有用 diff 的效果，這時有許多種格式可以使用。\n底下有個例子。\n\n```css\n.selector {\n background-image:\n linear-gradient(#fff, #ccc),\n linear-gradient(#f3c, #4ec);\n box-shadow:\n 1px 1px 1px #000,\n 2px 2px 1px 1px #ccc inset;\n}\n```\n\n### 預處理器: 額外的格式考量\n\n不同的 CSS 預處理器有不同的特色、功能、以及語法。\n應該要考慮到隨著所採用的不同預處理器的特點而去擴充你們的慣例。以下是關於 Sass 的守則。\n\n* 將嵌套深度限制在一個階層。對於任何兩階以上的深度重新評估。這將避免寫出過於針對性的 CSS 選擇器。\n* 避免大量的嵌套規則。當可讀性開始受到影響時將它們打散。盡量避免超過20行的嵌套。\n* 永遠將 `@extend` 宣告擺在樣式區塊的第一行。\n* 可能的話，將 `@include` 宣告群組置於樣式區塊的頂部，緊接著任何 `@extend` 宣告之後。\n* 考慮在自訂函式的前面加上`x-`或是其他的命名空間。這有助於避免與原生的 CSS 函式混淆，或是與其它函式庫衝突。\n\n```scss\n.selector-1 {\n @extend .other-rule;\n @include clearfix();\n @include box-sizing(border-box);\n width: x-grid-unit(1);\n // other declarations\n}\n```\n\n\n\n## 5. 實例\n\n這是遵循上述那些規範的範例。\n\n```css\n/* ==========================================================================\n 格線佈局\n ========================================================================== */\n\n/**\n * 帶有橫向捲軸的欄位佈局。\n *\n * 這會產生一個由全高且不斷開的多欄區塊組成的單列，可以在它的上層容器中橫向瀏覽。\n *\n * 範例 HTML:\n *\n * \n */\n\n/**\n * 格線容器\n *\n * 必須只包含 `.cell` 子元素.\n *\n * 1. 移除網格間的空白\n * 2. 避免 inline-block 網格斷開\n */\n\n.grid {\n height: 100%;\n font-size: 0; /* 1 */\n white-space: nowrap; /* 2 */\n}\n\n/**\n * 系統網格\n *\n * 不預設固定的寬度. 用 `.cell-n` 類別來變化。\n *\n * 1. 設定網格內間距\n * 2. 重設自 `.grid` 串接來的 white-space 屬性\n * 3. 重設自 `.grid` 串接來的 font-size 屬性\n */\n\n.cell {\n position: relative;\n display: inline-block;\n overflow: hidden;\n box-sizing: border-box;\n height: 100%;\n padding: 0 10px; /* 1 */\n border: 2px solid #333;\n vertical-align: top;\n white-space: normal; /* 2 */\n font-size: 16px; /* 3 */\n}\n\n/* 網格狀態 */\n\n.cell.is-animating {\n background-color: #fffdec;\n}\n\n/* 網格維度\n ========================================================================== */\n\n.cell-1 { width: 10%; }\n.cell-2 { width: 20%; }\n.cell-3 { width: 30%; }\n.cell-4 { width: 40%; }\n.cell-5 { width: 50%; }\n\n/* 網格修飾\n ========================================================================== */\n\n.cell--detail,\n.cell--important {\n border-width: 4px;\n}\n```\n\n\n\n## Acknowledgements\n\nThanks to everyone who has provided translations and to all those who\ncontributed to [idiomatic.js](https://github.com/rwldrn/idiomatic.js). It was a\nsource of inspiration, quotations, and guidelines.\n\n\n\n## License\n\n_Principles of writing consistent, idiomatic CSS_ by Nicolas Gallagher is\nlicensed under the [Creative Commons Attribution 3.0 Unported\nLicense](http://creativecommons.org/licenses/by/3.0/). This applies to all\ndocuments and translations in this repository.\n\nBased on a work at\n[github.com/necolas/idiomatic-css](https://github.com/necolas/idiomatic-css).\n"
}
]