The so-called "nico-style" brought to markdown. Because Style Guide.
This style guide is a jab at solving collisions between CSS class names, and issues that ultimately lead to confusion, having to use !important rules, copying and pasting style declarations, and similarly awful aspects of CSS development.
Goal
These suggestions aren't set in stone, they aim to provide a baseline you can use in order to write more consistent codebases. To maximize effectiveness, share the styleguide among your co-workers and attempt to enforce it. Don't become obsessed about code style, as it'd be fruitless and counterproductive. Try and find the sweet spot that makes everyone in the team comfortable developing for your codebase, while not feeling frustrated that their code always fails automated style checking because they added a single space where they weren't supposed to. It's a thin line, but since it's a very personal line I'll leave it to you to do the drawing.
Astonishingly, this style guide won't do anything for you that you're not able to figure out for yourself. That means you won't see the benefits unless you try and follow most of the conventions laid out next.
Classes that are meant to be shared among a large set of elements, or provide reusable styles, should be grouped under a universal namespace, such as uv.
Good
.uv-clearfix {
// ...
}
Bad
.clearfix {
// ...
}
See Selectors and Nesting for information in regard to how styles should be overridden
Classes
Class names must follow a few rules.
Must be all-lowercase
Words must be separated by single dashes
As short as possible, but as long as necessary
Don't abbreviate words carelessly
Name things consistently
Meaningful description of the elements that should use it
Styles shouldn't need to be nested more than three (four at worst) levels deep. This includes pseudo-selectors. If you find yourself going further, think about re-organizing your rules (either the specificity needed, or the layout of the nesting).
Ideally, you should keep your stylesheets separated in different files. Either of the approaches below is fine. The former is prefered.
Use a single all.{styl,less,scss} file and have it @import every other file
Use a build tool to glob the styles directory
A few rules apply.
Each component should take up its own file
Styles applied globally to tag names, see Tag Names, should be kept in a single file
Where possible split presentation-specific styles from layout-specific styles. See below
Presentation-Specific vs Layout-Specific Styles
Presentation-Specific styles are those that only alter the visual design of the element, but don't change its dimensions or position in a meaningful way. The examples below are presentation-specific.
Rules such as color, font-weight, or font-variant
Rules that animate other properties
font-size is not considered a meaningful dimension change
padding may fit this category (loosely), but only if box-sizing: border-box; is in effect
max-width and max-height may fit either category, but it's generally reasonable to consider them presentation-specific
Layout-Specific Styles are those that change the dimensions or positioning of DOM elements. These are mostly layout-specific.
Rules such as margin or padding
width, and height
The element's position
z-index, definitely
Where possible, it's suggested to explicitly split styles into these two categories. The explicit differentiation could be made in a few different ways.
(bad) No differentiation
(decent) Layout-specific first, presentation-specific later
(good) A line-break between both categories
(better) Split in subsequent style declarations using the same selector
(best) Declaring the rules in different files altogether
If the value of a property is 0, do not specify units
The !important rule should be aggressively avoided.
Keep style rules in a sensible order
Compose styles to dissipate the need for an !important rule
Fine to use in limited cases
Overlays
Declarations of the display: none !important; type
Keep z-index levels in variables in a single file. Avoids confusion about what level should be given to an element, and arbitrarily-high 999-style values
Use hex color codes #000 unless there's an explicit need for an rgba declaration
Dislike magic numbers
Avoid mixing units
Unit-less line-height is preferred because it does not inherit a percentage value of its parent element, but instead is based on a multiplier of the font-size.
If you are reading this, I salute you. You're almost as boring as I am. I'm more boring because I actually wrote the damn thing. It's not a contest, though.
A few rules apply to media queries.
Settle for a few (2-3) breakpoints and use those only
Don't wrap entire stylesheets in media queries
Instead, modularize media queries wherever possible, keep them relevant to the components
Approach your styles in a Mobile First manner. Generally you add more things as you get more real estate. Mobile First logically follows
Vendor styles, such as those required by external components are okay, and they should come before you define any of your own styles
Languages
Some rules apply to stylesheet, regardless of language.
Use a pre-processor language where possible
Use soft-tabs with a two space indent
One line per selector
One (or more) line(s) per property declaration
Long, comma-separated property values (such as collections of gradients or shadows) can be arranged across multiple lines in an effort to improve readability and produce more useful diffs.
Comments that refer to selector blocks should be on a separate line immediately before the block to which they refer
Use a plugin such as TrailingSpaces in Sublime Text to get rid of trailing spaces
请发表评论