Skip to content

Instantly share code, notes, and snippets.

What would you like to do?
Principals of writing good css
General High-Order Principles
* Simplicity - The most bug-free line of code is the one you don't have to write!
* Reusable - Create code that is portable to other sections of the site and are nestable.
* Extensible - Create code that lends itself to be easily extended and with low selector specificity to promote extensibility.
* One-to-many - Create classes that can be applied to many contexts.
* Fast - Know your selector performance basics, reduce HTTP requests.
* Semantic - Create CSS that speaks to the task or meaning that is being accomplished. Good CSS class names describe our HTML elements in very semantic and specific ways.
* Standards Oriented - Create portable, standards-forward code.
* Future Proof - Create code as if you'll never be able to edit it again.
* Accessible - Just as people have different capabilities with respect to vision, hearing, language or cultural understanding, devices have varying levels of memory, CPU, screen size or bandwidth.
* Progressive - Create a core experience for the least capable devices (legacy devices, low bandwidth, low power, small memory, small screen) and progressively enhance the experience as you detect richer capabilities.
Strive To:
* Separate Structure from Skin.
* Separate Container from Content.
* Create a Component Library - Use Components like legos, combining them to create rich UI widgets. Create a reference page to see all components in a single centralized place.
* Separate components into generalized sub-groups: (Ordered from least to most specificity)
* Base - Your base styles, which everything inherits from.
* Layouts - "l-" Positioning components
* Components - "c-" headings, paragraphs, lists, buttons, figures
* Themes - "t-" Pure stylized components, panels, borders with paddings, colors, textures
* States - "is-" Default, Active, Enabled, Disabled, Hover, Focus, Success, Error, Collapsed, Expanded, Shown, Hidden.
* Your markup should be distilled from combining your component library.
* Your pages should strive to have the least unique css-possible.
* Extend Components by applying abstracted classes.
* "Flow like water" - Be flexible, allow site to respond to content to dictate height, and screen size to dictate width. Layout should respond proportionally, do not be fixed and static.
* Tag Specific selectors - Poor portability & reuse.
* #ID selectors - Poor selector performance & reuse, difficult to override due to high selector specificity.
* Alpha transparencies on top of irregular backgrounds - Poor rendering performance.
* Fixed "height:" Content is dynamic, changing, and heights will change. Try to avoid height, there are many ways to avoid it.
* Fixed "width:" Layouts should indicate proportionality and fit accordly inside their parent containers. Use box-sizing.
* Relying on a defined HTML structure to drape your styles, markup changes over time, and requirements change, components move.
* Write your CSS selectors to be as concise as possible.
* Write your CSS selectors to be as performant as possible, efficient as possible and even more efficient.
* Don't overqualify your CSS selectors.
* Use the lessons learned in "Object-Oriented" CSS (OOCSS).
* Every selector you write is additional complexity that will need to be maintained. Can you generalize or abstract that selector so other components can use it?
Make use of the child selector to limit how deep your css goes. .nav-list > li can do a lot to prevent the cascade from going too deep.
Think of the class attribute in HTML as a mounting-point for CSS classes, fixtures upon which styling is attached to markup. This is opposed to using the markup as a skeleton on which you drape your style.
When asked to change existing code, rather than simply adding complexity with new classes or additional selectors, can you refactor or abstract existing selectors or classes to produce the desired behavior? Look at change requests as an opportunity to refactor.
Code reuse is your friend. The first "C" in CSS stands for Cascade. Use the cascade to maximum advantage. Inheritance is extremely powerful. When adding a css property, ask yourself if you can add it higher in the cascade, and inherit it from a higher abstraction.
Write obvious code. CSS becomes more fragile as it grows in size, write code as if a novice coder would be maintaining your code in the future.
"Extent your CSS objects with class" - not with selector specificity. Increasing selector specificity makes overrides more difficult and fragile to maintain. Class names can always be more semantic than the generic tag names at your disposal.
Browsers actually have a very similar set of core default-styles. Rather than obliterating the core-styles with a hard-reset css, think about the value of css normalization. Using a normalized approach, the focus is to normalize the differences across browsers rather than eliminating all styles together. This means you spend less time re-creating the core styles that are very useful in practice.
Create a UI Pattern and Component Library - MailChimp has a good one:
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.