{"id":23655231,"url":"https://github.com/caplin/css-styleguide","last_synced_at":"2025-11-22T07:30:15.582Z","repository":{"id":27074400,"uuid":"30540869","full_name":"caplin/css-styleguide","owner":"caplin","description":"Caplin CSS style guide","archived":false,"fork":false,"pushed_at":"2015-03-03T15:49:18.000Z","size":316,"stargazers_count":2,"open_issues_count":2,"forks_count":0,"subscribers_count":7,"default_branch":"master","last_synced_at":"2024-12-28T19:52:03.488Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"CSS","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/caplin.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2015-02-09T14:54:55.000Z","updated_at":"2017-08-24T15:46:48.000Z","dependencies_parsed_at":"2022-09-02T02:41:17.500Z","dependency_job_id":null,"html_url":"https://github.com/caplin/css-styleguide","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/caplin%2Fcss-styleguide","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/caplin%2Fcss-styleguide/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/caplin%2Fcss-styleguide/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/caplin%2Fcss-styleguide/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/caplin","download_url":"https://codeload.github.com/caplin/css-styleguide/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":239627287,"owners_count":19670844,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-12-28T19:52:00.090Z","updated_at":"2025-11-22T07:30:15.531Z","avatar_url":"https://github.com/caplin.png","language":"CSS","funding_links":[],"categories":[],"sub_categories":[],"readme":"1. [Introduction](#introduction)\n2. [BEM](#bem)\n3. [Reusable classes](#reusable-components)\n4. [Architecture](#architecture)\n5. [Selectors](#selectors)\n6. [Theory](#theory)\n7. [Formatting](#formatting)\n8. [Whitespace](#whitespace)\n\n# Introduction\n\nThe purpose of this document is to specify a CSS structure that improves the componentisation and encapsulation of Caplin CSS.\n\nA mix of [BEM](https://en.bem.info/), [OOCSS](http://appendto.com/2014/04/oocss/) and [SuitCSS](http://suitcss.github.io/) has been chosen as the basis.\n\nUsing BEM will mean that all CSS in a blade is encapsulated and can be modified or deleted at will.\n\n\n\n\n# BEM\n\nBEM stands for Block Element Modifier. It looks like this:\n\n``` html\n\u003cdiv class=\"Filter\"\u003e\n\t\u003cdiv class=\"Filter-row\" /\u003e\n\t\u003cdiv class=\"Filter-row Filter-row--highlight\" /\u003e\n\t\u003cdiv class=\"Filter-row\" /\u003e\n\u003c/div\u003e\n```\n\nA Block is a reusable piece of intertwined HTML and CSS. \nIn this example, we are creating a *Filter*.\n\nAn Element is a child DOM element that forms an essential part of the component we are trying to build.\n\nSo `Filter-row` is an Element which will uniquely style rows inside `Filter` Blocks.\n\nA Modifier is a variant of either of a Block or one of the Elements it contains.\nIn this example, we want the first row to stand out, hence the modifier of `--highlight`.\n\n\n*The syntax defined here differs from the original BEM (see [SuitCSS](https://github.com/suitcss/suit/blob/master/doc/naming-conventions.md)), but the end result is the same.*\n\n\n### Blocks\nThe single root element for every Block.\n\nThe Block is be named with PascalCase (camelCase with a capitalised first letter).\nEvery selector related to the Block is prepended by the Block name, this namespaces the Block and ensures styles do not leak or conflict with other parts of the page.\n``` html\n\u003cdiv class=\"Filter\" /\u003e\n```\n``` css\n.Filter {...}\n```\n\n\n### Elements\nElements within a Block are named with camelCase and separated from the Block by a hyphen.\n``` html\n\u003cdiv class=\"Filter\"\u003e\n\t\u003cdiv class=\"Filter-element\" /\u003e\n\t\u003cdiv class=\"Filter-element\" /\u003e\n\t\u003cdiv class=\"Filter-anotherElement\" /\u003e\n\u003c/div\u003e\n```\n``` css\n.Filter-element {...}\n.Filter-anotherElement {...}\n```\n\n**Note: The BEM 'tree' does not replicate the DOM tree. Elements within Elements must *not* be named as such.**\n\n``` html\n\u003c!-- Wrong --\u003e\n\u003cdiv class=\"Filter\"\u003e\n\t\u003cdiv class=\"Filter-outerElement\"\u003e\n\t\t\u003cdiv class=\"Filter-outerElement-innerElement\" /\u003e\n\t\u003c/div\u003e\n\u003c/div\u003e\n```\n\n``` css\n/* Wrong */\n.Filter-outerElement { ... }\n.Filter-outerElement-innerElement { ... }\n```\n\n```html\n\u003c!-- Correct --\u003e\n\u003cdiv class=\"Filter\"\u003e\n\t\u003cdiv class=\"Filter-outerElement\"\u003e\n\t\t\u003cdiv class=\"Filter-innerElement\" /\u003e\n\t\u003c/div\u003e\n\u003c/div\u003e\n```\n``` css\n/* Correct */\n.Filter-outerElement { ... }\n.Filter-innerElement { ... }\n```\n\n**Pseudo classes can be used ([assuming they are supported](http://www.quirksmode.org/css/selectors/)) to select elements if it is semantically correct to do so.**\n\n``` css\n.Filter-element { margin-top: 10px; }\n.Filter-element:first-child { margin-top: 0; }\n```\n\n### Modifiers\nModifiers (variants) follow the same naming as Elements, but are separated by a double hyphen.\n``` html\n\u003cdiv class=\"Filter--large\" /\u003e\n```\n``` css\n.Filter {...}\n.Filter--large { height: 9001px; }\n```\n\nYou can have modifiers on Elements:\n\n``` html\n\u003cdiv class=\"Filter\"\u003e\n\t\u003cdiv class=\"Filter-element\" /\u003e\n\t\u003cdiv class=\"Filter-element Filter-element--large\" /\u003e\n\t\u003cdiv class=\"Filter-element\" /\u003e\n\u003c/div\u003e\n```\n``` css\n.Filter-element {...}\n.Filter-element--large { height: 9001px; }\n```\n\n### States\n``` html\n\u003cdiv class=\"Filter is-selected\" /\u003e\n```\n``` css\n.Filter { ... }\n.Filter.is-selected { border: red; }\n```\n**The State class must be chained with the relevant Block or Element.**\n\nIf this is not done, encapsulation will be broken.\n\n``` css\n/* Forbidden. */\n.Filter { ... }\n.is-selected { ... }\n```\n\nStates are a variation on modifiers - in the original BEM, there is no differentiation.\n\nIf the class is added or removed over the life of the element (via JavaScript), it is a State.\n\n\n**States must not be included in the HTML or template markup.**\n\nAssuming a popup should be hidden on page load:\n\n**Good:**\n``` css\n.Popout { display: none; }\n.Popout.is-visible { display: block; }\n```\n\n``` html\n\u003c!-- HTML/Template file --\u003e\n\u003cdiv class=\"Popout\" /\u003e\n```\n\n**Bad:**\n``` css\n.Popout { display: block; }\n.Popout.is-hidden { display: none; }\n```\n\n``` html\n\u003c!-- HTML/Template file --\u003e\n\u003cdiv class=\"Popout is-hidden\" /\u003e\n```\n\n\n### Nested Blocks\n\n*Blocks can be used inside other Blocks.*\n\n``` html\n\u003c!-- Outer Block --\u003e\n\u003cdiv class=\"Filter\"\u003e\n\t\u003cdiv class=\"Filter-element\"\u003e\n\t\t \u003c!-- Inner Block --\u003e\n\t\t \u003ca class=\"Button\" /\u003e\n\t\u003c/div\u003e\n\u003c/div\u003e\n```\n\n**Blocks must not depend on their location in the DOM.**\n\nIf a Block is dependent on being contained within another Block or element, it can no longer be reused elsewhere in the Application.\n\nIn this example, the `Button` Block will not know what styles or dimensions are applied to `.Filter`. Therefore the CSS for a Block must be written in a way that works regardless of the properties of it's container.\n\nThe most common unknown will be the dimensions of the parent/container.\n\n**Blocks must not affect child elements.**\n\n``` css\n/* Good */\n.Filter--xyzElement {display: inline-block; }\n\n/* Bad */\n.Filter div {display: inline-block; }\n```\n\nAs any Block could be placed within any other Block, Blocks must not use selectors that could affect these 'child' Blocks or elements. Use Element classes instead (e.g. `Filter-element`).\n\n**The exception to this rule is when Blocks are explicitly designed to contain other Blocks.** \n*For example, a `ButtonGroup` Block which aligns a group of child `Button` Blocks. See [Selectors#Direct Child](#direct-child).*\n\n\n# Reusable Components\n\n## Utility Classes\n\nUtility classes must have a single responsibility. They are expected to be used frequently and as such, should rarely be modified after creation. \n\n``` css\n.u-strip {\n\tdisplay: block !important;\n\twidth: 100% !important;\n}\n```\n\n*(This is **proactive** use of `!important`, as we know that any element with the class of `strip` should span the entire width of it's parent.)*\n\n``` css\n.u-positionCenter {\n\ttop: 0 !important;\n\tright: 0 !important;\n\tbottom: 0 !important;\n\tleft: 0 !important;\n\tmargin: auto !important;\n\tposition: absolute !important;\n}\n```\n\n#### Naming\n\ncamelCase prefixed by `u-`, for example:\n\n``` css\n.u-myUtilClass {}\n```\n\n#### Use\nThese classes can be added straight onto any element or Block.\n\n``` html\n\u003cbody\u003e\n\t\u003cdiv class=\"Popup u-positionCenter is-visible\"\u003e\n\t\u003c/div\u003e\n\u003c/body\u003e\n```\n\n``` css\n.Popup {\n\tdisplay: none;\n\theight: 100%;\n\twidth: 100%;\n\tmax-height: 400px;\n\tmax-width: 600px;\n\tz-index: 9001;\n}\n.Popup.is-visible { display: block }\n```\n\n\n## Skin Classes\n\nSkin classes are similar to Utility classes, but deal with visual styles.\n\nIf there are multiple elements or Blocks using similar rules, then we can factor them out.\n\n``` css\n.Header {\n\t...\n\tbackground: grey;\n\tborder: 1px solid #BBB;\n\tborder-radius: 2px;\n\t...\n}\n\n\n.Filter {\n\t...\n\tbackground: grey;\n\tborder: 1px solid #BBB;\n\tborder-radius: 2px;\n\t...\n}\n```\n\nElements can share several properties, however that does not mean these properties should all be extracted to the same skin class. The skin classes must be short (1-4 rules) and only contain related properties.\n\n``` css\n.skin-box {\n\tbackground: grey;\n\tborder: 1px solid #BBB;\n\tborder-radius: 2px;\n}\n```\n\nAssuming the UI in our app calls for many elements to have a grey background with a rounded border, this can be reused in different Blocks.\n\n``` html\n\u003cdiv class=\"Filter skin-box\"\u003e\n\t\u003cdiv class=\"Filter-element\" /\u003e\n\u003c/div\u003e\n```\n\nThe properties below are *not* closely related and therefore this class cannot be reused in many situations.\n``` css\n/* Bad */\n.skin-text {\n\tcolor: black;\n\tbackground: white;\n\tfont-family: Helvetica;\n\tborder-radius: 5px;\n}\n```\n\nNote: It is *not* correct to apply this class and then override some of the properties.\n\n``` html\n\u003cdiv class=\"Filter skin-main\" /\u003e\n```\n\n``` css\n/* Wrong */\n.Filter {\n\tcolor: red;\n\tbackground: white;\n}\n```\n\n**Using skins classes enforces consistency in the UI and allows the app to be *partially* re-themed.**\n\n\n#### Naming\ncamelCase prefixed by `skin-`, for example:\n\n``` css\n.skin-border {}\n.skin-borderRounded {}\n```\n\n\n## Blocks\nFor reusable components (e.g. buttons) that require structure, style and (possibly) multiple elements, the BEM/Block conventions must be followed.\n\nAs the HTML/CSS will likely be maintained and reused, it must be commented using the [Knyle Style Sheets (KSS)](http://warpspire.com/kss/syntax/) syntax, so a living styleguide can be created for developers to view, edit and copy examples from. A good example of KSS in action is the [Github Styleguide](https://github.com/styleguide/css).\n\n``` css\n/*\n Buttons\n\n The majority of buttons in the site are built from this class.\n\n Markup: \n \u003cbutton class=\"Button {{modifier_class}}\"\u003eButton Element\u003c/button\u003e\n\n .Button--small         - Make the button smaller.\n .Button--large         - Make the button larger.\n .Button--default       - Apply default styling to the button.\n .Button--primary\t\t- Apply primary styling to the button.\n\n Styleguide 1.1\n*/\n\n.Button {\n\tdisplay: inline-block;\n\tpadding: 6px 12px;\n\tmargin-bottom: 0;\n\tfont-size: 14px;\n}\n\n.Button--small {\n\tpadding: 5px 10px;\n\tfont-size: 12px;\n}\n\n.Button--large {\n\tpadding: 10px 16px;\n\tfont-size: 18px;\n}\n\n.Button--default {\n\tcolor: #333;\n\tbackground-color: #fff;\n\tborder: 1px solid #ccc;\n\tborder-radius: 4px;\n}\n\n.Button--primary {\n\tcolor: #fff;\n\tbackground-color: #337ab7;\n\tborder: 1px solid #2e6da4;\n\tborder-radius: 4px;\n}\n```\n\n\n**Any CSS that is context specific must be in a Modifier or State.** Think about reuse in different parts of the App.\n\n\n\n\n# Architecture\n\nEach BEM Block must be in it's own CSS file.\n\nAll CSS at the Blade level must be BEM. The encapsulation provided by BEM means that no other elements can be affected by, or become dependent on, the CSS written in a particular blade. You need to be able to add, modify or delete BEM Blocks without being concerned of any impact on other Blocks or parts of the App.\n\nUtility, skin and component classes will be in the `default-aspect` or in external libraries.\n\nIf in doubt, write CSS in the Blade with BEM, instead of creating App/Aspect level CSS. App level CSS should rarely be modified once created, whereas it is possible to refactor your BEM CSS.\n\n\n\n\n# Selectors\n\n### Nesting\n#### **Don't nest your CSS.**\n\n[*The descendant selector (whitespace).*](https://developer.mozilla.org/en-US/docs/Web/CSS/Descendant_selectors)\n\n``` css\n.btn { ... /* Default styling */ }\n.Block .btn { ... }\n```\n\n``` html\n\u003cheader class=\"Block\"\u003e\n\t\u003cbutton class=\"btn\" /\u003e\n\u003c/header\u003e\n```\n\nWhile nesting decreases the classes required in the HTML, the CSS is now dependent on the HTML structure. \n\nIt is often the case that variants of elements are created for a specific situation and later reused elsewhere. In this example, `.btn` cannot be reused outside of `.block`.\n\nCould this be rewritten to make it reusable?\n\n``` css\n.btn { ... }\n.btn--variantA { ... }\n```\n\n``` html\n\u003cheader class=\"Block\"\u003e\n\t\u003cbutton class=\"btn btn--variantA\" /\u003e\n\u003c/header\u003e\n```\n\n\n\n\n### Direct Child\nThe direct child selector `\u003e` can be used to improve performance and limit the cascade of styles (good). But what if the DOM needs to be changed and another layer of HTML introduced? Now the CSS needs to be modified for what should be a trivial change.\n\nFor example, moving from this:\n\n``` html\n\u003cheader class=\"Header\"\u003e\n\t\u003cimg src=\"...\" /\u003e\n\u003c/header\u003e\n```\n\n``` css\n.Header \u003e img { ... }\n```\n\nTo this:\n``` html\n\u003cheader class=\"Header\"\u003e\n\t\u003cdiv class=\"grid\"\u003e\n\t\t\u003cimg src=\"...\" /\u003e\n\t\t\u003cp\u003eLorem ipsum\u003c/p\u003e\n\t\u003c/div\u003e\n\u003c/header\u003e\n```\n\nWill break your CSS.\n\n**Use the direct child selector where it makes semantic sense to do so.** \nFor example, creating a new BEM Block to contain `.Buttons`:\n\n``` css\n.ButtonGroup { ... }\n\n.ButtonGroup \u003e .Button {\n\tfloat: left;\n\tmargin-left: 10px;\n}\n\n.ButtonGroup \u003e .Button:first-child {\n\tmargin-left: 0;\n}\n```\n``` html\n\u003cdiv class=\"ButtonGroup\"\u003e\n\t\u003cbutton class=\"Button\"\u003e\u003c/div\u003e\n\t\u003cbutton class=\"Button\"\u003e\u003c/div\u003e\n\t\u003cbutton class=\"Button\"\u003e\u003c/div\u003e\n\u003c/div\u003e\n```\n\nSee: [Bootstrap button groups](http://getbootstrap.com/components/#btn-groups)\n\n\n### No ID's.\nID's are allowed for JavaScript and fragment identifiers, but should never be used in CSS.\n\n* ID's override any styles applied by classes and then require the use of even more specific selectors to override the ID's rule (and so on).\n* Only one ID can exist on a page, therefore the ruleset cannot be used more than once.\n* JavaScript ID's cannot be changed or removed for fear of altering styling.\n\n``` css\n/* The performance of these are virtually identical. */\n#Block { ... }\n.Block { ... }\n```\n\n### No qualifiers\n``` css\n/* No. */\nul.Nav { ... }\n```\n\nThe `ul` qualifier makes this more specific than any other class applied to the element and can only be overridden by an ID (bad) or using !important (bad).\n\nFurthermore, the `.Nav` class cannot be reused on a non-`ul` element, such as a `nav` element.\n\n\n### No nested wildcards\n``` css\n.Block * { ... }\n```\n\nWhile the wildcard does not *always* have the significant performance impact it used to, there are very few cases where it is the correct course of action. \n\n[Non-nested wildcards can be used sparingly.](http://www.paulirish.com/2012/box-sizing-border-box-ftw)\n\n\n### No reactive !important\n\n!important is the nuclear option when it comes to specificity. If following the rules above, it should never need to be used reactively. That is, to override rule already being applied.\n\nIt does have a place when attempting to ensure a class will always work as expected. For example:\n``` css\n.hidden { display: none !important; }\n```\n\n### No null rules\n\nSetting a CSS property to a default or null value is rarely the correct course of action. It is generally a sign that the property has been set too early in the CSS.\n\n``` css\n/* Bad */\nselector {\n\tfloat: none;\n\tborder: none;\n\tpadding: 0;\n\tmargin: 0;\n}\n```\n\n\n\n\n# Theory\n\n## Selector Intent\nThe selectors used when creating a rule should match the *intent* behind the rule.\n\nFor example, when styling a new navigation (which happens to be in the footer):\n``` css\n/* This will style every anchor in the footer, when the intent was only to style links in a secondary navigation. */\nfooter a { ... }\n\n/* Better. The secondary nav can now be used elsewhere on the page. */\n.SecondaryNav a { ... }\n\n/* Best. This does not select all anchors in the SecondaryNav, some of which may be used for other purposes. */\n.SecondaryNav-link { ... }\n```\n\n``` html\n\u003cnav class=\"SecondaryNav\"\u003e\n\t\u003ca class=\"SecondaryNav-link\" /\u003e\n\t\u003ca class=\"SecondaryNav-link\" /\u003e\n\t\u003ca class=\"SecondaryNav-socialIcon\" /\u003e\n\u003c/nav\u003e\n```\n\n\u003e There are only two hard things in Computer Science: cache invalidation and naming things.\n\nClasses should not describe the exact style being applied, as they cannot be changed:\n``` css\n.blue { color: blue; }\n\n/* After theming */\n.blue { color: red; }\n```\n\nClasses should not be contextual, as they cannot be reused:\n``` css\n.footer-color { color: blue; }\n```\n\n``` html\n\u003cheader\u003e\n\t\u003cnav\u003e\n\t\t\u003ca class=\"footer-color\" /\u003e\n\t\u003c/nav\u003e\n\u003c/header\u003e\n```\n\nAim for a compromise between describing the style and describing the use.\n\n``` css\n.Nav-link { color: blue; }\n```\n\n\n## Specificity\nSpecificity is increased when the descendant selector is used.\n``` css\n/* This: */\n.Block a { ... }\n\n/* Is more specific than this: */\n.Block-link { ... }\n\n/*\nNow when `.Block-link` needs to override rules from `.Block a`, there will be a specificity war, leading to either: \n*/\nheader .Block-link { ... }\na.Block-link { ... }\n.Block-link { ... !important }\n\n/* And the cycle will continue... */\n```\n\nAdditionally:\n\n``` css\n/* Can no longer be used outside header */\nheader .Block-link\n\n/* Can no longer be used for non-anchors */\na.Block-link { ... }\n\n/* Will cause specificity problems if reused */\n.Block-link { ... !important } \n```\n\n\n## More BEM\nA child element of a Block is only a BEM Element (of that Block), if the element *must* only ever be used within that block.\n\nIn our Filter example, we have two buttons inside one of our `Filter-rows`.\n\n``` html\n\u003cdiv class=\"Filter\"\u003e\n\t\u003cdiv class=\"Filter-row\"\u003e\n\t\t\u003cbutton /\u003e\n\t\t\u003cbutton /\u003e\n\t\u003c/div\u003e\n\u003c/div\u003e\n```\n\nIf we wanted to style the buttons, the BEM method would be to add a new class:\n\n``` html\n\u003cdiv class=\"Filter\"\u003e\n\t\u003cdiv class=\"Filter-row\"\u003e\n\t\t\u003cbutton class=\"Filter-button\" /\u003e\n\t\t\u003cbutton class=\"Filter-button\" /\u003e\n\t\u003c/div\u003e\n\u003c/div\u003e\n```\n\nHowever this should only be done if the `Filter-buttons` will *only* be used inside a `Filter` Block.\n\nIf the buttons are generic and will be used in multiple places, a generic Block (e.g. `.Button`) should be created (if necessary) and used:\n\n``` html\n\u003cdiv class=\"Filter\"\u003e\n\t\u003cdiv class=\"Filter-row\"\u003e\n\t\t\u003cbutton class=\"Button\" /\u003e\n\t\t\u003cbutton class=\"Button\" /\u003e\n\t\u003c/div\u003e\n\u003c/div\u003e\n```\n\nThe `.Button` CSS must be flexible enough to allow the `Button` class to be used in a variety of situations. Aka Location agnostic - not dependent on it's container.\n\nIn the majority of cases, elements in a BEM Block will need some generic rulesets *and* some rules specific to their location. Rather than duplicating rules in CSS, the element can be 'composed' with several CSS classes. \n\n``` html\n\u003cdiv class=\"Filter\"\u003e\n\t\u003cdiv class=\"Filter-row\"\u003e\n\t\t\u003cbutton class=\"Button Filter-button\" /\u003e\n\t\t\u003cbutton class=\"Button Filter-button\" /\u003e\n\t\u003c/div\u003e\n\u003c/div\u003e\n```\n\n``` css\n.Button { ... }\n\n.Filter { ... }\n.Filter-row { ... }\n.Filter-button.Button { ... }\n```\n\nFactoring out the reusable component from the CSS (in this case `.Button`) and using `Filter-row` to apply button styling specifically for a `Filter` Block, removes duplication and let's us reuse the `Button` class. \n\nTODO: would a normal BEM modifier break encapsulation for this?\n\n\n\n# Formatting\nFor clarity and consistency:\n* Indent with tabs. [So it is written, so let it be done](http://caplin.github.io/StyleGuide/).\n* Opening brace on selector line.\n* Closing brace on new line.\n* A single space before the opening bracket.\n* A single space after the colon.\n\n``` css\n.class {\n\tproperty: value;\n}\n```\n\nThese rules simplify diffs by ensuring only one change per line:\n* All rules on separate lines.\n* All selectors on separate lines.\n\n``` css\n.selector1,\n.selector2 {\n\tproperty: value;\n\tproperty: value;\n}\n```\n\nThe only exception is a class with one rule and one selector which performs a specific function. This can be on a single line:\n\n``` css\n.red { color: red; }\n```\n\nComments are preceded by a newline, unless at the beginning of a ruleset.\n``` css\n.class {\n\t/* Good */\n\tproperty: value;\n\t\t\t\n\t/* Good */\n\tproperty: value;\n\t/* Bad */\n\tproperty: value;\n}\n```\n\n**Wrong:**\n\n``` css\n.class\n{\n\t...\n}\n```\n``` css\n.class{\n\t...\n}\n```\n``` css\n.class {\n\tproperty:value;\n}\n```\n\n\n\n# Whitespace\n\nCSS is minified and stripped of whitespace and comments for production, so make *liberal* use of them.\n\nGroup related rules together and separate with newlines:\n\n``` css\n.selector {\n\t/* Box model */\n\tdisplay: inline-block;\n\tmargin: 0 auto;\n\tpadding: 10px 20px;\n\n\t/* Styling */\n\tcolor: #FFF;\n\tbackground-color: #000;\n\n\t/* Fonts */\n\tfont-size: 14px;\n\tfont-weight: bold;\n}\n```\n\nSeparate closely related rulesets by a single line of whitespace:\n``` css\n.MyButton {\n\t...\n}\n\n.MyButton--large {\n\n}\n```\n\nSeparate loosly related rulesets by two lines of whitespace:\n``` css\n.MyButton { ... }\n\n.MyButton--large { ... }\n\n\n.MyOtherButton { ... }\n\n.MyOtherButton--large { ... }\n```\n\nIf rulesets are unrelated, they should be in a separate file.\n\n# Further Reading\n\n* [CSS Guidelines](http://cssguidelin.es/)\n* [CSS Wizardry - BEM](http://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/)\n* [Smashing Magazine - OOCSS Introduction](http://www.smashingmagazine.com/2011/12/12/an-introduction-to-object-oriented-css-oocss/)\n* [CSS Wizardry - Code Smells](http://csswizardry.com/2012/11/code-smells-in-css/)\n* [CSS Wizardry - Open/Closed](http://csswizardry.com/2012/06/the-open-closed-principle-applied-to-css/)\n* [Drew Barontini - Single Responsibility](http://drewbarontini.com/articles/single-responsibility/)\n* [The SASS Way - The Inception Rule](http://thesassway.com/beginner/the-inception-rule)\n* [SMACSS - Applicability](https://smacss.com/book/applicability)","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcaplin%2Fcss-styleguide","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fcaplin%2Fcss-styleguide","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcaplin%2Fcss-styleguide/lists"}